How can a project manager create a plan without having specifications for the product defined at the beginning of the project?

Question

In handling my first real project as a project manager, I need to create a project plan to produce a particular product. However, the specifications are not being defined up front.

As a part of the project plan the stakeholders will produce the actual specifications of the product. My question then becomes how do I create an accurate work breakdown structure or project schedule for the implementation of the specifications and the project overall without knowing what those specifications will be?

Gathering specifications is a significant part of the project. It wouldn't make sense to plan the rest of the project until the specifications are completed. Either way the stakeholders will not be pleased.

Answer 1

How does a project manager manage planning without the specifications of the product at the beginning of the project

With difficulties.

Without knowing the specifications, you need to make assumptions about things. Projects go sideways even when you do have specifications, so this will be extra challenging. You need to draft a rough outline based on what you know right now.

So, take everything you know and try to lay it down. To that, add the things that are not specific to the project but are needed to be setup (not sure the project type you have but in IT for ex, that can be provisioning equipment, installing servers, etc.). Add everything you think is needed.

You will need buffers (you don’t know what you don’t know). You are at the start of the cone of uncertainty. So, unless you find a way to squeeze in a "project discovery and definition stage" to try to find out more of what you are building before starting the project, you will need to rely on a lot of buffers.

Then do the estimate with your team. Do you have a team at this point? If not, more buffer. Then also add a project management overhead required to keep things under control (like 10% or overhead metrics already available within your organization).

Use a PERT estimation. Discard the optimistic value and present a range between the most likely and pessimistic values as your estimate. Be transparent that a lot of assumption went into it and even that can go wrong.

The best approach though would be an incremental one. Take the large cone of uncertainty and break it down into smaller ones.

This reduces risk and allows for discovery of what is needed as things progress. It also avoids building what you were asked to build (eventually), but then everybody complaining that it’s not what they wanted.

An incremental approach though is more difficult to pull over in an environment where everybody wants traditional project management where they don’t know what they want, but they know exactly when they want it... and it has to be cheap.

Good luck!

Answer 2

There are a few options.

One option would be rolling-wave planning. Perhaps some aspects of the project, such as the end date, are known and can be laid out. You may be able to plan enough work to gather requirements and specifications, validate those requirements and specifications, and then plan the remainder of the work, while capturing any other high-level milestones that may be otherwise fixed.

You could also take an even more adaptive approach and focus on control. If you know some characteristics of the project and what knowledge and skills you may need, you can build a team and work in short increments. If you have an understanding of how long it may take to get enough detail in a specification to start to execute, you can plan that portion of the effort and then revisit, perhaps even deciding that, based on the specification, it doesn't make sense to proceed.

Answer 3

As you surmised, you cannot create an accurate work breakdown structure or project schedule for the implementation of the specifications and the project overall without knowing what the specifications are.

What you can do is some clever guestimating by talking to the developers who will be implementing the product.

Then add in the time to test, integrate and ship and you will have a ballpark figure.

The multiple all estimates by π and you'll have the perfect schedule. ;-)

Answer 4

Build a Phased Project Including Introspection and Baselining Activities

As a part of the project plan the stakeholders will produce the actual specifications of the product, my question then becomes how do I create an accurate work breakdown structure or project schedule for the implementation of the specifications and the project overall without knowing what the specifications are?

You don't. If you can't get sufficient planning details ahead of time, then you can put together a phased project with time and budget allocated to tasks such as:

Phase 1

1. Gathering specifications.
2. Analyzing specifications and decomposing them into WBS packages for a subsequent phase.
3. Build out the plan for Phase 2 based on the information you've gathered and analyzed.
4. Some form of project introspection to determine if the project should proceed to Phase 2 based on the information you then have.

A phased project is extremely common in situations where you know generally what is supposed to come out of the very end of the project (e.g. "build a new website" or "move to a new data center") but no one knows exactly what that will actually entail. So identify both the known-unknowns and unknown-unknowns, you have to build in information-gathering, analysis (including development or realignment of budget, scope, schedule, and resource baselines), inspect-and-adapt, and go or no-go inflection points within the initial project plan.

Why This is a Common (Anti-)Pattern and How to Communicate to Stakeholders

If you are asking about specifications, that means you aren't doing factory work where you're churning out additional widgets you already know how to make. That means you have a cone of uncertainty anyway, so even if you had some initial hand-wavey specifications you'd want to build in phases and add sufficient slack to do periodic re-evaluation anyway.

All projects require slack and fine-tuning to be successful. Poorly defined projects simply require a lot more of both. Make that clear as part of the plan, add the risks of having so many unknowns and a lack of defined specifications to the risk register you create during project initiation, and move on with your life.

As long as you have pointed out that a project with no specifications can't be planned with exactitude, all you can do is include gathering and refining those things explicitly within the project itself. It's a common issue in project management, and the project's sponsors fundamentally own that risk so long as you've done your due diligence in pointing that out during project initiation.

Consider Emergent Design, or Pad for Replanning

No large project can be fully specified up front. This is a myth, and the source of much pain for project managers who don't already know that and who fail to effectively communication that to stakeholders.

If you can use an iterative methodology where the how of the project deliverables are an emergent property, then do that instead. Otherwise, the lack of initial detail around scope, functional, and non-functional requirements will require continuous re-planning. That's why change requests, scope control, and rebaselining are relied on so heavily in traditional project management.

Experienced project managers build these activities into their projects even when doing waterfall-type projects, whether explicitly or implicitly, for exactly the reasons given above. You just have to plan for all the replanning, and set everyone's expectations—including your own!—accordingly.