Honeymoon Hangover:
The Happy Beginnings of a Creeping Scope

All project managers are familiar with the rush of enthusiasm that usually comes with the start of a new project. Like any new beginning, from the Cubs' first preseason game to a new school semester, a new project is a clean slate, full of potential and the promise of significant achievement. 

With the project’s full budget still available, with its entire duration stretching into the future, and with all of the immediate distractions of spinning up the project’s operations, it's easy to sail blissfully through the project’s “honeymoon” period without focusing much on critical project management issues. Those ignored issues, however, can erupt later as major project management problems – the honeymoon’s hangover.

This article talks about some of the issues a project manager needs to address and resolve during the first couple of weeks of a project in order to create a solid foundation for its management. Key among these issues are those dealing with the project’s scope and risk. Addressing these issues from the project’s start will go a long way to preventing the problems of scope creep and risk growth from plaguing your project.

We’ll use two conventions in this article. First, we’ll talk about how these issues should be dealt with during a project’s ”kickoff meeting”, the project’s first formal planning session that usually represents the beginning of the project. In practice, that meeting might not actually be a meeting. Instead, it might be a series of early planning conferences, or a multi-day workshop, or some combination of technologies like a webinar supplemented with a wiki workspace.   This article applies to kickoff "meetings" no matter what format they may use. 

The other convention we’ll use is to discuss kickoff issues in the context of the start-up of a contractor-supported effort. The same issues would naturally apply to a purely in-house government project, though without the additional formalities, roles, and requirements of the Federal Acquisition Regulations (FAR).

What’s Wrong With This Picture?

Let’s start by considering how some projects get launched . . . badly. Let say that you’re a contractor’s project manager heading off for a new project kickoff meeting for a contract you’ve just been awarded by a government agency. You and your Contracts person show up for the meeting and meet your new client and her Contract Officer. Social pleasantries are exchanged, after which you give a presentation that is mostly based on your proposal with maybe a few points highlighted for discussion. With those points clarified, the client discusses some schedule and logistical issues for the project’s early activities and then hands over background documentation that wasn’t available when the request for proposal (RFP) was released. With that and a few furtive glances at watches, the meeting winds down.

In a little more than an hour after your arrival, you’re leaving the building escorted by your client. Out of earshot of your respective Contracts people, you and she agree that the two of you will certainly be able to work together to talk through and resolve any issues that might come up and as they come up. You both agree that the project will be too fast-moving to let things get bogged down in empty formalities and in your respective Contracts shops. Frequent informal communication, documented if necessary in the monthly report, will allow you the flexibility and speed to adapt to new information and new requirements as the project takes shape. As you get in your car, you can’t help but think, “This project is going to be great!”

Is it? Maybe not . . . probably not. In fact, just the expression “new requirements as the project takes shape” should be enough to trigger a convulsive shudder of impending doom in experienced project managers.

Startup Requirements

As pleasant and undemanding as the project’s startup was, it pretty much failed to set the stage for the project’s success. No firm, detailed consensus was developed and documented about critical issues like what will define the project’s goals, scope, products, and risk. Discussion, agreement, and documentation of such issues are needed to provide a solid foundation for developing the project management plan and managing the project’s operations. Without that, the project is vulnerable to meandering requirements, unanticipated problems, repeated product fixes, multiple delays, and ultimately the project’s failure to meet its goals.

Article Overview

The remaining sections of this article will describe agenda items that should be talked about and agreed to during a project’s kickoff meeting and/or subsequent project planning meetings. The total list of a kickoff meeting’s agenda items is certainly going to differ from project to project. Nonetheless, consider these issues, which will be discussed in turn in the remaining sections of this article, as the core elements that should be addressed one way or another during the project’s start-up:

• Stakeholders – Identify who the project stakeholders are and what requirements, resources, and expectations each brings to the project and what role each will play during it. This will be discussed in Section 2.
• Project Success Criteria – Define what criteria will define project success, in terms of both the project’s outcome and operations. This will be discussed in Section 3.
• Product Standards – Define the acceptance standards for each of the project’s products. This will be discussed in Section 4.
• TBDs – Identify what the unknowns or the uncertainties are that confront the project’s planning. This will be discussed in Section 5.
• Assumptions – Identify what project assumptions are needed to plug the information gaps associated with the identified unknown/uncertain facts, conditions, requirements, or circumstances and what the plan and schedule are for resolving each of them. This will also be discussed in Section 5.
• Project Risks – Identify the project’s risks—including those involved with the project assumptions—and the related risk mitigation plans. This will be discussed in Section 6.

Section 7 discusses some practical considerations and possible techniques to use in meeting the requirements of a project's startup despite the real-world restrictions that PMs often face.