Ok so we have talked about iterative development, how to implements it then we got on to estimation and this post continues in that path to make it possible for you to provide reasonably realistic estimations and also talks about how to handle the customer when it comes to tight situations.
So you and your team come up with an estimate for the whole project and guess what, the customer thinks its way too long. If you think of it in the customer's perspective what he/she wants is to get that competitive advantage that they perceive the software you are developing will produce in the market before any of their competitors do. We all know what kind of a competitive world we all live in so your customer is no exception. Of course there are few things you can do at this moment.
First of all if you look back on how we made our previous estimation you could see we didnt take into account other overhead such as time spent on installations, updgrades, vacations, sick leaves, paper work etc. These all take considerable amount of time and you need to account for this in to your project estimation. Ok so now you will be asking how the **beep** are we gonna do that. Based on what? Ok chill chill. Variation to the rescue. Variation takes into account all the things that were stated before and counts for that. What is recommended is to have a Variation of 0.7 for a new project team. So how do you calculate the actualy number of days a developer will take to complete work within an iteration with the variation taken into account. Following is the calculation on how to do that;
1(the number of developers) x 20(project iteration size) * 0.7 = 14 days(The actual amount of time to complete the work within one iteration)
Multiply this by the number of iterations required for your first milestone and then you will get a realistic value on how many days are needed to complete the work. So now you have a realistic amount of days which your team feels confident about. Then you go to the customer and negotiate on what to do if this value is greater than the one he/she specified.
What you can do in this instance is lay down your user stories and ask the customer to first of all prioratize them according as they deem appropriate from high to low. You can give them a variation of values to base them such as 10-50 where 10 being the highest priority and 50 being the lowest.
After this is done you get this priority list and try to assign it to your iterations and see if you can get it everything in for the time specified. Something to note here is to assign the user stories according to the highest priority to the lowest. And one more thing is while doing this you should focus on only keeping your baseline functionality intact. Baseline functionality are the smallest amount of features that are needed to give a working solution to the customer.
With this amount still if the estimation is higher than what the customer expects then you have to sacrifise some of the user stories and push them back on to the next mile stone. And sadly you will have to notify the customer of the reality of the situation. One thing to note is to specify to the customer on what basis you came into this estimation. Then they will in most cases understand where your coming from. But thing to note is to always be upfront and honest to your customers because customer loyality once lost can never even be regained as i see it. What you have to specify to the customer is that the other features are not scrapped out completely, its just that they will only be available for the next milestone. If the customer still wants all that functionality then the only possible way to do that is by extending the number of iterations in your project which will eventually bring up the project deadline. But it is always the case where the customer will agree on scrapping some of the fuctionality until the next milestone.
In the end you have a realistically possible project due date that you feel confident about. And after all its better to under promise and over deliever and the vise versa. Hence you should be truthful about your estimation rather than building the project plan according to what the customer wants it to be which would only pave you a nice big path to failure :) .......
Well happy estimating and keep your projects in line.... In line of success ;)
No comments:
Post a Comment