Search This Blog

27 April 2013

Links to Management Resources

General Management Resources

Process Asset Samples and Templates

Project Management Newsletters

Project Management Resources

Project Management Tools

PM Social Media and Online Study Groups

Technical References

PM Blogs

PM Study and Free Resources

  • PM Study - Free Simulated Practice Test, Sample Guides and Podcasts, Work Experience Hour Calculation Tool
  • PM Success - 400 Questions of the Day
  • Head First Labs - Free PMP Practice Exam
  • Simplilearn - Articles and instructional videos

Agile Study and Free Resources

  • ScrumStudy - Free learning resources (including the ScrumStudy BOK) - Hat tip to Kylie Wilson in the Comments.

This is a work in progress. Add links to your favorites in the comments, below, and I'll add them.

10 April 2013

Understanding the Rule of Seven

Context: Discussion of the Rule of Seven in statistical process control 

Problem: In some industries, one cannot wait for repeatable errors as defects and errors lead to loss of life. I was told that, in pharmaceuticals, a certain % of death is acceptable and almost expected. The waiting process or period of time before halting tests or evaluations is where I am stuck.
First, let's use the terms specified value and control limit rather than errors or defects.
 
Also, we would normally discuss this topic in terms of parameters that have numeric values such as temperature, weight, and speed. In this conversation, we want to deal with measurable characteristics long before they result in catastrophic failures.

Rule 1. Out-of-bound conditions

If you have just one value outside the control limits, such as a severe side effect from a drug, you stop the process and figure out what went wrong. 

Rule 2. Calibrating the results

The Rule of Seven (or Run of Seven) does not apply to parameters that go outside the control limits. The Run of Seven applies when seven consecutive, acceptable values lie on the same side of the specified value. Such a situation indicates that the average has deviated from the desired value and you need to recalibrate the process so that the average is close to the specified value.

Illustrating with a made-up scenario

Suppose the scientists at Schpooky Pharmaceuticals want to test an inoculation against the HG (Heebie Geebie) virus. In order to train the immune system to fight off a full invasion of Heebie Geebies when somebody sneezes on us, the inoculation has to cause a fever of at least 0.5 degree F. They calibrate the variables in making the vaccine and in the dosage to cause a 1.0 degree F fever, or a temperature of 99.6 degrees F.  In this test, they set an upper control limit of 3.0 degrees, or a temperature of 101.6 degrees F.
 
Specifications:
  • T = 99.6 degrees F, average
  • 99.1 degrees F < T < 101.6 degrees F
Using the first rule, just one person develops a temperature of 103.0 degrees F. We stop the tests to see what's gone wrong because 103.0 > 101.6, the upper control limit.
 
Using the second rule, if we have seven consecutive people develop fevers between 99.6 and 101.6, we stop the tests to see what's gone wrong. These temperatures are all acceptable, but they are all greater than the desired value.
 
The Run of Seven indicates a special cause -- that is, one or more variables in the process need to be controlled. Maybe the dose is too large and needs to be reduced. Perhaps the HG virus needs to be baked five minutes longer. So we make the adjustments and then resume the trial.
 
These rules and others like them serve to stop a process long before it reaches catastrophic failure such as the death of a patient.

But catastrophic failures do happen

You might wonder, What about the catastrophic failures? They do happen! What about the one in 10,000 who dies? How can that be acceptable?
 
This takes us to other techniques such as Decision Tree analysis (p. 299 of the Project Management Institutes Project Management Body of Knowledge (PMBOK) Guide, 4th edition).
 
Suppose withholding the vaccine results in 1,000 deaths per 10,000, but giving the vaccine causes one death in 10,000. If you distribute the vaccine to 10,000, you save 999 lives.
 
Unfortunately, many drug companies withhold such drugs because that one in 10,000 will sue them, and the juries will severely punish the companies.
 
This issue, tort reform, is one of the dividing lines between the political parties in the US. A project manager needs to use various decision-making methods and maintain awareness of a wide range of environmental factors.

The Difference between Accuracy and Precision

In technology and science, accuracy and precision are different, although they go together.

For the measured characteristic
  • Precision is described by the range of values.
  • Accuracy is described by the difference between the average value and the specified value.
Lets have a goal of making two batches of cookies and specify that they measure 5" across. Afterwards, we measure the cookies.

Chocolate cookie widths
  • Average = 5.10 "
  • Range = 0.25"
Cinnamon cookie widths
  • Average = 5.01"
  • Range = 0.50"
The chocolate cookies have a smaller range of sizes, so they are more precise. The average size of the Cinnamon cookies comes closer to the specified value, though, so they are more accurate.
 
Does that seem counterintuitive?
 
For a measurement or a measuring tool
  • Precision is described by how many significant figures the tool gives you.
  • Accuracy is described by how closely the measurement matches the value of a standard device and also by how accurate the standard is.
As another example, I have two 18" rulers.
  • One came from a store that sells drafting supplies. It is graduated in 16ths of an inch.
  • The other, I made for myself after I loaned the store-bought ruler to a neighbor kid. I based it on one cubit (18"), the length from my elbow to my finger tips. When I graduated the cubit ruler in 50ths of an inch, I eyeballed the measurements and marked it by hand.
 The cubit ruler is more precise, but the store-bought ruler is more accurate.

24 March 2013

Project Management and Open Communications

Project Managers need to guard against setting up an environment where bad news never reaches them. They need to praise and encourage those who communicate risks before they become issues, issues before they become problems, and problems before they become project failures.

Some managers remind me of the Clinton trial in the Senate, following his impeachment in the House.

The Senate set up a rule requiring Ken Starr to keep all the records and evidence in another building. Bringing it to their offices without an invitation would have violated protocol.

Then the majority of senators refused to go view the evidence. A few who did view it said they came away weeping, and the rest (having refused to view the evidence) said that they lacked evidence sufficient to convict.

Does your comfort zone tempt you to maintain willful ignorance? Does your character allow reliance on plausible deniability? The PM has accountability for project success, which any lack of awareness may bring about; but that accountability extends to achieving success ethically.
 
I wonder:  Do PMs ever include ethical lapses as project risks?

23 March 2013

The Best Project Management Software

Project management covers many knowledge areas. Developers approach PM software functionality from the perspective of a particular discipline or PM knowledge area. The approaches usually focus on a narrow selection of the following needs:
  • Requirements
  • Software Development Life Cycle (SDLC)
  • Agile methods
  • Model Based Systems Engineering (MBSE)
  • General verification/validation
  • Software test management
  • Software test management with scripting
  • Issue and change management
  • Product definition from a market research angle
  • Scheduling
  • Cost management
  • Resource management
  • Project communications
  • Scope and requirements definition
  • Quality management
  • Configuration management
As a result, all the solutions I have looked at work for only a small portion of project management. For example, MS Project would be useless for requirements management, and DOORS would be useless for project scheduling.
 
Some developers stress integration of their products with other products -- preferably their own. For example, Rational (specializing in SDLC) bought DOORS and worked on integrating the two product lines. Then IBM bought Rational and expanded the integration effort to include other IBM products.
 
Implementing many PM software products and then tailoring them to the organization's needs can require permanent, trained resources. Integrating several products can take years, even in large organizations.
 
With the current state, I believe any attempt at a total PM solution will require a very large initial effort, significant support to maintain the solution, and an acceptance that some interfaces between PM processes just have to be done by hand.
 
Therefore, to answer the question, "What is the best software/tool for end-to-end Project Management?" you need to prioritize the areas of PM because no product addresses the end-to-end needs -- or at least, the top-to-bottom needs.

Life Cycle Costing for Projects

Defining Life Cycle Costing

Life cycle costing (LCC) looks at the cost of the whole life of the product, not just the cost of the project. A product has two major cost phases, the project phase that designs and produces the product, and the O&M phase where the owner operates, maintains, and decommissions the product.

(A lot of Project Managers (PMs) forget decommissioning. As an extreme example, consider how much it will cost to maintain and protect a nuclear waste site for the next 500,000 years.)

The design philosophy is part of the project scope.  The customer may want a cheap, disposable product, so the design team would not put much effort into designing for low maintenance, low manning, and long lifespan.

On the other hand, the customer may need the product to last a long time.  Operations costs can include:
  • building more units
  • maintaining equipment
  • training users
  • expanding, upgrading, or re-purposing the product
  • providing consumables
  • procuring replacement and spare parts
  • transporting, installing, or disposing of waste
Operations can far outweigh the initial cost.

The scope statement, the Statement of Work, the nature of the product, industry standards or government regulations, and the user needs can guide decisions about what aspects, if any, of life cycle costing to include in project planning.

What LCC Means to the Project

Considering operations and maintenance costs requires including, as part of the scope, performing the project in such a way as to keep O&M costs down for the customer.

For example, easy access to a car's timing belt decreases the amount of labor the owner has to pay to have it replaced, and using a steel widget instead of an iron one results in fewer failures due to corrosion.  Such steps will increase the cost of the project, but they may decrease the customer's total cost of ownership.

Considering operations and maintenance costs also requires estimating the cost of the entire product life cycle.

A point exists where spending more on reducing O&M costs would not cut total cost of ownership.  For example, making windshields out of the material they use in Soyuz windows might mean never having to replace cracked glass after a bird hit, but it would cost more than the rest of the car.

For this reason, the project will include a trade study that estimates the total of both the project cost and all the costs incurred by the customer after product delivery.  As its goal, the study will recommend ways to minimize the total cost.

What LCC Means to the Project Manager

The PM should consider the following steps to ensure project success:
  • Make sure the customer considers cost of ownership and agrees to LCC goals.
  • Ensure that project scope and project requirements clarify LCC goals.
  • During project planning, account for the effects of those requirements on the project.
  • Oversee a trade study to determine the best compromise between project cost and O&M costs before project planning is finalized.
  • Make sure the customer understands cost tradeoffs between a cheap project and a project that produces a product with characteristics such as longer life, less expensive maintenance, and greater safety.
  • Get approval of the LCC strategy from the customer and authorization to follow that strategy from the project's sponsor or management.
Please let me know in the comments if you have any corrections or additions.

19 March 2013

Life Cycle Costing for Project Planning

Life cycle costing looks at the cost of the whole life of the product, not just the cost of the project.

A product has two major groups of life cycle phases, the project phases that conceive, design, produce, and deliver the product, and the Operations and Maintenance (O&M) phases where the owner operates, maintains, and decommissions the product.

Some products also have phases where proof of concept testing, design refinement, and prototyping overlap with O&M phases.

(A lot of PMs forget decommissioning. As an extreme example, think about how a chemical or nuclear waste site might require maintenance and protection for the nest 500,000 years.)

The project scope should define the design philosophy. The customer may want a cheap, disposable product, so the design team would not put much effort into designing for low maintenance, low manning, or long service life.

On the other hand, Operations costs such as building more units, maintenance, training users, expansion and modification, providing consumables, transporting, installing, and disposing of waste can far outweigh the initial costs.

The scope statement and the nature of the product will guide in deciding which aspects, if any, of life cycle costing to include in project planning.