North Dakota Project Management Guidebook

Introduction

The original version of the North Dakota State Project Management Guidebook was published in November 2004. It was developed through the North Dakota Enterprise Project Management (EPM) process and designed to assist project managers in carrying out their duties. The Guidebook was based on information provided at the courtesy of the New York State Office for Technology (copyright 2001). The ND authoring body then took generally accepted principles of project management and refined and incorporated them into a project management lifecycle consistent with ND policies and practices. The team also worked to align the Guidebook with the Project Management Institute’s (PMI®) Guide to the Project Management Body of Knowledge (PMBOK®), the recognized ANSI standard for project management.

In 2010, the EPM process evolved into a new entity—the Enterprise Architecture Domain Team for Project Management  (EAPM). The EAPM is a group of dedicated and experienced agency project managers who provide project management advice and strategic direction to state government. This team became responsible for revising and maintaining the Guidebook, and subsequent versions of the Guidebook have been produced by the EAPM.

Under the direction of the EAPM, the Guidebook is now the living document it was initially intended to be. Starting with a major revision in 2013, the book began to be produced solely online utilizing Drupal Books. This means that the content may be updated more frequently. If you have any ideas for how to improve the Guidebook, please send an e-mail to the Domain Team. Please include your name, contact information, and a detailed explanation of your suggestion(s). The EAPM team lead maintains a log of comments and proposed changes. Once per quarter the team lead will bring this list to the EAPM group for review. The EAPM team lead will contact you if necessary to discuss your comments and/or invite you to present your ideas at an EAPM meeting, if required.  

Since 2004, the Guidebook has provided a common methodology for project managers to use in managing projects to encourage individual project managers across the state to approach each project endeavor with the same discipline and tools. The project management process outlined in the Guidebook is common to all business areas and across all agencies. Additionally, the Guidebook defines the appropriate roles and expectations for project processes regardless of the type of project (technology projects, engineering projects, business process improvement projects, etc.). The Guidebook, in combination with ND procurement standards, also provides guidance for contracting with third-party vendors. The EAPM members hope you will use the Guidebook as a personal project management consultant and that you find the contents to be useful and enlightening.

Guidebook Structure

The Project Management Lifecycle

The Guidebook is broken into four primary sections. The first section, the Project Management Lifecycle, guides a project manager through the complete project management cycle of a project. It details the specific processes to be performed within each lifecycle phase and defines the tasks that comprise each set of processes.

Checklists, tips, techniques, and templates for successfully performing the tasks/processes are offered, as are answers to frequently asked questions.  The hope is that a project manager will find useful direction for what to do, when to do it, and how to do it – no matter what stage of the lifecycle your project may be in.

Large Project Oversight

The Large Project Oversight (LPO) processes are specific to ND project management. The second section of the Guidebook details requirements for monitoring and guiding information technology projects with a budget in excess of $250,000 (beginning Aug. 1, 2013, this will become $500,000). ND Century Code, Standards, and Administrative Rules dictate certain requirements for projects of this size, and the LPO section provides navigation through these waters.

Development Methodologies

The processes that the technical team follows in developing their product may have an impact on how the project is managed. The third section of the Guidebook describes some of these methodologies, the impacts they may have on the project management lifecycle, and additional tips and lessons learned for working with them.

Resources

The resources page provides a listing of the templates, standards, laws and other helpful documentation used throughout the Guidebook, a glossary of the project management terms used throughout the text, an outline of the standard project management processes defined by PMI, and a list of references used in the compilation of the Guidebook.

How to Use This Guidebook

The Guidebook is intended to provide guidance to North Dakota State Government project managers about what to do and how to do it. It documents and standardizes project management practices relevant to all projects in a format that is intended to be clear and helpful.

Most of the processes and deliverables are required for all projects, although in smaller projects they may require less formality and a lower level of effort. When relevant, the Guidebook will make a distinction between approaches to use for smaller versus larger projects.

The guide’s end-of-phase checklists can be used to ensure that every process defined has been considered, necessary tasks are addressed, and required deliverables produced.

Icons are used throughout the Guidebook to help draw attention to important lessons learned.

The compass icon indicates a tip from an experienced project manager.

 

 

The life preserver icon marks advice intended to save the project from pitfalls.

 

 

The ND Gov icon marks a legislative mandate, state standard, or administrative rule to be followed.

 

 

Throughout the Guidebook, there are hyperlinks to templates that have been developed by the EAPM and by the ND Information Technology Department’s (ITD) Project Management Office (PMO). These templates are essential tools for managing state projects. They contain instructions and comments (in italicized, blue text), which facilitate their use. These templates can be customized for your project.  

Use this Guidebook as a tool to help you manage your project. Don’t let the process or the project manage you! According to the Project Management Institute, in its Guide to the Project Management Body of Knowledge, Fourth Edition, page 38, “Project management processes apply globally and across all industry groups. Good practice means there is general agreement that the application of project management processes has been shown to enhance the chances of success over a wide range of projects. This does not mean that the knowledge, skills and processes described should always be applied uniformly on all projects. For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process.” (Emphasis is the PMI’s own.)

Project Management Lifecycle

Project Management Lifecycle

The project management lifecycle defines how to manage a project. It includes the processes of initiating, planning, executing, monitoring and controlling, and closing. While no two projects are exactly alike, the project management lifecycle will always be the same, regardless of the project’s size or type. All projects should progress through these five project management phases:

Initiating

At the beginning of the initiating phase, a project manager is assigned. The project manager then works with the project sponsor to identify the necessary resources and team members needed to further develop the key project parameters – cost, scope, schedule, and quality (CSSQ). The project team documents its charge in the form of a project charter, which is based on information found in the business case documentation that was prepared in order to obtain funding for the project. Approval of the project charter by the project sponsor authorizes the designated team to begin project planning.

Planning

Project planning builds on the work produced during the project’s initiating phase, through the development of a project plan. The project plan defines CSSQ, and includes plans for involving and communicating with all the parties that are affected by the project, as well as identification of an initial set of foreseeable risks that can threaten the project. Additional key elements included in the project plan are the change control process and externally focused items such as project transition plans.

At the conclusion of project planning, the business needs defined in the project charter are re-evaluated based on the completed planning documents and a decision is made either to halt the project or to commit the resources necessary to move the project into the execution phase.

Executing

Project execution is where most of the resources are applied/expended on the project. A significant number of team members will join the project at the beginning of this phase. The primary task of the project manager during project execution is to enable the project team to execute the tasks on the baselined project schedule, and to develop the product or service the project is expected to deliver. The project manager uses the processes and plans prepared during the initiating and planning phases to manage the project, while preparing the organization for the implementation of the product/service and for transitioning the product/service responsibility from the project team to the performing organization.

Monitoring and Controlling

Project monitoring and controlling is not a “next step” in the lifecycle, but is rather a group of processes that the project manager applies to the project management assets in order to provide the project team insight into the health of the project. Monitoring and controlling processes include such things as status tracking and reporting, change control, cost control, quality control, contract management, risk monitoring, and taking corrective actions when necessary. Project monitoring and controlling occurs fully during project execution, and occurs to some degree during initiating, planning, and closing.

Closing

In project closing, the project team assesses the outcome of the project, as well as the performance of the project team and the performing agency. This is accomplished primarily through soliciting and evaluating feedback from customers, project team members, consumers, and other stakeholders. The primary purpose of this assessment is to document best practices and lessons learned for use on future projects. Key project metrics are also captured to enable the performing organization and the project management office (PMO) to compare and evaluate performance measurements across projects.

Stakeholder Roles and Responsibilities

Throughout the Guidebook, reference is made to specific roles that must be performed by stakeholders at various times throughout the project management lifecycle. Stakeholders are the people or groups that are in any way affected by the new product or service. Since the organization will rely on various stakeholders prior to developing a project plan (where roles and responsibilities are typically defined), it is important to understand the roles and responsibilities early in the process.

As you develop the project plan, you will determine the specific roles and responsibilities for stakeholders and team members in your project, which may vary from those identified below due to project size, scope, complexity, and the organizational structure of the agency/institution.

Customers and Users

The customers (or “users” of the product the project seeks to produce) comprise the business units that identified the need for the product or service the project will develop. Customers can be from any level of an organization, from executive director/president to entry-level clerk. Since it is frequently not feasible for all the customers to be directly involved in the project, the following roles are leveraged:

Project Sponsor

The project sponsor has a demonstrable interest in the outcome of the project and is responsible for securing spending authority and resources for the project. Ideally, the project sponsor should have full authority to make all decisions necessary to assure completion of the project, including decisions to increase the project scope and budget.

The project sponsor initiates the project proposal process, champions the project in the performing organization, and is the ultimate decision-maker for the project. The project sponsor provides support for the project manager, approves major deliverables, and signs off on approvals to proceed to each succeeding project phase. The project sponsor may elect to delegate any of the above responsibilities to other personnel either on or outside the project team.

Executive Steering Committee

Depending on the size of the project, there may be an executive steering committee (ESC). In ND, any information technology project with a budget at or exceeding $250,000 must have an ESC (over $500,000 beginning Aug.1, 2013). In these instances the project sponsor’s authorities listed above are shared by a team of five committee members. Projects with budgets under $250,000 (under $500,000 beginning Aug. 1, 2013) are not required to have an ESC.

NOTE: Throughout this Guidebook, when the project sponsor is listed as a resource for a particular task, the Executive Steering Committee can be assumed as included (when used).

Large Project Office (LPO)

The LPO is a role within the ITD PMO that provides oversight and reporting of all information technology projects with budgets at or exceeding $250,000 ($500,000 beginning Aug. 1, 2013), as designated by NDCC 54-35-15.2, NDCC 54-59-05.7 & .8 and NDCC 54-59-23 and in accordance with STD009-05. (N.B.: The 63rd legislative assembly will be considering a bill draft to raise the threshold for what constitutes a large project to $500,000. If this legislation is enacted the Guidebook will be updated.)

Performing Organization

The performing organization management (POM) includes all members of the organization’s management team that may exert influence on project team members or be affected by and involved in the development and implementation of the product that is produced as a result of the project activities.

Project Management Office (PMO)

A project management office is a centralized entity that seeks to manage projects in a coordinated fashion. PMO responsibilities may include providing project management support functions, establishing project management methodologies, mentoring, monitoring compliance with standards and policies, managing shared resources, and providing project management staff for projects. An agency may have its own PMO. Alternately, ITD has a PMO that provides project management services.

Project Manager

The project manager is the person who is responsible for ensuring that the project team completes the project. The project manager develops the project plan with the team and monitors the team’s performance of project activities. It is also the responsibility of the project manager to secure acceptance and approval of deliverables from the project sponsor/ESC and stakeholders.

Project Team

The project team is the group that is responsible for planning and executing the project. It consists of a project manager and a variable number of project team members who are brought in to work on their activities as defined in the project schedule.

NOTE: Throughout the Guidebook, when project team members are listed as a resource for a particular task, it should be assumed that project team leaders are included.

External Stakeholders 

1. Chapter 1 - Initiating

1.1 Purpose

The purpose of the initiating phase is to begin to define the overall parameters of a project and establish the appropriate project management and quality environment required to complete the project.

Development of the project charter is a pivotal starting point for the project, establishing the project definition that will serve as the foundation for all future efforts. The completion of this process is marked by the project kick-off meeting, in which the project manager presents the project charter.

1.2 List of Processes

This phase consists of the following processes:

Initiate the project ...

... where the project sponsor and initial project team are identified and work with the project manager to create the project charter.

Approve the project charter ...

... where the project sponsor formally approves the project charter, indicating approval to move forward with the next phase.

Conduct the project kickoff meeting ...

... where the project manager and project sponsor present the information from the project charter to the project team and kick off the project.

 

1.3. List of Roles

The following roles are involved in carrying out the processes of this phase. Descriptions of these roles can be found in the Stakeholder Roles and Responsibilities section.

  • Project manager
  • Project sponsor
  • Project team members
  • Customer
  • Customer representatives
  • Performing organization

1.4 List of Deliverables

Figure 1-2 below lists all project initiating tasks and their deliverables (and outcomes).

Processes

Tasks

Deliverables and Outcomes

Initiate the project

Identify project sponsor

Project sponsor selected

Identify initial project team

Project team selected

Review historical information

Information reviewed

Establish project repository

Project repository set up

Develop project charter

Project charter

Approve the project charter

Gain project charter approval

Project charter approvals

Conduct project planning kick-off meeting

Project kick-off meeting

Kick-off meeting

 

1.5 Initiate the Project

1.5.1 Purpose

Once the business unit has decided to move forward with a project, the project is assigned to a project team whose first responsibility is to initiate the project. The project manager, working with the project sponsor, must ensure that the performing organization’s expectations and all available project information are effectively conveyed to the project team. This can be done collaboratively with the performing organization’s management team.

Various areas of the performing organization may be required to provide resources to the project in order to complete the initiating phase. The project sponsor and project manager must determine specific resource requirements and effort estimates, and include them in the charter. The project sponsor must communicate with the affected areas of the performing organization, proactively gaining agreement and securing the necessary resources. The project sponsor must have a general understanding of the amount of effort that will be required to complete the project.

It is imperative that the project manager begins to track project initiation efforts and communicate status throughout. Items to discuss during status meetings include accomplishments, progress against schedules, work to be done, and any open issues that need resolution. As part of the communications plan for the project, a project status report should be prepared and reviewed at regular intervals during initiating meetings.

In the fairy tale version of the Guidebook, the project manager is always brought onto the project at the very beginning – the budget has been approved, the business case devised, and everyone has waited for you to show up to begin the initiating phase. In the reality-TV version of the Guidebook, however, this is often not the case. The PM may be brought in when a lot of work has already been done – with or without a charter or a plan – and the project status (if anyone knows it) may be good or “derailed.” If this is the case, don’t be afraid to call a time out to get the project initiated with a proper charter as should have been done in the first place. Remember, without a charter the team may not know what they are building, why they are building it, or what makes their efforts successful. These are key things to know, and finding them out warrants a project time out.

1.5.2 Tasks

The next set of pages describe the primary tasks involved in beginning a new project adventure, culminating in the development of the project charter.

1.5.2.1 Indentify the Project Sponsor

If a project sponsor has not been identified, the project manager must work with the POM to identify and formally appoint someone to that position. Because the project sponsor 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 and the project sponsor is critical to project success.

1.5.2.2. Identify the Initial Project Team

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

Prior to initiating the project, various business documents relating to the project were likely created (e.g., project proposal, business case, project ranking documentation, funding request). During the initiating phase, any existing business documentation should be reviewed to determine the roles required to staff the project. With the help of appropriate stakeholders, the project sponsor should take the lead in identifying the names of individuals within the performing organization who could fill the roles and become project team members. Names of the individuals needed to complete project initiation tasks will be documented in the project charter. In selecting the project team, definition of the skills required to perform current tasks, as well as skills for future project tasks, is needed. Immediate project needs should be met first.

Although the extent of the involvement necessary for each team member may not be known at this time, the project manager should provide those individuals who will be involved in the initiating phase with a brief project orientation and review with individual team members their current and future roles on 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 agencies hold a meeting at the beginning of the project’s initiating phase, where all potential stakeholders come together to review the project proposal, discuss required roles, and assign project team members. In other agencies, 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 your organization. Take the opportunity, from the outset, to establish the concept of a project team that comprises not only those who report directly to you, but also your project sponsor, customer representatives, customer decision-makers, and all other players participating in the project schedule.

1.5.2.3 Review Historical Information

Development of the project charter will require review of documentation complied or presented prior to project initiation. Materials and information reviewed may include:

  • The strategic plan, a formal document produced by the performing organization that outlines the business goals and direction over a designated number of years
  • The project proposal, including the initial business case document, which describes the project objectives and how they support the performing organization's strategic business direction
  • Project selection criteria, defining the parameters used in determining whether or not to undertake a project and identifying its business justification and measurements of its success
  • Information related to federal funding for the project, such as grant applications and advanced planning documents
  • Information from a previous project similar in size, scope, and objectives
  • Project knowledge and experience of the individuals on the project team.

1.5.2.4 Establish the 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 or PMO, 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. 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 (e.g., a file directory or email 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:

  • Project proposal and supporting documentation, including the business case
  • Project description/definition documents, such as the project charter and the project plan
  • Any working documents or informal documents defining the CSSQ of the project
  • Project schedules (baseline and current)
  • Project financials
  • Project scope changes and requests log
  • Project status reports
  • Team member progress reports and timesheets
  • Issues log and details (open and resolved)
  • Project acceptance log by deliverable
  • Products
  • Risk identification/model documentation
  • Contracts and other procurement documents
  • Audit results, if encountered, and LPO reporting documentation
  • Correspondence, including any pivotal or decision-making memos, letters, e-mail, etc.
  • Meeting notes, results, and/or actions

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 (although wherever it is kept this information is still public information available to anyone via the open records request process). Some project-related documents may also legally be regarded as confidential. A confidential project repository should be established in a separate location to secure sensitive information.

The North Dakota Open Records Law requires agencies to generally assume that all are open records unless there is some specific exemption in the open records law (or the agency’s laws or federal law) that makes specific information exempt or confidential.

In general, if someone asks for records regarding a project, the agency is required to remove confidential information and disclose the rest of the record. You should contact your agency’s legal counsel or the Office of the Attorney General for any specific advice regarding these matters.

Having a document repository for a large project is a requirement of state standard STD009-05. Section 1 of the standard describes the requirements to which the repository must adhere.

 

A project repository may be something simple, such as a shared drive/file server location, or something more complex, such as a SharePoint collaboration web site or other knowledge collaboration tool. When determining which route to follow in establishing your repository, consider factors such as cost, team member access, document versioning, archiving capabilities, file backup, and security.

1.5.2.5 Develop the Project Charter

The purpose of developing the project charter is to provide authority to establish the project, broadly defining its purpose, goals, and objectives. The charter serves as a formal authorization from the project sponsor to the project team. The project charter is the first in a series of project definition documents defining the business goals and objectives the project will meet. Information within the project charter is provided at a general level that will be further refined in documentation produced during subsequent project activities. The charter also documents the project’s mission, history, and background, and lists the benefits to be realized by the performing organization as a result of implementing the product or service.

Information compiled prior to project initiation is used and applied in the development of the project charter. To further understand how the project was selected and to write an effective, comprehensive charter, the project manager must work with the project sponsor and any appropriate subject matter experts and stakeholders.

If issues or conflicting project expectations are uncovered while developing the project charter, the project manager must communicate with stakeholders to resolve the discrepancies, elevate the issues when appropriate, and obtain consensus. Decisions that impact project expectations significantly should be thoroughly documented.

The project charter should minimally contain the following sections:

  • Project description
  • Initial scope
  • Business needs and objectives
  • Initial funding
  • Business risk analysis
  • Required resources for project planning
  • Business assumptions and constraints
  • Authority

The project charter can also include a preliminary schedule, an organizational chart, a communications plan, and any other relevant or specific detail. The important thing to remember is that the project charter is NOT the same as a project plan. The project charter’s purpose is to formally establish the project, and is a much more high-level document than a project plan.

Developing the project charter is a collaborative effort. Working with the project sponsor, the project manager should document the objectives that must be achieved in order for the project to be considered a success. These objectives should correlate with the goals and objectives of the project. 

An effective way to define an objective is to complete the following sentence, “The project will be a success if ______”.

 

For large projects, pay close attention to the creation of your business needs and objectives. They should be SMART (Specific, Measurable, Attainable, Relevant, and Time bound). They will also be presented to the Legislative IT Committee when the project starts (in the form of a startup report), with a follow-up presentation after project closing to let the legislators know whether the objectives were met. Details on this process are available in the Oversight  section of the Guidebook.

1.6 Approve the Project Charter

1.6.1. Purpose

When the project charter is complete and approved, a project planning kick-off meeting is conducted. This meeting is the event that formally marks the beginning of the project. It is most likely the first opportunity for the project sponsor 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 to begin work.

1.6.2 Tasks

The next set of pages describe the primary tasks involved in approving the project charter.

1.6.2.1. Gain Project Charter Approval

Meeting attendees should always include the project sponsor and the members of the POM whose resources are affected. Attendees may also include other members of the performing organization who are able to provide resources that will add value to the project. During the meeting, the project manager presents the project charter for review. The resources for the planning phase (and for the rest of the project, if known) are formally secured by gaining the signatures of the appropriate performing organization managers. If resources are included for the entire project, the project sponsor should be informed that the figures are estimates and will be refined as the project progresses.

At the conclusion of the meeting, the project sponsor will formally approve or reject the charter. Should the project sponsor reject the charter, he/she must provide the reasons for rejection to allow the project manager to make necessary adjustments. It is important to note that this acceptance and approval process is ongoing. The project manager should review and gain approval from the project sponsor and customer decision-makers for all interim deliverables upon their completion. Interim acceptances should streamline final acceptance.

At this point in the project, you may need to begin acquiring or transitioning the staff necessary to complete the work for the planning phase. If so, refer to Human Resources Planning and Procurement Planning in the Planning chapter.

 

1.7 Conduct Project Kick-Off Meeting

1.7.1. Purpose

When the project charter is complete and approved, a project planning kick-off meeting is conducted. This meeting is the event that formally marks the beginning of the project. It is most likely the first opportunity for the project sponsor 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 to begin work.

1.7.2 Tasks

The next set of pages describe the primary tasks involved in conducting the project kick-off meeting.

1.7.2.1. Project Kick-Off Meeting

Prior to the meeting, an agenda and a presentation highlighting the contents of the project 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 charter contents ensures that expectations for the project and its results are in agreement. If not already done, the project manager must ensure that the project sponsor has provided his/her signature on the project charter, indicating his/her approval of the contents of the document. If the project sponsor does not approve the charter, he/she must indicate the reason, to allow the project manager to make necessary adjustments.

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

At this point in the project lifecycle you’ve conducted a meeting to kick off the planning phase. Once planning has been completed you will have new and/or different information, a baselined project schedule, and the composition of your project team may have changed and most certainly will have grown. For this reason, you will want to conduct another kick-off meeting – a project execution kick-off – that will include all team members working on the project. For phased or iterative projects, you may even want to conduct a kick-off at the beginning of each phase or iteration to re-orient team members to the objectives and timelines for the next push forward. On the other hand, if your project is very small, you may only require one kick-off meeting.

1.8 Initiating: End-of-Phase Checklist

Use this checklist throughout the initiating phase to help ensure that all requirements of the phase are met. As each item is completed, indicate its completion date. Use the comments column to add information that may be helpful to you as you proceed through the project. If you elect NOT to complete an item on the checklist, indicate the reason and describe how the objectives of that item are otherwise being met.

Item description

Completion date

Comments and/or reason for not completing

Identify and assign the project manager

 

 

Identify and appoint the project sponsor

 

 

Identify project team members

 

 

Identify customer representatives

 

 

Review historical information

 

 

Establish the project repository

 

 

Document how issues were resolved and decisions made

 

 

Update the repository with all project correspondence

 

 

Review project charter template

 

 

Work with project sponsor and project team to gain consensus on project expectations

 

 

Write the project charter document

 

 

Conduct project charter approval meeting

 

 

Approve the project charter

 

 

Schedule time and location of planning kick-off meeting; invite appropriate attendees

 

 

Prepare meeting presentation and agenda

 

 

Designate meeting scribe

 

 

Prepare materials for distribution at meeting

 

 

Conduct planning kick-off meeting

 

 

Facilitate the project kick-off meeting

 

 

Distribute minutes to all attendees

1.9 Measurements of Success

The main measurement of success for project initiation is the decision to proceed with – or to halt – the project. While in the majority of cases, a well-executed project initiation leads to a transition to project planning, in some cases the organization is best served by deciding that the project should not continue.

Before the sign-off of the project charter, however, the project manager can assess how successfully the project is proceeding by utilizing the measurement criteria outlined below in Figure 1-4. More than one “no” answer indicates a serious risk to the success of your project.

Measurements of Success

Yes

No

Do you have a committed, interested, and influential project sponsor attached to the project?

 

 

Did you verify that your project charter reflects the vision of the areas of the performing organization affected by/involved in the project?

 

 

Did you identify specific benefits the product or service developed by your project will bring to the customer?

 

 

Do you have a clear structure for the project repository?

 

 

Do you have approval of the project charter, signed by your project sponsor, authorizing you to proceed to project planning, or halting the project?

1.10. Phase Risks / Ways to Avoid Pitfalls

The initiating phase lays the foundation for the rest of the project management lifecycle. In the same way that a faulty foundation will result in an unstable and eventually unusable building, an incomplete or improperly executed initiation will likely result in a flawed project.

What are some of the key elements of project initiation that require the most attention? The following table identifies processes and tasks that are highlighted in this section.

Process

Task

Why is it important?

Initiate the project

Identify project sponsor

A project without a project sponsor is like a ship without a rudder – no matter how sleek the hull or how tall the masts, it just can’t get anywhere useful without someone to steer it.

Approve project charter

Gain project charter approval

Just how far out on the plank are you willing to walk without formal buy-in from the sponsor?

Conduct planning kick-off meeting

Project planning kick-off meeting

It’s important to get everybody on board before setting sail.

1.10.1 Pitfall #1 – No Sponsor, No Champion

In preparing for the project, the first imperative is securing a project sponsor. Without the project sponsor to guide and support the project, the project manager has an impossible choice of either trying to take on the responsibilities of a project sponsor (for which he/she has no authority), or trying to secure the commitment of unwilling or uninterested executives (over whom he/she has little influence).

Having one project sponsor who is high enough in the organization to be of help, and who is interested enough in the outcome to be involved, is ideal. However, in many cases, the organization insists on more than one – usually the managers from the main business functions involved in the project – serving as joint project sponsors. If the managers are severely at odds with each other (e.g., about what the project ought to accomplish), in most cases the project manager can sit down with the project sponsor(s) as early as possible and hammer out a common vision for the project. Some of the useful questions to ask to gain consensus are:

  • What are we trying to accomplish? What is the desired outcome?
  • Who will benefit, and in what ways?
  • Why is the project important to YOU?
  • How is it going to change the way people do their work?
  • How will the organization adjust?

However, when the number of project sponsors exceeds two, trouble may be afoot. There will be more delays getting everyone to the same place, or chasing everyone down, more difficulties achieving a consensus, more corrections to deliverables, more minds to convince, and more personalities to please. You’d better add lots of time to your schedule for securing necessary approvals in a multi-sponsor environment.

The effort you will expend in securing an interested, influential project sponsor now will pay dividends throughout the duration of the project. In some organizations, often those with a defined project selection method, projects may only be requested by someone willing to be the project sponsor.

1.10.2 Pitfall #2 – Ineffective Kick-Off Meeting

The importance of selecting an effective project team and writing a comprehensive project charter is self-evident and well understood. However, the other key, but often overlooked or lightly regarded, task during the initiating phase is the kick-off meeting.

A trap that project managers frequently fall into when conducting the planning kick-off meeting is to waste the time in a pro-forma, listless exercise of bringing unwilling participants together and stultifying them with boring recitations of project objectives, replete with industry buzzwords and technical jargon. Instead, you should look at the kick-off meeting as your opportunity to ignite interest in the project, secure enthusiastic participation in crucial activities later on, and set accurate expectations about what the project is – and is not – likely to accomplish.

How? First, the kick-off meeting should be a creative, participatory exercise, involving all attendees. Second, it should emphasize and focus on how the project and its eventual product will benefit each attendee. And third, it should be a showcase for the performing organization’s commitment to and interest in this project, and your team’s enthusiasm for it.

To make it a creative, joint exercise, you may consider asking the attendees to share ideas on why the project is important and how it will benefit the organization as a whole. To involve self-interest, you may also want to ask participants to explain how the project will benefit each of them specifically, making their jobs better, easier, or more fulfilling. If they can’t come up with anything, have the project sponsor make appropriate suggestions. To showcase executive commitment, develop a draft of talking points for the project sponsor to use in a statement at the beginning of the kick-off meeting, explaining why the organization is making a significant investment in this project, from both budgetary and human resource standpoints.

Finally, this is a great opportunity to showcase yourself and your team, and demonstrate great enthusiasm for the project, which will be contagious and will set the tone for the activities to come.

1.10.3 Pitfall #3 – Chicken Before Egg, Schedule Before Plan

It is a lucky project manager who is not seized by “analysis paralysis” when pressured to develop a project schedule and budget at this stage of the game.

How can I commit myself to an estimate without knowing enough about the project? (And let’s not kid ourselves – the estimate you do put down will become a commitment, which the performing organization will immediately embed in whatever budgetary or strategic plan they are developing.) This paradox is easily resolved if you can estimate as you go along – one phase at a time. Unfortunately, that is a luxury afforded few, if any, project managers. The budgeting process demands answers well ahead of time, and there is no avoiding it. If you must provide preliminary project schedule and budget information, the following information may help.

The one thing that can help at this stage is experience – either personal, or in the form of organizational historical data. If you have been involved in similar projects in the past, you develop a feel for how long things take, and what obstacles, other than product-related, must be overcome and accounted for in the schedule.

However, if you are new to project management, to the performing organization, or to the technology, you need to fall back on organizational knowledge. If you are lucky, the organization captured lessons learned from prior projects, and you can find out how long similar efforts have taken. More likely, no such knowledge base exists other than in people’s heads, and your project sponsor can perform an important service in helping identify and recruit project managers who may have been involved in similar efforts. Make sure those efforts were actually successful; after all, you do not want to make the same mistake twice. Ask to see their initial and final project schedules. If they don’t have one (or worse, either) you will need to rely on anecdotal evidence. This type of information may be expanded upon by such methods as speaking with others who have worked on similar projects, researching via Gartner, reviewing the state’s lessons learned database, etc.

Most of the time, the end date for the project will be pre-defined by some event outside your control: executive commitment, governmental mandate, or some physical constraint. In that case, “backing into” an estimate is eminently reasonable. Walk through the entire project lifecycle backwards, making informed “guesstimates” along the way, and see if you end up at the beginning with today’s date.

Keep in mind that the earliest estimates tend to be on the optimistic side, before reality sets in. Consider your first attempt optimistic. Now make a second, more pessimistic attempt, assuming Murphy’s Law. This will provide you with the worst-case scenario. The truth is probably somewhere in the middle.

In other cases, there is a budget limit to which you must adhere. Once again, you can back into your schedule by estimating how many weeks, months, or years of effort by a reasonably sized team the expected budget would support, and from there you can use the industry-standard percentages for product development lifecycles to approximate what your effort is going to be.

Most of all do not obsess over your preliminary schedule if you have included it in your project charter. Document carefully all your estimating assumptions, and run it by as many experienced and knowledgeable people as you can, including your project sponsor.

1.10.4 Pitfall #4 – Pretending Nothing Will Go Wrong

The one process that few organizations engage in despite the fact that it can provide the most “bang for the buck” is risk management, which consists of risk identification, assessment, and response planning. These activities should be completed in the project planning phase, but you will also want to include some risks in your project charter during the project initiating phase.

You can’t ignore risk. Stuff will happen, and most of it will negatively impact your project, if you let it. What you can do is anticipate it, and be ready with a solution before the problem arrives. Once again, either your own experience or organizational knowledge (captured as historical data in a repository or as knowledge in people’s heads) is the key. What obstacles, problems, and disasters did other projects run into before? How were they dealt with? What was the impact on the schedule?

Consider every aspect of your project. Ask yourself, “What can possibly go wrong?” What assumptions am I making that may not be accurate or consistent? Then, for every risk factor that you identify, you need to determine how it can affect your project.

1.10.5 Pitfall #5 – Not Enough Talk

Another activity that costs very little, but can provide enormous benefits, is communication. In fact, one of the few success factors consistently cited in analyzing successful projects is frequent and comprehensive communication. Communication keeps all the players in the loop, avoids unpleasant surprises, and builds confidence in project progress and success. Nobody ever complains that they are being told too much, but they usually resent being told too little.

Anyone who will be in any way affected by the product or service that your project will develop must be communicated to at some point, and most likely throughout the project lifecycle.

There’s an interesting formula for determining how many lines of communication exist in your project. The formula is N(N-1)/2 in which the variable “N” signifies the number of people on the project team. So if you have five people on your project team, then 5(5-1)/2 = 10, and you have 10 separate lines of communication. If you have a team of 20, then 20(20-1)/2 = 190, and you have 190 separate lines of communication! As you can see, it is very important to communicate, communicate, communicate.

1.10.6 Pitfall #6 – Is the Project Official?

Finally, you are all done with initiation. Your project charter inspires masses to commit great deeds. You think you are done? Not until you have a signature (in ink or electronically, depending on your process) of someone authorized to certify that your opinion of your work is justified, and that you have authorization to proceed to the next phase.

Remember that unless you are in the highly unusual situation of being your own boss, you do not have the authority to certify your own work or to commit resources to continue. And unless you want to go very far out on that proverbial limb, you need to have proof that someone with proper authority – most likely, your project sponsor – is on board with what you have done, and what you are about to do.

1.10.7 Pitfall #7 – We don't need to follow these steps, do we?

Skipping tasks and their documentation during the initiating phase can cause serious consequences affecting all of the subsequent phases of your project. Project management methodologies were developed not because people had nothing better to do with their time, but in response to crises and disasters that resulted precisely from seat-of-the-pants approaches (see Pitfall #5 in the Project Planning section).

1.11 Frequently Asked Questions

What if no one will agree to be the project sponsor?

Although no one may have assumed the official role of project sponsor, someone secured the funding for this project, and someone appointed you to manage it. Talk to that person, explain the role of the project sponsor, and notify him/her that you will consider him/her your project sponsor unless someone else is identified to fill that position (see Pitfall #1: No Sponsor, No Champion).

What happens later on if my preliminary time/money estimates are off by 50 to 100 percent?

Accurate estimating takes a lot of effort, knowledge, available historical data, and a bit of luck. Chances are, your estimates are going to be off; the only questions are by how much, and what will you do about it.

Your lack of accuracy could be due to one or both of the following: (1) you did a lousy job estimating (usually due to lack of historical comparative data) and/or (2) things changed. In the first case, take responsibility for your mistake, use it as a learning opportunity, and make sure everyone realizes what you are doing. In the second case, make sure everyone’s aware of the changes as soon as they occur, and use the change-control umbrella to cover you (which you will define in the planning phase). Remember, executives hate surprises. It is better (for your career, at least) to be off by a lot if everyone knows about it well ahead, than to be off by a little and have it be a total surprise to the decision-makers. In both cases, it behooves you to document your estimating process and assumptions, and reforecast on a regular basis. If an underestimate becomes apparent, identify root causes, define corrective actions and alternatives, and work with the project sponsor to head off any significant degradation of project schedule.

How do I justify the initiation time to the project sponsor or customer who just wants it done?

It’s called “customer education.” Encourage your project sponsor and your key customers to read (or at least peruse) this Guidebook. Explain to them the benefit they will derive from proper planning. Illustrate your arguments by pointing to other projects (hopefully, disastrous) and explaining why they failed (hopefully, due to lack of planning). Seek persuasive allies among their colleagues. And finally, use it as a continuous improvement opportunity: explain what has to be accomplished, and ask for a creative way of getting the same result using some other means. Who knows, they may actually come up with a process improvement that you can use as a best practice later on (see Pitfall #7 for more details).

What can you do if the performing organization doesn’t recognize the importance of project management or feels that they can do it better?

This is a kind of variation on the theme of the previous question. You can either try to persuade them that it’s the right thing to do, or lead by example and just do it the right way. It is unlikely that everyone doesn’t understand project management; seek out people with similar ideas and have them bolster your arguments. Seek assistance from the EAPM or ITD’s PMO or LPO role with justifications and examples of successful projects done right. Brandish this Guidebook and follow the practices it advocates.

Is the project manager expected to perform all of the tasks required of the role? Can some tasks be delegated in whole or in part?

Management means, “getting work done through others.” Delegation is one of its principal tenets. Depending on the size of the project, the project manager may be physically unable to perform some of the duties outlined in this book. For example, take new team member orientation. Ideally, the project manager would spend a chunk of time with every team member, inculcating proper disciplines and techniques. However, what if the project team is comprised of hundreds of members? Project team leaders must be identified to take on those responsibilities. But remember, it is still the project manager’s responsibility to verify that delegated tasks are being correctly executed.

The bottom line is that the project manager must do whatever it takes to have every task done right, on time, and within budget. Whether you accomplish this by sitting on the beach and firing off occasional e-mails (improbable), or by spending all your waking moments in the office (undesirable), you are still doing a fine job.

What do you do if the project sponsor doesn’t fulfill his/her role to the level of satisfaction expected by the project manager?

The first thing to remember is it doesn’t pay to fight your project sponsor. The project sponsor is your principal ally and benefactor. Reasoning, persuasion, and education are the way to go.

First, make sure your project sponsor knows that you are both trying to accomplish the same goal: to solve a business issue with the product of the project. Second, make sure the project sponsor understands and agrees with the approach the project is taking. Finally, once you have established commonality of interests, you can gently educate your project sponsor on the responsibilities of the position, and if his/her understanding differs, try to come to terms to which you both agree. Always argue from the benefit standpoint, explaining how a particular action on his/her part will benefit the project, and eventually the project sponsor.

However, what does the project manager do if the positive approach isn’t working? If the project sponsor continues not to fulfill his/her role, the project sponsor needs to know that he/she, too, is responsible for the project. As the project manager, you are not the only person who is to be held professionally accountable for the project. There needs to be a clear understanding that it is the project sponsor’s project and the project manager is there to help the project succeed. If project success becomes threatened because of this situation, the project manager may need to escalate this as an issue to the ESC (if one exists) or through other appropriate channels in the organization.

2. Chapter 2 - Planning

The remaining sections of the revised, online Guidebook are currently being developed. If you are interested in being placed on the email list for updates regarding progress, please send the working group an email.