Sometimes it is worth reviewing the basics. I was listening to a fellow product manager recently who was complaining how they couldn’t ever lock plans and deliver as expected because things always change. This is not good management. Sure things can change, but it must be done in context and intentionally.

At the end of the day, the scope of all development projects come down to a basic function:

Project scope is a function of Resources, Content, and Schedule

Resources: The people and equipment deployed on the project

Content: The features expected in the finished project

Schedule: The time allocated in terms of working units (hours/days/weeks) or calendar time

You could probably get fancy with a formula that added constants and factors to derive a true equation and the relative weights of each factor but it really all comes down to one dynamic: Projects with a chance of measurable success have a finite scope, changing one variable requires changing another. If you add Content you have to either increase Resources or Schedule. Similarly reducing Schedule requires cutting Content or increasing Resources.

These are what some people call ‘laws of physics’ problems. They could just as easily be called ‘laws of projects’. There is no magic, just effective tradeoffs.

So, the next time someone wants “just one more feature” or to “borrow a developer” go back to basics. Ask what s/he’d like to change? Delay the project? Lend extra resources later? Cut something else from the feature list? Something must be done.