Does your final project schedule look identical to the project schedule that you began your release with?  If it does, you either aren’t managing your schedule or you are working on a dead product.  Project Management is predominantly an exercise in change management - so much so that I like to think of them as synonyms for one another. 

There are two primary sources of schedule change.  One source is when the actual productivity doesn’t match the budgets in your work break down structure.  The other source, the more problematic source of change, is when your requirements change.  This article will concentrate on managing changing requirements.

The Case for Change

No project develops as scheduled.  The schedule needs to change to reflect the new estimates and dependent consequences.  I’ve seen many software managers produce a detailed schedule during the planning phase only to never open the schedule again once the actual work begins.  That’s mismanagement.  This usually occurs when you have a technically oriented manager who undervalues what good management can bring to a project.  In my experience, these people are the source of more team problems than any other factor. 

A project with no requirements changes is either mismanaged or a dead project walking.  If the project you are delivering is something that has a future and the project stakeholders are excited and interested about, requirements change is an inevitable consequence.  Run from the projects that don’t have any requirements change pressures.  They don’t have a future.

Too often software managers make themselves adversaries of change.  They too frequently place the objective of hitting the release date above all other competing concerns.  The primary objective of every project is to add value — value not only as far as profitability is concerned but value in its benefits to its customers.

A successful project adds value.  I’m not suggesting that on time delivery doesn’t contribute to value.  It does, but it’s rarely as important as it’s made to be.  Take Microsoft for example.   They’ve been late on every delivery of their Windows operating system.   In spite of late shipment, they have added significant value to Microsoft and their millions of customers.   Even in my own experience, projects that were a few weeks or a few months late never had negative real consequences.  Delivering a bad release on time is always a terrible idea.

Steps for Controlling Change

The challenge for software managers is how to successfully manage change.  First, don’t view your product marketing team as an adversary.  As they are the source of a majority of your requirements change requests, it’s only natural to see them as the source of problems.   The product marketing team is working to deliver upon the customer need and thereby secure a revenue stream for the product.  Product marketing requests changes because they see an opportunity to reach more customers, to fend off a competitor, and/or at a minimum to ensure the product is received warmly. If, as the manager of the engineering effort, these aren’t your priorities, then you make it easy for your competitors to exploit your missed opportunities.

Requirement changes shouldn’t be accepted easily; they have to be controlled to meet all the project’s objectives.  Certainly as the software manager, it is your objective to ensure that all the project commitments are delivered timely, but timely doesn’t necessarily mean the original release commitment date.  Here are some strategies in priority order for managing requirements during your release.

1. Absorb the change without changing your release commitments. Many change requests are in areas that you are already working in and can be easily accommodated without impacting the schedule.  This is not debatable: just do it.
2. Offer alternative solutions to the change request that will allow you to deliver on the change and allow you to hold your release date, but don’t offer bad solutions just to maintain the date.  That benefits no one.  Take the time to understand the customer need.  In doing so, you may find there are better and easier alternatives that can be easily absorbed into the release.
3. Offer the alternative to deliver the original commitments as planned followed by a small release shortly after with the change request(s) included.  This is a great compromise approach when you know you can deliver the changes shortly after the release: something less than eight weeks has worked well for me.
4. Negotiate other features out of the release when you know the only way to deliver the change is to extend the release date.  When the delivery date is truly a priority and a small slip to the schedule is intolerable, the Product Marketing team will often work with you to change the commitments. 
5. Slip the release date.  Sometimes this is the only alternative, but this should be the last position you argue for.  If you find that you are here too frequently, something is wrong with the chemistry on your team.   As the software manager, you should feel extremely disappointed when this is the solution, but realistically sometimes it is the best solution.  Develop a feel for the difference because if you don’t your managerial skills will be doubted.
6. Don’t accept the change in the current release; look to reach agreement to move it to a future release.  Only accept change that will actually make a material difference to the success of the product.  There is no rule for this, but the good software managers know the difference and partner with their product marketing team to successfully accommodate change.

Summary

It would be easier to deliver a project as originally planned if the requirements are immutable once they are agreed upon.  However, good change is inevitable and should be embraced.  An environment that partners with change is vibrant and energetic.  Those teams are focused on the possibilities.  The word “can’t” is an anathema.  Everyone is the source of change in these environments.  These are forward looking teams, focused on the customer.  Teams that don’t partner with change are too often self-limiting and focused on what’s not possible.  They do what they’re asked to do and no more.  They are the polar opposite of all the characteristics of teams that successfully partner with change.  When you consider the alternative, partnering with change is the only sensible choice.