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

Lifecycles.jpeg

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

Sdlc

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

Apples-and-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.