ALL3PM

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

Archive for the tag “Risk”

30 Jan 2013
1 Comment

Using Six Sigma Tools for Project Risk Management

Show your work.  It’s not just for math teachers.  I’m a big fan of using and creating tools that allow me to explain and someone to follow my thought process.  While great as a communication tool it also allows me to share my ideas with others and how I came to my conclusions.  I currently work with inventors and students in the nascent stages of commercialization.  Mainly engineering or PhD types working on a product idea, the simple question “Who’s this for…?” causes puzzlement and consternation.  “Do you have written requirements…?”  A Requirements Document is a simple example of showing your work.  Others can look over the requirements and contribute by seeing what is written down.  It allows you to constantly input, review, and modify any requirements as new learnings and discoveries are made.

I use this example to help explain using a Cause & Effect Diagram, aka Ishikawa Diagram or Fishbone Diagram, for project risk management.  This is a simple Six Sigma Tool to assist in understanding where areas of risk may develop.  In Figure 1 below you can see the sections of the diagram.  The Effect is listed in the box on the far right.  You list ONE item of failure (or you could list a success), Scope, Schedule, or Cost. Then under the six main groupings of Measurement, Materials, Personnel, Environment, Methods, and Machines you list input factors that may have an effect on the output of  Scope, Schedule, or Cost.

Figure 1 Project Management Cause & Effect Diagram

Figure 1 Project Management Cause & Effect Diagram

In Figure 1 I’ve listed many items as found in the Project Management Body Of Knowledge (PMBOK) 5th Ed. plus a few others.  This is to help with the thought process.  For each of the secondary inputs you should be able to add additional detail.  For example, under Environment>Physical Location you could add additional legs for each of the various plants/division locations that interface with your project.  Many global companies develop in one location, pilot in another, and scale up in a third location.  Each of these should be listed.  Each one has its own risks associated with it.   THAT’S THE POINT.   You’ve now identified a potential risk to add to your risk register to grade and review and determine its level of risk.  Any risk item must fit on the cause and effect diagram because it is an input that has an effect on the output, e.g. schedule.  YOU’VE JUST SHOWN YOUR WORK.  In the risk reviews I’ve participated in everyone starts listing detailed risks.  There is no systematic method to ensure you’ve at least looked over the landscape. Another way of putting this is looking from the 10,000 foot lever meaning a broad overview.  Now someone else can come along and review your Risk related Cause & Effect Diagram at both a high level and detail level.

This tool is a way to systematically review and capture a wider and deeper look at potential risks.  Let’s not forget that it may also be used to capture success’ and understand what inputs were driving successful projects.  This is a simple tool to assist in better outcomes and at the same time allowing others to follow your thought process.  Show your work!

Advertisement
Posted in Risk Management and tagged , ,
21 Apr 2012

When was the last time you actually created a Project Management Plan? (Not just a schedule?)

When was the last time you actually created a Project Management Plan (PM Plan) and not just a schedule? The Project Management Body Of Knowledge 4th Ed. definition;

Project Management Plan [Output/Input]. A formal, approved document that defines how the project is executed, monitored, and controlled.  It may be a summary or detailed and may be composed of one or more subsidiary management plans and other planning documents.

Formal usually means written.  Approved, should be at least by two or more otherwise it’s not approved.  You just become both author and approver. 

I’ve posted one example of a plan I created for a major project.  Refer to Fig. 1 Project Management Plan example.  This was a major corporate initiative and a large complicated project with 150 people onboard at its peak running across several business units and multiple sites in four states across the United States and a budget of over 20 million dollars. I’ve only shown the Table Of Contents to give you an idea what can go into a PM Plan.  If you work for a large company they may have a template or form to use.  Many of the large companies I’ve worked for had no formal PM Plan procedures.  The Project Manager would put together a schedule and that would become the “Plan.” There would be a business feasibility study (most of the time) but not much in the way of an over arching plan or how it fit into the company’s strategy.  From the example you can see that I showed from the top down how this project fit into the companies goals and how it fit into the site goals.  Overall this PM Plan example was a 57 page document and DID NOT INCLUDE ONE SCHEDULE OR GANTT CHART!  The example described key aspects that would be put into the Work Breakdown Structure and schedules but in itself did not contain a schedule. 

Fig. 1 Project Management Plan example for a large project, 150+ people.

Fig. 1 Project Management Plan example for a large project, 150+ people.

Key aspects of this plan were communication and organization.  Meetings were held every day. Two days of individual team meetings, then core team, next the main site leadership meeting, and finally wrapped up with a corporate meeting with VPs.  So it went week after week.  It was imperative that we structured the who, what, and when of each of these meetings.  The escalation process followed. If a team couldn’t make the decision it went to the core team, next site leadership then up to the VPs if no decision was forth coming.  

Organization was also key.  With 150 individual employees and contractors it was imperative that everyone knew who was on what subteam and who the contacts were for the many offsite resources.  One lesson learned during the project is to make sure you have the NAMES of all individuals that are assigned to your project.  In many cases the functional manager assured us we would have support so in the organization chart I added the functional group name, e.g. R&D Engineer or Quality Engineer.  When it came time to interface with these individuals it took over one week to determine WHO was assigned and accountable.

Peruse this Table Of Contents and see if there are areas you could/should capture in writing.  Are there areas that standout because they were not written down before, then they changed during execution resulting in major negative affects on your project?   If you only write down your current understanding of these items and share them with management or other team members you’re bound to generate discussion and feedback which should result in a better plan.   Who are you going to talk to for expert advice?  Are there outside influences?

Remember not to get bogged down in style or formatting.  It’s more important that you think about each of the items in the Table of Contents and even if there is nothing appropriate write “Not Applicable” it will show that at least you gave it consideration.

While this may seem a bit much for smaller projects my question would be “How much are you willing to do to improve your probability of success?”

Posted in Closing, Execution, Initiating, Monitor & Control, Planning and tagged , , , , , | Leave a comment
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
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