Negotiating Achievable Commitments in Software Project Management

Modifying Commitments

Many projects have formal agreements to implement a specific set of requirements by a particular date. Such commitments can fall by the wayside if the requirements turn out to be technically unfeasible or especially challenging, if customers modify them, or if the stated requirements were just the tip of the real requirements iceberg. Project stakeholders must alter their expectations and commitments in the face of evolving information.

Inevitably, project realities—requirements, resources, technologies, budgets, schedules—will change. Problems will arise, risks will materialize, and new functionality will be requested. If your customers demand 10 new features late in the development cycle, they can’t expect to get the product by the original deadline. Whenever it appears that some targeted deliverables won’t be completed before you run out of time and resources, the key project stakeholders need to decide how to respond. As described in Chapter 4 (“Success Criteria Breed Success”), you need to remember which project dimensions are constraints, which are important success drivers, and which ones you can adjust if necessary. Here are some options you might explore, guided by your established project priorities:

• Can some lower-priority requirements wait for a later release?

• Can delivery be delayed? By how long?

• Can you channel more developers onto the project?

• Will the customer pay extra to bring contractors on board to implement the new features?

If it becomes apparent that you or your team won’t meet a commitment, inform the affected stakeholders promptly. Don’t pretend you’re on schedule until it’s too late to make adjustments. Letting someone know early on that you can’t fulfill a commitment builds credibility and respect for your integrity, even if the stakeholders aren’t happy that the promise won’t be kept.

Rigidly adhering to impossible or obsolete commitments can lead to serious problems. One project manager promised year-end delivery of a mission-critical application. He maintained that his small team could do the job without additional resources, but the year drew to a close without a delivery. The next year, his manager brought more team members on board and the project made good progress. Again, the project manager promised to deliver by the end of that year but again he failed to do so. Unwilling to admit that he couldn’t achieve his commitment, he kept the challenges he was facing to himself, hoping to save face.

In fact, his stubbornness had the opposite effect. His development team lost credibility with both customers and managers. In addition, technology changes over the long course of the project rendered the new application largely irrelevant. When the system finally was delivered, it was nearly dead on arrival and many stakeholders were disappointed. A more responsible manager would have acknowledged reality and renegotiated resources and delivery dates. And when it became clear that pursuing the initial requirements amounted to throwing good money after bad, the project’s decision makers should have redirected or canceled the project.