Honeymoon Hangover:
The Happy Beginnings of a Creeping Scope

Project Assumptions

Purposes and Application

Assumptions can be thought of as temporary scaffolding that supports project planning and management until solid information becomes available to fill information gaps. There will almost always be a need for assumptions to fill that role. It’s very rare, after all, for a project to begin with complete knowledge about all of the factors and circumstances that will shape the project. Instead, projects usually start with at least some TBD (to-be-determined) facts needed to plan the project and some project management decisions that have to be made with sketchy information.

One important objective of the kickoff meeting is therefore to make sure that all individuals involved in the project’s management or oversight have a common understanding of what uncertainties face the project and what steps are being taken to protect the project from them.

In the complex, dynamic environment in which Federal projects are conducted future circumstances are especially difficult to foresee. A project manager may therefore be tempted to take a “wait and see” approach about something that’s unknown or uncertain by waiting until the decision absolutely has to be made in the belief (or hope) that the needed information will be available or confirmed by then.

Letting project management decisions just slide for an indeterminate period is, of course, a mistake. “Wait-and-see” is just not a valid management approach. After all, the epitaphs of many a failed project read “We hoped for the best.” Instead, the PM should proactively address any important but missing/uncertain information through four steps:

1.  Identify each missing or uncertain piece of information that is important to the project’s planning and operation.
2. Make the best possible estimate of the information to use for near-term project planning and management. That estimate is formalized as a project assumption in the Project Management Plan.
3. Document a project risk associated with the possibility of the assumption being incorrect. Each project assumption presents an element of project risk because if the assumed value or circumstance turns out to have been incorrect, some adjustment may have to be made to the project’s scope, budget, or schedule. Each substantial project assumption should therefore be represented in the project’s risk registry and have an associated risk mitigation plan. These will all be documented in the project’s management plan, which will be updated as circumstances changes and information becomes available.
4. As the project progresses, use the project’s risk management and change management processes to adjust the project’s plans as new information about the unknown or uncertain factor becomes available. If an assumption turns out to have been incorrect, the impact, if any, on the project can be managed by using the change management process to balance the effect across the project’s scope, schedule, and/or budget.

One goal of the project’s kickoff and other early planning meetings, then, is to fully lay out the project assumptions so that they can be fully understood and vetted by the project management team and stakeholders. Doing this starts the project with a shared understanding of the project’s challenges and scope that might otherwise not exist. It’s likely that each project’s stakeholder and member of the management team harbors at least a general notion of what any missing information will turn out to be. The danger is that those notions may be very different from one another. Uncovering those differences later when the project is well underway could very well produce problems in project communications and scope management.

By discussing the project assumptions at the kickoff meeting, the PM can uncover these differences and build a consensus on the project assumptions going into the initial project management plan. The discussion of the assumptions can also uncover new perspectives and information that can guide improvements to the assumptions.

Developing Project Assumptions

Preparing for the assumption presentation at the kickoff meeting will consist largely of assembling the assumptions contained in the project’s solicitation and proposal. Unless the solicitation explicitly required that a consolidated list of assumptions be presented in the proposal, it’s likely that assumptions appeared in different proposal sections or volumes and had differing levels of emphasis. Bringing them together in a single presentation will therefore serve the very useful purpose of helping all stakeholders and members of the project management team understand the full range of contingencies the project will face as new information becomes available and key events occur.

That is especially true of the stakeholders and government members of the project’s management team. It’s possible that these individuals, even if they served on the source selection review team, will not be aware of all of the assumptions made by the contractor in their proposal. For example, under some procurements’ procedures, the technical evaluation review team may not see the cost proposal. Instead, select members of the evaluation team may only be given cost summaries or the results of cost analyses developed by cost analysts or the Procurement Officer. Under these circumstances, they may not be at all aware of any cost assumptions contained in the cost proposals, even though those assumptions could have technical and/or management implications.

The discussion of each assumption should also include the plan and schedule for validating or otherwise resolving it. That plan will center around the point in the project’s schedule at which information is expected to become available that will show the assumption to be valid, incorrect, or irrelevant. For the purposes of this article, we’ll refer to this point as the assumption’s milestone. The milestone serves the useful purpose of bringing management attention to any slippage in resolving the assumption and its associated risk.

It’s possible for a single assumption to have multiple milestones when it relates to a repeated activity. For example, an assumption may be that each of a number of sites will be fully prepared to support project operations during a system’s deployment. In that case, the scheduled date for each site’s implementation will be a separate milestone for the assumption and would represent a separate part of the assumption’s overall project risk.

Depending on the number and complexity of the project assumptions as well as their potential impact on the project, the presentation on them can take many forms. However, the key elements of information presented for each assumption should include:

• The fully stated assumption
• The rationale and method by which the assumed value or condition was estimated
• The project benefit realized if the assumption proves accurate
• The potential project impact if the assumption turns out to be incorrect
• The milestone for determining the accuracy of the assumption.

The window opened by this link «Sample Assumptions Table» shows one possible layout for presenting project assumptions, especially in cases where there aren’t a great number of assumptions and their estimation methods are not complex. In other cases, each assumption may require a separate slide or even a fact sheet.