Project initiation

All projects begin with an idea. Perhaps your organization’s client identifies a need, or maybe your boss thinks of a new market to explore, or maybe you think of a way to refine your organization’s procurement process. When an idea forms, your project ha

All projects begin with an idea. Perhaps your organization’s client identifies a need, or maybe your boss thinks of a new market to explore, or maybe you
think of a way to refine your organization’s procurement process. When an idea forms, your project has entered the conceive phase. Sometimes this phase is informal. For a small project it may just consist of a discussion and a verbal agreement. In other instances, especially for larger projects, a project requires a formal review and decision.

Decision-makers consider the following two questions when deciding whether to move ahead with a project:
– Should we do it? Are the benefits we expect to achieve worth the costs we’ll have to pay?
– Can we do it? Is the project technically feasible? Are the required resources available?

If the answer for both is “yes”, then large or small, a project always has the following ingredients:

■ Specific outcomes: Products or results – What are you going to accomplish?
■ Definite start and end dates: Projects don’t go on forever
■ Established budgets: Required amounts of people, funds, equipment, facilities also

■ Success Criteria—Closely related to outcomes, list of measurable, verifiable results that will determine the success level of this project.
■ Project Context—Documents how this project relates to other projects within the product program and within the organization as a whole.
■ Project Dependencies—Closely related to Project Context, this section clearly documents any dependencies that could impact the results or success factors of this project.
■ Scope Specifications—Clearly designates the organizational, process, systems, and functional specification boundaries for the project. Should be high-level breakdown of the Goals and Objectives.
■ Out-of-Scope Specifications—To better communicate what is considered to be “in scope,” it is recommended that you clearly indicate the high level work items that are related (or associated) to this initiative, but that are not part of this project.
■ Assumptions—This section clearly communicates the underlying basis or things to be considered true in regards to any other aspect of this document. In most cases, the Scope, Out-of-Scope, Assumptions, and Constraints sections combine to clearly define what work will be performed by this project.
■ Constraints—This section lists any business event, schedule, budgetary, resource, or technical factor that will limit the options available to the project.
■ Risks—This section lists any uncertain event or condition (risk) that, if it occurs, could have a negative impact on one or more project success criterion (schedule, budget, quality, and so on). For each risk, it is good to list the related causes, the perceived negative impacts, the likelihood it will occur, and the planned response strategy and action items. See Chapter 14, “Managing Project Risks,” for more details.
■ Stakeholders—This section lists all the individuals, business units, and organizations involved in the project, the role(s) each is expected to play, and an indication of how they relate to one another. A Project Organization chart and a Stakeholder-Role Description Table is highly recommended here.
■ Recommended Project Approach—To better describe the intent of the initiative, this section highlights the recommended approach to getting the work of the project done and why it was selected over any other options. This section should note any key strategies, methodologies, and technologies to be used.