Business Case Scoring – Template

Just wanted to share this quick business case scoring template.

 

In evaluating various business cases, individuals can score each based on the following:

– Business Justification

– Analysis of Alternatives

– Technical Alignment

– Feasibility of Implementation Strategy

– Funding/Resource Availability

The ratings are done with 1 being the lowest and 5 being the highest. 

The scoring sheet calculate average, and identifies highest and lowest scores.

Then the individual scores can be summarized and used to rank the projects in your portfolio. 

Based on overall funding, you can determine how many of the top-ranked projects are doable in the year, and then roll over the others for reevaluation along with new business cases next go around. 

Capisce? 😉

(Credit Graphic: Andy Blumenthal)

Project Governance and Gate Reviews

Thought this may be helpful for those looking at a Governance Process and Gate Reviews for project management. 

This aligns the Capital Planning and Investment Controls (CPIC) process of select, control, and evaluate phases with the Systems Development Life Cycle (SDLC). 

There are 5 notional gate reviews with associated documentation for project conception, initiation, planning, execution, and launch.

Of course, this can be modified as needed based on the project threshold and governance stringency required and seeks to create strategic alignment with the goals of the organization. 

(Credit Graphic: Andy Blumenthal)

Getting The Biggest Bang For The Buck

So I had the opportunity to sit in on a colleague teaching a class in Performance Improvement. 

One tool that I really liked from the class was the Impact-Effort Matrix. 

To determine project worth doing, the matrix has the:

Impacts (Vertical) – Improved customer satisfaction, quality, delivery time, etc.

Effort (Horizontal) – Money, Time, etc. 

The best bang for the buck are the projects in upper left (“Quick Wins”) that have a high impact or return for not a lot of effort. 

In contract, the projects that are the least desirable are in the lower right (“Thankless Tasks”) that have a low impact or return but come at a high cost or lot of effort. 

This is simple to do and understand and yet really helps to prioritize projects and find the best choices among them. 😉

(Source Graphic: Andy Blumenthal)

What Are The Chances for IT Project Success?

So I was teaching a class in Enterprise Architecture and IT Governance this week. 

In one of the class exercises, one of the students presented something like this bell-shaped distribution curve in explaining a business case for an IT Project. 

The student took a nice business approach and utilized a bell-shaped curve distribution to explain to his executives the pros and cons of a project. 

Basically, depending on the projects success, the middle (1-2 standard deviations, between 68-95% chance), the project will yield a moderate level of efficiencies and cost-savings or not. 

Beyond that:

– To the left are the downside risks for significant losses–project failure, creating dysfunction, increased costs, and operational risks to the mission/business. 

– To the right is the upside potential for big gains–innovations, major process reengineering, automation gains, and competitive advantages. 

This curve is probably a fairly accurate representation based on the high IT project failure rate in most organizations (whether they want to admit it or not). 

I believe that with:

– More user-centric enterprise architecture planning on the front-end

– Better IT governance throughout

– Agile development and scrum management in execution 

that we can achieve ever higher project success rates along the big upside potential that comes with it!  

We still have a way to go to improve, but the bell-curve helps explains what organizations are most of the time getting from their investments. 😉

(Source Graphic: Adapted by Andy Blumenthal from here)

People, Process, and Technology Lifecycles

The table describes the alignment of the various people, process, and technology lifecycles commonly used in Information Technology to the CIO Support Services Framework (CSSF).

The CIO Support Services Framework describes the six key functional roles of the Office of Chief Information Officer (OCIO)–it includes:

1) Enterprise Architecture (Architect)

2) Capital Planning and Investment Control (Invest)

3) Project Management Office (Execute)

4) CyberSecurity (Secure)

5) Business Performance Management (Measure)

6) IT Service (and Customer Relationship) Management (Service)

All these OCIO Functions align to the lifecycles for process improvement (Process), project management (People), and systems development (Technology).

– The Deming Life Cycle describes the steps of total quality management and continuous process improvement (Kaizen) in the organization.

– The Project Management Life Cycle describes the phases of managing (IT) projects.

– The Systems Development Life Cycle describes the stages for developing, operating and maintaining application systems.

Note: I aligned cybersecurity primarily with doing processes, executing projects, and designing/developing/implementing systems.  However, cybersecurity really runs through all phases of the lifecycles!

My hope is that this alignment of people, process, and technology life cycles with the roles/functions of the OCIO will help bridge the disciplines and make it easier for people to understand the underlying commonalities between them and how to leverage the phases of each with the others, so that we get more success for our organizations! 😉

(Source Graphic: Andy Blumenthal)

SDLC On Target

I found this great white paper by PM Solutions (2003) called “Selecting a Software Development Life Cycle (SDLC) Methodology.”

The paper describes and nicely diagrams out the various SDLC frameworks:

– Waterfall
– Incremental
– Iterative
– Spiral
– RAD
– Agile

It also provides a chart of the advantages and disadvantages of each framework.

Finally, there is a simple decision cube (D3) based on time horizon, budget, and functionality for selecting an SDLC framework.

This is a very useful and practical analysis for implementing SDLC, and it aligns closely with the guidance from the National Institute of Science and Technology (NIST) Special Publication (SP) 800-64, “Security Considerations in the Systems Development Life Cycle” Appendix E that states:

“The expected size and complexity of the system, the development schedule, and the anticipated length of a system’s life may affect the choice of which SDLC model to use.”

While NIST focuses on the time horizon and complexity versus the PM Solutions Decision Cube that uses time horizon, budget, and functionality, the notion of tailoringSDLC to the project is both consistent and valuable.

Just one more resource that I found particularly good is the Department of Labor IT Project Management guidance (2002)–it is a best practice from the Federal CIO website.

I like how it integrates SDLC, IT Project Management, IT Capital Planning and Investment Control (CPIC), and security and privacy into a cohesive guide

It also establishes project “thresholds” to differentiate larger or more significant projects with greater impact from others and calls these out for “more intensive review.”

Even though these these resources are around a decade old, to me they are classic (in a good sense) and remain relevant and useful to developing systems that are on target.

(Source Photo: Andy Blumenthal)

Apples or Oranges

There are lots of biases that can get in the way of sound decision-making.

An very good article in Harvard Business Review (June 2011) called “Before You Make That Big Decision” identifies a dozen of these biases that can throw leaders off course.  

What I liked about this article is how it organized the subject into a schema for interrogating an issue to get to better decision-making.

Here are some of the major biases that leaders need to be aware of and inquire about when they are presented with an investment proposal:

1) Motivation Errors–do the people presenting a proposal have a self-interest in the outcome?

2) Groupthink–are dissenting opinions being actively solicited and fairly evaluated?

3) Salient Analogies–are analogies and examples being used really comparable?

4) Confirmation Bias–has other viable alternatives been duly considered?

5) Availability Bias–has all relevant information been considered?

6) Anchoring Bias–can the numbers be substantiated (i.e. where did they come from)?

7) Halo Effect–is success from one area automatically being translated to another?

8) Planning Fallacy–is the business case overly optimistic?

9) Disaster Neglect–is the worst-case scenario imagined really the worst?

10) Loss Aversion–is the team being overly cautious, conservative, and unimaginative?

11) Affect Heuristic–are we exaggerating or emphasizing the benefits and minimizing the risks?

12) Sunk-Cost Fallacy–are we basing future decision-making on past costs that have already been incurred and cannot be recovered?

To counter these biases, here are my top 10 questions for getting past the b.s.
(applying enterprise architecture and governance):

1) What is the business requirement–justification–and use cases for the proposal being presented?

2) How does the proposal align to the strategic plan and enterprise architecture?

3) What is return on investment and what is the basis for the projections?

4) What alternatives were considered and what are the pros and cons of each?

5) What are the best practices and fundamental research in this area?

6) What are the critical success factors?

7) What are the primary risks and planned mitigations for each?

8) What assumptions have been made?

9) What dissenting opinions were there?

10) Who else has been successful implementing this type of investment and what were the lessons learned?

While no one can remove every personal or organizational bias
that exists from the decision-making equation, it is critical for leaders to do get beyond the superficial to the “meat and potatoes” of the issues.

This can be accomplished by leaders interrogating the issues themselves and as well as by establishing appropriate functional governance boards
with diverse personnel to fully vet the issues, solve problems, and move the organizations toward a decision and execution.

Whether the decision is apples or oranges, the wise leader gets beyond the peel.

>Toward A Federal Enterprise Architecture Board

>

A Federal Enterprise Architecture Board (FEAB) would provide “teeth” to further implementing enterprise architecture across government.

We have a Federal Enterprise Architecture (FEA) that provides a government wide framework for architecture strategy and planning, but we do not have a FEA Board to govern the subsequent IT investments through capital planning and investment control (CPIC). CPIC is the governance process whereby we select, control, and evaluate new IT investments.

Interestingly, The Federal CIO Council’s Architecture Alignment and Assessment Guide (October 2000) specifically calls for complementary EA and CPIC functions (see graphics).

In this paradigm, the enterprise architecture (EA) informs, guides, drives the CPIC, and in turn the decisions from the CPIC governance process updates the EA planning, so that the EA and CPIC processes are seen as mutually supportive.

In the federal government, we have departmental and agency architectures and boards that serve to plan and govern IT investments at their respective levels. However, as we seek to build greater standardization, interoperability, and reuse across government with IT initiatives that cut across traditional government boundaries driven and guided by the Federal CIO and Federal CIO Council, there is a need for a FEAB to review new and major changes to IT investments.

There would be many purposes for the FEAB.

• Strategic alignment: One would be to ensure strategic alignment not to any single department or agency mission, but rather to the greater federal government strategy and policy. Some examples of this would be data center consolidation, green IT, open government, and more.
• Streamlining of investments: Additionally, the FEAB would assess IT investments to ensure that there is no overlap or opportunities for consolidation of initiatives. OMB performs some of this function today, but a FEAB would augment their capability with IT subject matter experts from across the government.
• Other key benefits: Of course, the FEAB would also look at things like return on investment measures, risk mitigation plans, technical compliance to federal architecture standards and mandates (security, privacy, records, FOIA, Section 508, etc.).

The FEAB would not be a substitute for the EA Boards that provide oversight functions at the department and agency levels, but would provide governance for the largest and riskiest IT initiatives and those that cut across different agencies.

While the OMB currently assesses IT investments using Exhibits 300s and 53s, which include EA assessment questions, the FEAB would provide a governance board made up of cross-cutting governmental IT subject matter experts to vet these business cases from an EA perspective thoroughly and provide recommendations to the Federal CIO Council and the OMB on approval or denial. Therefore, and not unimportantly, the stand-up of a FEAB would add an important human factor to the Federal Enterprise Architecture and make it “real.”

Of course, with a portfolio of some 10,000 IT systems, the FEAB would not be able to govern every new Federal IT investment. Therefore, it would be critical to establish thresholds that would be practical for implementation.

I would envision the FEAB being chaired by the Federal Architect and the board being a recommendation body to the Federal CIO Council and the Office of Management and Budget, Executive Office of the President.

Critical initiatives by Federal CIO Vivek Kundra to effectively manage (i.e. CPIC control phase) IT investments through the Federal IT Dashboard and TechStat sessions would be augmented by the FEAB work to carefully recommend for selection (i.e. CPIC select phase) new federal IT investments.

Together, I see the federal select and control mechanisms of CPIC functioning in harmony to enhance governments IT planning, investment decision-making, and execution. Essentially, the FEA (architecture) and FEAB (governance) on the “front-end” will guide new IT investments, and the IT Dashboard and TechStat sessions on the “back-end” will ensure IT investments are properly progressing for the taxpayer based on cost, schedule, and performance measures.

In summary, the Federal Enterprise Architecture Board would be the governance arm of the Federal Enterprise Architecture, and serve as a support to the IT leadership of the Federal CIO, the Federal CIO Council, and the IT budgetary functions performed by the Office of Management and Budget.

>Why EA and CPIC?

>

Note: This is not an endorsement of any vendor or product, but I thought this short video on enterprise architecture planning and capital planning and investment control/portfolio management was pretty good.

>The CIO Support Services Framework Improves IT Operations

>http://www.meritalk.com/include/flow_player/FlowPlayerDark.swf?config=%7Bembedded%3Atrue%2CbaseURL%3A%27http%3A%2F%2Fwww%2Emeritalk%2Ecom%2Finclude%2Fflow%5Fplayer%27%2CvideoFile%3A%27%2E%2F%2E%2E%2F%2E%2E%2F%2E%2Fuploads%5Fvideo%2F1000%2F523%2F108%2Eflv%27%2CinitialScale%3A%27scale%27%2CcontrolBarBackgroundColor%3A%270x01406C%27%2CautoBuffering%3Atrue%2CautoPlay%3Afalse%7D