Coders want to code, and project managers want to make sure coders are coding efficiently. All too often, the question of why the coders are coding is left unanswered, or at the very least is not given careful enough consideration before a project takes off and gets a life all its own.
Why is this such a common problem? In large part, it's because doing a credible business case justification, particularly on a large project, is an enormous undertaking that spans various disciplines and departments within the company. A serious go/no-go business case evaluation can involve numerous focus groups, prototypes and data models - all so that an executive committee can simply say "no" and scrap all that effort with no tangible deliverable. When you are juggling a ton of projects, that's a tough pill to swallow.
You can get a great idea of the scale of this effort initiative from a sample business case, provided by our partners at gannthead.com, for one of the most complex IT projects out there - a data warehouse build out. The complete business case is available free to IT Business edge members here in the IT Downloads library. The document reads as a completed document, but you certainly can delete specific information to use it as an outline template. Or you can simply read it as a reference for what goes into making a solid business case.
The first thing you're likely to notice about the business case is that it is huge - 66 pages long, to be precise. It's written from the perspective of a consulting firm that has been brought in to evaluate three candidate data warehouse projects - two are targeted at optimizing business processes for cost savings, the other for meeting compliance in the (thankfully) highly regulated waste water treatment industry.
One quick takeaway from this document is that business cases are designed for people who are not intimately familiar with the project. A VP in accounting may have just heard lunch room chatter about how great a data warehouse will be. A lot of information goes into this. The recommendations section of this business case lays out a strategic phased approach to the project that included past events, including "strategic visioning," as you can see in the image below.
Before the business case was completed, a Strategic Information Plan (code for a really elaborate business requirements document) was reviewed and filtered as a basis analysis and prototyping that followed. For a project of this scale, focus groups were culled from business owner contingencies. Additionally, a simple prototype DW implementation was developed using sample data from the client. Vendors of data warehouse and similarly massive solutions often build out a simulation late in the sales process; there's no reason your internal team should not do the same in evaluating a major project on a business case model.
The business case then goes on to spell out the high-level business justification for each of the three candidate projects. Obviously, much of the conversation revolves around core financial metrics such as return on investment, as you can see in the image below.
However, the business case goes on to describe in great detail how the data warehouse project can impact business processes. Tomorrow, we'll look at some useful examples of how to describe the functional benefits of a major project with numbers, instead of just nebulous terms like "improve" or "optimize."