I’m growing weary of project managers whining about bad requirements. The truth is, no one can possibly be surprised. From research studies to high-profile disasters, we hear over and over that incorrect requirements and poor scope management are key reasons projects fail. If we know this is a recurring problem in project work, why do we mindlessly continue engaging in the rote repetition of what doesn’t work?
I’d like to share some suggestions to keep us from stumbling over the same mistakes:
Surrender the pipe dream of complete requirements.
There’s always going to be one dependency missed, one person we didn’t interview, one nuance hidden, one more thing we wished we had known. Don’t fall into the trap that more is better or you’ll never get started.
Always assume the initial requirements are wrong.
Sometimes the scope is inappropriately slanted toward one executive or maybe hasn’t been properly vetted. Sometimes the bulk of the requirements are actually “nice-to-haves.” Today’s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure that you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with your sponsor to refine it.
Accept that all requirements change.
Traditional project management culture portrays change as a necessary evil, like traffic laws: If drivers did everything right, we wouldn’t need them. To mitigate the “risk” of change, we install intimidating change-control boards and financial penalties. But what if the work you’ve been implementing for the last two years is no longer relevant to the market? Does it make sense to have your customer continue paying for what is now essentially a useless output? Not in my estimation.
If we accept that our requirements are incomplete and incorrect, then we need to edit them to reflect reality. Indeed, PMI’s Guide to the Project Management Body of Knowledge (PMBOK® Guide), warns:
“Due to the potential for change, the development of the project management plan is an iterative activity and is progressively elaborated throughout the project’s life cycle.”
Today’s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with the customer to refine it.
Simplify your change-management approach.
Agile project managers explicitly embrace the value of responding to change, and institute project policies accordingly. Start by implementing a contract that supports authorized change rather than penalizes it. At the start of each project phase, mandate a high-level yet thorough revision of priorities. If your sponsor has difficulty determining priorities, coach him or her through the tradeoffs. Once changes are accepted, update your metrics to match the latest details. And while you’re at it, be proactive in communicating the latest details to everyone involved in the project.
Now it’s your turn:
What patterns have you seen around bad requirements? What have you done to minimize the pain or ensure the right things get done? Leave a comment below and share your own experiences.
[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]
