PLAN                                                                            April 16, 2004

 

PLAN = Predicted Logistics and Actions based on Needs

 

 

A plan is an articulation of the significant actions and logistics necessary to track whether the projection will be met or not.  There will be millions of streams of time that will happen in reality, but the plan captures only the ones we need to highlight for ensuring the outcome is achieved.

 

To be effective, plans must be follow-able and track-able, and need to be regularly updated and published to all who are participating in its execution.  Levels of detail are necessary for different levels of tracking.

 

This highlights that the quality of a plan depends on the understanding of the needs, the quality of the predictions, and the effectiveness of publishing and tracking.  It is finally evaluated by the degree of variation between the plan and the actual.  The more the variation the worse was the plan, and the closer the actual is to the plan the better the plan was.

 

The kinds of plans a project will have:

·        Financial plans

·        Work breakdown schedules and dependencies

·        Resource plans

·        Infrastructure plans

·        Quality assurance and control plans

·        Risk management plans

 

--- o ---

 

A good enabler to make effective work breakdown structures and schedules simply, is to begin each task or activity name with a verb, e.g. “Create storyboard”.  I have seen most plans saying generally some thing like “Storyboard”, which is inadequate.

 

--- o ---

 

Being creative about how to break down a problem into solvable chunks of problems is the most important for the planner/designer of the solution.  How the (bigger) problem is broken down into smaller problems conceptually, and how the smaller problems are configured into practical action plans that solve them is what leads to the innate quality of a plan, or design to work towards the solution.

 

And it is always the alignment of understanding of a problem in a way that is commonly envisioned by all stakeholders, which will make the solution valuable.

At what level should a plan be describing what will happen?

 

The diagram below shows all the levels that a plan will describe, and who are the people who need to see the plan at that level of detail most often.

 

Plan should be down to this level of detail.
 
Task/Activity Levels                                                             Most used by

 

      PRODUCT                                                                                  -            Customer, PM

            1         Phase/Process                                                          -   PM

            1                Deliverable                         -                             Config Repository

1                         Sub-phase/process                                  -   TL

            1                                  Activity/Behaviour                          -   Individual

            1                                          Person                                    -   (for self)

1                                                 Day  

            1                                                          Hour

 

One of the biggest risks that a project runs is of all the team members not understanding the plan.  They might not understand the assumptions in the planner’s mind as she was planning, nor the detail of the work/decision activities they will do as they execute the plan.  This should be a primary concern for the project manager.

 

A great way of ensuring this is to show the plan down to detailed activities which are at least at the 1 person level in the above structure.

 

-- o --

 

To highlight the criticality of this risk when many people are involved, lets look at a scenario where 100 people are working together in a team that is working towards completing a project.  Each of the team members when asked was very confident of their meeting the project goals, and said they were each 99% sure they would meet their individual goals as set by the project manager.  This might seem a good situation for the project, and the PM may be confident about success.

 

However, if you calculate the probability of success for this project based on members’ confidence, the nett probability of the project meeting its goals is =  99% raised to the power 100.  And this number is a meager 64% !!

-- o --

 

MPP

 

Schedules in mpp meet the following objectives by being created, published, tracked, updated, and reviewed:

·        Predict the future activity schedules

·        Provide a personal plan for each member of the team – for improving focus

·        Replan based on updates

·        Show variation from plan for PM – for improving predicatability

 

Schedules in mpp – Guidelines:

 

Project Plan Phase

 

 

#

Aspect

Guideline

 

Preparation

 

 

 

Detail

1.  Activity at 1 person+task level – detail down

 

 

 

2.  Real, relatable names of tasks

 

 

 

3.  Task names uniquely descriptive and identifiable

 

 

 

4.  Enough written indication not to need memory

 

 

Voice

1.  Active, task names must start with verbs

 

 

Dependencies

1.  Correctly done (F-S, S-S, S-F, or F-F)

 

 

Effort

1.  Real, with process support to justify can be followed

 

 

 

2.  Resources leveled

 

 

Chunking

1.  Real as per project breakdown structure from Product – Deliverables – Tasks – Activities, with milestones at places for visibility.

 

 

Balance

1.  Milestone balance for visibility into project at least at 10% (or less) (effort) level into the project.

 

 

Format

1.  Must be in MS Project - *.mpp

 

 

Need based

1.  Reviewed with stakeholders vs. Project Goals to meet needs of all stakeholders, exceptions highlighted.

 

Deployment

 

 

 

 

·        Communication to all stakeholdes – Customer, Management/Business, Team, (Self)

 

 

 

·        Confirmation from all resources for acceptance (consensus) on plan (Do you know how… ?)

 

 

 

·        Get confidence levels and discuss (add value) to raise

 

Tracking

 

 

 

 

·        Update % task completion from each team member at end of day

 

 

 

·        Review reports from mpp

 

 

 

·        Replan

 

 

 

·        Communicate with all stakeholders to manage projections on schedules, process, and tasks.

 

 

Improvement in dates can happen through:

 

(Look at Critical Tasks/Activities in the schedule)

·        Reduce effort

o       Higher skill, knowledge -           From Practice

o       Better process                          -           From Practice/Splst

o       Automation                               -           From Content Technology

·        Increase number of people working at a task if technically feasible

·        Reduce work elements – customer has to agree if output parameters change!

·        Change dependency

·        Change sequence

 

If not enough improvement in dates happens, then communicate with customer for either:

·        Staggered delivery, or

·        Delayed delivery

--- o ---