Build a Business Case — Project Success Tips from Project Failure Blog

I’m commenting on the project success checklist at Michael Krigsman’s Project Failure Blog.  My comments are scattered among his notes (excerpted below).  I’d love to hear your comments on the details behind some of these factors as we go along:

1. Build a business case…
 The business case must rigorously state why the project is necessary…

At a minimum the business case needs to lay out:

  • What the project is supposed to accomplish (objective)
  • The problem it solves or the opportunity it exploits (As Is)
  • The proposed solution or approach (To Be)

…how it supports organizational goals

Demonstrate this support by identifying the:

  • Business or technology strategy enabled by (or driving) the project/program
  • Deliverables of the project, outcomes generated by the deliverables, the benefits expected, and how the outcomes generate the benefits (tangible and intangible)
  • Expected return (ideally calculated with both quantitative and qualitative measures to mirror the tangible and intangible benefits)

…and describe the resources required to achieve those goals.

Very simple, actually: people, places, and things…

If your business case can’t stand up to careful scrutiny and evaluation, then it’s highly likely the project will experience significant downstream problems.

No doubt…it is critical to validate deliverables and work packages by explicitly reviewing the business case.   For large projects or programs, I’ve learned to ask to see (or at least discuss) the business case presented to a customer’s capital committee (or other similar body).  One should at least master the contract, statement of work, service agreement, and any change control language therein. 

Such documents express what the most important stakeholders — e.g., sponsors and financial types — expect to see delivered from the project.   Skimping on formal business case validation is a common mistake for inexperienced project managers or consultants.   Eager to make a good impression, they jump into working away on schedules, requirements, code, config, etc.   They assume that what they’re being told to work on is the “right” work, and we know what assuming does…

2 Responses

  1. […] Build a Business Case — Project Success Tips from Project Failure Blog […]

  2. […] of project success and trouble factors (I’ve posted on them a number of times, especially here, here, and here), but I’d like to take it to the next […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: