ALL3PM

Sharing tools and ideas for Portfolio, Program, and Project Managers

Archive for the category “Scheduling”

26 Sep 2017

Why Projects Fail

Introduction

There are three primary categories of project failure or delay. The first objective of turning around a failing/delayed project is to identify causes. Once causes are understood potential remedies can be planned and implemented. Below is an outline of typical causes and/or symptoms of failure or delay.

Technical Development

There are many reasons for failure/delay in technical development whether hardware, software or service products.

a. Has the value proposition been identified?

i. You can’t design a product or process without a firm definition of what marketing has determined as the customer need and how the organization will satisfy this need. Fundamental.

b. Has product usage been identified? Sounds obvious but can be difficult in specialized niches or a new use for an existing product.

c. Poor customer definition.

i. Who’s the customer/user…the nurse, doctor, patient, purchasing, housekeeping, or other?

Hint 1: Everyone from the purchasing agent to housekeeping (disposal) is a customer/user. Does it meet their needs? If a hospital incinerates its trash can the materials be burned?
Anyone and everyone who touches or has to experience the product is a customer/user. And yes, unit and shipping packaging is part of the product. I’ve witnessed a medical disposable product launch get off to a very slow start because of product presentation (the method used to package). Current products on the market were presented on rolls for use where multiple units could be hung on an IV pole by the bedside for nurse’s use and convenience. This new product delivered individual units in a box. The box had to have a home in a drawer or on a shelf which was not always bedside. The product itself was a winner but acceptance slow due to expediency. BTW, the company made a change to rolls. This took several months with changes to parts, tooling, sterilization validations, and production.

Hint 2: Make a value stream process map on one axis showing the who, what, and where of the potential product flow from mfg. to hospital (vs. home vs. outpatient center vs. ?) through to disposal (trash vs. incinerator). On the other axis show/describe customer/user process flow for each user and location from diagnosis to therapy or want/need to supply. The axis should cross where customer/user meets product/service.

ii. Has the customer/user been formally defined?

Even if one of the users is the Doctor, has the type of Doctor been identified? The needs of an OB/GYN vs. a General Practice vs. a Nurse Practitioner are all different. Where are they located? Answers to these questions drive product requirements.

d. What is the product?

Is it hardware, software, service, combination, other?

e. Poor product definition

i. Without a. above being defined this cannot be done.

ii. Does marketing keep changing their mind as to features/benefits?

f. Poor product/customer requirements definition.

Need to answer who, what, and where in order to identify requirements.

g. Poor Engineering Requirements (ER) definition.

i. ERs must first be translated from product/customer requirements to ERs.

ii. ERs must be defined in a manner that can be measured or verified (NOT-Is this red enough?).

iii. Can you prove the product meets the requirements via facts (objective) as opposed to opinion (subjective)?

1. “Easy to carry” is not measurable and is a matter of opinion.

2. Product must weigh less than 10 lbs. is measurable and is a fact.

h. R&D not focusing on developing one ER at a time.

Several ERs are developed simultaneously thereby confounding the measurements necessary to determine which of the outputs meet the ER. This is particularly true when ER’s are at the opposite ends of the engineering spectrum, e.g. “Must be strong” vs. “Must be light” Q: How strong is strong? Requires defining tensile, cross section, etc. Q: How light is light? Requires weight definition. R&D needs to determine output individually or understand how the ERs relate.

i. Not understanding Key Input Variables (KIV) that drive ER output.

In systems there may be many KIVs that drive desired output. Most teams stop looking after they find 3-4 KIVs. Typically the other ones are found during launch when production variability via materials, process, and labor, are forced into the system. This may result in product slowdowns if product does not meet specifications or a recall if product makes it to market.
True story: I know of a medical disposable that had a designated activation force (ER). This device was made of several pieces of which two were rubber. One KIV to the system was the hardness of the rubber (durometer) for these two components. The company never measured durometer of this key component during production. Company received lots of rubber components that were too hard (high durometer). Product made it to market. Customers complained of high activation force. Company instituted a voluntary recall. Very costly in terms of dollars spent/lost and customer satisfaction!

Project Management

a. Time/Schedule

i. Forced upon team by executive management regardless of scope/costs

ii. No/Poor planning

iii. No schedule integration

iv. Death by a thousand cuts

v. No management control or feedback mechanisms

b. Scope/Quality

i. Scope is not defined or poorly defined (a top reason projects fail/delayed)

ii. Deliverables not defined

iii. Myriad scope changes without consideration of affect on Time/cost.

1. Marketing changes to

a. product requirements

b. Use requirements

c. Volume-from a 10k/mo to 1mm/mo.

d. Countries in which product will be sold

2. Manufacturing changes

a. Manual assembly vs automation

b. Mfg. location changes (from one plant to another)

3. R&D can easily add one more product feature

4. Regulatory issues

5. Legal issues

6. On and on and on……

c. Cost/Resources

i. Resources shuffled around due to firefighting because of No project-program-portfolio management.

ii. Poorly trained resources as in “(S)he’s an engineer let’s make him/her a project manager!”

iii. Task/Skill level mismatched

iv. Key Skill sets assigned to too many projects (always and always a bottleneck)

Hint: Lookup Critical Chain project management if this is a regular issue

d. Management dictating all three elements of the PM triple constraints (cost/scope/time).

This is dictating the length of all three sides of a triangle. Sometimes the ends meet sometimes they don’t, e.g. two short sides and one really long side. This also happens more than we care to admit and usually with a hand wave, “Make it so….”

Business Management

a. Projects/programs don’t align with strategy

i. No strategy

ii. Constantly changing strategies

iii. Not keeping up with changes in strategy

iv. Executive pet projects (happens all the time)

v. No method to determine if projects/programs align with strategy

b. Management doesn’t understand business strategy requires an implementation strategy.

It’s easy to say we’re going to the moon but if you don’t have any idea of what it may take it’s only a dream (or is that nightmare?)

c. “Culture eats strategy for breakfast”

A famous quotation attributed to the late business management guru Peter Drucker speaking to the need to have a business culture that can execute the strategy or recognize the need to change the culture to align with strategy.

d. No project/program portfolio management

i. Too many projects (This gets my vote for the No. 1 reason projects fail or delayed and a key killer of company moral.)

Many midsize companies easily have 200-300+ projects they can identify across all disciplines, e.g. R&D, Software, Mfg., Regulatory, Medical, Customer Service, Field Service, Supply Chain, etc.
As a manager of an R&D group in a large company I had 40+ projects for my group alone including NPI, line extensions, and Sustaining Engineering.

a. Some are high priority and assigned w/resources and costs.

b. Some are assigned w/resources and costs but no one is sure of their priority.

c. Some are picked at and mosey along when someone can spend some of their very limited time moving them along.

d. Some are hidden using hard dollars and resources

e. Some are department or executive pet projects

f. Some are project names or concepts only, on the To Do list, and without definition, scope, or resources.

g. Most require multidisciplinary teams.

ii. Too few resources/too few key resources

iii. All projects are top priority (therefore none are)

iv. Executive pet projects (happens all the time)

v. Not knowing the difference between a project, a program, and a strategy.

e. No project/program sponsor.

f. Lack of key decision making resulting in lack of scope definition.

i. Legal issues

ii. Regulatory issues

iii. Other issues(?)

iv. Flip flopping on decisions dependent upon whose making them or stakeholders involved.

This may happen when key decisions are made and take a long time to implement. Over time a new leader comes in who is now responsible for the former decision and does not believe in that decision and changes it without consideration of downstream effects.

Summary
This is a short list of the more typical causes of project failure and delay. My vote for the top two causes are:

1. Too many projects (or not enough resources) resulting in regular shifts in resource assignment and priorities.

2. No or poor scope definition resulting in regular changes to project deliverables.

Either of the above, if done perpetually, results in extremely inefficient performance and low morale.

The challenge in curing any disease is to: 1) Acknowledge there is a problem and 2) Diagnosis. Once a diagnosis is made as to potential cause(s) adequate steps may be taken to address causes.

Have a look through the list again, reminisce, and see if you recognize those causes that have affected your projects.

Question: What will you do differently next time?

 

Advertisement
Posted in Execution, Failure, Initiating, Leadership, Monitor & Control, Planning, Portfolio, Risk Management, Scheduling, Strategy, Uncategorized | Leave a comment
26 Apr 2013

Death By A Thousand Cuts or How To Slow Down Your Project Without Knowing Why

Just an observation regarding resources and resource planning.  When I’ve viewed other PMs project plans I’ve noticed that they assign resource names of core team members (first level) and many times extended team members (second level) and Subject Matter Experts (SME).  What I don’t see many PMs do is regularly create and assign resources to ALL “touch points” in a project.  My definition of “Touch Points” is any person, department, division, R&D/production/test equipment, vendor, supplier, or other that interfaces with the project and that must provide inputs or produce an intermediate or final output of some kind to the project.  Case in point, how many list the documentation department, metrology, or equipment maintenance as a resource in projects?  Why not?  New product projects easily generate hundreds (sometimes thousands) of Engineering Change Notices (ECNs) or Engineering Change Orders (ECOs). If the documentation dept. is a small staff and you have a  new medical product that generates one thousand ECN/ECOs over one year at one hour per ECN/ECO for review, input, processing, scanning, approvals, recording, backups, filing, and offsite storage you’ve just handed the dept.  1000+ hours of work or 6 man months of labor.  Will they be able to absorb that amount of additional work?  Are other projects ongoing that will add additional labor to this dept.?  Does the Doc. Dept. even have the budget for overtime or hire additional temporary staff if needed?  These are typical areas that are outside the project that we normally take for granted.  I worked on a project that revalidated an entire manufacturing site.  There were 1800 Installation Qualifications (IQ) alone not to mention additional Operational Qualifications (OQ) and Process Qualifications (PQ).  Each protocol had to be submitted and approved and put into documentation BEFORE execution.  Every executed final report had to be approved and placed into documentation.  That alone is two ECN/ECOs times 1800 IQs equals 3600 hours of additional labor!  By adding touch points to your project plan you can summarize your findings and have data to discuss with others. With this information you can meet with affected department managers and go over your findings and come up with a plan to address this potential bottleneck.  Perhaps the additional labor required to pay for processing ECN/ECOs comes out of your project budget!  This is the foresight and preplanning for which excellent PMs get paid.  The alternate is to wait three to six months into the project and keep bringing up and explaining why deliverables are late, “The paperwork is still in documentation!”

You get the idea.  Add ALL touch points as resources to your project plan.  Summarize and share the data with the affected parties.  They can approve your plan or you’ll at least have time to make changes that will minimally affect your schedule.

Posted in Execution, Planning, Scheduling and tagged | Leave a comment
01 Dec 2012
1 Comment

How Do You Plan With Your Team?

How do you plan your project?  How do you create, gather, compile, organize, and record your project plan and schedule (remember these are two different things…)?  Do you or your company have a procedure or is it ad hoc (“fashioned from whatever is immediately available…”)?  I’ve seen a range of planning, from:

1) the PM slapping together a Gantt chart,  then handing out the schedule with a few names here and there (think of this as resource planning), to

2) kickoff meetings where key items are discussed and recorded, to my favorite-

3) a full two and a half day planning session.

Each method above has its advantages and disadvantages.  I’ll touch briefly on the first two then describe why I believe the third choice is superior for medium to large projects.

In order of appearance above…

1) In the first method little upfront time is invested (low cost),  resources begin work immediately (hitting the schedule hard!), while true cost of the project ($$$) is determined later (and several times over) when all the project SCRAP is continually changing. (SCRAP- Strategy, Constraints, Risks, Assumptions, Parking Lot (unresolved questions)).   Comment: while the good news is they at least have a schedule my comment is this is a thinly disguised state of continuous confusion.  The PM and or management thinks they will meet the schedule because someone created one.  Meanwhile all the issues that plague projects will appear (they always do) and the schedule will be done over and over again until someone (PM, stakeholder, or business) runs out of money or time.

2) In the second method time is invested in determining or agreeing on Goals, Objectives, and Scope, perhaps at a project kickoff meeting.  Additional meetings are required to determine SCRAP one or more component at a time over the course of several days, if not weeks, maybe, maybe not.  My experience with this method is that teams tire of the additional meetings very quickly.  Getting team members to attend multiple planning meetings may be difficult especially if they are already attending the project meetings.  Key inputs may or may not be determined in advance.  In some cases they are dictated and not agreed upon by team members.  The good news is this method recognizes the need to obtain inputs from and communicate high value aspects of the project to team members.  Key decisions may be captured in a PM plan or at least captured in meeting minutes.  Discussions will evolve around typical project issues.  Time is limited to discuss full breadth or depth of project related matters.

3) As is the case in all these methods the purpose is to improve project definition, boundaries, understanding & strategy.  The multi-day planning session typically has higher up front time related costs.  8-10 core team members participate @ $50/hr for 20 hours = $10,000.  Plus meeting expenses, e.g. large meeting/conference room, food, projector, easels, etc.   Team members are introduced (team forming/storming/norming) and become focused on the project over the course of 2.5 days.   In addition to Goals, Objectives, and Scope the team defines and begins to understand project SCRAP.  Figure 1 below shows the agenda for this multiday exercise.Planning Session-Agenda

You should be familiar with many of the items listed on the Agenda.  Some of them are less traditional.  The slide titled  “Where are we?” is intended to capture what is currently known and perceived about the project.  Also the slide asks the additional questions “What do we know we don’t know?”, “What should we know that we don’t?” and “What don’t we know that we don’t know?”.  Also, when was the last time (or first time) you ever did a SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) on a project?  Some of this may be covered during Risk Analysis.   The idea here is to immerse the core team/key player or stakeholders into the thought process for this project to uncover many of the discoverable issues as soon as possible in order to address them.

Scheduling multiple meetings and handing out multiple agendas (method 2) does not typically allow for the depth and breadth of discussion required of key projects.  In the multiday session many of the discussions are done as exercises using flip charts.  These notes are hung as they are completed around the conference room and stimulate discussion in other areas.  Also, as the meeting progresses and decisions are made, new insights are gained then a finger goes up “That’s not on the list”  and someone goes over to capture the  new insight on the appropriate flip chart.  The immersion and visual notes (flip charts) capture more information quickly allowing for deeper,  broader, and focused discussions.

Once the meeting is completed all information is gathered, captured and placed into what becomes the initial Project Management Plan.  It doesn’t take but one day to type up the notes, place them into an outline and publish it to the team, stakeholders, and management for feedback.  There are typically unanswered “Parking Lot” issues/questions that require resolving.  The Project Management Plan will be modified based on the responses to those questions/issues.

I’ve both facilitated and been on teams using this approach.  The PM plans that results from this method are outstanding with higher quality inputs and less surprises during execution.   While  this method may be used at anytime it is not for every project.  With a high upfront cost it should be used for efforts that are of strategic importance, high cost, or high risk.

I have a slide deck of 40 slides I created to prepare and facilitate this multiday planning methodology.  It includes the slides and speaker notes to facilitate the meeting and what is needed to prepare for and execute the meeting.   Send me a request and I’ll forward the slide set to you free no questions asked.  This is another tool I’ve found to be extremely valuable therefore  the desire to share it and see it used by others.  I hope it does for you what it has done for me….execution of projects with fewer bumps and surprises and improved outcomes.

Posted in Initiating, Planning, Scheduling, Strategy
23 Feb 2012

Custom scheduling tools and databases – Part III

This post continues to discuss six more Microsoft Project templates described in previous posts, Custom scheduling tools and databases – Part I and Part II.  These posts are about using your scheduling software as a database to create custom tools needed to plan, execute,  monitor, and control your projects. The advantage is that it keeps your project data in one place while associating the data with the appropriate tasks and resources. 

Next on the list is an expense and capital cost estimating template PMO_Costs, Fig. 1.  This template is for estimating project costs by inputting optimistic, expected, and pessimistic expense costs then calculating an amount based on the equation described below.  

Fig. 1 Microsoft Project template PMO Costs screen shot

Fig. 1 Microsoft Project template PMO Costs screen shot

I’ve noted Custom Fields with a (CF) notation.  Reviewing the definitions for each column going across are:

  • Task Name – Regular WBS Task Name
  • Cost Assumptions (CF) – Captures assumptions and inputs used to generate the costs.
  • Cost Optimistic, Expected, Pessimistic (CF) – Range of potential costs.  Good practice is to ask others who have completed similar tasks and determine typical costs required to complete the task.  This will provide a best, worst, and average to use for input. This should be done for each task that will generate an expense toward the project.  Highly recommended for tasks with a wide degree of variability.
  • Cost Most Likely (CF) – Calculated using  (Optimistic+(4x Expected)+Pessimistic)/6
  • Cost Capital- Fill in with best estimates of cost to obtain capital goods.  Can usually be done via quotations. 
 PMO_Costs is formated to print on 8.5″x11″ (letter) sheet for comments and review. 
Fig. 2 Microsoft Project template PMO Progress Rollup-Inputs screen shot

Fig. 2 Microsoft Project template PMO Progress Rollup-Inputs screen shot

Fig. 3 Microsoft Project template PMO Progress Rollup-Report screen shot

Fig. 3 Microsoft Project template PMO Progress Rollup-Report screen shot

Next on the list are the PMO_Progress Rollup-Inputs, Fig. 2 and PMO_Progress Rollup-Report, Fig. 3 templates.  Purpose of these templates is to communicate project status. With PMO_Progress Rollup-Inputs you choose which tasks either individual, summary, or milestone you want to report on by placing a value, typically 0% as a starting value, in the Last % Complete column.  Once you’ve chosen the individual tasks, summary tasks or milestones to report on you then chose PMO_Progress Rollup-Report view to condense the chart to only those tasks. This allows you to pick and choose ANY item in your WBS to report on. This is much more flexible for reporting than trying to use MS Projects built in filters where you only get milestones, or critical path, or incomplete tasks, etc.   You can then take a screen shot and copy the results into report or presentation.  Refer to screen shot above.   Custom Fields are noted as (CF). 

  • Status Indicator – The Indicators field displays indicators that give different types of information about a task.  Go to the link for more details.
  • Task Name – Regular WBS Task Name
  • Last % Complete  (CF) – Any task that has a value placed in it will condense down to only those tasks when the PMO_Progress Rollup-Report View is chosen.  This allows you to choose individual or summary tasks or milestones to report on for management or status updates.
  • % Complete  – Current % Complete value based on the amount of work completed.  Once you’ve generated the report the first time all values on the Last % Complete field will typically be 0%.  For second and subsequent reports copy and paste the % Complete values into the Last % Complete field.  That way when you run the next report the older values will already be there.

PMO_Progress Rollup-Inputs and PMO_Progress Rollup-Report are formated to print on 8.5″x11″ (letter) sheet for comments and review.

Fig. 4 Microsoft Project template PMO Task Risks screen shot

Fig. 4 Microsoft Project template PMO Task Risks screen shot

 
Fig. 5 Microsoft Project template PMO Task Risks Report screen shot

Fig. 5 Microsoft Project template PMO Task Risks Report screen shot

The next two views are Risk Management views.  Use PMO_Task Risks Inputs, Fig. 4 to capture risk related information for specific tasks and PMO_Task Risks Report, Fig. 5 to condense only those tasks having information in a risk field.  The purpose is to scan the WBS and determine what tasks have risks worth capturing.  It is not the intent to describe a risk for every task.  Your experience should help in identifying tasks with higher severities or probabilities of occurence.  This view can be copied into a report, presentation, or all-encompassing Risk Management file for further analysis.
The following is an explanation of each field.  Custom Fields marked with a (CF) notation. 
  • Task Name – Regular WBS Task Name
  • Risk Cause (CF) – Identification and description of the cause of the Risk.
  • Risk (CF) – Description of the risk, e.g. cost risk, testing risk, resource risk. Be descriptive so management and outsiders can understand. 
  • Risk Effect (CF) – If this risk event occurs what happens to what?
  • Risk Ranking (CF) – Estimated risk based on your ranking criteria.  You could use Low, Medium, High, a Likert scale of 1-5, or something else. The goal is to be consistent.
  • Risk Trigger (CF) – What is the event that will cause the risk to transpire?
  • Risk Mitigation (CF) – Describe what actions, if any, can/will be done to lessen the severity or probability of this risk occurring.
  • Risk Owner – The person who will monitor and determine if the risk trigger has occurred.

PMO_Issues Tracking is formated to print on 8.5″x11″ (letter) sheet for comments and review.

Fig. 6 Microsoft Project template PMO WBS Dictionary screen shot

Fig. 6 Microsoft Project template PMO WBS Dictionary screen shot

 
The last View described in this post is the PMO_WBS Dictionary, Fig. 6.  This should be filled in as or as soon as the WBS is created to capture the intent and scope of the task.  This is helpful in describing, scoping, and level setting what work will be performed and a description of the deliverable, possibly even a description of the acceptance criteria used to measure if the work is properly completed.  During one project we had to describe what WAS and WAS NOT included in any particular task because we were condensing several tasks into one task so it was necessary everyone understood what the task entailed.  It should not be necessary to provide a definition for every task but those tasks that may be confusing or involve many steps.  This should be used as an addendum to your project plan.

 PMO_WBS Dictionaryis formated to print on 8.5″x11″ (letter) sheet.

This post captured six more views discussed in this series. We’ll wrap up the last views in the next post which will be final part of this series. 

If you would like the MS Project file with all views already included send me an email with your request to wayne@all3pm.com and I will forward a copy to you.  Any feedback you care to provide is greatly appreciated. 

Thanks for following…

Posted in Execution, Initiating, Monitor & Control, Planning, Scheduling and tagged , , , | Leave a comment
25 Jan 2012

Custom scheduling tools and databases – Part II

 This post will discuss several tools listed in the previous post, Custom scheduling tools and databases – Part I.  These posts are about using your scheduling software as a database to create different tools needed to plan, execute,  monitor, and control your projects. The advantage is that it keeps your project data in one place while associating the data with the appropriate tasks and resources.  Two key tools on the list are PMO_Entry and PMO_Tracking Gantt.  Screen shots for each View and explanations are below.  To see the screen on your computer open the file (refer to file request at end of this post) then choose View>PMO_Entry.

Fig. 1 Screen shot of PMO_Entry View

Fig. 1 Screen shot of PMO_Entry View

The purpose of the PMO_Entry View was to simplify and normalize data  input into creating the WBS. I had nine PMs at once inputting data into their schedules so I required a standardized template in which I could review inputs for consistency. No matter how careful one is, there will be errors when inputting vast amounts of data. This template allows for quick checks and reviews.  Most of the fields are self-explanatory.  Fields like task Type and Constraint Type are shown to ensure consistency and intent during entry.  MS Project defaults to Effort Driven tasks (Type) which in my case is seldom used. This is because my projects are typically in highly matrixed organizations with resources working on several projects at once.  Because of this it is easier to create a window of when the work will be completed using Duration and Work.  There are several custom fields created for this template.  I’ve noted them below with a CF (Custom Field) notation.  Reviewing the definitions for each column going across are:

  • Task Name – Regular WBS Task Name
  • Duration – Duration used by MS Project for calculating schedule
  • Duration Optimistic, Expected, Pessimistic (CF) – Range of potential Durations.  Good practice is to ask others who have completed similar tasks how long it typically takes to complete the task.  This will provide a minimum, maximum and average to use for input. You don’t necessarily need to do this for every task.  Highly recommended for key tasks and tasks with wide degree of variability.
  • Duration Most Likely (CF) – Calculated using  (Optimistic+(4x Expected)+Pessimistic)/6
    Note:  Copy Duration Most Likely column and paste into the Duration Column. 
  • Work – Fill in with best estimates of how much time it should take to complete required task deliverable.  Personally I’ve always estimated with the help of others then doubled the value.  This is not to pad the schedule.  I’ve found over time that this method gets closer to how much time it actually takes to accomplish the task in a highly matrixed organization.  Time is wasted when having to change often between multiple projects. 
  •  Accountable (CF) – I added this column because there were several resources for the majority of tasks and it was unclear who had final authority for task decisions and completeness. 
  • Resource Names – Individuals assigned and “responsible” to achieve the task.  
    Note: Accountable and Resource Names are two of the four elements required for a RACI Matrix (Responsible, Accountable, Consulted, Informed) or RAM (Responsibility Assignment Matrix).  You could add two more columns (custom fields) titles Consulted and Informed then create a view showing the Task Name and RACI columns. You would then use Autofilter to filter for names to conduct a review.  While this method is not a standard RACI matrix (usually there are tasks running vertically and  names running horizontally across the top) it allows you create one without having to do it all over again in a spreadsheet.  This is the database part of the thinking – to keep your data in one tool, MS Project, instead of multiple files, programs, or software.
  • Predecessors – Tasks required prior to starting or finishing the current task.
  • Type – Project uses one of three task types to calculate the duration of tasks and subsequently their finish dates or their start dates (if you schedule your project from the project finish date rather than the project start date).  It’s imperative you know how each task is set to understand how Units, Work, or Duration will change once updates are made to your schedule.  My experience is that this setting is the most frustrating for new (and many older) users as they don’t know task Type and when they make a change to duration or work other fields don’t behave the way they expect it to.  Go to the link for a detailed explanation of what and how changes are reflected once updates to the schedule are made.
  • Effort Driven – The Effort Driven field indicates whether the scheduling for the task is effort driven scheduling. When a task is effort driven, MS Project keeps the total task work at its current value, regardless of how many resources are assigned to the task. When new resources are assigned, remaining work is distributed to them. Typically for my projects these are all set to No.
  •  Constraint Type – There are eight choices. For most tasks this is set to “As Soon As Possible.”  This column is inserted to check consistency and errors. In a table format it is easy to conduct a scan or use the filter to ensure tasks are set as intended.

PMO_Entry is formated to print on 11″x17″ (tabloid) sheet for comments and review. 

Next on the list is the PMO_Tracking Gantt.  The purpose of the PMO_Tracking Gantt is just what is says, tracking and monitoring of your project. Refer to screen shot below. To see the screen on your computer open the file (refer to file request at end of this post) then choose View>PMO_Tracking Gantt.

Fig. 2 PMO_Tracking Gantt screen shot

Fig. 2 PMO_Tracking Gantt screen shot

 

Before using this template it is preferred you’ve already input all data, set predecessors and successors, verified your schedule using the SCRAPP Method, and have a robust project model.  I’ve seen many PMs use MS Project out of the box using the standard views and never set any baselines.  To use this the PMO_Tracking Gantt template it will be necessary to set the baseline.  

The following is an explanation of each field. Again I’ve noted Custom Fields below with a CF (Custom Field) notation. 
  • Task Name – Regular WBS Task Name
  • Accountable (CF) – I added this column because there were several resources for the majority of tasks and it was unclear who had final authority for task decisions and completeness. During task updates this is the person who should provide an update or their assignee.
  • Task Issues (CF) – This field is to capture issues affecting task completion.  Use this field to describe the cause of the issue.  These should be escalation issues meaning you have to go outside the project team for resolution.  This field is NOT for describing general task status.  Once the template is updated choose PMO_Issues Report (View>PMO_Issues Report) to generate a report on all tasks having an issue written in the Task Issues field.  The report can now be copied and pasted into a slide for reporting and communication.
  • Status – This is an MS Project generated indicator which can be sometimes misleading. The Status field indicates the current status of a task, specifying whether the task is Complete, On Schedule, Late, or a Future Task based on the MS Project algorithm.  The trouble with this is that you can begin a task ahead of schedule (good) then fall behind on this task (bad) meanwhile the task Status will read Future Task (due to the baseline) which is no longer true. This is why I’ve added the next custom field…
  • Slipping Tasks (CF) – This field calculates whether a task is slipping based on the baseline or actual start if started early then gives you an indicator based on the number of days the task is behind schedule;  Yellow 1-10 days late, Red 11-20 days late, Black >20 days late.  If completed the status changes to Green (100% complete). 
  • Actual Start – Date the task was started.
  • Actual Finish – Date the task was completed to everyone’s satisfaction.
  • Actual Duration – Number of days actually spent on task.
  • Rem(aining) Dur(ation) – Number of days left to complete task.
  • Finish – Scheduled finish date of task.
  • Baseline Finish – Scheduled baseline finish of task.

The PMO_Tracking Gantt view gives you realtime feedback and predictive power as you update the Actual Start, Actual Duration, and Rem(aining) Dur(ation).  The indicators predict what will happen if you allow the task to take as long as stated per your Remaining Duration input.  This should force you to respond to reduce the Remaining Duration until the Yellow, Red, or Black indicators disappear.  Once you’ve taken steps and reduced task time to remove indicators you now know your project is back on track!  There are no indicators for tasks that are up to date.  Think of the indicators as Management By Exception (MBE). 

There are two other key views to use after updating the PMO_Tracking Gantt;  PMO_Issues Report (View>PMO_Issues Report) and PMO_Complete Tasks (View>PMO_Complete Tasks). 

Use PMO_Issues Report (View>PMO_Issues Report) to generate a report on all tasks having an issue written in the Task Issues field in the PMO_Tracking Gantt .  You’ll find all issues identified are now in a single view with additional fields to input to track progress, status, owner, etc.  Keeping to the database theme we take information that is already being generated and captured in previous views and adding information to them in another view to maintain continuity, consistency, and conciseness.  You can generate a screen capture which can be copied and pasted into a slide for reporting and communication. This view may also be printed as a handout.

Fig. 3 PMO_Issues Tracking screen shot

Fig. 3 PMO_Issues Tracking screen shot

The following is an explanation of each field.  Custom Fields marked with a (CF) notation. 

  • Task Name – Regular WBS Task Name
  • Task Issues (CF) – As captured from PMO_Tracking Gantt.
  • Possible Solution (CF) – Description of potential solutions.
  • Issue Owner (CF) – Person accountable for issue resolution.
  • Issue Date To Complete (CF) – Estimated date issue is to be resolved.
  • Issue Status (CF) – Current status on issue resolution.
  • Issue Escalation (CF) – A lookup list describing where in the escalation hierarchy the issue is currently at.  The lookup list is used to maintain consistency in issue tracking and limit choices to certain levels/people. In a perfect world the project management plan will describe the who and how of  the escalation process.

PMO_Issues Tracking is formated to print on 8.5″x11″ (letter) sheet for comments and review.

The other view that’s good to review during team meetings or right after updating the schedule is PMO_Complete Tasks.  Refer to screen shot below.  This is a report only, no inputs required, which captures all completed tasks and groups them by the week in which completed.  This is a quick way of celebrating completed tasks but also ensures those tasks that are shown as complete are indeed complete and are not there by error. All fields except the last are described above. The field Finished vs. Plan calculates the difference in days between the Actual Finish and Baseline Finish dates.

PMO_Complete Tasks is formated to print on 8.5″x11″ (letter) sheet.

Fig. 4 PMO_Complete Tasks screen shot.

Fig. 4 PMO_Complete Tasks screen shot.

This post captures four of the views discussed in Part I of this series. We’ll continue on with several more descriptions and use of the views in the next part of this series. 

If you would like the MS Project file with all views already included send me an email with your request to wayne@all3pm.com and I will forward a copy to you.  Any feedback you care to provide is greatly appreciated.  Thanks for following…

 

Posted in Monitor & Control, Planning, Scheduling and tagged , , , | Leave a comment
20 Jan 2012
1 Comment

Custom scheduling tools and databases – Part I

In making your own custom scheduling tools it’s best to think of your scheduling software NOT as scheduling software but as a DATABASE!  When you get down to it that is all scheduling software really is: information inputs, information outputs.  Inputs are information like, e.g. Task Name, Resource Name, Duration, etc.  Output info  may be very different, e.g. finish dates or calculations, and are usually in the form of text, numbers, and or graphics, e.g. Gantt Chart or Network Diagram.  Make your database or tool work for you.  I try as much as possible to use my scheduling software as a database and input as much information into it as possible prior to going outside of it to use another type of software or creating another file.   Before I make any custom tools I figure out what information I need for OUTPUT which drives the required information INPUT.  Knowing this you can make your own tools for planning, tracking, and communication.

Regarding tools, I’ve been using Microsoft Project for years.  There are plenty of arguments on which tools are better or worse. That’s not the point here.  The point is that it is a tool and as a planning and scheduling tool it works well for the types of projects I’ve managed.  Typical projects for me have been 200-500 tasks.  I’ve used it successfully for a program with over 10,000+ tasks .  MS Project 2003 has about 300 fields while MS Project 2007 has 421 fields! Many of these fields are customizable for creating your own information inputs or outputs.  With this post and the next three posts I will show, share, and explain previous tools I’ve created for project planning, executing, monitoring and controlling by customizing MS Project using Views, Fields, Tables, and Filters.

All templates described below were created using MS Project 2003 single standalone version.  All have a screen view and a formatted printout.   Here’s the entire List:

MS PROJECT VIEW

VIEW DESCRIPTION
PMO_Complete Tasks (Outputs) Prints list of all completed tasks grouped by week. Good for:
1) Verifying task completion,
2) Celebration of task completion,
3) Ensuring completion date is in the past. Note: If the PM checks 100% complete box instead of inputting the actual completion date the date may show complete in the future. E.g. If the schedule shows a baseline finish of May 1 and the task was actually finished on April 20 checking the 100% complete box will establish the finish date as May 1steven though the real date is April 20. You end up with a schedule that is not reflective of what’s really happening and you miss opportunities for improving execution.
PMO_Costs (Inputs) Shows task costs.  Calculates most likely expense costs from inputted pessimistic, expected, and optimistic costs and rolls up total costs.  Also includes Capital Costs.
PMO_Critical Path (Outputs) For schedule control.  Creates filtered view of the current critical path and shows progress on the critical path. If the critical path slips the project will be late.  Good for management reviews and updates. Placing Deadlines for key tasks will place an alert in the Indicators column if the task slips.  
PMO_Entry (Inputs) Data input and review.  
PMO_Gantt Chart (Outputs) All tasks with Gantt bar schedule.  
PMO_Issues Report (Outputs) Prints only incomplete tasks in which there is something printed in the Task Issues column in the PMO_Tracking Gantt.  Good for Issues tracking, management reviews and updates.  
PMO_Network Diagram (Outputs) To printout and review the network diagram and corresponding project logic, predecessors and successors.  It only takes one wrong dependency to screw up an entire project complete date. Can be used by the project team to track where the project is at.  Used in conjunction with the SCRAPP™ METHOD.  
PMO_Progress Rollup-Inputs (Inputs) Fill in Last % Complete column for only those tasks you want to highlight for management reviews and updates.  These are usually summary tasks and or milestones.  Start out by inputting “0%”.  Print out using the PMO_Progress Rollup-Report. Good for management reviews and updates.  
PMO_Progress Rollup-Report (Outputs) From PMO_Progress Rollup-Input generates a view that shows only those tasks that have a value in the Last % Complete column.  Adds progress line and shows current percent complete.  Placing Deadlines for key tasks will place an alert in the Indicators column if the task slips. Good for management reviews and updates.  
PMO_Resource-Incomplete Tasks (Outputs) Input a resource name and a time frame with a start date and end date. The print out filters and shows all INCOMPLETE tasks for that resource within the time frame chosen. This includes tasks not started.  
PMO_Resource-To Do Tasks (Outputs) Input a resource name and a time frame with a start date and end date. The print out filters and shows all tasks for that resource that START in the time frame chosen. 
PMO_Slipping Tasks (Outputs) The print out filters and shows all tasks that are Late in the Status column OR have a value >1 in the Slipping Tasks column.  Excellent for problem solving and getting the project back on track.  
PMO_Task Risks (Inputs) Allows inputs to Risk Cause, Risk, and Risk Effect with their associated tasks.  
PMO_Task Risks Report (Outputs) Filters and condenses project to only tasks with any inputs into any one of Risk Cause, Risk, and Risk Effect.  Requires completion of Risk Ranking, Trigger, Mitigation, and Owner.  Combine and add with the Risk Management Plan.  
PMO_Tracking Gantt (Inputs) This is the workhorse for schedule tracking. Filtered and shows all incomplete tasks.  Input the Actual Start, Actual Duration, Remaining Duration, Actual Finish, and Task Issues to get an up to date view of project status.  After updating the schedule the following reports are useful for managing and communication.
Print PMO_Issues Report to get a printout of all task issues.  Print PMO_Slipping Tasks for a report showing all slipping tasks. Print PMO_Critical Path to see if the critical path has changed.  
PMO_WBS Dictionary (Inputs) Use to define the task activities during project initiation, project charter, and preliminary scope definition.  

In the next post (Part II) I’ll discuss two of the primary tools, PMO_Entry and PMO_Tracking Gantt.

Do you make your own tools, customize, or use straight out of the box?  I’m interested in hearing how others have approached this issue.

Thanks for visiting…

Posted in Execution, Monitor & Control, Planning, Scheduling and tagged , , ,
11 Jan 2012

SCRAPP™ Method or How To Integrate Your Schedule

  1.  Print out your project schedule as a NETWORK DIAGRAM.  Depending on the size of your project, this may take one “A” size sheet (8 1/2″ x 11″) or several “E” size sheets (34″ x 44″) .  Don’t be afraid of the amount of paper used.  I’ve literally covered all the walls in a large conference room using this method.  It’s money well spent.   Make sure the settings on your project software shows discrete lines between tasks. This usually means setting the software so it draws a straight line from task to task.  This is so you can trace each predecessor and successor tasks.  If it is set to only draw horizontal and vertical lines the lines will tend to run together and you’ll lose traceability.
  2. Write on each of SIX large sheets of paper (e.g. those 2 ft x 3 ft easel size Post-it® Notes) one of the following headers:  STRATEGY, CONSTRAINT, RISK, ASSUMPTION, PROBLEM (known problems), and PARKING LOT (issues to be resolved but need more info or are outside of project scope but affect the project).
  3. Begin your analysis by choosing and reviewing a starting task, a task with no predecessors. Using a yellow highlighter and a red pen, if the information is correct, highlight it in yellow to show that information has been reviewed and is correct.  Use the red pen for any corrections.  What you review for each task will be dependant upon the information you’ve chosen to show in your printout for each task , e.g. task name, resources, start date, etc.  Your project software should allow you to change this information.  As a minimum I would recommend Task Name, Resource Name, Duration and effort.  Start and finish dates are not important at this point as they will be driven by the final schedule and dependencies. If there are date constraints list them on the CONSTRAINTS sheet.
  4. Next, review the first task’s successor tasks.  If the relationship is true and the line connecting the predecessor to the successor task is correct, and going in the right direction, highlight the entire connecting line, not just a portion of it, in yellow to show it has been reviewed and is correct.  Mark any corrections or changes using the red pen. Thus if the dependency was incorrect crossout the incorrect line and draw the new/corrected dependency using the red pen.  Review the balance of the task information and mark as reviewed and correct (yellow) or corrected (red).
  5. As each task and dependency is reviewed, questions/issues/problems may arise.  If so, write them in plain English on one of the six SCRAPP sheets.   For example, if you could accomplish a deliverable three different ways, right down the one selected on the STRATEGY sheet.
  6. If during this review there are risks discovered and associated with a particular task or strategy write it on the RISK sheet.
  7. Tasks may have constraints, i.e. finish on or by a certain date or limited amount of funding, capture these on the CONSTRAINTS sheet.  Projects have many assumptions; capture these on the ASSUMPTIONS sheet.  Again, write these in plain language without all the techno speak. This is so others outside the project, mainly executive management, can read and understand it.
  8. Your project may face a known roadblock or problem.  List these on the PROBLEM sheet.  Any items that cannot be addressed immediately or require further research place on the PARKING LOT.
  9. As you work your way through the schedule every aspect of it should be discussed, e.g. “Should we proceed serially or create a parallel path?” (hint: capture it on the STRATEGY sheet).  Do not stop until ALL TASKS, TASK INFORMATION, AND DEPENDENCIES ARE HIGHLIGHTED YELLOW OR CORRECTED IN RED.  Any item not highlighted or corrected has not been reviewed.  You’ll know where you left off and where to pickup if this takes more than a day.
  10. Revise the schedule per the redlined corrections using a different filename for your schedule.  As you go through and make each correction in the software, use a green highlighter/marker and mark the red corrections on your printout to show you’ve inputed the changes.  This is because there are typically many changes and it is easier to keep track of where you’re at.
  11. Once all changes are input, printout the schedule a second time starting from step 1 above.  It typically takes 2-4 rounds before the schedule is finalized.
  12. Type up all SCRAPP paper and review with your team.
  13. Finalize and document your schedule.  Print out one page of  schedule milestones.  There shouldn’t be more than 12-15 key milestones on this page.  Combine this one page of milestones along with the SCRAPP paper. You should now have 2-4 pages, one page of milestones and the balance SCRAPP paper, that can be used as an executive summary. They should always travel together.  A schedule will never make sense unless the SCRAPP is known.
Fig. 1 Network Diagram before SCRAPP Method

Fig. 1 Network Diagram before SCRAPP Method

Fig. 2 Network Diagram after SCRAPP Method applied.

Fig. 2 Network Diagram after SCRAPP Method applied.

There are several advantages to this method:

  • It is a team building exercise with key inputs and decisions determined by the team.
  • Team members will have a higher degree of confidence that the project is achievable.
  • As circumstances change within your project you will be in a position to make better decisions because you will have previously discussed many strategies, options and details.
  • All elements of SCRAPP can and should be integrated into the Project Management Plan.
  • Lastly, when management asks for a schedule you can provide them with the SCRAPP paper and a single page of key milestones instead of 20 pages of a Gantt schedule that has little or no rigor or meaning behind it.

This method is best used for project types that are vastly different every time.  That is why this method has worked extremely well in the medical industry.  Well versed project types like construction, while able to take advantage of this method, may not extract the advantages of other project types.

How do you do schedule integration or do you?  I’m interested in hearing how others have approached this issue.

Posted in Initiating, Planning, Risk Management, Scheduling, Strategy and tagged , , , , | Leave a comment

Post Navigation