Showing posts with label Business Case. Show all posts
Showing posts with label Business Case. Show all posts

February 2, 2020

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)
Share/Save/Bookmark

May 25, 2011

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.

Share/Save/Bookmark

August 21, 2009

Taking the Politics out of Enterprise Decision Making

Some people say power is primarily exerted through military might (“hard power”), others says it is through use of diplomacy—communications, economic assistance, and investing in the global good (“soft power”). Then, there is a new concept of employing the optimal mix of military might and diplomacy (“smart power”).

It’s interesting to me how the Department of Defense—military approach—and the Department of State—diplomatic approach—is as much alive and well in our enterprises as it is in the sphere of world politics to get what we want.

At work, for example, people vie—some more diplomatically and some more belligerently—for resources and influence to advance their agendas, programs, projects, and people. This is symptomatic of the organizational and functional silos that continue to predominate in our organizations. And as in the world of politics, there are often winners and losers, rather than winners and winners. Those who are the “experts” in the arts of diplomacy and war (i.e. in getting what they want) get the spoils, but often at the expense of what may be good for the organization as a whole.

Instead of power politics (hard, soft, or smart), organizations need to move to more deliberate, structured, and objective governance mechanisms. Good governance is defined more by quantifiable measures than by qualitative conjecture. Sound governance is driven by return on investment, risk mitigation, strategic business alignment, and technical compliance rather than I need, want, like, feel, and so forth. Facts need to rule over fiction. Governance should not be a game of power politics.

Henry Mintzberg, the well-known management scholar, identified three mechanisms for managers to exert influence in the organization (Wall Street Journal, 17 August 2009):

1. Managing action—“managers manage actions directly. They fight fires. They manage projects. They negotiate contracts.” They get things done.

2. Managing people—“managers deal with people who take the action, so thy motivate them and they build teams and they enhance the culture and train them and do things to get people to take more effective actions.”

3. Managing information—“managers manage information to drive people to tale action—through budgets and objectives and delegating tasks and designing organization structure.”

It is in the third item—managing information—that we have the choice of building sincere business cases and creating a genuine call to action or to devolve into power politics, exerting hard, soft, and smart influence to get what we want, when we want it, and how we want it.

When information is managed through the exertion of power, it can be skewed and distorted. Information can be manipulated, exaggerated, or even buried. Therefore, it is imperative to build governance mechanisms that set a level playing field for capturing, creating, calculating, and complying with a set of objective parameters that can be analyzed and evaluated in more absolute terms.

When we can develop decision support systems and governance mechanisms that take the gut, intuition, politics, and subjective management whim out of the process, we will make better and more productive decisions for the enterprise.


Share/Save/Bookmark

December 31, 2008

Comments from OMB's Chief Architect: Kshemendra Paul

Recently, Kshemendra Paul, Chief Enterprise Architect, at the President's Office of Management and Budget (OMB) made the following critical comments to me about business cases and pilots and incorporating these in the Systems Development Life Cycle:

"I was online and came across your site -
http://usercentricea.blogspot.com/2007/08/system-development-life-cycle-and.html.

I had two comments I wanted to share. First, I would recommend you highlight a business case step, a formal decision to move out of select/conceptual planning and into control. While this is implied, it is such a crucial step and we don't do it well - meaning that we don't force programs to work through all of the kinks in terms of putting forward a real business case (tied to strong performance architecture).

Also, this is a step that is inevitably cross boundary - either on the mission side and for sure on the funding side.

Second, I'd like to see more emphasis on smaller scale rollout or piloting. The goal of which is to prove the original business case in a limited setting. Nothing goes as planned, so another objective is to have real world data to refine the over all plan."

I completely agree with Kshemendra on the need to develop business cases and do them well for all new initiatives.

Organizations, all too often, in their zeal to get out new technologies, either skip this step altogether or do it as a "paper" (i.e. compliance) exercise. Symbolic, but wholly without intent to do due diligence and thus, without any genuine value.

Therefore, whenever we plan for new IT, we must ensure strategic business alignment, return on investment, and risk mitigation by developing and properly vetting business cases through the Enterprise Architecture and Investment Review Boards.

It's great to want to move quickly, get ahead of the pack, and gain competitive advantage by deploying new technologies quickly, but we risk doing more harm than good, by acting rashly and without adequately thinking through and documenting the proposed investment, and vetting it with the breadth and depth of organizational leadership and subject matter experts.

Secondly, as to Kshemendra's point on doing pilots to prove out the business case. This is an important part of proofing new ideas and technologies, before fully committing and investing. It's a critical element in protecting the enterprise from errant IT investments in unproven technologies, immature business plans, and the lack of ability to execute.

Pilots should be incorporated along with concept of operations, proof of concepts, and prototypes in rolling out new IT. (See my blog http://usercentricea.blogspot.com/2007/08/conops-proof-of-concepts-prototypes.html)

With both business cases and pilots for new IT projects, it's a clear case of "look before you leap." This is good business and good IT!

Share/Save/Bookmark

October 21, 2007

Circumventing the CIO—What’s the Harm?

One of the most difficult challenges we face as enterprise architects is when end-users don’t ask permission, but instead ask forgiveness.

The typical scenario is that a division or unit or group of end-users decides to go out and purchase some new IT widget, gadget, or system without going through the CIO shop. (I know this shouldn’t happen if the CIO controls the IT funding, but even then someone always finds some money squirreled away and decides to use it for something they weren’t supposed to or in some cases even bypasses the money channels altogether, getting a freebie from a eager vendor looking to build or test some new capabilities to sell later to other customers).

Well, where’s the harm?

Oh my G-d, where should I start…

Innovation from the field and operators is great, but bypassing the CIO shop circumvents the structured processes and good governance that is in place to ensure projects succeed. Without these mechanisms, IT project can be at tremendous risk:

  1. Business Case—Without a business case, the justification for the IT project was never made, return on investment not calculated, alternatives not considered, and the best course ahead not properly laid.
  2. Investment Review Board—Without IRB vetting, the senior-level sponsorship has not been solidified, the project has not been authorized, and its priority has not been set with respect to other, maybe more critical, projects that the enterprise needs; further, the project may not have adequate life cycle funding; additionally, the project is likely not being ongoingly monitored and managed by leadership and enterprise subject matter experts for cost, schedule, and performance.
  3. Enterprise Architecture Review—Without an EA technical review, the IT project may align with the target architecture and transition plan, may not be interoperable with other systems, may not meet enterprise technical standards, may overload or be incompatible with existing infrastructure, may be duplicative of other investments, may not be the best or most cost-effective technical solution, may not meet various legal, regulatory, and other compliance requirements.
  4. System Development Life Cycle—Without following a defined, repeatable, and measureable SDLC process, the project risks failure by not having adequate and documented planning and requirements, design, development, testing, implementation, training, operation and maintenance, and disposition.
  5. Project Management Plan—Without a project management plan, projects are at risks for being mismanaged, having cost-overruns, schedule delays, and quality problems.
  6. IT Security Plan—Without an IT security plan, the project is at risk in terms of the confidentiality, integrity, availability, and privacy of the information.

No question, from an end-users perspective, there are quite a few hurdles to go through in implementing a new IT project. An if we’re honest with ourselves, the process can be onerous. Therefore, the CIO and his staff needs to work to streamline the processes, integrate them, provide the users with job aids and excellent customer support. Additionally, there should be a quick pass process for getting those “emergency” (must have now) projects through quickly (although not any less comprehensively).

The key is to balance the needs of the enterprise (ensuring mission execution and sound stewardship of enterprise resources), end-users (supporting innovation and operators ability to do their jobs successfully and safely), and customers or citizens (bringing new products or services to market quickly, reliably, and at high quality levels). To do this we have to balance the necessary processes and governance to ensure IT projects’ success with the imperative to foster innovation and deliver quality and speedily to market.

So as an enterprise architect, what do you do when a end-user asks forgiveness, instead of permission?


Share/Save/Bookmark