Project Plan Development - Training Kate Pynn Product Management

Project Planning - 101 Task Assignment & Ownership Logical Relationships and Dependencies Task Duration Project Schedule Optimization and Risk Management Task Identification and Work Breakdown Project Plan Project planning is the construction of a dynamic agreement across diverse functional groups involved in a project. This agreement specifies: Goals and deliverables of the project What is being developed Major activities that will be performed to achieve those goals The assumptions that were made Major risks, as they become known

Project planning is the construction of a dynamic agreement across diverse functional groups involved in a project. This agreement specifies:

Goals and deliverables of the project

What is being developed

Major activities that will be performed to achieve those goals

The assumptions that were made

Major risks, as they become known

Common Questions - Answered in this Training The benefits of good planning seem obvious. So, why do so many organizations and project managers fail to plan their projects? New project managers may lack paradigm knowledge about planning, but why do even some experienced project managers ignore or actively avoid good planning? What are the elements of a good project plan? No matter how much or how little I plan a project, the plan ends up gathering dust on the shelf during execution - why? What are some of the methods used to create such a plan? How detailed does the plan need to be? How can I identify the risk areas early? What is the difference between project scope and product scope? What is "scope creep" and how can I avoid it? How do I manage the trade-offs among project stakeholders? What processes and tools can help me turn a product vision into a coherent, executable plan?

The benefits of good planning seem obvious. So, why do so many organizations and project managers fail to plan their projects?

New project managers may lack paradigm knowledge about planning, but why do even some experienced project managers ignore or actively avoid good planning?

What are the elements of a good project plan?

No matter how much or how little I plan a project, the plan ends up gathering dust on the shelf during execution - why?

What are some of the methods used to create such a plan?

How detailed does the plan need to be?

How can I identify the risk areas early?

What is the difference between project scope and product scope?

What is "scope creep" and how can I avoid it?

How do I manage the trade-offs among project stakeholders?

What processes and tools can help me turn a product vision into a coherent, executable plan?

What is Project Planning? An agreement. The heart of this agreement is the documented compromise among the following variables: The time to complete the deliverables The amount of work to complete the deliverables The cost of completing the deliverables Features, functions, and attributes (such as product cost) of the deliverables. The planning process allows for changes to this agreement during the project's execution. As the planning process proceeds, its documentation becomes a dynamic guide for the execution of the project.

An agreement. The heart of this agreement is the documented compromise among the following variables:

The time to complete the deliverables

The amount of work to complete the deliverables

The cost of completing the deliverables

Features, functions, and attributes (such as product cost) of the deliverables.

The planning process allows for changes to this agreement during the project's execution. As the planning process proceeds, its documentation becomes a dynamic guide for the execution of the project.

Why have a Project Plan? When you create a project plan, you are developing: An initial course of action toward a well-defined set of objectives A mechanism to aid in detecting variance both in the planned progress of the work and also in the target objectives. The purpose of a project plan is NOT to predict the future. You lay out: The best initial course of action with what you know today A process that will constantly test this course during its execution for its match with the current, changing environment.

When you create a project plan, you are developing:

An initial course of action toward a well-defined set of objectives

A mechanism to aid in detecting variance both in the planned progress of the work and also in the target objectives.

The purpose of a project plan is NOT to predict the future. You lay out:

The best initial course of action with what you know today

A process that will constantly test this course during its execution for its match with the current, changing environment.

Measuring and Checking Progress Build into the plan the activities and processes that will support dynamic, round-robin, never-ending measurement during execution: Frequent, measurable milestones Periodic testing, reviews, and issue management that will systematically capture and measure the delta between requirements and emerging design Periodic "testing" of the product or system requirements with marketing or the customer, to see if the target is changing out from under you Scheduled midcourse corrections of the project plan itself, as you learn more Early removal of technical risk through prototypes and testing

Build into the plan the activities and processes that will support dynamic, round-robin, never-ending measurement during execution:

Frequent, measurable milestones

Periodic testing, reviews, and issue management that will systematically capture and measure the delta between requirements and emerging design

Periodic "testing" of the product or system requirements with marketing or the customer, to see if the target is changing out from under you

Scheduled midcourse corrections of the project plan itself, as you learn more

Early removal of technical risk through prototypes and testing

What is Scope Creep? "Scope creep" is a shift in project goals or project process caused by incremental changes to the project's requirements or constraints (like adding a product feature or reducing a critical resource from 75% time to 25% time on the project). The term is also used to describe the deterioration of the project plan caused by incremental changes to the project goals that are not: Detected, Measured for their impact, Approved or rejected based upon the contribution to overall project value, Incorporated into the scope of work, time, and cost of the project.

"Scope creep" is a shift in project goals or project process caused by incremental changes to the project's requirements or constraints (like adding a product feature or reducing a critical resource from 75% time to 25% time on the project).

The term is also used to describe the deterioration of the project plan caused by incremental changes to the project goals that are not:

Detected,

Measured for their impact,

Approved or rejected based upon the contribution to overall project value,

Incorporated into the scope of work, time, and cost of the project.

How do you Manage Scope Creep? The best insurance against scope creep during the execution of the project is the following: a clear, precise, measurable, written vision, and... a record of the benefit-cost tradeoffs and the early reviews and negotiations that built the vision. When the inevitable changes are requested, you can manage the scope creep by testing these change requests against the vision - the value you are trying to deliver to the customer in a constrained time.

The best insurance against scope creep during the execution of the project is the following:

a clear, precise, measurable, written vision, and...

a record of the benefit-cost tradeoffs and the early reviews and negotiations that built the vision.

When the inevitable changes are requested, you can manage the scope creep by testing these change requests against the vision - the value you are trying to deliver to the customer in a constrained time.

What are the Project Plan Elements? Here's a checklist of what should be included in nearly all project plans: The business case Scope Statement The name of the Product/Project manager The project's organizational strategy and management strategy A roster of required team members and their functional expertise Work Breakdown Structure. Cost estimates, start dates, and responsibility assignments of the work breakdown. Performance level baselines for schedule and cost. Major milestone descriptions and dates Key risks, including constraints Scope Management Open issues and pending decisions (punch list)

Here's a checklist of what should be included in nearly all project plans:

The business case

Scope Statement

The name of the Product/Project manager

The project's organizational strategy and management strategy

A roster of required team members and their functional expertise

Work Breakdown Structure.

Cost estimates, start dates, and responsibility assignments of the work breakdown.

Performance level baselines for schedule and cost.

Major milestone descriptions and dates

Key risks, including constraints

Scope Management

Open issues and pending decisions (punch list)

Good Project Planning - Key Two keys to success in good project planning are: Always think about and say something about each one of the checklist areas (and others that are applicable), regardless of the size of the project, the industry involved, and the product or service being produced. Clearly, the scale of the plan elements will differ, depending on project scope. Plan accordingly.

Two keys to success in good project planning are:

Always think about and say something about each one of the checklist areas (and others that are applicable), regardless of the size of the project, the industry involved, and the product or service being produced.

Clearly, the scale of the plan elements will differ, depending on project scope. Plan accordingly.

How do I get Started? Announce the Product/Project manager Start planning with a team, not alone Create a Vision Start small with a few core people and verify that the overall project goals make sense: the product is a strategic fit with the organization's goals, the return on investment is attractive, etc. If the fundamentals don't pan out, then kill the project early. If it looks good, then add to the core team, investigate and learn some more about the effort, and validate the goals again with this increased level of detailed knowledge. If the plan still looks viable, then continue this process of committing more resources and developing more detail. Business strategy first Accessing Lessons Learned

Announce the Product/Project manager

Start planning with a team, not alone

Create a Vision

Start small with a few core people and verify that the overall project goals make sense:

the product is a strategic fit with the organization's goals,

the return on investment is attractive, etc.

If the fundamentals don't pan out, then kill the project early.

If it looks good, then add to the core team, investigate and learn some more about the effort, and validate the goals again with this increased level of detailed knowledge.

If the plan still looks viable, then continue this process of committing more resources and developing more detail.

Business strategy first

Accessing Lessons Learned

How does Project Planning fit into ISD? The initial project planning process is tightly coupled to our ISD product development process. Activities are grouped into phases that are gated by management reviews The planning process is the centerpiece of the first three product development process phases.

The initial project planning process is tightly coupled to our ISD product development process.

Activities are grouped into phases that are gated by management reviews

The planning process is the centerpiece of the first three product development process phases.

How do I Balance Planning with Time-to-Market Demands? Choose the features we need in the time that we have Coming up with a set of product features and attributes that we can get done in the time we've been given is probably the toughest part of project planning. Here are a few pointers to keep in mind during the feature/time/cost trade-off negotiations: Identify the 5 - 20 critical product requirements without which the project should not be done. Apply benefit-cost trade-off analysis - time-to-market vs. feature set - to break a negotiation impasse. Continually validate the negotiation process with customer involvement. The better job you do in arriving at a truly shared vision, the less "scope creep" and "creeping elegance" you are likely to see later in the project.

Choose the features we need in the time that we have

Coming up with a set of product features and attributes that we can get done in the time we've been given is probably the toughest part of project planning.

Here are a few pointers to keep in mind during the feature/time/cost trade-off negotiations:

Identify the 5 - 20 critical product requirements without which the project should not be done.

Apply benefit-cost trade-off analysis - time-to-market vs. feature set - to break a negotiation impasse.

Continually validate the negotiation process with customer involvement.

The better job you do in arriving at a truly shared vision, the less "scope creep" and "creeping elegance" you are likely to see later in the project.

How do I Balance Planning with Time-to-Market Demands? Preliminary design reviews. As soon as enough high-level design has been done to identify design alternatives, one or more preliminary design reviews should be done as part of the feature/time/cost trade-off negotiations. It's never too early to test! Early testing can uncover many issues and allow an alternative approach to be selected while it is still relatively cheap to do so. Identifying all of the work. Early identification of all project work is crucial to estimating project cost and also a fundamental input into the scheduling process.

Preliminary design reviews.

As soon as enough high-level design has been done to identify design alternatives, one or more preliminary design reviews should be done as part of the feature/time/cost trade-off negotiations.

It's never too early to test!

Early testing can uncover many issues and allow an alternative approach to be selected while it is still relatively cheap to do so.

Identifying all of the work.

Early identification of all project work is crucial to estimating project cost and also a fundamental input into the scheduling process.

How Detailed should my Project Plan be? Detailed planning versus light planning Just-in-time planning Measurable and testable goals Do planning at a sufficient level of detail to ferret out issues and problems during the early planning process itself Build into the plan the hooks for measuring if you are drifting off course during the plan's execution. Finding the sweet-spot for planning At-a-distance teams and outsourced services/development

Detailed planning versus light planning

Just-in-time planning

Measurable and testable goals

Do planning at a sufficient level of detail to ferret out issues and problems during the early planning process itself

Build into the plan the hooks for measuring if you are drifting off course during the plan's execution.

Finding the sweet-spot for planning

At-a-distance teams and outsourced services/development

What is Risk? "Risk" is a measure of two factors: the probability of an event occurring, AND... the severity of the consequences of that event. Thus, a "high risk" event can be either one that is very likely to occur with moderate consequences each time it does, or one that is extremely unlikely but with catastrophic consequences on each occurrence. Removing a risk means either eliminating the possibility of occurrence of an event or rending the event completely harmless when it does occur.

"Risk" is a measure of two factors:

the probability of an event occurring, AND...

the severity of the consequences of that event.

Thus, a "high risk" event can be either one that is very likely to occur with moderate consequences each time it does, or one that is extremely unlikely but with catastrophic consequences on each occurrence.

Removing a risk means either eliminating the possibility of occurrence of an event or rending the event completely harmless when it does occur.

Project risk verses technical risk Project risk examples: Inability to find a suitable project manager Inability to staff key team positions Design reviews don't identify deviations from requirements Inadequate communication among remote team members Technical risk examples: Cannot achieve noise targets in an analog circuit design Cannot achieve dimension requirements in a packaging design Cannot implement a software algorithm on the target machine Cannot meet response requirements in a real-time system Cannot fit software program in available memory

Project risk examples:

Inability to find a suitable project manager

Inability to staff key team positions

Design reviews don't identify deviations from requirements

Inadequate communication among remote team members

Technical risk examples:

Cannot achieve noise targets in an analog circuit design

Cannot achieve dimension requirements in a packaging design

Cannot implement a software algorithm on the target machine

Cannot meet response requirements in a real-time system

Cannot fit software program in available memory

How do I keep Risk from Disrupting my Project? Start the process early, as soon as one other core team member is available for brainstorming. Brainstorm with core team, identifying as many risks as possible. Use previous product experience, personal experience, regulatory input, and common sense. Create a risk analysis document that, at a minimum, contains the identified risk, the event that causes it, a measure of probability, a measure of severity, and a mitigation or elimination strategy. Explicitly incorporate the mitigations into either planned project process activities or product requirements. Make the risk analysis part of the project plan that is agreed upon by all stakeholders and team members. Periodically review and amend the risk analysis with new information gained from reviews, inspections, audits, and marketing or customer input.

Start the process early, as soon as one other core team member is available for brainstorming.

Brainstorm with core team, identifying as many risks as possible. Use previous product experience, personal experience, regulatory input, and common sense.

Create a risk analysis document that, at a minimum, contains the identified risk, the event that causes it, a measure of probability, a measure of severity, and a mitigation or elimination strategy.

Explicitly incorporate the mitigations into either planned project process activities or product requirements.

Make the risk analysis part of the project plan that is agreed upon by all stakeholders and team members.

Periodically review and amend the risk analysis with new information gained from reviews, inspections, audits, and marketing or customer input.

How do I remove Technical Risks? Techniques for removing technical risk include the following: Measuring innovation risk Early reviews of high-level architecture Early feasibility tests Early prototype tests

Techniques for removing technical risk include the following:

Measuring innovation risk

Early reviews of high-level architecture

Early feasibility tests

Early prototype tests

How do I document Assumptions and Risks? Here's a few pointers on how to document assumptions and risks in the project plan: Generalized characterizations of a plan like "this is aggressive" or "this is the 20% confidence plan" tend to be filtered out and lost by upper management. What is retained is your commitment to the plan. So, if your plan has such a risk characterization, put it in the title of the plan itself or an equally prominent place. Make the risk analysis, or at least a summary of it, an integral part of the project plan document. If they are separate documents, the plan may be taken out of context. List "assumptions" as "risks" in your plan. Making an assumption really is a statement of risk. And assumptions may get more attention that way.

Here's a few pointers on how to document assumptions and risks in the project plan:

Generalized characterizations of a plan like "this is aggressive" or "this is the 20% confidence plan" tend to be filtered out and lost by upper management. What is retained is your commitment to the plan. So, if your plan has such a risk characterization, put it in the title of the plan itself or an equally prominent place.

Make the risk analysis, or at least a summary of it, an integral part of the project plan document. If they are separate documents, the plan may be taken out of context.

List "assumptions" as "risks" in your plan. Making an assumption really is a statement of risk. And assumptions may get more attention that way.

How do I Form a Cross-Functional Team? Planning in a Vacuum A fundamental cause of project failure is planning done by a sole project manager or an incomplete group of stakeholders. Plan to negotiate for people's time to plan Make a team roster Identify team members and prospective team members by name, role, and area of responsibility. Do a gap analysis Identify the critical skills needed for the project Compare those to the current and potential team members Identify any gaps.

Planning in a Vacuum

A fundamental cause of project failure is planning done by a sole project manager or an incomplete group of stakeholders.

Plan to negotiate for people's time to plan

Make a team roster

Identify team members and prospective team members by name, role, and area of responsibility.

Do a gap analysis

Identify the critical skills needed for the project

Compare those to the current and potential team members

Identify any gaps.

Is this YOU? “ I don't want to commit to a plan because it limits my flexibility and documents my poor estimates and incorrect assumptions.” Commit to planning, not just the plan. When you commit to a project plan, an important part of that plan should be the process of constantly re-verifying the assumptions and estimates that are clearly stated in the plan. Pejorative metrics. Midcourse corrections in schedule, cost, or features demonstrate a success in managing your project, instead of a failure.

“ I don't want to commit to a plan because it limits my flexibility and documents my poor estimates and incorrect assumptions.”

Commit to planning, not just the plan.

When you commit to a project plan, an important part of that plan should be the process of constantly re-verifying the assumptions and estimates that are clearly stated in the plan.

Pejorative metrics.

Midcourse corrections in schedule, cost, or features demonstrate a success in managing your project, instead of a failure.

How do I “freeze” my Project Plan? You can "Soft freeze". FYI - Project planning is never really finished. There are three planning milestones to ensure that the plan is as complete as possible with what you currently know: Cross-functional agreement among all stakeholders and team members on the business case and the basic viability of the project. Cross-functional agreement among all stakeholders and team members on the product vision after high-level design solutions have been reviewed and tradeoffs have been made between features, time, and cost. Cross-functional agreement among all stakeholders and team members that you have a viable plan to achieve the product vision within the boundaries of the business case.

You can "Soft freeze". FYI - Project planning is never really finished.

There are three planning milestones to ensure that the plan is as complete as possible with what you currently know:

Cross-functional agreement among all stakeholders and team members on the business case and the basic viability of the project.

Cross-functional agreement among all stakeholders and team members on the product vision after high-level design solutions have been reviewed and tradeoffs have been made between features, time, and cost.

Cross-functional agreement among all stakeholders and team members that you have a viable plan to achieve the product vision within the boundaries of the business case.