Be smart, see dependencies
Problem (Estimations/ Price/ Budget).
During my many years of dealing with IT projects I often encountered and struggled with ESTIMATIONS. As the Project Manager of the inhouse DevOps team responsible for the whole SDLC; a Project Manager/Product Owner responsible for subcontracting other suppliers or people, and finally as a PM of the outstandingly talented, global contractor UIG Studio; the question is how much - BUDGET. Surely knowing the particular scope, and that the risks defined cost depends on the quality and time; which is true within all dimensions of this triangle, the question remains on how to estimate this price. Besides the obvious reason related to the Client’s wallet, the way of PRICE estimation has a deep impact on the perception of the Company trying to win the contract. If you can legitimately count the number of hours foreseen for the project, you will probably have the understanding of it and hopefully, you have similarly succeeded on your portfolio. Yes - it’s that essential.
IDEA.
Here at UIG Studio we adapt our own three leveled patch for the project quote. In brief, the first stage is made at first glance with limited pieces of information that are based on similar completed projects with some assumptions and preconditions. This is where we put in wide hour ranges and ask questions. Upon receiving feedback after the first stage, we then move on to the second level where we have 4 independent numbers, in which two are then taken from similar projects that are best matched for technology and functionality. The other two numbers are then estimated by experts with both an optimistic and pessimistic approach. During this stage, additional questions and doubts often occur as a result of expert analysis and product projecting. Finally, having gathered second feedback, we can deliver the last estimation, the UIG Project Matrix, in which we place a high level project plan with the main items referring to functionalities, pitch with inspirations, and direction of our thoughts and impressions. So far it’s nothing special, many firms have their own methods and approaches for some processes. By the way, is the estimate the process or a small project? We do however, have our Mysterious Ingredient ;) and we use it in every stage of the project estimation process.
Chart 1
Here you can find the examples of distribution between the Front End Development and UI/UX Design:
What is this Mysterious Ingredient, you ask? In brief, it’s based on lessons learned and the experience of projects completed. It’s where we can understand the relationships or dependencies between some elements of estimations and between all accomplished elements. Obviously these facts have to be proved in as many cases as possible, the more the better. So what are they? Examples include: Front-end works vs Back-end works, Design works vs Front-end works, Design <Wireframe/UX> works vs Design <UI> works, Design <Wireframe/UX> vs Front-end works and so forth. For all those pairs, we can find a percentage distribution taken from the hours spent within completed projects. The Mysterious Ingredient method is as flexible as the author is creative; we can use it as a phase in all of the three levels of the UIG estimates or even instead of the first. This approach is especially deserving of a situation when one of the project activities is always or usually well estimated. For example, when our efforts estimations for the whole Design works is usually proper, and especially, when UX research and Wireframe task are almost always hitting the target, then why do we not take these numbers as certain foundations?
Chart 2
Here is Wireframe vs Whole Design:
In some cases we can build the whole chain for the first level estimation starting with the Wireframe estimated only. Wireframe -> UX design -> Entire Design -> FE development -> BE development -> Entire project … Simple right? Yes, but what we really need is a proven track of completed and accomplished projects and reliable calculations showing that this percentage distribution and relationship between elements are reliable and reasonable.
Chart 3
Here are a samples of the chain which can be used as the first step of the estimate, support for detail estimations, or a tool for risk detection or project monitoring. You can start with one simply number of wireframe, design or Front-End.
Finally, what are the other PM activities where we can also apply this mysterious ingredient? Almost everywhere, the first example in the second level of the UIG studio estimation patch is where we use two scenarios, both pessimistic and optimistic.. Comparing numbers (given by experts for those estimates) with our well known Mysterious Ingredient (based on the previously checked and completed project - as you may remember) we have an excellent but rough project risks analysis. We can see how the numbers are changing within particular scenarios and how our distribution reacts .. the second example,project monitoring, is where we exceed planned budget for one entire task, and knowing our Mysterious Ingredient for the ongoing project tasks, we can assess where further overcost can be placed.
SUMMARY:
PM daily work consists of 80% improvisations and 20% numbers, both taken from the lessons learned, ventures completed, failures in general: experiences …
Projects are unique in that they require some improvisation; because, they are unexpected and so you much be flexible and constantly improvise. However, when you have the ability to use your previous experience and verified, battlefield-tested routines or just numbers, you should make sure to apply them.
