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.