Project planning – problems, scope, and deliverables

Project meeting

Plans are nothing; planning is everything.

— Dwight D. Eisenhower

If you missed Project Initiation: Let’s get this party started! go ahead and check it out now.

For some companies, project planning is a nuisance.  As project managers, we often must balance the urgency of senior management to see results and the importance of ensuring the team knows exactly what they are trying to accomplish. We know that planning is an integral part of the process – sometimes our stakeholders aren’t so sure.

Avoid Ready, Fire, Aim!

The planning process builds on the initiation process. As the project manager, it’s important that your sponsor supports you. You need to get on the planning as soon as possible, gather up the team, and start working on the project plan and the supporting documents. Try not to let the folks that aren’t interested in a plan take you off course.  To quote the PMBOK: The project management plan and project documents developed as outputs from the Planning Process Group will explore all aspects of the scope, time, cost, quality, communications,  human resources, risks, procurements, and stakeholder engagement. (Fifth Edition, 2013, pg. 55).

Yikes! That sounds like a whole bunch of work – and it can be. Keep it all in perspective for your project. Smaller projects won’t need quite as much planning as larger, multi-year projects. On the positive side, as the documents are drafted, they are available to your stakeholders as evidence that planning is progressing. Each company has different requirements and as a PM, you’ll begin to understand which documents you’ll need.  I’ve created all these documents for long-term, internal projects and smaller versions of most of these plans for those projects that have quick turns. There are only so many hours in a day!

The main thrust of planning should be a problem statement, the scope statements, a list of deliverables, the work breakdown structure, and the schedule with resource planning. I’ve also found requirements definitions, resource plans, communication plans and risk plans invaluable in some projects and if your projects are mainly for the same company, you may be able to repurpose some of these documents.

We’ll start with the problem and scope statements and deliverables, and work our way into the rest.

Problem and scope statements

How many of us have held that first project team meeting and heard these words, “We know exactly what the problem is and how to fix it. Let’s just get on with it!” If you haven’t heard this (or some version of it) you will eventually. Ignore these people – politely. If that is indeed the case, the meeting will be short and you’ll all go back to your desks in record time. This will not happen.

Agree on the problem

Get your team to agree on the problem you’re trying to solve. It usually becomes immediately apparent that everyone has a different version of this truth. Bring refreshments because folks need sustenance to get through this. Get the problem statement down to a couple of sentences – it should not be a page long. If it is, you may have several projects or phases to develop. Power through – this is a great way to start team bonding.

Agree on the boundaries.

After the problem is defined to most of the team’s satisfaction, it’s time to put boundaries around the project. Bring more cookies. This could take a while, but if you can get folks to agree, you’ll be halfway to success.

Here’s an example for a project I did many years ago: “The creation of training environments on a centralized web server for all XX Company’s courses, both application and technical. These courses include those for CRM, APS, and ERP.” This project took about eight months.

As the team is working through defining the scope, also take notes on what is not in scope. This list is important.

Project Deliverables

I suggest that there be some major deliverable or milestone about every four to six weeks. Stakeholders either lose interest or start rattling cages if they don’t see something happening. What can the team deliver to show progress is being made?  If you’re writing a new software program, what can be delivered and shown to stakeholders over time? Think about it and define it now so that everyone is aware.

As the planning is progressing, keep your sponsor and stakeholders aware of both the process and the decisions of the team. Communication is very important. Once the problem, scope, and deliverables are defined, you and the team should move on to time frames and the work breakdown structure.

What are the first phases of planning a project in your company? Let us know in the comments below.