Two: Project Planning (High Level)

Process Descriptions


2.1 Prepare for the Project




After formal approval of the Project Charter during the Initiation process, a Project Manager is assigned along with the initial project team. Their first responsibility is to Prepare for the Project. The Project Manager must work to ensure that the Sponsor and/or Project Director and their performing organizations expectations and all available project information are effectively conveyed to the Project Team. This can be done collaboratively with the organizations management team.


Tasks associated with Preparing for the Project

2.1.1 Assign the Project Manager

2.1.2 Identify Initial Project Team

2.1.3 Review Historical Information

2.1.4 Conduct Project Kick-Off Meeting

2.1.5 Establish Project Repository


2.1.1 Assign the Project Manager

The Project originator (generally the Project Sponsor) will assign the Project Manager to the project. The Project Executive Sponsor and Project Sponsor and/or Director(s) are also confirmed. Because the Project Sponsors will champion the project within the organization, secure spending authority and resources, and provide support to the Project Manager, it is imperative that he/she be identified as early in the project management lifecycle as possible. Building the relationship between the Project Manager, the Project Sponsor and/or Project Director and the Executive Sponsor is critical to project success.


2.1.2 Identify Initial Project Team

The extent to which the Project Team has been defined at this point may vary. At a minimum the manager for the project and certain individuals who can provide support in preparing for the project should be identified.

During Project Initiation, a Project Charter was created and should include the governance model and resources for the Project Planning (High Level). The Charter is reviewed to confirm the roles required. With the help of appropriate Stakeholders, the Project Sponsor and/or Project Director should take the lead in identifying the names of individuals within the performing organization who could fill the roles and become Project Team members. In selecting the Project Team, definition both of the skills required to perform current tasks and of the skills required for future project tasks is needed.  Immediate project needs should be met first. Various areas of the Organization may be required to provide resources to the project in order to complete Project Planning (High Level). The Project Sponsor and/or Project Director must communicate with the affected areas of the performing organization, proactively gaining agreement and securing the necessary resources. After Project Team members have been identified, the Project Manager should provide them with a project orientation and review with individual team members their current and future roles in the project.  This establishes a baseline understanding of team members project responsibilities, which will be useful for conducting performance reviews later in the project.

Some organizations hold a planning meeting at the beginning of Project Planning (High Level), where all Key Stakeholders come together to review the Project Charter, discuss required roles for the next steps of developing the High Level Plan (Project Initiation Plan), and assign the Project Team members. In other organizations, establishing a Project Team is a less formal process. You should choose and use the method to identify your Initial Project Team that will work best for your project and within your organization.

Take the opportunity, from the outset, to establish the concept of a Project Team that comprises not only the folks reporting directly to you, but also your Project Sponsor, Customer Representatives, Customer Decision-makers, and all other players participating in the Project Schedule.


2.1.3 Review Historical Information

Development of the Project Initiation Plan will require review of documentation compiled or presented during development of the Project Charter. Materials and information reviewed may include:


2.1.4 Conduct Project Kick-off Meeting

When the Project Team has been identified, the Project Kick-off Meeting is conducted. The Project Kick-off Meeting is the event that formally marks the beginning of the project. It is most likely the first opportunity for the Project Sponsor and/or Project Director to assemble the entire Project Team to discuss his/her vision of the project, demonstrate support, and advocate project success. Project Team members are introduced to each other and given the opportunity to discuss their areas of expertise and how they will contribute to the project. The Project Charter is presented by the Project Manager and discussed in an open forum, to foster a mutual understanding of and enthusiasm for the project. At the conclusion of the meeting, Project Team members will understand their next steps, and will leave the meeting ready and excited to begin work.

The Project Manager can review the next Process of the Project and distribute the Project Initiation Plan Template and describe the approach that will be taken to complete the Process of developing the High Level Project Initiation Plan.

Prior to the meeting, an agenda and presentation highlighting the contents of the Charter should be prepared by the Project Manager.  The Project Manager should designate one of the Project Team members as the scribe for the session, to capture decisions, issues and action items.  The Project Charter and any applicable supporting materials are distributed to attendees for their review.  The review of the Project Charter contents ensures that expectations for the project and its results are in agreement.

Following the session, the decisions, issues and action items should be compiled into meeting minutes and distributed to all attendees.


2.1.5 Establish Project Repository

Maintaining information about the project in an organized fashion facilitates new team member transitions and creates a central point of reference for those developing project definition documents. Most importantly, it provides an audit trail documenting the history and evolution of the project.

All relevant project-related material, documents produced, decisions made, issues raised and correspondence exchanged must be captured for future reference and historical tracking.  The project repository can be kept as hard copy in a binder or notebook, or as electronic files and email folders, or both, at the discretion of the Project Manager, in accordance with organizational records management policies. Within the primary hard copy repository, information should be organized in indexed volume(s) to enable easy access. An index should provide reference to all material maintained electronically (for example, a file directory or e-mail folder by drive, directory, and filename). The most current hard copy of documentation should be kept in the primary hard copy repository, with earlier versions in the electronic file.

By the end of the project, a project repository may include the following materials:

The project repository should be available to everyone involved in the project and must, therefore, be considered public information.  It is not advisable to keep sensitive information concerning individuals on the project, such as salaries or evaluations, in the project repository. Some project-related documents may also be regarded as confidential.  A confidential project repository should be established in a separate location to secure sensitive information.

The organization of an electronic file system is at the discretion and preference of the Project Manager in accordance with organizational records management policies.  All files related to the project should be grouped by categories within project-specific folders.  The structure should be intuitive so that anyone browsing the directory can easily locate needed information.


2.2 Develop the Project Initiation Plan




The purpose of this process is to define the overall parameters of the Project. This process is shaped by the development of the Project Initiation Plan.  The Project Initiation Plan is comprised of the business case (refined from the Charter), overall goal, specific objectives, success criteria, scope, high level schedule, stakeholder accountabilities, the communication plan, benefits and costs, governance and resourcing, the management approaches and a high level risk plan. The Project Initiation Plan is a High Level overview of the project and will serve as the foundation for all future efforts. This is an interactive process with the Key Stakeholders to come to agreement on the overall parameters of the project.


Tasks associated with Developing the Project Initiation Plan

2.2.1 Refine the Business Case

2.2.2 Define Goals and Objectives

2.2.3 Define Project Scope

2.2.4 Develop High-Level Schedule

2.2.5 Identify Stakeholder Involvement

2.2.6 Develop Communications Plan

2.2.7 Establish Benefits and Budget

2.2.8 Define Governance and Resourcing

2.2.9 Define Management Approaches

2.2.10 Develop High Level Risk Plan

2.2.11 Produce Project Initiation Plan


2.2.1 Refine the Business Case

The Project Initiation Plan starts with an Executive summary that introduces the project by giving an overview of the project with a brief background as to how it came about.  This should include a further refinement of the Business Case (Business Need) that was originally defined in the Project Charter. It would include the business drivers (that is, market demand, business need, customer request, technological advance, legal requirement, or social need) that created the problem, opportunity, or business requirement.

The executive summary should also include a Project Description of the project that includes the opportunity, purpose of the project, what the project will deliver and any other high level expectations of the project.  It should identify if this is part of a larger project or if it has follow on projects. Finally, it should identify the customers and anticipated consumers of the project and why they will benefit from the project.

As you complete all the tasks for Project Planning (High Level) and develop the Project Initiation Plan, you may revisit and continually refine the business case as the project unfolds.


2.2.2 Define Goals and Objectives

The purpose of developing the Overall Goal and Specific Objectives is to provide a clear picture of what the project is trying to accomplish. It is also the basis for documenting the Success Criteria that will explain how you will know the overall project was a success. The input for this task is the Project Charter and the Executive Summary that you just completed. To write an effective, comprehensive list of Specific Objectives and Success Criteria, the Project Manager must work with the Project Sponsor and/or Project Director and any appropriate subject matter experts and Key Stakeholders.

If issues or conflicting project expectations are uncovered while developing the Specific Objectives and Success Criteria, the Project Manager must communicate with Key Stakeholders to resolve the discrepancies, elevate the issues when appropriate, and obtain consensus. Decisions that impact project expectations significantly should be thoroughly documented.

This task contains:

Developing the Overall Goal, Specific Objectives and Success Criteria is a collaborative effort. Working with the Project Sponsor and /or Project Director, the Project Manager should document the outcomes that must be achieved in order for the project to be considered a success. These critical success factors should correlate with the specific objectives of the project.

The Overall Goal should encapsulate the purpose of this project in a single sentence. The Specific Objectives should name the objectives and describe the objectives and their Success Criteria.

For each objective, identify the following: Objective Name, brief description (what and how) and the success criteria which will explain how you will know the objective was met.


You can use the S M A R T Objectives as a guideline in developing the project Objectives.

List your objectives, then make sure that each is SMART:


Explicit, clear, understandable ( for example, written from a business perspective)


Quantifiable (typically making reference to business metrics, quantity, quality, cost, or time)


Reachable, within capabilities


Relevant, right approach


Specific time period


An effective way to define a critical success factor is to complete the following sentence:

"The project will be a success if _____________."

For example, here's a critical success factor defined for the development of a SDLC (Software Development Life Cycle) methodology:

"The project will be a success if the SDLC methodology developed meets the needs of application developers and application development Project Managers within Cornell. It must be able to be implemented for any application development project, regardless of the development environment."


2.2.3 Define Project Scope

The purpose of defining Scope is to clearly identify what will actually be included in the project and what is beyond the range of activities and results to be included. By clarifying this at the inception of the project, people can be fully aware when the project has scope creep, the tendency to add activities and outcomes to a project without fully recognizing the impact.

This is where we will introduce one of the major concepts that is incorporated throughout this Guidebook: Triple Constraints. The Triple Constraints concept is derived from a project's constraints: Budget, Scope, and Schedule, which determine the resulting Quality. Because the constraints are interdependent, they are defined and managed together. You cannot change one with out affecting the others. The work products that define the project and its desired outcome are called the Triple Constraints and are first created during Project Planning (High Level).

The purpose of defining the Triple Constraints is to:

During this Task we will be focused on Scope, but you can begin to think about how the Scope is interrelated with Budget (Cost) and Schedule (Time) as we complete the Project Initiation Plan. Remember that you cannot change one of these without affecting the others.

The written scope definition serves as input in future project planning efforts (see Project Scope section of the Project Initiation Plan). The scope definition below is a sample generally used for technology projects. The Scope definition should include a clear statement on what is in scope and what is out of scope. If during this Project Planning (High Level) process some items are uncertain they should be listed and put on an open issues list for resolution before Project Planning (Detail Level) begins:

The Project Manager and Project Sponsor and/or Project Director must be specific about what is in scope and what is not in scope, as the weaker the boundary between the two, the more difficult it will be to affect the change control process if required later in the project. Also, the details regarding what is in and what is out of scope are critical input to the creation of a Project Schedule (High Level) and its later refinement.

The Project Charter provides input for defining Project Scope relative to the business need and project description and benefit for the organization undertaking the project. The scope statement will build on the information in the Project Charter by developing an approach to deliver that result, and by developing additional detailed information about the scope of work to be done. Interviews with other Project Managers who have had experience developing scope statements for similar projects can also be helpful.

While writing the Project Scope, the Project Sponsor and/or Project Director, Project Manager, and Customer Representatives must consider the effect the outcome of the project may have on the performing Organization. The organization must be prepared to support the product once it is transitioned.  If implementing the product will result in a change to the way the organization will conduct business, the Project Manager, Project Sponsor and/or Project Director, and Customer must anticipate impacts and communicate them proactively to the Consumer community.  Sometimes people are resistant to change.  Selling the positive aspects of the project and the benefits of its product throughout the projects duration will facilitate acceptance. If adaptation to the new environment requires new skills, the Project Manager will need to identify appropriate training opportunities and include them in the Project Scope and Project Plan.

Scope creep is a major bane of project management. How do you combat it?  By pre-empting it with a thorough, accurate, precise, and mutually agreed upon Scope definition.  Avoid words and statements that require judgment or invite interpretation, such as "improve," "enhance," "better," "more efficient," and "effective."  Use numbers, facts, and concrete results. Use quantifiable terms, and provide target values or ranges.  Emphasize outcome, not process.  A statement like "We will work very hard for a long time to improve our response capability and enhance our effectiveness" belongs in a Dilbert cartoon, not in a Scope definition.


2.2.4 Develop High-Level Schedule

A Project Schedule is a calendar-based representation of work that will be accomplished during a project. Developing a schedule means determining the start and end dates for all tasks required to produce the projects product. The High Level Schedule should include key deliverables and milestones.

At this early stage in the project management lifecycle, information required to complete a Project Schedule is known only at an overview level, often based solely upon the expert judgment of the Project Manager or other individuals with experience managing projects with similar lifecycles. Even at a high level, this information still provides insight into preparing the first draft of a Project Schedule. The activities documented in the schedule at this early stage will be further broken down during Project Planning (Detail Level), when the schedule will be refined to include the specific individuals assigned and the amount of time required to complete the work.

A Work Breakdown Structure (WBS) is a very useful work product that a Project Manager should create to facilitate development of a Project Schedule. A WBS is a graphical representation of the hierarchy of project deliverables and their associated tasks. As opposed to a Project Schedule that is calendar-based, a WBS is deliverable-based, and written in business terms. All tasks depicted are those focused on completion of deliverables. There are no dates or effort estimates in a WBS. Using a WBS, Project Team members are better equipped to estimate the level of effort required to complete tasks, and are able to quickly understand how their work fits into the overall project structure.

The first hierarchical level of a WBS usually contains the phases that are specific to both the Project Management Lifecycle and the Product Lifecycle of the project being performed. For example, the first level of the WBS for a software development project might look something like this: Project Management, Definition, System Design, System Development, System Implementation, and Transition to Steady State.

For this reason, a WBS may be reused for other projects with the same lifecycle. Once the first level has been completed, it is broken down into more detailed sub-levels, until eventually all deliverables and tasks are depicted at the level you intend to manage the project. When defined to the appropriate level of detail, a WBS is very useful as input to both creating and refining a Project Schedule, including estimating the required resources, the level of effort, and the cost.

In Project Planning (High Level), the information required to produce a complete WBS representing the entire project will not be known in sufficient detail. There will be enough information, however, to enumerate the tasks required to produce the High-Level Schedule. The WBS is not static - the Project Manager should work with the Project Team throughout the project lifecycle to refine the WBS and use it as input to refining the Project Schedule.

The following figure is a sample High-Level Work Breakdown Structure organized by Project Management and System Development Lifecycle for a software development project.


The WBS is an effective management tool that can help you control the project and understand project status. Be careful, however, not to drown it in so much detail that it becomes difficult to interpret and a nightmare to maintain. The WBS that you create must present a clear understanding of the project and the work that must be performed to produce a successful product or service. Save the detailed tasks and other minutia for the Project Schedule.

Once you have the high level work break down structure (WBS) it is helpful to list all the Key Tasks and Deliverables of the Project. This is another way to develop the next level of the WBS.


The following table is a sample of Key Deliverables organized by Project Management Lifecycle and System Development Lifecycle. It is structured as a matrix by type of deliverables to help ensure all major tasks and deliverables for the project are identified.

Project Management Key Deliverables

Project Management Lifecycle


Project Charter

Project Initiation


Project Initiation Plan

Project Planning (High Level)


Develop Project Team Learning Plan

Project Planning (High Level)


Project Plan (Detail) with Baseline Schedule

Project Planning (Detail Level)


Transition Plan

Project Planning (Detail Level)


Issues Log (Open/Closed)

Project Execution and Control


Change Control Log

Project Execution and Control


Risk Plan

Project Execution and Control


Communication Plan

Project Execution and Control


Budget / Tracking

Project Execution and Control


Project Closeout Report

Project Execution and Control


Lessons Learned

Project Closeout

Infrastructure Design

System Development Lifecycle


Define Technical Architecture Strategy



Define Application Architecture Strategy



Define Application Security Architecture


Business Process Documents



Business Requirements Definition



Conference Room Pilot (CRP)



Create Future Process Design Model (To Be Process)



Reconcile Business Requirements (Fit / Gap)



Functional Specification

System Design

Business Requirements Mapping Documents



Analyze High Level GAPS

System Design


Map Business Requirements



Define Application Setups

System Design


Design Security Profiles

System Design

Module Design and System Development



Define Application Extension Strategy



Define System Development Standards

System Design


Define Application Functional Design

System Design


Define Database Objects

System Design


Create Application Extension Technical Design

System Development

Data Conversion and Interface Programs



Define Conversion Standards

System Design


Perform Conversion Data Mapping

System Design


Design Conversion Programs

System Design


Develop Conversion Programs

System Development


Convert and Verify Data



Define Interface Standards

System Design


Perform Interface Data Mapping

System Design


Design Interface Programs

System Design


Develop Interface Programs

System Development

Project Documentation Strategy

Transition to Steady State


Publish User Guide

System Development

Business System Testing Documents



Develop Test Strategy



Develop Unit Test Scripts

System Design


Develop System Test Scripts

System Design


Perform Unit Test

System Development


Perform Acceptance Testing

System Development

Adoption and Learning Documents



Develop Campus Readiness Plan



Develop User Learning Plan

System Development


Conduct User Learning Events

Transition to Steady State


Conduct Effectiveness Assessment

Transition to Steady State

Production Migration Documents



Define Transition to Steady State Strategy

System Design


Prepare Product Environment



Measure System Performance

Transition to Steady State

User Acceptance



User Acceptance Test Results Completion Certificate


A preliminary list of the roles and skills required to perform the necessary work (for example, Architect, Team Leader) should be created at this stage in the project. This list will be refined in subsequent work as more becomes known about the project. Additional constraints, such as completion dates for project deliverables mandated by the Project Sponsor, Customer, or other external factors, will most often be known early in the project management lifecycle and should be noted. There may be financial, legal, or market-driven constraints that help dictate a projects high-level timeline.

Using the information from the WBS and a list of Key Tasks and Deliverables, the Project Manager should create a worksheet to begin to document effort estimates, roles and dependencies in preparation for creating a Project Schedule using a project management tool. It may also be helpful to solicit input from past Project Managers, Project Team members and subject matter experts for insight into past project performance, and to help uncover required activities, dependencies, and levels of effort. Researching and documenting this information first will not only help organize thoughts on paper, but may bring new information to light.

Once this has been completed and reviewed, the Project Manager should enter the information into a project scheduling tool (for example, Microsoft Project) to produce the High-Level Project Schedule.  The High-Level Schedule will include the Key Tasks and Deliverables that were developed during this planning stage and the Milestones of the Project. Information typically required for a project management tool includes activities, effort estimates to complete the activities, the role or individual assigned to them, and any known dependencies among them.  The activities entered into the tool should be those required to complete the deliverables described in the Project Scope statement. Information will only be known at a very high level at this point, but will be refined during Project Planning (Detail Level).


As you create the High Level Schedule, your decisions have underlying assumptions. Now is the time to examine those assumptions.  In particular you want to include assumptions about scope, time frame, deliverables, policies, schedules, technologies, resources, and costs. Assumptions you record provide documentation for your budget estimate. Make sure to list these assumptions in you Project Initiation Plan following the High Level Schedule.


2.2.5 Identify and Document Stakeholders Involvement

Stakeholder Analysis and Management is a critical part of every project. Stakeholders include all individuals, groups, and entities internal or external to your organization that contribute to the project or are impacted by, or can impact, the outcomes of the project. Stakeholders can come from many areas: Project Governance (Executive Sponsors, Sponsors, Directors, Steering Committees, Consultants, and Project Teams), Technology Groups, Customers, Subject Matter Experts, Suppliers, Support Groups, Training Groups, Special Interest Groups, other Interdependent Project Teams, Auditors, Legal, Purchasing, etc.

Normally, major or key stakeholders are identified during the Project Planning (High Level) and documented in the Project Initiation Plan and is reviewed again during Project Planning (Detail Level). You will complete Table 9 in the Project Initiation Plan with the Project Role, Name of Stakeholders, University Role, Project Responsibilities/Accountabilities, and their commitment of time to the project. This is where you set expectations for the Stakeholders, define their roles, establish individual accountabilities, and gain agreement on those accountabilities. This activity is critical to the successfully initiation and implementation of the project.

Failure to address stakeholder issues is a major cause of project failures.

In defining the High-Level Schedule for the Triple Constraints (Budget, Scope, and Schedule), a preliminary list of roles and skills required for the project will be produced. This list may be useful when creating the list of stakeholder roles needed to perform the tasks leading to the desired project outcome and the responsibilities for each role. Even if the information is known only at a preliminary level, it is helpful to the Project Manager.  When documenting roles and responsibilities, the Project Manager should evaluate whether the individuals being assigned are in appropriate roles, if this information is known. If it is decided that assigned individuals may be weak in certain areas, or there are no individuals to fill certain roles, the Project Manager documents this information.

One of the greatest challenges in project management is getting the work done by individuals and business units that do not report to the Project Manager, or even to the Project Managers entire chain of command. The earlier you can identify whom you need cooperation from, and the more detail you can provide as to the extent and outcome of that cooperation, the better your chances of actually influencing the work done. Make your case early and convincingly (emphasizing how the folks that DO have influence will benefit), and you may actually get them to do what your project requires.


2.2.6 Develop a Communications Plan

The Communications Plan (Table 10 in the Project Initiation Plan) describes the means by which project communications will occur. The communication process must be bi-directional. The Project Manager must receive input from Project Team members and Stakeholders about their information and communications requirements, determine the best and most cost effective way in which the requirements can be met, and record the information in a formal, approved document. Similarly, the Project Manager must provide details to the team and the internal and external Stakeholders regarding the communications he/she expects to receive, and document his/her requirements in the plan.

The Communications Plan is developed early in the project management lifecycle and documented in the Project Initiation Plan. It must be reviewed regularly throughout the course of the project and updated as necessary to ensure it remains current and applicable.

Some of the requirements the Project Manager and internal/ external Stakeholders will need to communicate and understand, and which should be documented in the Communications Plan include:

The methods and technologies used to communicate information may vary between departments or organizations involved in the project, and by Stakeholders. These differences must be considered when creating a Communications Plan.  Are there any other considerations that may affect or limit communication?

A great way to communicate with the Project Sponsor and/or Project Director and the Customer Representatives is to conduct a status meeting. Some items to discuss during the meeting include accomplishments, progress against schedules, work to be done, and any open issues that need resolution. A Project Status Report should be prepared and reviewed during the meeting. Use the Project Status Report template as a guide.




2.2.7 Establish Benefits and Budget

Benefits (Table 11 in the Project Initiation Plan): By documenting the benefits of the project in the Project Initiation Plan you will gain support and buy in from all the stakeholders and continue to justify the project and obtain approval to proceed. Benefits can be classified in either quantitative or qualitative terms and should be assigned a benefit class: Increase in revenue, avoid revenue loss, reduce costs, avoid cost increases, improved service, legislative/regulatory mandates, meet competition/protect or increase market share, etc.

Budgets (Table 12 in the Project Initiation Plan): Using available tools, the Project Manager calculates the preliminary budget that will be required to complete project activities. All aspects of the project, including the cost of human resources, equipment, travel, materials, consultants, and supplies, should be incorporated. At this point information will be presented at a summary level; to be refined during Project Planning (Detail Level), as more detailed information becomes known. However, the budget should be more detailed and more accurate now than it was during Project Initiation (Project Charter). The Project Manager should use manual or automated tools to generate a Preliminary Budget Estimate. The budgeting tools may be simple spreadsheets or complex mathematical modeling tools. (See Figure 2-9 for the Preliminary Budget Estimate.) For historical purposes, and to enable the budget to be refined, the Project Manager should always maintain notes on how this preliminary budget was derived. Cost estimating checklists help to ensure that all preliminary budgeting information is known and all bases are covered.

The Project Manager must also have a general understanding of the cost of both the human resources and the equipment and materials required to perform the work. The method by which staff and products will be acquired for the project will directly affect the budgeting process.

In coming up with the projects budget, many Project Managers fall into one of two extremes, depending on their temperaments and prior experience:

  • those who are risk-averse or have been burned in the past tend to "aim high," inflating the Project Budget to protect against all eventualities

  • those who are "green," optimistic, or afraid of rejection often "aim low," underestimating the risks and realities

Neither approach, of course, is optimal; both put the whole project at risk, the former by either disqualifying the project in view of limited funds or inviting uninformed wholesale cuts, the latter by setting unrealistic expectations and guaranteeing multiple additional requests for more money. The best approach is to use organizational experience, your own expertise, and the best advice you can muster to predict with the greatest possible accuracy what the project will actually cost, and then set up a separate change budget.

Above all, document the basis of your estimates!


2.2.8 Define Governance and Resourcing

Governance (See Figure 4 in the Project Initiation Plan): The Governance of a project should describe the manner in which it will function.  It is the accountability framework and may be quite different from the organizations normal management structure. The depiction of the projects governance structure is usually put in a graphical chart showing accountable relationships and includes the Project Role the person has and their name. It also includes the groups they belong to (Steering Committee, Technical Team, Functional Team, Campus Readiness Team, etc.). Agreeing on the project governance structure is a critical step for the project. It brings clarity to the project team on accountabilities and it is used later when we define the management approaches on how issues are escalated and the change control processes.

Resourcing (See Table 14 in the Project Initiation Plan): A number of constraints, financial, political, and organizational, may dictate the methods by which required individuals, equipment, and materials are acquired. The Project Manager needs to be aware of existing resource acquisition policies, guidelines, and procedures. In addition, the preferences of the performing Organizations management team and/or the Customer Representatives may influence acquisition decisions. In any case, the strategies defined should satisfy the needs of project Stakeholders. Information from similar past projects can be used to gain an understanding of acquisition strategies; those that were successful and applicable may be considered for implementation on the current project.

Once the Project Manager assesses the needs of the project, financial considerations, time constraints, and individual skills and availability, a method is defined for acquiring project staff. Depending on the way different organizations relate to one another, strategies used to acquire staff may vary. It is important for the Project Manager to understand the reporting relationships, both formal and informal, among different organizations, technical disciplines, and individuals. Staff may be allocated from within an organization or from an outside source using an established staff procurement procedure. The Project Manager should work with the Project Sponsor and/or Project Director to determine staffing options.

The skills required for the project, influence the means by which staff members are acquired. If there are limited qualified in-house resources available to staff a project or if a Project Manager has had positive experiences with contract staff, for example, he/she may elect to retain contractors to fill the positions rather than allocating resources from within.

As is the case with human resources, a method is defined by which equipment, materials, and other non-human resources will be obtained. The Project Manager, in conjunction with the Project Sponsor, should determine the method to be used to acquire these resources.

Regardless of how staff and products are acquired for the project, the Project Manager must add the estimated cost of all resources to the Preliminary Budget Estimate. (See 2.2.4 Develop High-Level Schedule and 2.2.7 Establish Budget)

Table 14 in the Project Initiation Plan is a summary of all the resources needed including those already identified and those that are yet To Be Determined (TBD). This table provides a clear picture of the number of resources, the percentage of time needed, and the time frames they will be needed, along with the name of their manager (if applicable).

Don't forget to document in the Project Initiation Plan any important resourcing comments, constraints, and/or issues that are important to understanding the High Level Schedule and Budget.

Any manager providing resources of any significance to the project should be identified as a stakeholder and usually needs to sign off on the Project Initiation Plan.


2.2.9 Define Management Approaches

It is important to define early in the project the approaches used to manage the project. In general, the Cornell Project Management Methodology (CPMM) will be applied as the project management approach to implementing your project, specifically, planning, controlling, and closing out the project. If there is a Product Lifecycle approach being used, it should be identified. These approaches will be documented in the Project Initiation Plan. (See the Management Approaches section of the Project Initiation Plan) Mode of Accomplishment

The mode of accomplishment is an overall statement on how the project will be accomplished. Will it be totally done by Cornell resources, or will outside partners be involved? Who is the Customer and how will their participation be needed? How will the project be organized? Are all the stakeholders and their responsibilities clear or are some yet to be defined? Will the project team need any training to develop individual or group skills to enhance project performance? How many end users will be impacted by this project? Will it require a Campus Readiness activity? Will a transition team be required? Is training a significant part of the project? How will you ensure the project will satisfy the needs for which it was undertaken? Are their quality standards that need to be met? How will the quality of the project be assured? Issues Management

Critical to the success of a project is to manage issues that surface from the very beginning of a project. It is important that all key stakeholders participate in resolution of issues that might affect the Triple Constraints (Scope, Time, and Cost) and resulting quality.

Here is a sample of a standard issues management procedure: Change Management

Change is expected to occur during the life of any project, but that change must be managed if the project is to succeed.  The Project Manager and the Sponsor need to determine how change will be controlled during the project and make sure all team members are aware of the process.  Normally the Change Process begins when the Baseline Project Schedule completed during Planning (Detail Level) is approved. The change management procedure and required approvals should be documented in the Project Initiation Plan.

Here is a sample of a standard change management procedure:

  1. Complete a CPMM Change Order (Internal) and log the change requests in the CPMM Request for Change Log.  Complete the Impact Analysis Statement of the change.

  2. Submit the CPMM Change Order (Internal) to the appropriate people for authorization.

  3. The Project Manager will track the CPMM Change Order (Internal) and log the status in the CPMM Request for Change Log:  (Proposed, Authorized, Denied, Deferred)

  4. The project manager reports on the status of the Change Orders in the CPMM Project Status Report (Template: CPMM Project Status Report).

The above change management process covers managing changes that are internal to Cornell.  If the project you are managing will involve changes to Purchase Orders or contracts with outside Vendors, then please follow standard University Policy.
 Risk Management

Risk planning is the process of deciding how to approach and plan the risk management activities for a project.

Risks will be managed as follows: Procurement Plan

If your project will involve procuring products or services outside of Cornell University, this section should outline the scope of the product or service, any assumptions or constraints, and any other activities that will be required for the procurement or contract. The project team should identify the specialists within Cornell for Procurement and/or Contracting and involve them early in the planning process as a member of the project team.

The following should be considered: Transition Management Plan (Campus Readiness)

Identify the approach that will be required to move the project from development to production or from project completion to steady state. When will this planning start? Will it be managed by the project manager of this project, or will there be a Transition (Campus Readiness) Team Lead or will there be a completely separate Campus Readiness Team that includes members of this project team integrated with the transition (Campus Readiness) team? Gathering Customer Requirements Approach

A key component to delivering projects on-time and on-budget is doing a great job of defining the requirements and understanding the approach. Requirements can be gathered in many ways. Some projects cannot start before all requirements are known, while other projects will have a more iterative approach to gathering requirements.

It is important that for every project you: Reporting

Each team will determine who should receive their status reports and attend status review meetings, based on the stakeholder table. Status reports will be distributed on a regular schedule determined by the project team. Status review meetings will be held on a regular schedule determined by the project team.

All of the above Management Approaches should be documented during Project Planning (High Level) in the Project Initiation Plan. These are continually refined during Project Planning (Detail Level) and the course of the project as needs change.


2.2.10 Develop High Level Risk Plan

Developing a High Level Risk Plan with broad Risk Areas is important early in the project. This provides the executive sponsor, sponsors and/or project director and funding sources an understanding of what can go wrong and if they need to have a contingency strategy and possibly contingency funds. Identify Risks

Risks are events that can potentially affect the cost, schedule, and/or efforts of a project.  Project risk identification begins during Project Planning (High Level) with the documentation of known project risks so that early planning can mitigate their effects.

Throughout the duration of the project, risks must continue to be identified, tracked and analyzed to assess the probability of their occurrence, and to minimize their potential impacts on the project.

The Project Manager solicits input from the Project Team, Project Sponsor, and from Customer Representatives, who try to anticipate any possible events, obstacles, or issues that may produce unplanned outcomes during the course of the project. Risks to both internal and external aspects of the project should be assessed.  Internal risks are events the Project Team can directly control, while external risks happen outside the direct influence of the Project Team (for example, legislative action).

A list of risks is documented in the Project Initiation Plan, and as the scope, schedule, budget, and resource plan are refined during Project Planning (Detail Level), it is updated to reflect further risks identified.

The project should be analyzed for risk in areas such as:

Documentation associated with Project Planning (High Level) can also be used to help identify risks. Some examples are:

Refer to the parts of this document concerning the Triple Constraints (Scope, Budget, and Schedule) and other information in the Project Initiation Plan to review for possible areas of risk.

Historical information can be extremely helpful in determining potential project risks. Data and documentation from previous projects, or interviews with team members or other subject matter experts from past projects provide excellent insight into potential risk areas and ways to avoid or mitigate them. Quantify and Document Risk

The Project Manager documents the identified broad level risks. (See Table 15 in the Project Initiation Plan) The table should include the broad risk areas that have been identified and their impact on the project.  A risk rating is assigned. The rating should include a probability of the risk occurring and the severity of the impact of the risk to the project should it occur. This will provide an overall Risk rating. (You can use a "High / Medium / Low" scale or a numerical rating if you prefer).

Since each risk may have more than one impact, the Risk Management Plan must describe the actions to be taken to avoid, mitigate or accept each risk impact, including contingency plans.  It should also specify the individuals responsible for the mitigation actions or contingency plan execution. Most attention should be directed to those risks most likely to occur, with the greatest impact on the outcome of the project. On the other hand, a conscious decision can also be made by the Project Team to accept or ignore certain risks. These decisions must be documented as part of the Risk Management Plan for subsequent re-evaluations.

Some commonly employed risk mitigation strategies may include:

In addition to quantifying risk probability and impact and formulating risk responses, the risk assessment process facilitates establishment of an agreement for the Project Team, Project Sponsor and/or Project Director, and Customer Representatives to collaborate in managing risks as they arise during the project.

Last, and most important, risk management plans must specify the individuals responsible for the mitigation actions, the timing of the actions to be implemented, and the expected results of the actions.

There are a number of tools available to quantify risks. The Risk Management Worksheet presented here has been selected for its simplicity and ease of use. More sophisticated tools may be necessary for large-scale high-risk projects.

A factor to be considered when quantifying risks is stakeholder risk tolerance, the threshold to which the organization will assume risk, which is dependent on its attitude toward and motivation for the project.  For example, an organization may view a 15% chance of a project overrun as acceptable since the cost benefit for the organization to do the project far outweighs this factor.  The Project Managers understanding of the organizations strategic direction and the motivation of both the Project Sponsor and/or Project Director and the Customer will help determine the level of risk tolerance for the project.

Management Techniques for Risk Response planning can include four types of responses:

    1. Avoidance – Changing the plan to eliminate the risk or condition.

    2. Transference – Shift the consequence of a risk to a third party together with ownership of the response (shifts, but does not eliminate the risk).

    3. Mitigation – Seek to reduce the probability and/or consequences of an adverse risk even to an acceptable threshold. Early action is taken to reduce the probability of occurrence.

    4. Acceptance – Deal with the risk and identify a suitable strategy.

Identifying the risk is good, but planning a wise course of action around it is infinitely better.

Be aware that by addressing one risk, you may be introducing another. For example: you identified a risk that your cost estimates may be off by as much as 15%. Your mitigation plan is to request a 20% increase in funds to cover the increased cost. You may have introduced a new risk, because a red flag may be raised, inviting an audit.


2.2.11 Produce Project Initiation Plan

The Project Initiation Plan is a collection of information used to describe the environment that will govern the project and set the overall parameters of the project. All of the work products and deliverables produced during Project Planning (High Level) will be compiled to produce The Project Initiation Plan (PIP). At this point in the project management lifecycle, the Project Initiation Plan will consist of the following information:

the refined business case (refined from the Charter), overall goal, specific objectives, success criteria, scope definition, high level schedule, stakeholder accountabilities, a communication plan, benefits and budget, governance and resourcing, the management approaches and a high level risk plan. The Project Initiation Plan is an evolving set of documents; new information will continue to be added and existing information will be revised during Project Planning (Detail Level).

This information will be refined and supplemented in later project work as the Project Manager and team becomes more knowledgeable about the project and its definition. The Project Initiation Plan is not a static document; it requires iterative refinement.

"Don't judge the book by its cover." Hogwash! While we are not advocating style over substance, the format, style, and presentation do mean a lot. During the few minutes that most decision-makers will spend reviewing your written deliverables you want them to be well disposed towards you, and able to abstract the most information in the least amount of time.  A professional-looking document will make a good first impression; a well-organized text that clearly and logically builds your case will solidify that impression. So don't just slap it together, snap a rubber band around them, and submit it as the deliverable; treat your Project Plan as a repository of your brightest hopes for the future.


Deliverables for Task 2.2 (Develop the Project Initiation Plan)

Project Initiation Plan the key deliverable produced during Project Planning (High Level). The initial plan will be refined during Project Planning (Detail Level) and iteratively throughout the entire project management lifecycle and will serve as the main guide to follow during Project Execution and Control. The Project Initiation Plan incorporates the deliverables described in each Task of this section: the refined business case (refined from the Charter), overall goal, specific objectives, success criteria, scope definition, high level schedule, stakeholder accountabilities, a communication plan, benefits and costs, governance and resourcing, the management approaches and a high level risk plan.

The Project Initiation Plan is used to:


2.3 Confirm Approval to Proceed to Next Phase




The purpose of this process is to formally acknowledge the completion, review and acceptance of all deliverables produced during Project Planning (High Level). Formal acceptance and approval by the Project Sponsor and/or Project Director or an authorized designee also signifies that the project can continue into its next phase, Project Planning (Detail Level).

Acceptance and approval are ongoing. The Project Manager should review and gain approval from the Project Sponsor and/or Project Director and Customer Representatives for all interim deliverables with upon their completion. Interim acceptances should streamline final acceptance.


Tasks associated with Confirming Approval to Proceed

2.3.1 Submit Project Initiation Plan for Approval

2.3.2 Gain Approval to Proceed


2.3.1 Submit Project Initiation Plan for Approval

At the completion of producing the Project Initiation Plan, the Project Manager should submit it to the Steering Committee, Executive Sponsor, Project Sponsor and/or Project Director, Customer Representatives, any funding sources, or anyone whose resources will be affected by the project. Depending on the size of the project the, Project Manager along with the Project team should then schedule one or more meetings to present the Project Initiation Plan for review and discussion. Attendees may also include other members of performing organizations who are able to provide resources that will add value during Project Planning (Detail Level).

Once the review has been completed, the Project Manager should prepare the Final Version of the Project Initiation Plan that will signify the close of Project Planning (High Level) and it should be submitted for signature/approval.


2.3.2 Gain Approval to Proceed

One the Project Manager has submitted the deliverable (The Project Initiation Plan) to the Project Sponsor and/or Project Director any other required signers or their authorized designee and obtain their signatures on the Project Initiation Plan, indicating approval to proceed to Project Planning (Detail Level). If the Project Sponsor and/or Project Director do not approve the contents of the acceptance package, he/she should indicate the reason for rejecting it. It is then the responsibility of the Project Manager to resolve any issues regarding the deliverables and to present the updated package to the Project Sponsor and/or Project Director again.


Deliverables for Task 2.3 (Confirm Approval to Proceed)


 Continue to next section: