Your development team is telling you it will take 24 weeks to do product development.
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.)
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 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!
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?