Tag Archives: articles

Just Enough, Just In Time, and Sometimes Just Because

Posted on
13

This post currently appears as the latest installment of my recurring “The Agile Project Manager” column in the January issue of PM Network magazine. PMI members can view the original printing of the column here: http://www.pmnetwork-digital.com/pmnetwork/201101?folio=17

“How much up-front planning should we do? How many people should we hire? How many meetings, documents and procedures do we need?”

No matter what field or what project, we all face the “how much?” questions over and over. To avoid getting bogged down, project managers should heed three golden rules: Just Enough, Just in Time and Just Because. I first heard these from Mike Griffiths, PMP, one of the earliest council members of the PMI Agile Community of Practice, when we were struggling with a lengthy document. After much debate, Mike interrupted with a seminal insight in agile efficiency: “When it comes to documents, I coach my teams to generate just enough, just in time and occasionally just because. I think this document fits the last category. Our client has asked us for this document, and even if we consider it excessive, the project will simply never get launched unless we use it.”

Let’s take a closer look at these three tenets of agile productivity:
Just Enough
GOLDEN RULE NUMBER 1: Just Enough. Only do enough prep or support work to achieve the primary goal of delivering business value. The problem is that we so easily intertwine this work with the bottom-line deliverable we’re paid to generate. With that confusion comes the temptation to do more prep and support work than is necessary or required.

Yes, we need a project roadmap, but rather than spend time building a yearlong plan down to the hourly resource requirements, we’re going to provide just enough detail to communicate a vision to stakeholders.
Yes, our IT staff needs some technical direction, but rather than waiting to architect every layer of every interface of every system up front, we’re going to provide just enough direction to get started.
Yes, we need to pass the certification and accreditation audit. But rather than defensively launching an avalanche of paperwork, we’re going to collaborate with the auditors to deliver just enough documentation to satisfy them.

Just In Time
GOLDEN RULE NUMBER 2: Just in Time. You could be crafting lightweight documents, lightweight architecture and lightweight processes—and still be doing all that lightweight work way too prematurely. Of course we could need that architecture component, but let’s invest the time to implement it only when we know for sure we’ll need it.

Of course we’ll need a detailed action plan for next year’s project phase, but let’s devote time to crafting that detailed plan when we get to that phase.
Of course we’ll need to generate some documentation, but let’s wait until we get the documentation requirements before we waste our time on unnecessary write-ups.

Just Because
GOLDEN RULE NUMBER 3: Just Because. This is the constraint that keeps us grounded in reality. I know the 40-page template violates “just enough documentation,” but we’re going to use it, just because we won’t get sign-off without it.

I know forecasting the full project cost up-front violates “just-in-time planning,” but we’re going to do it, just because we won’t get funding without it.
I know triple-entering our hours into the timesheet system violates “just enough administration,” but we’re going to do it anyway, just because we won’t get paid if we don’t.

The next time you’re faced with a dilemma over “how much” of something you should do, rely on these three rules to generate an agile response.

Bad Requirements? Actually, That’s Your Fault

Posted on
8

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.