Anticlue

Conceptual Phase

The conceptual phase of the project lifecycle defines a the project, so management can decide to pursue or not. The purpose is to yield the tools, so someone can make an informed decision and envision the project's intent, scope, benefits and costs. There are several tools that can be used to paint the picture for executive management.

One of the first items that needs to be completed is to determine what is required, needed, and or desired. This is done with simplified use case modeling. Discover the actors, their functions, and goals. Detail these use cases in simple paragraphs to capture the essense of the case. (More elaborate use cases are completed as a part of the building phase of the project)

As you are discovering the intented usage of the system, it is a good idea to start a risk list, and how you intend to manage each risk. Its best to identify and start working on risks in the beginning instead of the end.

Since no one really referrs to the same term in the same manner, another item to have is a glossary. This will help to define terms. I'm not familiar with other industries, but in healthcare there are several ways to refer to the same thing. For example the unique number for a patients visit can be either serial number, patient case number, encounter number, account number, and so on.

After establishing the use cases at a high level, it is time to create the vision document. This document has many components to capture the intent of the new system. One part details the problem that is at hand in terms of the root cause. Normally for technology business cases, the problem is a business processing problem for which a technology solution can help or eliminate. Another part of the document details the stake holders. This defines who will be affected by the proposed project and how they will be affected. The document also includes a portion which covers the functional requirements of the system.

If you think the vision statement just isn't clear enough, sometimes a prototype can help to illustrate the solution. This isn't a defined deliverable, but if you believe it will help to illustrate the point. It may be worth the time to invest.

Another deliverable is the implementation plan or software development plan. At this point, it is high level, but it does capture the needed resources, and time for tasks within the project. Its a work breakdown structure with people assigned to the tasks.

After there is a clear understanding of the vision of the system is going to be, the next document that emerges is the executive summary. This document provides a high level overview of the key findings and recommendations. It is also summarizes the current situation and the future if enhancements go as planned.

Finally the business case takes all of these components, and analyzes them in conjuncture with the total cost of ownership, including both one-time and recurring operational costs. The business case includes the executive summary overview, the risk list, functional requirements, the resource costs, and the vision of the new system. It is probably ideal to have this in a format that can be used for multiple projects so they can be compared to one another.

The business case should be the comprehensive document that allows executive management to decide the feasibility of the project.