This is a reprint of my column in this month’s PM Network magazine. Click here, and then search for “The Agile Project Manager”
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 our profession, 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 stakeholder 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 stakeholder or 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 the 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 scope you’ve been implementing for the last two years is no longer relevant to the market? Does it make sense to have your sponsor continue paying for what is now
essentially a useless deliverable? Not in my estimation. If we accept that our requirements are incomplete and incorrect, then we need to edit them to reflect reality. Indeed, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) warns: “Because of the potential for change, the project management plan is iterative and goes through progressive elaboration throughout the project’s life cycle.”
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 structure that supports authorized change rather than penalizes it. At the start of each iteration, mandate a high-level yet thorough revision of scope priorities. If your sponsor has difficulty determining priorities, coach him or her through the tradeoffs. Once changes are accepted, re-baseline earned value metrics at least every three to four iterations to match the latest scope. And while you’re at it, proactively communicate the latest scope to all stakeholders.
If you consistently find your requirements getting you into trouble, do something about it. It’s your responsibility as the project manager to be adaptable to your sponsor’s needs. Stop taking the requirements for granted and start equipping your sponsor to make the right scope choices.
{ 2 trackbacks }
{ 6 comments… read them below or add one }
One way in the defense and space business, we start off on a better footing with requirements, is to define what “capabilities” are needed for mission success. Or in the case of a commercial project, what business capabilities are needed to fulfill the business plan.
For example there were three capabilities needed for a Hubble Robotic Servicing mission (the program got canceled).
1. Do no harm to the telescope
2. change the wide field camera
3. Attach the battery umbilical for the service module attached to Hubble to the power plug on the side of Hubble.
From there 1,000′s of requirements can be “flowed down,” as we say.
Then several things happen.
1. When someone comes up with a requirement deep in the bowels of the project, we can ask “what capability does this support.”
2. When we start tossing requirements overboard, we can connect the decision to a capability that will be adjusted.
In all cases this traceability between capabilities and requirements enables the conversation of “why are we doing this?”
hey Jesse — great article. i think the idea of welcoming change is tough for a lot people who have for many years been entrenched in cultures that try to fight it. in any project undertaking there will almost always be a point or points where stakeholders will want more than you are prepared to give based on already agreed upon terms (“that’s not a new story – that’s what I thought was being delivered today”). the ability to keep your sanity and the trust of your stakeholders in those moments is a critical skill and truly an art. it will be interesting to see what kind of strategies and tactics teams come up with to successfully cope with that kind of natural tension and not lose their ability to remain agile.
Glen, that is an excellent story. I find that the biggest cause of requirements / scope creep is that some big wig has his pet idea, and nobody has a recourse to politely say “NO”. Filtering all change requests against the stated mission of the project is a good way to support PMs in declining the latest so-called “urgent need”.
Hey rich, great to hear from you. Yes, change can be tough for some people and some personalities. However, I think the difference between success and failure is not WHETHER you have change, but HOW you process and coordinate it. Every project evolves along the way. The weak PM will cry foul and complain about scope creep. The strong PM, as Glen mentioned, will simply escalate the changes to the right decision makers, offering pros/cons/accountabilty. Change is not the enemy; fear and helplessness are the enemy. You WILL encounter change, but you are NOT helpless to do something about it.
Excellent article. My two cents: create a business case for the project – i.e. what part of the organization’s strategy benefits from the project and how. Then, when evaluation change (or even scope), also evaluate against the business case.
Sean, I totally agree. Many times project managers looks sight of the business case, and focus only impact changes have to a project schedule. Sometimes it makes sense to blow your budget, in order to make a lot more money down the road.