Avoid This Project Management Schedule vs Requirements Trade-Off Trap!
Your development team is telling you it will take 24 weeks to do product development.
You only have 20 weeks to your product launch window, as reflected in your project management tools. After that, the product won’t be competitive.
You have 50 feature requirements going into this product.
So what do you do?
- Push hard on the product team to bring in the schedule four weeks. The last time you succeeded at doing this they missed their schedule by more than the amount of time you asked them to shorten it. Your explanation of “but they promised!” did not win you any points with senior management.
- Accept the schedule as 24 weeks and go inform your bosses. The guy before you did this — which is why you now have his job.
- Reduce the requirements by eight features. This reduces requirements by 16%. You tell development they can now reduce their schedule by 16% which now gets you 20 weeks. Development’s response is that the schedule remains the same at 24 weeks.
What? You were just sure that you finally had a solution with approach #3. You spent your weekend working around the clock finding those eight features. They were significant features, not small features. You had also gotten the business manager to agree that giving up just these eight features would not significantly drop the expected product volume and margins.
Annoyed, but determined, you ask the development manager what features could be dropped to get it down to 20 weeks of development. You also realize you should have asked this first. Now you’ve told the development manager that those eight features were not really needed — when all along you’ve been insisting that *all* the features were needed.
The development manager tells you four things:
- While we have estimates for each feature, they are only just estimates with a lot of unknowns.
- What we do know is the typical feature development averages eight weeks.
- We also know that the standard deviation is also eight weeks.
- She gives you a bar chart showing times to develop a feature that looks eerily like the hill your cross country coach made you run each Friday in high school.
She says this information allows her to estimate overall schedules very accurately. Her Six Sigma Black Belt adviser — who just happens by — cringes a bit, but he admits it models pretty well the actual past performance in this environment. (See Get The Schedule Right! for more on this type of approach. Also, standard deviation is being used in a somewhat non-standard way to calculate when about 95% of features get completed. We periodically verified the accuracy by actually counting out to the point where 90-95% of past features were completed.)
You stand there feeling lost. Recovering quickly, you say in your most assertive project manager voice: “well, so what?”
She asks you what is three times eight. You, feeling like being back in elementary school, spit out: twenty four! Which you realize is the number of weeks in her proposed schedule.
She asks you what is the percentage of past features, based upon the chart of times, that completed development in under twenty four weeks? Luckily, marked on the chart are some lines showing eight week intervals and the percentage completed in each interval. You eyeball the chart, rapidly add them up and say gleefully “looks around 95%!”
Finally she asks, if only 95% get completed in 24 weeks, then of your 50 features, how many would we expect to be completed in 24 weeks? You are getting the hang of this so you say “47.5 features!” You did win the math bowl in 10th grade after all.
She looks at you closely now. Waiting.
Your mind starts to spin. You realize what you just said. Not all features are completed at 24 weeks and you want them all in 20 weeks. Oops. Ah ha! But my 50 features are different you think. Um, but why? Yes! Another great idea: I’ll challenge her to “prove” that my 50 features will be like the previous ones — otherwise this doesn’t apply! Uh oh. If this doesn’t apply, then what do we use? OK, back to the individual estimates. We could just drop off the features that take the longest, but I needed some of those. We were hoping their individual schedules could be shortened by some of the folks being freed up by dropping features. She’ll just remind me that the estimates are just estimates with a lot of unknowns. Then why do we make estimates on individual features? Doesn’t individual feature estimates decide the overall development schedule? What would happen if one of those individual estimates was longer than 24 weeks? But thinking about it, she was already planning for a couple of features to possibly not make it on time. In the past, we’ve rolled out late features after the development deadline. It worked fairly well when there were only a few. Great. So what do I do now? If I had known about how long things were really taking I could have engaged the development team earlier. Well, if my boss had assigned this to me earlier I might have. I wonder if he knows about this? Oh! I forgot. I still have my ace from this weekend!
“But I now only need 42 features!” you tell the development manager.
She asks: “How much is 95% of 42?” You are wary now. That works out to 40 features. Forty features in 24 weeks. Not in 20 weeks. You are still at risk with two needed features even at 24 weeks. Jeepers. How many features do you have to drop to get them all in just 24 weeks, let alone 20? You do some more math in your head. Egad! It has almost nothing to do with how many features you need. It has to do with how long it is currently taking to develop the features!
For the rest of the story see Is Your Schedule Really Driven By Your Requirements?
The whole discussion on the number of features is almost irrelevant. How can that be? If the average time to develop a feature was seven weeks with a standard deviation of seven weeks, that would be 21 weeks. Almost there! But, holy molly, you don’t have any control over how fast they develop features. About all you can do as the project manager is insist they get it done in the given time or negotiate the number of features. Maybe you can offer to fight for more money and more staff! Oh yeah, she’ll say you can’t make a baby in three months with three women. Plus, it would blow away the margins on the product. You start wondering if the local high school needs a math teacher who can also coach cross country.
Was there a solution? In the organization this example is loosely drawn from, what finally worked was to recognize that development consistently took a certain amount of time to launch a new product. When that period of time was allocated to product development up front, they not only delivered on time, but the quality of the software features improved dramatically. The popular and often stated belief was that development just took too long and they were the reason why products were late. All evidence however indicated that their time to develop new products was not significantly different than their competitors. Surprisingly, this was not to be the only company I was to encounter that had inexplicably institutionalized being late by simply starting late and not realizing it (see The Leap To The Exceptional Is Shorter Than We Think).
When you’ve increased or decreased your requirements, did it really increase or decrease your schedule proportionally?
11 thoughts on “Avoid This Project Management Schedule vs Requirements Trade-Off Trap!”
Comments are closed.
Management is the ART and SCIENCE of defining and accomplishing the objectives of an organization through the effective and efficient use of labor and other resources. Note: it is both an ART and SCIENCE. The ratio between ART and SCIENCE depends on what you’re managing. I studied Project Management in an academic setting long before MS-Project. Today, I’m subject to people who insist on a level of detail within MS-Project that to develop and maintain far exceeds the point of deminishing returns. Theoretically, they’re right, but in practice it falls apart. I see it on project after project, over and over. I try to establish a practical level-set in the beginning and I’m the one who is labeled the “bad project manager”, even though in the end, they circle back to what I said in the first place.
Sean,
Yes, this happens a lot to me also. I mentioned that this notion is counter intuitive to many people. This simply means that when we try to do it, we get a lot of push back that says “that is not the way to do it!” One of my purposes to writing these kind of articles is to plant the notion that maybe the “common wisdom” approach is not what we always want to do. My best “change management” approach is often to just go and do it – to demonstrate that it works. I’ll do it in parallel with the “conventional” approach (so, yes, it is an extra load with no guarantee of payback) and show how one was a better predictor of what actually happened then the conventional approach.
Hang in there and good luck.
Bruce
Bruce;
Ive been around software development efforts a very long time, and while its great that there are somewhat “objective” tools available to help predict completion times, efforts, etc…in the end the “highest order” effect on a projects time comes down to the same single variable everytime: the people working on the project.
Software development is part art, part science, and all brain. Being able to retain “big picture” views, while focusing on minute details of functionality and quality is a gift that is very infrequently visited on the multitude of developers out there. Most coders are “average” (including myself), and that “average value” has a wide variant. The larger the project, and the more developers, the more difficult it is to come up with a single valid estimate of when something will be “done”.
That is why startups usually fair so well in the software market…highly competent, like-minded individuals, with tremendous drive and determination are able to now develop amazing software in a staggering short amount of time. Once the “sanctity of coder purity” is broken as the startup grows and hires more people, the slower development becomes…when you need “Project managers” to manage everything, the game is over.
-avi
Avi,
I’ve had folks openly “snicker” at me in meetings when I say we can deliver consistently on time. These are exactly the “game is over” organizations that you refer to. The snicker represents to me the real barrier. These are not the same “highly competent, like-minded individuals” you refer to but instead equally highly competent but expert in large corporate politics and survival. Many of these folks are incredibly capable – but need a bit of a hint to realize it can really be done and it is safe to do it.
However, I clearly disagree with the notion that these companies reach a point where they can no longer deliver on time with high quality. My writings specifically chronicle how I’ve been a part of doing just that. From military organizations, to small corporations, to Fortune 50 corporations. I was there. We did it. It really is possible. But, it is not easy. And it is not easy for the reason you suggest, the size and politics of the organization. The talent needed was always right at hand. They just needed a little guidance and a whole lot of guts.
Yes, there is some magic in being objective. Here in part because it helps overcome the politics. But for everyone, yes, you can use basic measurements and handled the large variations. Yes, it will give you a very good probability date. It is done in context however. Where this has worked very well is in organizations that are consistently late. Always late in some cases.
As strange as it sounds, I am often recommending a schedule that has a 50% probability of success. In an organization that is always late, delivering half on time is a tremendous improvement. It is humorous to have folks who tell me we can predict nothing about our ability to deliver on time, for some of the same reasons you mention, tell me that the 50% schedule is not good enough!
These fairly simple techniques have worked on teams as small as 5 developers to efforts that run 12 months and peak at 450 developers a month.
There are more sophisticated tools and techniques, but I find the sophistication is the barrier to proper use. I watched an organization that never delivered on time implement a Monte Carlo technique. Gee, it came out with almost the same schedule. All the products using this new technique all delivered late, as they always had. It was too mystical to too many, very smart, people to realize how ridiculous a result that was. I used a simple average of past product deliveries, we nailed the schedule, and we took no more time than products did in the past.
Thanks for your comments.
Bruce
If the “long pole in the tent” is 24 weeks, then cutting other features won’t shorten your “long pole” unless those resources are applied to the “long pole”. Even so, don’t expect a 1:1 reduction.
RM,
In practice, at least for organizations that are not good at estimating, I’ve rarely seen the long pole stay the same throughout the development cycle. This means you can’t rely on the long pole being … the long pole. With each status update, it often looks more like a horse race on who will finish and in what order.
My conclusion is that it is almost never a 1:1 reduction. I’ve seen it where the overhead processes are so great that it takes something like an 80% drop in requirements to get a 20% reduction in schedule. In this actual situation, this turned out to have a hidden but silver lining. While reducing the schedule was near impossible, increasing the requirements by 450% – which was insane in my book – didn’t actually cause that much problem. I likened the company’s development team to a draft horse (a Clydesdale maybe). You probably can’t make it run very fast, but you sure can load a lot more onto it than you would expect and still get to where you are going in the same amount of time.
Thanks
Bruce