Point 4 - Deming in Project Management

Consider Costs and Benefits of the Entire System and Deliverable Lifetime

The textbook wording of this point varies, but is usually something like “Stop making decisions purely on the basis of cost.” When I read the various descriptions however, I believe the textbook title is not an adequate summary.

When Deming talks about not making decisions purely on the basis of cost, he is referring to a plant perspective and talks about the importance of having regular suppliers. This fosters long-term relationships leading to loyalty and mutual improvement. The key factor is that when you look at the big picture, it is usually not cheaper to switch vendors all the time based on price, because you are going to pay for it in other ways in the long term.

In projects, I see two specific applications of this point. First, be sure to consider costs and benefits of a project in terms of the entire system, not just the project alone, or even the specific department or customer who pays for it. Second, weigh the costs and benefits on a project for the complete expected lifetime of the final deliverables, not just the duration of the project that creates them.


The Entire System

To be truly effective, projects must be in alignment with the entire system in which they are carried out. I have personally witnessed many projects which were undertaken with a very narrow focus, and as a result caused unforeseen problems for either the supplier or customer of the final product. When these dependencies are not taken into consideration, rework and band-aid fixes are usually required later on. Many times, these efforts incur significant costs and do not result in an optimal situation for everyone involved.

Additionally, lack of broad consideration can incur more total cost for the organization, even when the department who sponsored a project saved money. For example, Department A sponsors a project in which the ROI seems obvious when considered locally. Department B is dependent on Department A however, and as a result of this change, must incur new costs to accommodate the new state. Had Department A been willing to incur some additional cost, it is possible Department B would not have incurred any, or very little. With the common cost center silo mentality within organizations, it is very common for functional managers to “not care” about what it costs other departments. After all, they aren’t responsible for other department’s budgets, only their own. This is a great example of one of the benefits of a truly independent portfolio and project management team. Projects can then be carried out in light of what is best for the entire organization as a whole.


The Total Lifetime

How many opportunities arise during a project for the short-sighted project manager to cut corners to meet their project constraints? More subtly, how many opportunities to enhance the quality of the long-term result are overlooked because of a short-term focus?

You can plan a project in such a way that the actual production of the deliverable will be cheap, but maintenance will be expensive and frustrating. The same project can be run so that it takes months longer and costs more up front, but the maintenance cost and effort is drastically diminished. Which option makes the project manager look better in a short-term environment? Which option are project managers encouraged to lean towards? Now, which one probably has a higher ROI for the entire organization when you factor in the total lifetime?

As an idealistic beginner in the world of project management, I am continuously frustrated by the ignored opportunities that arise in almost every project. Many times project managers focus on minimizing scope, and the Standish CHAOS report even supports this measure as a factor in project success. These missed opportunities are hard to quantify however, and I believe the Standish report misses them too.

During the course of project execution, it is common to find opportunities to enhance quality. In my experience (when I am not the project manager), the only way these get worked into a change request is for the customer or sponsor to take the ball and run with it. Usually though, the project team usually comes up with the best ideas for enhancing the project. The sad truth is that many project managers, overtly or implicitly, discourage these ideas from their teams if they will result in an increase in scope, take them off schedule, or over budget. It may be that sponsors are reluctant to sign off on more time or money for a change that was not initiated by their team. It may be that the project manager has enough to do without trying to advocate an increase in their workload. Either way, ideas for improvement are suppressed.

These issues result from short-term and/or localized thinking. I believe Dr. Deming would say to think big, and think long-term.

(Back to Deming's 14 Points)

CCEVM Evaporating Cloud Diagram

A Goldratt technique came in handy to map out where I see the conflict between CCPM and EVM that I referred to in my last post. Please excuse it's sloppiness, I will try to make a cleaner computer-generated version later on, but I think I may be refining this later on anyway.

I've never seen an evaporating cloud with more than 1 requirement for each of the prerequisites, but I found it necessary to have a requirement which stems from both CCPM and EVM. The conflict indicated between employing Critical Chain and EVM stems from different behaviors being driven by the two. Critical Chain supports behaviors that focus on efficiency with tasks on the Critical Chain , thus improving the outcome of the project. EVM supports behaviors that make it appear overall cost efficiencies are good, even if those efficiencies are being achieved on tasks that aren't critical to the completion time of the project. Project managers might decide to work on some easier non-critical tasks if their EVM is going to fall short and get a short-term EVM win, but if that happens it throws EVM's predictive power regarding schedule out the window.



















The resulting direction from this is to modify the budgeting and cost control tools in the Critical Chain body of knowledge. It needs to use buffer management methods for cost, to control the project that is implemented in such a way to make it compatible with existing EVM metrics. There would be a single project cost buffer which is already part of the CCBOK. Cost buffer management would be used for controlling project costs, in addition to an accurate EVM translation based on cost buffer utilization compared to planned utilization.

Note: from a cost perspective, all tasks are on the Cost Critical Chain (CCC) because cost over run in any task will make the project over budget unless other tasks have under runs. It makes no difference if they are on the schedule's critical chain. That's why there's only 1 cost buffer, the project cost buffer.

Please leave comments about this post!