Section 5.10. Solutions Fast Track

5.10. Solutions Fast Track

5.10.1.

5.10.1.1. Project Management Process Overview

The project management process has seven major steps: define, organize, form the team, plan, manage, track, and close the project.

The project management process is iterative. You may have to repeat several steps a number of times in order to clearly define, organize, and manage your project.

Sometimes projects are terminated after this process is complete because the data developed during the definition stage does not support moving forward with the project.

It's better to terminate a project early before valuable time and resources are committed or expended on a project that, ultimately, is not the right project at the right time.

5.10.1.2. Project Origins

A project, by definition, is a unique solution to a defined problem. Projects can originate from a stated problem. These are needs-driven projects.

Sometimes projects originate from a proposed (or assigned) solution. These are solution-oriented projects. These still have to be validated and the underlying problem must still be defined.

Some project managers are handed a project by way of a project proposal. This assumes that some analysis and research has already been done. If a project proposal exists, the project manager should validate the proposal to ensure that the project is still appropriate, feasible, and desirable. Things change rapidly and an old project proposal may be out of date.

5.10.1.3. Validating the Project Proposal

Whether you're validating a project proposal or beginning the project definition phase, you should form a small team to help you with these initial tasks. Two (or three or four) heads are better than one.

Reviewing the project proposal you've been handed is the first step toward validating the proposal. Gather all related materials so you can properly evaluate the data contained in the proposal.

At minimum, a project proposal should have the problem and mission statement, the optimal or proposed solution, as well as some initial targets including scope, time, cost, and quality.

A more formal project proposal could contain data that makes the business case for the project showing how it aligns with corporate and/or IT strategies, how it addresses a need in the market, or how it addresses a customer/user need.

Each company may have a unique approach or attitude toward a project proposal. Follow your company's guidelines, but make sure you include the basics so you'll know what you're doing and what the project will entail.

If the project cannot be validated, you've either made errors in your research or the project should not be undertaken. Sometimes projects are scrapped at this stage if they cannot be validated.

5.10.1.4. Defining the Project

The definition phase includes these elements: problem statement, project mission statement, list of potential solutions, selected solution, and project proposal.

A clear, concise problem statement is fundamental to a successful project. Make sure you're solving the right problem with a well-crafted problem statement.

The project mission statement describes the desired outcomes or results, not how those results will be achieved. A well-written mission statement can help describe the gap between where you are and where you want/need to be.

The list of potential solutions should begin as a brainstormed list of all potential solutions. Don't filter ideas until all have been recorded.

Develop a list of criteria for the project (if possible) so you can determine optimal solutions. Criteria can include scope, time, cost, quality, market, or user requirements.

Develop a ranked list of potential solutions and select the best fit for both the stated problem and desired outcome(s).

5.10.1.5. Developing the Project Proposal

Develop a project proposal that outlines the problem, mission, selected solution, and the business case for the project.

Include other project details in the project proposal only if they are known or relevant to making the decision to move forward at this point. Otherwise, capture that data for later use.

Some companies neither require nor desire a formal project proposal. Develop the basic data for your own sake even if a formal process is not in place.

There are numerous methods for creating high-level estimates that you should be familiar with. Some help you develop better cost estimates and others help you develop better time/schedule estimates.

Remember that an estimate is really an educated guess, but it often becomes your project target. Avoid giving estimates until you have the data to support those estimates.

5.10.1.6. Identifying the Project Sponsor

The person who assigns the project to you is typically the project sponsor.

Ensure you are clear who the project sponsor is and that the project sponsor knows he or she is the project sponsor.

The project sponsor is the person who can rally corporate resources on behalf of your project, approve budgets and timelines, and help you stay on course with your project.

5.10.1.7. Gaining Validated Project Proposal Approval

Once you have defined the problem, mission, and optimal (or selected) solution, you should formalize this data in a project proposal.

A project proposal can be short or long, formal or informal, but it should capture at least the essential elements.

Sometimes the project manager and project sponsor may forgo a more lengthy or formal project proposal in favor of taking immediate action on an opportunity. The project manager and small team should still take time to define the project (problem and mission statement, potential and selected solutions) to both validate the fast action and to ensure everyone is headed in the same direction.

These initial definition steps can be performed very quickly with a small, focused team.

A project proposal, ideally, should be presented to the project sponsor for formal approval. This is the first of many checkpoints in the IT project management process that we'll discuss.

Formal project approval is important to ensure that the assumptions under which you're operating are correct, that you and the project sponsor agree on the basic project data and direction, and to assure you that you're covered later on if the project runs into trouble.