Sometimes it is the team process and not the project requirements that determines a project’s schedule.
I talk a lot about getting the schedule right as a key project management tool. What may be a bit unusual is I don’t emphasize figuring out the schedule by looking at the requirements of the project and then estimating how long it will take. Instead, I first suggest looking at how long it has taken us to do past projects of this kind and then using the average of these past projects to estimate how long this current project will take. This strikes many as odd and maybe even backwards. (To check how good our current estimates are, see “you can tell if your project estimates are accurate.)
The bottom line is that projects are carried out by multiple teams each doing their part of the effort (e.g., software development, IT, consumer electronics, etc.). While the project details change each time, the team and their people+process+tools pretty much stays the same. The reason why the past performance average schedule is often more reliable than a bottom up schedule based upon the requirements is that the dynamics of the people+process+tools of the team often overwhelms the requirements of the project. (For more on how the process can be key, see managing software is a repeatable process.)
Let me provide one example that startled me when it happened but illustrated well my point. We had been planning a small project for some months. We had in fact gotten rave reviews for how well we were planning our project. The organization, needing its next “big thing” decided to leverage our project into its mega project to produce its latest and greatest products. This leveraging meant that we would triple the number of products we would produce and we would increase the functionality in those products by 450%. We were then told the schedule had to be two months shorter than our current, much smaller, project schedule in order to hit the market window!
Great, I thought. Total disaster. I did my analysis and looked over the addition of the new requirements and products. I concluded that not only couldn’t it be brought in by two months but in fact it needed to be pushed out by three months (so a total of five months longer than wanted) because of the addition of so many new products and features in the project. I’m pretty confident of my analytic ability to calculate and estimate these kind of things so I was startled when we ultimately delivered the first product of this mega project in the month we originally estimated our simpler project would have been completed (but two months later than management wanted).
How was that possible I thought? OK, the quality of the product was not great. Good enough for the customer to say they’ll take it (it turned out to be a big seller with consumers) but we struggled for years with projects on this product line because the initial software quality was so low. We also had to delay our most profitable product in the mega project, again due to low quality. When I looked at the actual record and what we achieved, it was literally the same original project schedule but with three times the products and 4.5 times the requirements.
I had already observed from the past that our new product projects took a fairly consistent amount of time, about 18 months. So if this had been planned from the beginning with this many products and requirements, what would I have estimated as the schedule? Well, we had just completed a mega project and had real data, so I compared that to the previous data I had on completed projects. I characterized my conclusion to a software development director as “We are like a Clydesdale draft horse. You can’t make us run any faster, but you can load a lot more on top of us than we had suspected.” (See related, its the project management schedule, stupid and you don’t always have to panic in a crisis.).
I had also previously noticed that with smaller projects, usually an updated version of an existing product, that the time to deliver it to market was certainly not proportional to the amount of new requirements going into the project. We clearly also had a minimum period of time it would take us regardless of how big or small the project was. (For more examples of this minimum time notion, see avoid these project planning trade-off mistakes.)
The conclusion was that while the requirements of the project impacted what we did, they did not significantly influence the total time it would take to complete the project. Instead, how long things were taking was more a function of the organizations’s people+process+tools, and these had a bit more capacity in them then we had thought. We had assumed the inability to hit schedules (that were in hindsight compressed and unrealistic) was because capacity was limited but instead it was more that the speed through the development process had an upper bounds.
When planning a project, look both at the requirements of your project and at the performance of your teams that will work on the project. The details of the teams and their past performance may have a bigger impact on your estimates than the requirements of the project itself.
Is your team’s schedule driven more by requirements or more by its internal way of doing business?