Building Executable Project Plans – Part 3

by Kathleen Austin & Gerald Kendall

Part 1 provided an introduction to projects and the need to plan a project. Part 2 discussed how to ensure the correct level of detail in a project network. Basis for these posts: Advanced Multi- Project Management: Achieving Outstanding Speed and Results with Predictability, by Gerald I. Kendall and Kathleen M Austin, J.Ross Publishing, 2012.

Finally, we begin the 10 steps to building an executable project plan!

Step 1: Define the project’s measurable goals, tangible scope and sponsor criteria

Background: Users often complain about project outcomes. Scope creep is one of the most voiced issues in project management. No wonder. In the vital “giving birth” stage of a project, once again, we witness two extremes. Either we see a 20+ page document, sometimes called a Project Charter, that has so much detail in it that it is almost guaranteed to put you to sleep, and further, to not be very useful in gauging whether or not the project will meet all of the key stakeholder needs. The other extreme is brief project scope and/or objectives statements that are so vague as to be proclaimed an open invitation for scope creep within days of project initiation.

This step is analogous to having a blueprint for building a house. Before you start building, you must have a pretty good idea of how big the house will be, and its dimensions, or you will not know where to put the footers nor how strong the footers must be. Everything else flows from this key front end definition of stakeholder needs. Do not skip this step nor any of the elements described below!!! Have your attention? Good! There are too many anecdotes about a project’s budget and timeline being almost totally gone when the project team finds out that what’s being produced is not what the stakeholders expect. Oops!

 

What is the desired result of Step 1? The project planners and all stakeholders understand and agree upon the goals, scope, sponsor criteria, functional criteria, and boundary conditions for the project.

There are two parts to this step:

1. Preparing for the Project Stakeholders’ meeting;
2. Holding the Project Stakeholders’ meeting;

Note: The material below assumes you are responsible for project planning

Preparing for the Project Stakeholder’s Meeting

Meeting Attendees: First identify the project stakeholders and other key people who should be invited to the meeting. If you’re not sure, these questions may help in developing a checklist of meeting invitees for this and future projects:

• Who does the Project Manager report to for this project?
• Who is sponsoring this project?
• Are there customers for the project? Please note that a project’s customers may be internal or external to the organization; at times there can be both internal and external
• Who is providing funding for the project?
• Who provides resources for the project (human, equipment, facilities)? Again, these resources may be internal or external – who represents each of their interests? Do unions represent any of the resources? If so, are they represented?
• Are there key functional areas that should be represented? Engineering (and those sub- sets), production, marketing, sales, contracting, legal, safety, product development, technical documentation, distribution, etc.?
• Are there additional people (internal or external) that require project progress reports?

Meeting Logistics: After determining who should attend the meeting, determine when and where the meeting will take place. It may also be important to set up video-conferencing for some attendees.

Meeting Self-Preparation: This is not so that you can provide all the answers at the meeting! J It is so you begin to understand what you will hear from the attendees as well as giving you the “big picture”. This preparation will also help ensure nothing is left out at the meeting.

• Gather and study any existing project documentation, including any planning documents, trade studies, etc.
• Ensure you understand how each of the customers plans to use the output of the project – similarities and differences.
• What is the scope of this project? How many, what is involved, which locations? Is the scope the same for each customer?
• What are the tangible deliverables and what functional requirements must they meet?
• What is the project’s output – an analysis, a prototype, a production-ready unit, a quantity of product delivered to multiple distribution warehouses with technical

 

support fully-staffed and ready to answer questions, a new product available at all locations with full advertising campaign and fully-trained sales staff?

• What impact does this project have on your organization: What is the predicted bottom- line positive garnered from delivering the project on-time, within budget, and with full scope? When does the organization expect to begin seeing those bottom-line impacts? If there is not a bottom-line positive impact, why is the project being done? There must be a benefit statement of some kind – expect it to be measurable, even if it is qualitative rather than quantitative.
• What are the budget(s) allocated to the project (remember, a financial budget is not the only type of budget)?
• What are the risks to the project’s success? Include known significant technical, schedule, and budget Will the major items that the project needs (e.g., equipment, prototypes, software, long-lead-time items) be available when promised? Will these items likely be according to required specifications? Have those risks been documented and their impact calculated?
• What assumptions are being made about the project (by any of the stakeholders, including you)?

Now that the pre-meeting homework is done, you’re ready to conduct the meeting: gathering data from the experts in the room in a manner that fully accomplishes the meeting goals without wasting time or money.

TIP: Consider whether the pre-work will be similar for all projects. In many cases, it makes sense to follow a checklist in preparing for every project meeting. Here’s a sample:

 

Project Name

Meeting Attendees? List required and optional

Project Access, Information, Considerations, Security, Sensitivities?

Project Due Date(s)? What is required on this date/each date?

Project customers (internal & external)?

Project Documentation Required? Specify both internal and external requirements

Project Reviews? Specify type, quantity, and dates, if already scheduled

Customer furnished data, drawings, materials, specifications, etc.?

Required Tests? Specify types, locations, requirements, attendees

Minimum or Maximum intervals between tests?

Test data? Sent to whom? In what form and format?

Required Permits or Certifications? Specify types and sources

External Resources or Facilities? Specify

 

Long-Lead items?

Public Affairs/Legislative constraints?

Marketing/Sales/Legal constraints?

Global manufacturing constraints?

Government involvement/constraints? Specify level, agency, involvement/constraint

Assumptions?

 

PRE-STAKEHOLDERS’ MEETING SAMPLE CHECKLIST TOPICS

 

Project Stakeholder’s Meeting

Ensure that the person whose role is to facilitate the Project Stakeholders’ Meeting uses this standard approach. Remember, in a multi-project environment, if some project networks and scope are defined poorly, this will create chaos for ALL the projects during execution.

TIPS:

• All the attendees need to be able to see what’s written in its entirety. Have available multiple whiteboards or chart paper that you can stick on the walls. Since this will be a multi-page outcome, using a computer is only practical if you are able to print what you capture for all attendees as you go.
• Remember: The facilitator’s pre-work is to get in the right mindset to listen and gather data at this meeting, not to tell the attendees what the project should be!
• Follow the meeting outline!

 

1. Present this meeting’s goal: “The project planners and all stakeholders understand and agree upon on the goals, scope, sponsor criteria, functional criteria, and measurable outcomes for this project.”
2. Identify the scope and goal(s) of the project. What IS this project? There may be one or multiple statements of scope elements. Identify whose goal (perspective) it is as you go, since different stakeholders/key people may state the same goal in different ways or it may sound the same but have a very different meaning to some attendees. This also helps determine whether there are conflicting goals (or whether they are just stated from a different perspective). The facilitator is the “clearinghouse” – making sure everyone understands what’s been said and that terms have the same meaning for all.
3. Make sure that the goals are expressly and measurably related to the goals of the organization. How much new revenue will be generated? By how much will operating expense be reduced? How much will this project add to the organization’s profits? How much faster will patients get through an emergency room? How many more aircraft will be ready for missions and testing? How much shorter will customer lead-times be? Etc.

 

4. Ensure all customers/types of customers are listed, including what needs this project meets or issues this project resolves for each of the customer types. Reminder: Customers may be internal, external, or both.
5. Define the tangible deliverables – the project’s output(s). How many, in what form, delivered to which customer, delivered where (to the loading dock, delivered to a distribution facility, etc.)? Are there any interim outputs that must be provided? Are any of the interim outputs date sensitive? Are the outputs products, drawings, an analysis, a prototype, a production ready unit, a fully-ramped up production line, etc.? What must accompany the output? Ensure the functional requirements or specifications of the project’s output(s) are defined as well.
6. Are there any major items needed for this project (e.g., equipment, software)? When will they arrive? From whom? What are the specifications required for those items?
7. When does your organization start making money (gaining bottom-line benefit) from this project? Do the goal and scope statements reflect that? For example, is the project to construct a new production facility or is the project to be at full productive capacity in the new production facility? There is a big difference between those two project scopes! The goal and scope should always be stated in a way that reflects when your organization realizes bottom- line positive value.
8. Are any customers imposing mandatory reviews? Are there contractual milestones?
9. What are your budgets to accomplish this project? Budgets can be financial, facilities, headcount, or a combination.
10. Describe the technical, schedule, and budget risks to the
11. Define any sponsor criteria that have not yet been
12. Document any additional stated

When you have achieved the meeting’s objectives, summarize and close the meeting. After the meeting, review what’s been gathered. Do a final check to make sure all statements and documentation are clear. Ensure all attendees receive a copy of what’s been documented.

Here’s a sample format:

 

Scope/Goal(s):

·

Customer(s):

·

Tangible Deliverables/Functional Requirements of Output(s):

·

Major Items / Specifications Needed as Project Inputs:

·

Bottom-Line Impact to Organization:

 

·

Budget(s):

·

Risks:

·

Sponsor Criteria:

·

Assumptions:

·

TEMPLATE FOR STAKEHOLDER MEETING RESULTS

 

Food for thought: Kitting has become an important aspect of accomplishing projects smoothly. It is certainly too early to identify and evaluate all kitting opportunities, but some kits may be able to be identified already. Do not miss the opportunity to gather kitting ideas, but do not let this diffuse/dilute the meeting’s purpose.

Summary

To avoid scope creep and its ultimate consequences – projects delivered late, over budget and/or not within scope, a careful process is needed. The process includes people who must be invited to a meeting to define the project, topics to be covered, and documentation of the outcomes. This documentation forms the basis of checking every task in a project plan, to see if it is needed and if it, in fact, helps the project meet these stakeholder criteria. Furthermore, this documentation allows the team to check that all criteria are met, once the network is finished. To be useful, such documentation must be organized, succinct and directly related to the goals of the organization.

Next Post

• Step 2: The Backbone of the Project Plan