The Secret Life of Scope Cuts

Over the past few weeks I have been talking with some old co-workers about our experiences with our old clients. One of the things we talked about was how rare it was that project managers really examine closely the real impacts of cutting scope. By this I mean that they often feel that, for example, if they cut a set of tasks from their project that is estimated to take 30 days that this means they actually cut 30 days from their project. While this might be true for things like a construction project it does not always work out for things like software development projects.

At first thought it sure sounds good though. You have a feature that when you add it all up will take 10 or 20 days to develop. You cut it from the project in an effort to shorten your project and you feel pretty good. (Well as good as you can ever feel after you cut a feature you obviously at some point really liked!) Then you feel pretty flush and you figure you can now shorten your QA time in the schedule because you now have fewer features to test! This is getting better and better. Right? Well maybe not.

The thing that I have noticed people forgetting is that sometimes it takes time to NOT finish a feature. How is the feature or code you are pulling from the product linked or related to other features in the product? Do other features or parts of the application depend on code you plan on pulling or not finishing? Will it require you to rewrite other code to deal with the cut you want to make? Was the application designed in a way that will make this hard or easy? If you decide that you do need to make changes to other code to compensate for this cut has that code already been tested? Will you need to retest code because of this cut?

You see what I’m getting at here. It could end up costing you more time to cut the feature than cutting it would save you! Isn’t software fun?

 

Comments

[Glen B Alleman]

Brian,

The physical presence of a PMO is not necessary. Just behave as if you have
one. Ask the same questions a PMO would ask.

I'd conjecture there is a VAST number of project managers are hidden inside large firms and have all these tools and more. We probably have a 1,000 people who "manage" projects as planners, cost analyst, IPT leads, using all the tools and processes of Lockheed. They NEVER get out of the building, attend a PMI event, talk to anyone outside their comparmentalized project.

Locally Ratheon, NG, Ball, Level 3, Pharma's and the 2nd and 3rd tier suppliers
have similar numbers....

In either case, "thinking like a PMO" is the starting point.

[Brian Kennemer]

Sure this is the job of the PMO but only in the land of milk and honey (organizations big enough and projectized enough to have PMOs). Im addressing this to those that are not lucky enough to have a professional PMO staff backing them up and doing these kinds of impact assessments. I have no numbers to back it up but I'd be willing to bet that the VAST majority of project managers have no such organization and no formalized process for doing such assessements.

My thoughts here pertain only to those PMs and those organizations that do not currently do in depth impact assessments.

[Glen B Alleman]

This is he role of the Program Management Office and Portfolio management. No chages (add, deletes, changes) are made without on impact assessment.