What is Project Delivery Estimation? 
 
At the outset of project plan, senior management or customer is always asked to come up with an answer of the most inadequate question? “What is the delivery date or completion date of this project?” In fact this question can be put in several other ways, but main aim will remain same i.e. to know the project delivery timelines and schedule.  
 
Now next question arises how can one give the date? The delivery date of the project is dependent on the amount of effort put in. Hence very rudimentary equation is Delivery Estimation a Effort Estimation 
 
 
I guess nobody should have doubt on this basic equation. But again question is how one can conclude the final date of the project completion based on the amount of efforts. Actual efforts will be in units of amount software project completed per unit of time (example: amount of Line of Code per Day or per week, amount of Function Point per day or per week etc), hence in case somebody estimates at the beginning of the project as to how much exact effort is required to complete the project, one can give exact date of completion.  
 
To elaborate lets assume that a software project requires implementation of 5 functional points to get completed and our software team can complete 1 FP per week (). To give delivery date is anybody’s guess hereafter, that is, after 5 weeks from now customer can get the product if one FTE is deployed.  
 
Are there any techniques to do Effort Estimation? Yes, there are. Some of the effort estimations techniques are:- a) Parametric Approach:- This approach assumes software development is kind of automatic and fully sequential process. Once efforts have been calculated developer will follow strict controlled process and will eventually deliver the product.  Main methods used in this approach are a) LOC (Line of Code method like COCOMO) b) Function Point Analysis. However what this approach fails to see is human factor i.e.
 ? People who are coding are not robots or machines  ? Every developer is unique and has unique style of coding ? Motivation curve ? Learning curve ? Risks ? Technology challenges etc. 
Page 2 of 7 
 
b) Top-Down Approach:- This approach considers that Goal of a project is at least visualized if not crystal clear. Hence based on the rough visual goal, timelines are exploded and drilled down to tangible and atomic goals. All goals are mainly achievable in few days to maximum in a week, hence while completing and integrating small goals, big goals can be achieved.  Best part of this Approach is it gives human touch to provide estimates of their own efforts. However it fails to see  ? future uncertainties,  ? risk,   ? technology challenges etc 
 
c) Bottom-up Approach:- In this approach, the goal is so vague that it is almost impossible to visualize final outcome. Hence while completing small initial goals, which are clear, main objective is achieved. This approach may include iterations and incremental development. Hence based on the number of iterations and incremental integration estimate can be given. Again the major limitations of this approach are same as Top-Down approach, however major benefit is, no two separate Goals of two separate projects are same and it may happen that the way Project has been conceived Goals look same however they are so different that not even same technology can be used.  
 
d) Analogy Approach:-  This is most realistic approach in  the sense that if we have delivered same product before we can estimate on the current project and provide a good estimate of it. The point to be noted here is no two projects are identical, at least the time dimension has to be different, in worst scenario, the whole team is new hence old learning curve and best practices may not be utilized. 
 
What is so challenging about the Delivery Estimation? 
 
Just to make sure that we still know the subject of this white paper: The question is why the most challenging and intriguing stage in project management is Delivery Estimation. The matter of fact is everybody (from Developer to Program manager) tries to give his or her best and most accurate dates and still in most of the cases it is not achieved.  In fact ask anybody, they will know the means and ways to do the Project Estimations however upon asking if they have ever done the correct estimation, almost 95% will answer ‘NO’, and for rest, they have achieved it because either they stretched the work (as work was completed before time) or they have stretched the developers/testers efforts by overtime or staying late in night to meet the committed deadlines.  
 
So what is common across all the project effort estimation techniques, is no technique is foolproof and there are work around to cover up missing or hidden efforts and in case you find  that you are about to miss your timeline, then you 
Page 3 of 7 
obviously forgot to read the fine printed disclaimer with the effort estimation technique. Also take any project, success rate to achieve the committed timeline is always challenging, so why there is so much fuss in estimating correct and exact delivery estimates. Why effort estimation in most of the cases is inaccurate?  
 
The answer lies in understanding SDLC. A conventional SDLC will involve below stages: ? Requirement Stage ? Analysis/Design Stage ? Implementation/Coding Stage ? Testing/Debugging Stage ? Project Closing Stage 
 
As it can be easily seen that above waterfall fails to deal with so many intermediate stages (and in most of the organizations these unlisted stages always goes unlisted and most shocking thing is that everybody is familiar with the importance of these stages), what I am talking about?  
 
? Can you imagine any project without brainstorming sessions about the functionality achievement, even we put extra time for documentation, but do we actually put separately time consumed in imagining the code to achieve functionality. ? Do we really count time when we actually optimize our pre-written code? ? How about Learning curves. ? Is simple functionality really simple to achieve? ? Are we sure that whenever attrition will happen, new team member can start from the point where one has left? ? Do we all have same coding speed? ? What about friction within the team? 
 
This list is endless.  
 
However the main point I am trying to make is:- 
 
a) Software development is more of art, it is science to the extent that we have programming languages and compilers, and however the people who are using them are imagining and dreaming whatever they are coding. 
 
b) Everyone goes through its own unique learning curve, even if he has already worked on similar kind of project before. Simple example will be, even if you have to change the GUI color to launch old product as new one, one has to develop a great aesthetic taste and these cosmetic changes consume time say in color matching. In other words, irrespective of the complexity or simplicity of deliverable, learning curve cannot be avoided, but yes it can be minimized.  
Page 4 of 7 
 
c) Development is more of a teamwork than individual contribution (only exception I guess where single developer is doing everything from requirement gathering to delivery, but we all know it seldom happens or never) and there will certainly be ego clashes, especially while testing somebody’s else code, so managing that too consumes time. 
 
d) Rework time. There is excellent saying in software arena, “Do it correct the first time”. This simple means Do whatever possible to deliver bug free code, however, it rarely happens as chances of error increases with increase of LOC’s. But what is more challenging is developer himself most of the times revisits his code and does the corrections and no body counts this time. 
 
e) Lastly the Parkinson’s Theorem:- Work always fills all the allocated time. It means whatever time you allocate for the particular task, it will get completed within that time only, not sooner. Even if it gets completed much before the timelines, it will take extra time to get optimized, code modification, making the functionality much more generic or used in knowledge gain. 
 
 
Does it mean Estimation will always be elusive? 
 
Yes it is difficult no doubt about it. However there are ways to make it more accurate and less challenging.  
 
First let’s ask what makes a Project Manager or whosoever gives the estimates to provide a good estimate: 
 
A. Realistic: - He has to be realistic that everyone in software development has its own unique learning curve, there are hidden challenges like attrition, illhealth of team member and even technology might not be tested for the committed functionality. Henceforth he should make genuine efforts in providing estimates however it should be buffered up with risk at least which can be easily identified. 
 
B. Courageous: - He should be courageous enough to make everybody know the real picture as why estimates cannot be rigid.  
 
C. Communication:- Communication is the heart of any project, in case of integrated development if one team member is not disclosing the completed functionality, it may held up other team members who require that functionality as a base to work on, 
 
D. Motivator:- There are times when developer is surrounded by bugs, source safe crashes and source code is hard to recover. Despite thousands of 
Page 5 of 7 
contingency plans if thing has to go wrong it will (Murphy’s Law). Hence if the leader gets disheartened, his team might get lost mid way. Always try to safeguard however always be prepared for the damages too, there are million of bugs in software which are still to be discovered, (and you may have hard luck to get one noticed). Bottom line is a) Positive thinking b) minimizing Murphy’s law  c) True support and faith (Nobody without an exception tries to sabotage his own work) can do magic. 
 
E. Leader:- Everybody follows the leader, hence always take lead to encourage the developer to submit code as soon as he/she is done with that, it will help in reducing the Parkinson’s Law.  It means Leader should raise the alarm whenever he/she reaches the goal despite milestone date is a week after, because estimation is not a real thing.
 
 
Now let’s discuss why the estimation is far from real
 
 
In the beginning of the project, every objective or business requirement is just an imagination it is somewhere listed in somebody’s dream or may be in some document. Once requirement takes the shape of design it gets clearer, and likewise once developer starts to shape the requirement into implementation uncertainties starts to fade away. Hence estimation is associated with 
 
? Uncertain Goals ? Unpredictable Technologies ? Unpredictable shapes till it gets delivered to users ? Developers/Analyst/Designer imagination
 ? Customer Imagination
 ? Uncertainties of several kind ? Risks of unknown dimensions 
 
Is it possible to give estimates? The answer is ‘Yes’, however I like to take example of car and distance to be covered. Though we know that Distance between city A and B is X miles and average speed of the car is Y miles/hour, can we really commit that we can reach city B from A within X/Y hours. NO- we cannot say we can reach within X/Y hours however we can tell minimum we will take X/Y hours. How this helps, in several ways like 
 
a) It will prepare us for unforeseen scenarios like flat tire, gas filling etc 
 
b) It will help, if somebody at city A is waiting to meet us, to give realistic picture that minimum time can be X/Y hours and in case it will take more He/She can call you on mobile and ask for next probable time. 
 
Page 6 of 7 
 
Now suddenly why I included the conversation on mobile, because you can clearly tell there is some mishap that happened and you may take time. It can hold true in project delivery estimates also. 
 
c) As the place where you have to meet is unexplored and you have to search for it, you can revise your estimate time, and remember that this learning curve is irrespective of the speed of the car. 
 
Now the learning from the above analogy:- 
 
a) Learning curve cannot be avoided 
 
b) Risks can be minimized however you have to be prepared for them and they can affect timelines 
 
c) Communication is the key because lot many people are dependent on completion date of your project. 
 
But how to make delivery date a success:- 
 
a) Iteration and Incremental approach:- Always revise timelines on the basis of what you have achieved and what can be the probable timeline to achieve next milestone. Hence delivery date is invalid till you actually achieve it. It means to give rigid timeline is suicidal, always put your assumptions to it and give a range not fixed date, like project can be delivered within first quarter, don’t give date like 26th Jan. 
 
b) Always keep track of learning curve and document it as much as possible, it will be certainly useful in giving next delivery date. 
 
c) Document what all risks you have faced and how much time they took to mitigate, it helps you move forward and in case such risk arise again you can know time it took. 
 
d)  There is a term in agile planning- Velocity. Velocity is time taken in delivering functionality, LOC or other unit of software. This will help in parametric approach to estimate overall timelines. 
 
e) Don’t let Parkinson’s Law to take over your project allocated timelines, make at least internal milestone dates. Come up with small yet achievable timelines after taking buy-in from whosever is responsible for delivery. 
 
f) Keep team motivated and don’t overlook complexity of even simple functionality till it get coded is delivered. 
 
Conclusion 
 
Delivery dates are hopeless unless they are constantly monitored and people who are responsible for them are not courageous and communicative. There is no magic wand despite innumerable approaches for estimating project delivery date. However things are not impossible and if somebody really dares and put extra care it can be achieved with minimum error. 
 
Only courageous managers know the rigid deliverable dates are far from real till they achieve them with the help of highly motivated team and keep customer delighted whilst following not one fixed methodology but tweaking them too as per their need and use.
 
 
Agile Planning – S Kan
 
 
Page 7 of 7 

Comments powered by CComment