The Principles of Project Management

The Process of Initiating

The process of project initiation is quite simple. Gather information about:

• why the project is happening
• what needs to be delivered and how this will be done
• who will be involved
• the timings to which the project will be delivered

Make sure to get input from all the key stakeholders:

• Summarize the why, what, how, who, and when of the project into a Project Initiation Document.
• Review the Project Initiation Document with the project board and key stakeholders to get their agreement.
• Hold a kickoff meeting to herald the start of the project, share the success criteria, and plan going forward with the project team, board members, and key stakeholders.

There may well be a number of unfamiliar terms in that process explanation, but don't worry about that just now. We're about to look at the different tools and best practices that will help you get your project off to a flying start. The key point to take away from the initiating process is that you should start the project with everyone on the same page, and move forward towards a common, agreed goal.

Initiation Tools and Best Practices

The project's Initiation phase will be eased by the following key tools and practices.

The Project Initiation Document

The Project Initiation Document (PID) summarizes the what, how, when, and why of the project. It represents the agreement between all parties on what the project is about and, importantly, why the project is being undertaken. Although obviously some facets will change during the course of the project (notably the details of how the project is achieved, the project's timings, and the resources available) the fundamentals of what the project is and why it'll make a difference to the organization should be pretty stable.

The Project Initiation Document needs to summarize:

• the project's objective (what you're trying to achieve)
• the key deliverables (how you're going to achieve the objective)
• the overall rationale for the project (why you're undertaking it)
• the initial timings (when it will be achieved)
• the project's initial organization (who is involved)

Other elements that should be included in the initiation document are key assumptions and constraints, and success criteria. You may also want to include high-level information about the risk and quality management approaches you'll use, although this detail is often included in the project plan, rather than the PID.

It's important that the PID be as concise as possible. The shorter the PID, the greater are the chances that the stakeholders will actually read it at the outset, which can smooth the project's progress over time.

Once you've written your initiation document, don't just stick it on a shelf and forget about it! The document should be agreed upon up-front with your project's key stakeholders (including the project sponsor and board), and should be referred to subsequently throughout the project. Whenever you're making difficult decisions about which changes to the project's scope or design should be accepted, referring to the project's original objectives and success criteria will prove invaluable.

A PID Is Not a Contract!
The Project Initiation Document is not a legal contract. For a start, it's much shorter than any contract I've ever seen! The PID can't replace the contract, either. If you're a freelancer or a business providing services to a client, you still need to make sure that you have all your regular contracts in place. You probably want to refer to the PID in the contract, but since it's accepted that the actual execution of the project will likely diverge from the descriptions in the PID, you can't rely on it as you would a contract.

If you're employed by an organization, and providing project management services to another part of the same company, it will depend very much on the company culture whether or not you need to have a contract in place. Many companies don't have formal contracts for internal projects. In such cases, the PID serves an even more important role, since it's the only place where the expectations that the project team and customer have of each other are recorded.

Let's consider the project initiation document for our example project, which will address all four opportunities originally identified during the discovery phase.

The first section defines the business need -- it's simply a paragraph or two that describes the opportunity for the project, as Figure 2.2 shows.

Then comes the project objective, as shown in Figure 2.3. You'll notice that this part is written to a particular format that includes:

• an overall description of what the project's about
• a description of the key areas to be addressed
• a definition of the specific business benefit that the project will realize

This is a very useful format for describing objectives. You may find another standard in use in your organization, though, and it's often best to use the format that people are familiar and comfortable with.

SMAC Your Objectives
Your objectives should be SMAC: specific, measurable, actionable, and consistent. The key feature is that at the end of the project, you should be able to say "yes, we did that" or "no, we failed." There should be no gray areas. Throughout the project, you should be able to track the team's progress towards those objectives.

The next section of the PID identifies the project deliverables, as shown in Figure 2.4; it describes how you're going to achieve the objective. This description must necessarily be completed on a very high level, because the project is just getting started -- you haven't done any detailed planning yet. Here, you just need to give an idea of the biggest chunks of work to be done. Try to make sure that no deliverable will take longer than a month to complete, though -- if you're still looking at phases of three months or more, break those phases into a little more detail.