At work this week I needed to develop an estimate for a front-end development project. Since creating a full project estimate is not something I do very often I decided to review the chapter on estimation in The Art of Project Management by Scott Berkun, a book I read several years ago. Below are my main takeaways.
Rule of thirds: design, implementation and testing
Scott’s general rule of thumb here is that for every project or task it will take the same amount of time to do the design as it will take to do the implementation and likewise the testing. So if a project will take 2 weeks to implement, then you need to factor in 2 weeks for design and 2 weeks for testing. I think this one is important because when coming up with an estimate it is very easy to focus only on how long it will take to implement. Testing is an aspect that is easy to forget or grossly underestimate when building a project plan. And taking time to carefully design software can save a lot of wasted effort down the road.
Divide and conquer: big schedules are many small schedules
The more a project estimate is broken down into smaller and smaller tasks, with estimates on each task rolled up into the overall estimate, the more accurate it will be. Another important point here: the length of the small schedules should correlate (inversely) to the volatility of the project — more volatile == shorter small schedules. Maybe another way to put this: the more unknowns there are, the smaller the small schedules should be so that the plan can be adapted at each iteration.
Good estimates require good designs and experienced engineers
The quality of designs and the maturity of the engineers are two very important factors that affect the quality of estimates. The main point here isn’t so much that you have to have the best designs and senior engineers to get good estimates but rather understand that estimates are probabilities and the quality of designs and engineers are going to impact those probabilities. A good design, especially up front, may be hard to develop if the project itself is meant as a learning exercise. That’s okay, just recognize that any estimates for the project are going to have a low probability of being hit.
Be optimistic in vision and skeptical in the schedule
Honestly, I’m not sure how to put this in practice, but I like this idea. On many projects the schedule is the only or the main overall description of the project, so it can feel disheartening to build one that is conservative when there is excitement for the possibilities of the project. I think having a vision for the project that is separate from the schedule is a good idea, but I’m not sure I’ve seen that in practice. If they are separate then I think you can apply this advice.
But mainly I’m including this piece of advice because the schedule does need a high degree of critical thought applied to it to make sure it is realistic. And the schedule should not contain all of the hopes and dreams of the project.
Take on risks early
When you look at the sequence of tasks for the project, there may be a part that isn’t needed until 80% through the project. But if that part is for something where there are some unknowns, it makes sense to move it up in the schedule so that any scheduling surprises can be absorbed into the scheduled. For example, if your team hasn’t developed a mobile app before and that’s one of the deliverables, it would make sense to start work on that as soon as possible in the project.
Invest in good design
Build prototypes. Spend time on teasing out those unknowns before coming up with a schedule. Where the specification lacks the necessary detail to give an accurate estimate, ask questions and dig to get answers. The more that can be known up front, the better the estimates.
Conclusion
These were all good reminders for the project I’m estimating at work. The rule of thirds reminds me that time will be needed for testing. This is a second phase of the project, the first phase built a prototype and that does help with having a good design since there is already a prototype as a reference point. There are some risks such as full text search of timestamped transcripts, with deep linking to audio and video, so we’ll likely want to tackle those early in the project. Finally, I appreciated the reminder to ask questions about the specification to get the kind of details that help build a stronger estimate.