The blame game

Share to0

ArticleRequirements ManagementJuly 2010

PM Network

Fewell, Jesse

How to cite this article:

Fewell, J. (2010). The blame game. PM Network, 24(7), 23.
Reprints and Permissions – opens in a new tab

Despite the rise in the number of projects that realize successful outcomes, the percentage of projects that fail remains extraordinarily high. The reason for such failures is often the result of poor requirements management. This article describes four tactics that can help project practitioners manage a project's requirements. In doing so, it defines each tactic and suggests how project managers can avoid the issue causing the failure, an issue that the tactic can resolve.

VIEWPOINTS

 

THE AGILE PROJECT MANAGER

BY JESSE FEWELL, CST, PMP

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.”

〉〉 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 sponsor 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 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. PM

Jesse Fewell, CST, PMP, is the managing director for offshore agile projects at RippleRock India and founder of the PMI Agile Community of Practice. He can be reached at [email protected].

img

JULY 2010 PM NETWORK

Like what you just read?

Log in or register for a free PMI account to get access 
to even more articles like this one.

Offer from our training partner

Advertisement

Offer from our training partner

Advertisement

Related Content

Offer from our training partner

Advertisement