Hi, this is Scott Roth. I am new to Armedia and Armedia’s blog. I have been watching the past few weeks as Dave, Tim and Judy have shared their cutting edge technology lessons learned with you. Personally, I have found these posts incredibly insightful and had to scurrying off to Google more than once to figure out what exactly they were talking about. Well, this post won’t be that technical. In fact, this post won’t be technical at all.
I’ve been in the software development business for 20 years. Over the course of those years I have been involved in a lot of proposals, project plans, project re-plans, and estimating exercises. I have used a variety of approaches and processes from very rigid, overly-documented approaches, to looser, Agile approaches to develop estimates. One thing I have seen, regardless of the approach, is that project plans rarely reflect reality. I have observed three frequent oversights when developing estimates that always seem to bite project teams once reality meets the plan.
- Developers will spend 5% of their time every week on project management activities. Time and budget are not usually allocated to developers to attend status meetings or company staff meetings, write input for the project manager’s weekly report, mentoring, or help with business development efforts, but it happens. So, figure that 2 hours of every week will be consumed by activities of this type.
- Developers (especially those on the customer site) will spend another 5% of their time attending impromptu meetings,
attending ad hoc JAD design meetings, giving demos, supporting the project manager or customer, or dealing with customer drive-by meetings.
Again, these are not activities easily anticipated or scheduled, but they occur all the time, and can negatively affect project performance. Figure that 2 hours every week will be consumed by activities of this type.
- Developers new to a project need time to get up to speed on the project, the requirements, the environment, the tools, the processes and practices, the rhythm of development, and the project culture. Don’t expect developers — even senior, seasoned developers — to be 100% productive from day 1. Expect that it will take at least 40 hours for a developer to settle into the project before he will be as productive as the rest of the team. Schedule tasking accordingly.
I know it doesn’t seem like much, but over the course of a 5 week sprint, a team of 5 could lose 100 hours to these otherwise “invisible tasks”! And, adding team member #6 will not immediately improve performance.
I mention these things because when I (and I suspect most project planners) sit down to estimate development times, we tend to estimate in a vacuum. What I mean is, when asked how long it will take to develop Widget X or complete Requirement Y, we tend to give estimates that assume a perfect environment, the steady state of the universe, and that developers never get distracted by other project activities. Or, that developers can be dropped into running projects and be 100% productive from the word “go”.
Hedging your task estimates by 10% and easing new developers into running projects can give your project plans a little buffer and more accurately reflect reality. This advice will certainly not be popular with project managers or business development folk who continually strive for lower costs. However, it may be to everyone’s advantage — yours and your customer’s — to produce a realistic project plan that can be met, as opposed to apologizing half way through the project that you have run out of resources for no ascertainable reasons.
Thanks Scott. Unfortunately, we have no time to hedge the project or ease the new developer into the project. Management has agreed to an aggressive schedule just before the holidays. Matter of fact, I have to get back to coding. Seriously, you may want to increase it by 15 or 20% depending on the complexity of the technology, seniority of the team, experience working with client, etc.
I rarely heard a team say they’ve total over estimated a project. 🙂 Maybe that’s because they do not win the contract in this price sensitive market. Unfortunately, price generally trumps superior technology solution. Buyers rarely factor in their cost to manage the system or the cost of failure.
Agreed! Further examples of how reality and estimates rarely agree; thus deal making is an art and not a science. There are plenty of other factors to consider here also, like: contract type, management reserve, risk sensitivity, etc. My point was that when making estimates, there are some “invisible” costs that can add up if they are not identified. By identifying them, estimators can hedge a little. There is no garauntee these hedged estimates will make it past management review or into the final bid, but at least people are aware they exist. Thanks for your dose of reality and reminding us that estimating and project planning can’t be done in a purely technical mind set.