Why is it that many IT projects seem to lose direction and focus over time? Three percent of US federal government software projects are used as delivered. Forty percent of these same software projects are delivered but never used. Given that similar, depressing statistics exist in the commercial realm, what factors are contributing to this problem?

How do you keep your projects on track and on target? One overlooked technique is to step back and understand the framework for the project before you begin. This ability to build and understand the big picture for your software project allows you to use that context to guide project decision-making and communications from beginning to end.

Interesting how the best practices and required business case knowledge distill into the five W’s of fundamental project management: who, what, why, where, when. Even if your projects are mandated to your organization from “on high”, you have a responsibility to understand who needs to be involved, what needs to be done, where it fits into the organization and the existing operational environment, why the work needs to be done and when is it needed. This level of context is necessary regardless of your project size or complexity.

Let’s delve deeper into the five basic components of your project’s business case and big picture framework...

1. Who Needs to be Involved?
It is important to identify all of the stakeholders for your project, get them involved and keep them involved with the project. Brainstorming is an effective technique for identifying all stakeholders and their organizations that have an interest in the outcome of your project.

One technique: Take out a blank sheet of paper, draw a circle with your project in the center and graphically depict all other people and organizations that need to be involved. Your stakeholders should run the gamut from end users of the system to management to externals suppliers to organizations that use data generated by your application.

Once you have identified all of the stakeholders, you must determine the appropriate and expected level of involvement with the project efforts. One metric to use for evaluation is their stake and involvement with the end result. Another measure is their level of interaction with the completed system. Not everyone can or needs to be involved all of the time.

This documented and agreed upon project environment and stakeholder identification exercise forms the basis for your project communication plan and decision making architecture that will apply across the project lifecycle, from initiation and justification to closure.

2. What is the Problem Being Addressed?
Another facet of the business case for your project addresses the problem that the effort is targeted to solve. It is important to talk with management and subject matter experts in order to understand the full scope of what can be achieved. Ask them “What is the problem we are trying to solve or the opportunity we are addressing with this planned work effort?”

It is also important to have your project stakeholders define their criteria for project success and acceptance criteria relative to the problem and their slice of the operational world. Ultimately, these will be the metrics by which project success is measured.

The defined problem being addressed or opportunity being leveraged is used throughout the project in order to keep the project within scope and on track during its lifecycle. Targeting this definition and keeping work efforts within this framework allows the stakeholders and the project team to work together towards the same well defined project scope and consistently understood project goal.

3. Why Are We Doing This Project?
What is the justification for proceeding? In other words, why are we doing this project and choosing to solve the problem of leverage the opportunity? This is the basic reason or diver for spending the time and money to define and implement the software development project itself. There can be a wide range and combination of reasons, ranging from extra budget to be spent to regulatory requirements to an idea springing from executive management reading an airline in-flight magazine.

It is important to understand project justification from multiple points of view, such as those from the major project stakeholders. When defining the business drivers or justification for software projects, there are any number of reasons, including researching new technology, developing new or improved products, providing better customer service, being more competitive, making or increasing profits, doing this because other people have done it and we need to keep up, increasing our market share, being the first to market with something new, just because it’s cool, and because our constituents like or need this system or application.

Once you know why you are proceeding, make sure you can quantify the business drivers into measurable events that can be tested for at the end of the development lifecycle. It is imperative that the reasons why translate into the tangible results to be achieved. Combined with the “what” parameters of the high level project scope, this enables your project to deliver to its stakeholder what is was intended to provide.

These final two areas raise questions and concerns about the potential impacts of high-level project constraints and associated strategic risks.

4. Where Will the Work be Done? Delivered? Deployed?
It is always wise to begin planning your project with the middle and the end in mind. Within your business case, you need to address the numerous non-functional needs and constraints that may impact your development project downstream. The sooner they are recognized, analyzed and addressed, the less of a risk they will be.

We are looking for any known big picture constraints that will need to be addressed, such as location of infrastructure, legacy systems and interfaces, existing business processes and practices, and facilities issues.

5. When Does the Project Need to be Completed?
Time or project schedule more often than not emerges as a primary project constraint. Best to deal with it up front and ask your major stakeholders when the project needs to be completed and what is contributing to this deadline. Evaluate the schedule within the other business case facets and scope and make sure it makes sense.

Are there other major project constraints in addition to schedule? Budget? Resources? Functionality? Quality? Be wary when multiple primary constraints exist and pin down the primary one.

When managing the process of going from a business case to a functional, business level set of requirements to an operational system, it is imperative that the project manager eliminates the need to reinvent the way we develop technology. In addition, user and project stakeholder involvement, understanding and buy-in from project start to finish is essential to the project’s success.

Agreeing to and acting within the project scope this big picture framework provides allows the project planning and implementation stages to occur within a top down process that minimizes risk and manages the inevitable changes that will occur downstream. Defining and understanding this business case for your project adds a framework that can help your project achieve what it sets out to do with fewer omissions and no gold plating.


Copyright © 2002 Rhyming Planet Technologies, Inc., All Rights Reserved.


Click here to download the PDF document for this article.     

home | about you | about us | what we do | courses | articles | people to know | resources | contact | privacy