Describing the strategic vision of the project; justifying resources; estab- lishing expectations
Module 1—Objectives
• Explain the value-add of a business case as an agile tool • Make the case for best-value as the optimum project objective
Adding Value with the Business Case
There is always a case to be made for developing a business case, even in the public and nonprofit sectors. The project objective may not be to make money in a business context, but every project envisions some expectation and every project requires resources. Thus there is always an opportunity choice: do this or do that. The choice is explained and justified in the business case.
These points are valid for any project—even the smallest agile project. And, there is a case to be made that the agile business case itself should be agile in spirit and fact. Agile methods do not make the business case un- necessary; indeed, the business case supports and justifies the project as a strategy step toward business goals.
Even if the project is simply to burn down a bug list, the project benefits by imagining and exploring the opportunity and its alternatives—collecting everyone’s thoughts in an organized way. Some put process labels on the effort with names like the Envision and Speculate phases or the Explore 360 strategy1—or, even simpler: Scoping the project, Beck and Fowler, Planning
Extreme Programming, Chapter 9.2
The business case is a capture document. It is an interface mechanism be- tween the project and the business and between the decision-maker spon- sor, myriad stakeholders, and the project manager. The business case itself should be an example of lean and agile principles: simple, value adding, responsive, and evolutionary.
A project management tip
Stakeholders focus on outcomes
• The agile-thinking stakeholder has a bias toward out-
comes; input and process are a means to achieve goals.
• Agile managers forecast the outcomes based on the iter-
ation backlog that is a small, stabilized slice of the project backlog.
• Each iteration or delivery cycle produces an increment of
product as developed from the iteration backlog.
Three Levels of Business Case
To that end, we define three business-case levels corresponding to business impact:
• Level 0: A one-page form for small projects with one team working on the least intrusive projects. Level 0 is approved by a one-step work- flow-managed approval process.
• Level 1: A simple template for more complex multi-team projects; it is approved in a two-step workflow.
• Level 2: For enterprise projects that have significant business implica- tions; Level 2 requires executive approval.
Every project has an impact on the organization; these four sets of questions commonly arise in the business case:
1. Is a project the right approach to obtain what the business needs and wants? Is there an approach other than a project that should be considered?
2. Specifically, why is the proposed project the right project to under- take? Have alternative project choices been examined?
3. Can the project deliver the required business value for the resources available (e.g., time, money, people, and technology)?
4. What are the risks, and how will they be mitigated? An Agile Business-Case Framework
The business case is a framework to hold content; the content is intended to be adaptable to many situations, and amenable to iteration and evolution as the solution solidifies. The business case begins with a high-level idea from the business, a vision of the expected outcomes, discriminating features, and needed functional capabilities.
At the top level, these intended outcomes are the project scope. The ex- act solution is value-driven by the end users or customers, rather than plan- driven by sponsors and project management. In Chapter 1, agile projects were characterized as evolutionary—meaning that details evolve over time as customers evaluate each increment delivered to the product base.
There is an anticipated investment and expected payback—financial and otherwise:
• The investment goal is the limit on available funding
• The payback is an anticipated benefit stream tied to the vision • Investment and payback are linked to milestones
• Milestones establish a timeline and relate expected outcomes and ben- efits to the calendar as prioritized by value.
Take a look at the framework in Figure 2.1 for an example of the discussion so far. Each business element evolves during the project lifecycle.
Best-value Emerges Tactically, but Is Strategically Anchored
The value proposition of a project is always in the eye of the beholder— business leaders and customers alike—meaning that it’s the beneficiaries that bestow value. Ideas about values as beliefs generally come from the top of the enterprise; ideas about value as an opportunity come from all points of the customer base, internal and external.Best
value Delivering the most scope possible—for the available resources—that informs business effectiveness, importance, and urgency.
We hold that a best-value outcome is the optimum outcome for agile projects, and the optimum objective to achieve.
Why so? Especially since best-value may not be:
• The lowest cost (there may be a value-cost trade that favors higher cost for much greater value)
• It may not be the shortest schedule, again thinking of the most advan- tageous trade off
• It may not be the most scope-deliverable because some envisioned scope may not be economically feasible
It is because best-value is the most likely meld of beliefs, opportunity, ca- pability, and capacity deliverable at an affordable price. Beliefs and business opportunity provide anchoring of the business case; capability and capacity are the means to take advantage of tactical opportunities that emerge. Figure 2.1 Business case framework
Framework
elements Business case details (example)
The framework provides boundaries and limitations to govern project implementation
Opportunity To improve new-orders customer service in a manner that invites repeat business
Goals Raise customer satisfaction metric by 50%
Raise sales from existing customers by 25%
Strategy Improve the business environment and tools
Transfer some order entry functions to the customer
Project vision An integrated, near-real-time order entry application useable by internal and external customers that reduces order entry time and improves the quality of the entry process
Scope functionality Web-based application that validates product, price, and customer account
Integrates with product catalog and price books Milestones M1: Internal order process or capability
M2: External customer user capability M3: Automated sales credits
Investment $1M total, M1: $500K, M2: $300K, M3: $200K
Beneficiaries Order processors, sales team, billing and credit, external customers Benefit pay-back Recover investment with increased sales and reduced operating
Imagine a chain with links from the fuzzy front end of opportunity and vi- sionary ideas, through goals, to strategy and operations. Think of opportunity as untapped value that is waiting to be captured and processed into business results. Tapping into opportunity provides the fuel to power projects.
Figure 2.2 illustrates the relationships in the chain from opportunity to goal satisfaction. The chain is shown in the familiar V form so that lateral alignments are more apparent. Most organizations pull all this together in a strategic plan.
Strategy and Goals
As commonly practiced, strategic planning sets goals and identifies the means to achieve those goals. The means of achievement is called strategy:
Strategy is a linked and ordered set of actionable steps that point unambiguously to a goal.
Project balance sheet
Integrated strategy to exploit opportunity O ppo r t un i t y w i t h bu s i ne s s va l u e Balanced scorecard business goals
Agile project with multiple iterations Verify earned value scorecard Operations validate strategy satisfaction C u s t o m e r - v a l ue d ou t co m e Va l ue - add b y p r o j e c t Goal achievement and updated KPIs
Strategy is a plan for action set in the context of business culture, strengths and weaknesses, and threats and opportunities. The business makes projects part of the action, an element of strategy, and thereby an instrument to achieve goals.
A project management tip
Projects are valued for their impact on strategy
• Opportunity is where the value is; a project becomes valu-
able if it can harvest and transform opportunity into busi- ness results.
• A project’s value proposition is derived from the strategy of
which it is a part.
• Best-value is the most scope that is affordable for the
available investment, delivered in priority order, and con- sistent with the beliefs of the enterprise.
Planning Element Relationships
To get a better handle on the business plan fundamentals, let’s take a look at the relationships among planning elements as given in Table 2.1. Notice that there is a lot of entanglement among planning elements in the agile business case, many of which will change as the business case is developed and customers express their wishes. In other words, the agile business case is expected to adapt as the project particulars emerge. Adaptive planning requires a trade off between a point solution and a best-value outcome.
Table 2.1 Relationships in the agile business case Customer valued
features and function
All the product capabilities that depend on the value and importance assigned by the customer, as evolved with operational experience incre- mentally over the lifecycle of the project
Scope All the features and functions valued by the customer, and everything
else needed by the project or the business even if there is no direct cus- tomer value
Resources All the people, technology, and environment needed to produce value
for the customer in the prescribed time Investment and
funds
Investment: the limit of affordability established by the business as the value of the opportunity
Funds: All the money needed to pay for resources but constrained to the limits of affordability, according to the project
Schedule Business milestones at which time features and functions are incremen-
tally needed
The point solution is plan-centric; it has seemingly precise estimates and predictable outcomes, but the track record is often otherwise: estimates and outcomes wind up with distressingly low accuracy and wide variances. On the other hand, the best-value outcome emerges during the project as guided by the strategic direction given in the business case. Beginning with a product vision depicted in the business case, the best-value outcome pro- gressively acquires definition and detail with each release—bound by com- mitment to customer-driven value and framed by architecture, the business case milestones, and available investment.
Both the business—including by extension, the customer—and the proj- ect have rights and responsibilities as they mutually engage in business proj- ect planning, as given in the project management tip that follows:
A project management tip
Rights and responsibilities in the agile business case
• The business has a responsibility to provide a clear busi-
ness vision.
• The business has a right to a best-value response to the
business need.
• The agile project has a responsibility to be responsive to
the value judgments of the business and provide a best- value solution.
• The agile project has a responsibility to respect the limita-
tions of funds and the business milestone identified by the business case.
Module 1—Discussion for Critical Thinking
• Some say that a business case is too much process for agile projects; that such an anchoring and documented case for the project is not necessary. Do you—the reader—agree, or not, and why?
• Best-value presumes the delivered scope emerges from the best meld of many business and project factors. Could you justify best-value even when it may not be the lowest cost, shortest schedule, or even the most complete scope?