The managers in your company have a lot of work they would like to get done this new year. This work is typically surfaced during the annual budgeting process. Usually, however, many more projects are proposed than your company has the ability to fund. Even if your company had the money, it won't have the people to do all of the work.
So, every company also has some kind of process that it uses to select and prioritise the project work for the coming year. The work that is prioritised highest is usually funded until there is no more money left. The projects that are rated lower in priority are cancelled or postponed.
This process of selection, prioritisation, and authorisation can be part of a portfolio management process, or it could be a part of your overall company yearly planning cycle. If your company managers are lucky, the process is stable and changes little from year to year. However, I've worked for companies that liked to reinvent the planning and budgeting process every year so that it dragged out twice as long as it needed to.
The planning process for small companies and organisations is usually looser and more informal. As companies get larger, it's vital that more structure and rigour be brought into the process. When it comes time to identify projects, for instance, a small company might list the proposed work on a whiteboard in a meeting with all other company managers.
That's not going to work for large organisations with thousands of people and hundreds of projects. Those companies will want a common template for defining the purpose and value of a project. Each project is going to need a business case.
I'm using the term business case to refer to the document that defines each project and lays out the high-level objectives, deliverables, estimated cost and effort, and scope. (Your organisation may have a different term for a similar document.) This is not the same as a project definition. The business case is completed during the planning process. The project definition is much more detailed and is completed before a project is ready to begin.
It's important that all the company managers understand how to complete the business case for each project, so that the business value of the project is understood by the reader and the project can be accurately compared with others. Each business case contains the following information.
Name and description of the project
Include a brief description of what is being proposed. Keep this to a couple paragraphs maximum, but also make sure that it provides enough information so that others can understand the work.
Category scheme
You may need to categorise the work into buckets that are of interest to your company. For instance, you might specify whether the project is internally focused or externally focused, whether it is high-risk or low-risk, or whether the project supports the current business or helps grow new business. All of these categories are specific to your company.
Assumptions
List the circumstances or events that must occur for the project to be successful.
Risks
List the external circumstances or events that would be a major impediment to the success of the project. Risks have a probability of occurring, but they are not guaranteed to occur. List the major risks of the project, and some high-level ideas about how you would respond to these risks.
Estimated business benefit
The business benefits of the work must be defined fairly precisely. You must try to determine tangible and intangible benefits in terms of process improvements, new products or markets, increased revenue, cost reduction, and increased customer satisfaction. If the work involves infrastructure or increased internal capability, the business benefit may be indirect. In all cases, try to quantify as much of the business benefit as possible.
Estimated cost
Provide a more detailed and accurate estimate of the cost. Your organisation may set a standard for the level of accuracy required. It's not reasonable, for instance, to always be able to create an estimate that will be within +/- 10 percent. You don't have all the details you need, and the project start date (if authorised) may be many months away. However, you should try to be as accurate as possible within a range of perhaps -10 percent to +35 percent.
Financial model
Your company should use one or more standard financial models that can be used to compare projects (ROI, EVA, etc.). This common financial model is applied to all projects so that they can be compared. You may have more than one financial model, but they should be consistent on all business cases.
Alignment
Validate the alignment by specifying how this work contributes and aligns to your organisational objectives, goals, and strategy. Alignment is very important, so be as descriptive as possible in explaining how this work aligns. Your organisation may want to come up with a common rating scheme for alignment to help compare projects.
Is the work required?
Specify whether you feel this work is required. For instance, work may be required for legal or regulatory reasons, even if it is not aligned and does not have business benefit.
Urgency/consequence of not performing this year
Describe what the consequences are of not performing the work. On many projects, this is just as important to know as the business benefit and alignment. Some work is very valuable to the organisation, but it is not urgent. Based on priorities and available funding, you may need to postpone some very beneficial and aligned work to a future year if the urgency is not there now.
You can see that a business case takes time and effort to prepare. So, you would not want to create one for a project that is only 100 hours of effort. However, assuming your company sets a reasonable threshold of effort, the business case should be prepared for all projects over that level.
Every company has some process to identify projects that are candidates for funding. It also must have a way to compare projects on an apples-to-apples basis so that it can determine which ones are more valuable than others. A business case document provides this level of information. It is much easier and quicker than having to do a formal project definition, but it contains enough information so that your management team can make intelligent decisions.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to firewalls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2004 TechRepublic, Inc.
4%
4%
