Author: Fewell, Jesse
Date published: February 1, 2012
Journal code: PMNT
Stop me ifyeii've heard this one before: You've been handed a project char· tec, a detailed requirements document, an unrealistic plan - and a mandate to be successful. Then, as a dutiful project manager, you simply accept the unreasonable, and march forward to inevitable disaster.
An agile approach calls for a different idea: replan. Find a new path that involves the shortest distance between today's problem and tomorrow's victory.
FIRST, DEFINE BUSINESS SUCCESS. Each project is funded to achieve a better future for your sponsor, so you need to know his or her vision. For example, a new payroll system might be developed to lower the cost of back-office operations. Or it may be that the organization plans to dominate a niche market with an innovative product.
Agile frameworks emphasize project charters for good reason. They should have this desired future documented as a high-level scope statement, maybe with some measurable business capabilities. But the important part is to ignore the detailed requirements in the giant 3,000-page contract appendix.
SECOND, DEFINE YOUR BUSINESS CONSTRAINTS. Do not simply assume that scope, schedule, cost and quality are all fixed. Instead, ask what are the most important constraints to your sponsor. Because each case is different, you must have a discussion as to which constraints are fixed and which are flexible. Then you have more options.
THIRD, DELIVERTHE MINIMUM NECESSARYTO MEETTHE BUSINESS COAL WITHIN THE BUSINESS CONSTRAINTS. This is where you have to unlearn everything you've been taught. You've been told that project success is implementing all the detailed requirements with the best possible implementation, on time, on budget.
But real success is not in the requirements, nor the implementation; it is achieving the high-level business goal within the business constraints. You are moving from a scope-driven project to a constraint-driven one. Agile practitioners call this "nipping the iron triangle upside-down." Why do so?
1. Most of the requirements do not contribute to the desired future state: Studies reveal that more than half of all technology features are rarely or never used. That means sponsors are merely guessing which requirements will achieve more revenue, market share or customer satisfaction. Agile frameworks encourage sponsors to regularly reprioritize requirements. What if you were able to deliver the project with half the budget and schedule?
2. Most implementations are over-engineered. Recently, Research in Motion announced the BlackBerry 10 will not be released for another year; as a result, the company's stock price fell almost 40 percent. Could it be that the project team created an unacceptable schedule in the quest for cutting-edge technology, when in fact it wasn't really needed? You don't have to gut a building's entire internal structure to lower its carbon footprint. Agile finds the minimum solution possible to achieve a business goal.
Challenge your project teams to propose the simplest solution. Prototype that solution, and then see if it meets the business objective.
The most dramatic cause of project overruns is that we are doing more work than is absolutely necessary to achieve the high-level scope statement. We dig into the weeds and lose sight of the garden we're trying to create.
But you can be the exception. Do not simply accept the project plan handed to you. Facilitate true innovation: the most business results from the least amount of work.
BY JESSE FEWELL, CST, PMP
Jesse Fewell, CST, PMP, is the managing director for offshore agile projects at RippleRock India and founder of the PMl Agile Community of Practice. He can be reached at jesse.fewell@firstname.lastname@example.org.