Is Your Project Schedule Really Driven By Your Requirements?
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?
I do not want to discount too severely using actual data as part of the estimating process, but to rely too heavily on it under the assumption that the past will repeat itself is dangerous. Take for example rolling the dice. It has six sides and 1/6 probability of landing on any of the six numbers. If you roll it six times, you will not likely get each number once, even though the law of probability says so. So, in any one’s limited experience, whether it is your thirty years or my twenty, you will likely not have the kind of data that provides a true distribution of a task. Your actuals can be extremely skewed. Now, if you had a few hundred years of experience, you have my attention.
“…variation is often a lot less than we think it will be….” I do not know how to even address that rather generalized statement. Can you show me how you arrived at that conclusion?
Great effort certainly helps bring a schedule in on time. When it does not come in, we can certainly find all kinds of external reasons. When it does, it was due to great effort. That, Bruce, is a human bias. We have a tendency to ignore the stochastic nature of performance.
Average means that 1/2 of the projects will come in late. It does not mean that 1/2 of YOUR projects will come in late. Who knows why, perhaps you are a super project manager, very lucky, or who knows. When someone boasts that they “never” have a late project, the question as to whether they budget way out on the distribution must be answered.
I am all for simple. But I know what I don’t know, I don’t know what I don’t know, and I know what I still need to learn and understand. And these things have an effect on my projects everyday.
You discuss a project time as if there is only a single-point estimate and you stay silent on the stochastic nature of work, which ends up in some type of a distribution. To be surprised that you ended the project sooner than your estimate is surprising of and in itself. And to assume that, well, you did it once so you will likely do it again is unsophisticated to say the least.
Looking at your project team’s past performance is a red herring. Again, performance is largely stochastically driven, too! Expect their performance to degrade the next time out. Always plan for average performance because that is most likely what you will get.
David,
You hit upon why this site is called “Tools That Work.” It helps to sort out the theoretical or the thought exercises from what has really worked in a wide array of situations.
So first off, past performance has done well – for whatever reasons – over my thirty years of experience. So the question becomes “why?” given that things should vary based upon some underlying distribution. The question itself leads to finding the answer, and that it by measuring – objectively – the actual performance, including the variation, to see what happens in actual projects (see for example: http://pmtoolsthatwork.com/you-can-know-if-your-project-estimates-are-accurate/).
Not to our surprise, because it is what we’ve observed, the variation is often a lot less than we think it will be – or even think we remember it being. One reason for this is summarized in this article. Another that I mention periodically is that when we give people reasonable schedules (i.e., an average instead of 20% below the average that no one has ever attained) they work hard to meet the schedule – and do so. In a sense, the hard work on an attainable schedule (such as an average) overcomes the variation – because the variation is usually not that large especially in a mature organization (people+process+tools). Supreme effort *does* make a difference when the parameters of a project are realistic (as confirmed by past performance – not what we think is realistic). Working hard, extra effort, surging – all can make a realistically planned project successful. Using past performance is one way, a very reliable way, to realistically plan projects. Hard work will rarely, if ever, make a poorly planned projects successful. Every failed project certainly included a period of time of really hard work to try and save it – and still failed.
Next, I often hear, planning for “average” sounds pretty lame! Think about it. An average implies what? That we’ll meet only half our project schedules – we’ll miss half! So an average is aggressive. Let me say that again, an average is aggressive. But in actual practice, in real projects for over 30 years, half our projects didn’t come in late. Almost none of them came in late (for more on this, see http://pmtoolsthatwork.com/is-your-project-on-time/).
Finally, I’m always intrigued hearing the “unsophisticated” observation. Strangely, many people are suspicious of simple things they do understand but will readily sign-up for complex techniques they don’t understand. This is a reason why many really good techniques are not executed well (both simple and complex, see http://pmtoolsthatwork.com/project-management-on-steroids-kick-the-habit/).
Will this stuff work for everyone? I don’t know. But I’ve not worked with anyone where this did not improve their on time performance – dramatically (yes, they were struggling organizations in the first place). What is nice about these techniques is you don’t have to believe me. A manger can do this estimating in parallel, with little effort, and compare it and their current planning and see which one is more predictive of what actually happens.
Thanks for the pointed comment!
Bruce