Point 14 - Deming in Project Management

Total Participation Starting From the Top

This point speaks to the need for
(1) commitment from top management and
(2) commitment from everyone else in the organization.
Quality is everyone’s job, and if any implementation is not total, it will not fulfill its full potential.


In project management, I see this point alluding to executive formation and support of a company-wide Project Management Office. That PMO must be the central source of all project management knowledge, under continuous development by the practitioners of project management. Lessons learned and any potential improvements to the project management methodology used by all PM’s in the company should be evaluated, tested, and implemented as a positive change.

Communication channels and documentation management must be in place so that everyone is completely and totally aware of any changes and how it impacts the way they are to run projects. Feedback mechanisms must be in place to allow those same project managers to make suggestions to initiate their own changes to the methodology.

This also speaks to the necessity for everyone who works on projects to have some knowledge of the methodology. They should at least be familiar with the methodology from an executive summary point of view. They should understand how to use some of the tools and techniques that may be applicable to their contributions on projects.

(Back to Deming's 14 Points)

Point 13 - Deming in Project Management

Training Not Related to Job/Task

In order for continuous improvement to become organizational culture, it must also become a personal goal for every employee. Self-improvement should not be limited to immediate application, that would be an example of short-term thinking. Employees are the most important assets of an organization, and therefore require effort to retain and enhance them.

On project teams, the most important assets are the individual contributors that make the project happen. I believe in making all relevant project documentation available to the whole team, including planning exercises and other resources. Explaining your approach as a project manager is key to helping everyone understand the method to your madness, and by example you can help develop organizational and project skills in them. Anyone can become much more productive when they learn and apply many of the concepts in project management. Other skills will come through such as time management, documentation/configuration management, leadership, communication, planning techniques, estimating, and scheduling/work flow management.

If you are a project manager of a permanent group of project team members, you have an even better opportunity to help them grow personally and professionally. On a permanent team, you may even have the power to set aside training time for everyone where they can plan to educate themselves on any topic they wish. This reminds me of Google’s policy of setting aside time for developers to work on their own personal projects without any interference or direction given from management.

(Back to Deming's 14 Points)

Point 12 - Deming in Project Management

Enable Pride of Workmanship

Deming claimed that the sense of having helped other people is the most significant motivator and source of job satisfaction. It is one of the biggest enablers for pride of workmanship.

Of the projects you have worked on, think about the ones you are most proud of. What is it that makes you look back and say, “Wow! Look what we did!!!”

Does meeting an arbitrary project deadline set by a sponsor make you proud of the project? Does fulfilling the written requirements even though the customer expectations were not met make you feel like you’ve really done something important? Probably not.

Personally, I feel the most pride when (1) a really significant positive impact was made and (2) I helped people and know they are grateful for what was accomplished. I want people to think and say “wow!” even if it is only to themselves about something the team did, big or small. These criteria are true for me whether I am managing the project, or am participating as an individual contributor.

Project managers should be looking for the great things their teams are doing. People on their projects should know that when they go above and beyond, they will be recognized. A huge part of this is that the PM must be unselfish and there to serve their people. Servant leadership, that is what is required. The PM should start with the viewpoint that the multitude of talent on their team is going to come up with better ideas than the PM can alone, and not be afraid to embrace those ideas.

Another key point is the avoidance of micromanaging projects. Tasks should be broken down to a certain level where the individual contributor can apply their expertise, and no further. Let them execute how they wish based on their talent and expertise. Be there to guide and serve, yes, but not to micromanage. Micromanaging is one of the quickest ways to kill the soul of a project team.

(Back to Deming's 14 Points)

Point 11 - Deming in Project Management

Attribute Results to Processes

This may be the most controversial point, but in my opinion it is aligned with the rest of Deming’s philosophy nicely, and I agree with this point totally. In the US especially, Management By Objectives (MBO) is very much the status quo. I’ll give a short explanation of my opinion from an operational standpoint first before relating this concept to project management.

In MBO, standards are set for a particular process with the intention of evaluating employee performance by them. Performance in relation to the standard weighs heavily (and is sometimes the only factor) in merit increases, bonuses, etc. A standard example would be handle times in a contact center environment. If the standard handle time is set to 3 minutes, and you are taking an average of 4 minutes, it is said the employee is performing poorly. This paradigm assumes that the measured metric (handle time) is the full responsibility of the employee. Pros and cons of this management philosophy:

Pros

• Easy to set expectations
• Easy to quantify
• Easy to base performance evaluations on

Cons

• Tends to move the focus to being ‘at’ standard
• No focus on process variability
• Tends to make the standard the ‘only’ performance measure
• Provides little incentive to improve processes when the standard is being met
• When defining standards, operational leaders tend to lean towards lower standards in fear of not meeting them
• Propogates the ‘carrot and stick’ approach where fear usually wins out as the strongest motivator
• Discourages educated risk-taking and experimentation with processes, because it might throw people ‘out of standard’ temporarily
• Discourages employees from helping each other by encouraging detrimental internal competition
• Forces employees to try and acheive contradictory goals (”I want to provide great customer service and spend the time the customer requires, but if I do that the way I know it really should be done, I’ll miss my standard and get written up.”)
• Employees and managers may be motivated to skew results so their numbers look better
• Moves focus from customer satisfaction to “covering my butt.”

You can probably tell that I don’t like Management by Objectives. To me it seems like the easy way out, and very much the wrong approach. Deming would say that 90% of defects in any situation can be related to poor systems or the lack of systems in place. Most people want to do a good job and will follow a process when it is well designed and they have the ability to provide input for it’s development and improvement.

Let us discuss this point in terms of estimating project tasks for duration and cost. In the MBO paradigm, what usually happens is that a project team member is given a piece to plan and estimate. Many times there is no process for them to follow in making their estimates. The project manager assumes they are the SME and know how to estimate. The PM may not really have a good idea of how much time they will be able to devote to their project work, alongside all their other projects or daily duties. In many cases an experienced team member is going to throw on a lot of slack time because they are in fear of missing their estimated deadlines. In any case, an MBO mindset is going to lead everyone to blame individuals for mistakes. It doesn’t necessitate a focus on improvement.

What would a Deming approach change? First, there would be a process in place to help guide estimates, evaluate performance to planned estimates, and go back to figure out why estimates were wrong. Another option might be to change the resource load so that a team member can devote all or most of their time to a project for a limited period of time, thereby reducing the cycle time on their deliverables (for your and other projects) and allowing them to more easily estimate in terms of effort required. Part of the process may be to train and guide them in doing a lower level of WBS to break things down into 4-16 hour chunks. It is going to be important in a Deming approach to evaluate tasks that took longer or shorter than anticipated. Not to place blame on the individual who did the estimate, but to find ways to enhance the process of estimating to make it more accurate in the future.

(Back to Deming's 14 Points)

Point 10 - Deming in Project Management

No Slogans or Disingenuous Pep Talks

This point consists of two elements as I see it. (1) Walk the talk, and (2) hold systems accountable.

Walk the Talk

Slogans are phony. The word slogan has a connotation of something that is not real. It sounds like an advertisement, and not something you can really trust in. In a project management organization, it is much better to have published guidelines and a vision that defines your philosophy and practice. Train your project managers and teams on the methodology. Then, let them execute within that framework, and put a system in place so that the practitioners can revise the process and make it better.

Additionally, if you say you are going to deliver the product by a specified date, budget, and quality, then do it. Consistently. Estimating a launch and then consistently missing the deadline is a sure way to make upper management believe you are full of it. Sometimes this goes with Point #9; the project manager points the finger at the stakeholders and says “well, it wouldn’t be so late if they wouldn’t have changed their requirements.” It’s your job to fully understand the requirements early on, so step up to that responsibility and stop the finger pointing. If you took the effort to better understand what they wanted, perhaps you could have provided more reasonable estimates. No excuses.

Hold Systems Accountable

If you do not have a common and well-defined company methodology for project management, you must be expecting every project manager to be perfect. The lessons learned from other projects and project managers must be transmitted through osmosis or psychically, I suppose. That project manager “should have known” how to do proper risk planning. If you lecture the project managers, they should automatically be motivate to do a better job right? After all, it was their fault for not being omnipotent in the first place, right?
A better approach might be to have a set of guidelines, tools, and techniques within well defined processes so that a project manager does not have to also be a mind reader. If projects are constantly failing at your organization, it is not because you have a set of lousy project managers (more than likely), it’s because you have no system in place to manage projects.

(Back to Deming's 14 Points)

Point 9 - Deming in Project Management

Break Down Departmental Barriers in Pursuit of a Common Goal

Many processes are cross-functional. The same is true of projects. This point is about dissolving the “us versus them” scenario that so often exists in one form or another within organizations. In most projects that I work on, there are individuals from departments such as operations, central services and other support functions, MIS, IT, Service Engineering, etc. The “us versus them” attitude comes about when project managers and project team members look at their own interests at the exclusion of others, and instead of working towards a common goal, work towards their own separate and distinct goals.

Although I have much respect for PMI and am a member of the organization, there is a statement in the PMBOK to the effect that a project is successful if the written requirements are met, regardless of whether or not the actual customer needs are fulfilled. To me, this is lunacy and reality avoidance. Project management within any organization can not be successful in the long-term if the only goal is to meet the written requirements. The goal should be to help the stakeholders and sponsor flesh out their true requirements fully, and then meet those needs. The objective of any project is to add value to the organization, period. I have been a team member on projects where the ‘requirements’ were met, and yet the end user was thoroughly dissatisfied with the results. This is not a successful project, regardless of what PMI says.

I have begun using SCRUM at my company recently, and although I was at first frightened because of the paradigm shift required of such a technique, I am beginning to like it. The general premise is that stakeholders really don’t know what they want until they can see it and work with it. SCRUM (a light version of Agile) is a way for the stakeholders to actually use incremental versions of a working prototype software, and I have already seen it’s power in fleshing out true requirements. I completely understand and realize now the hardship that stakeholders bear when trying to visualize a future state and properly articulate the requirements to get there. So far it appears SCRUM is specific to software development, but I am starting to have ideas that elements of it can be applied elsewhere to better understand the true stakeholder needs in an iterative manner.

I encourage everyone who is a project manager to not take the CYA route of “well, if they don’t put it in the requirements, it’s their fault” and instead be proactive and engage the stakeholders. If any doubts exist, do not throw responsibility over the fence, take it on yourself. A truly great project manager holds themselves accountable for stakeholder satisfaction.

(Back to Deming's 14 Points)

Point 8 - Deming in Project Management

Drive out Fear and Create Trust

Fear encourages short-term thinking. One of Deming's classic stories was about a foreman who didn't stop production to repair a worn-out piece of equipment, because he feared that stopping production would mean missing his daily quota. Instead, he let production continue. When the machine failed, it forced the line to shut down for 4 days.

The manifestations of fear are many:

* Fear of reprisal
* Fear of failure
* Fear of the unknown
* Fear of relinquishing control
* Fear of change
* And more....

Some management philosophies assert that a certain level of fear is healthy. I disagree, and feel along with Deming that fear is so unproductive and harmful that it should be driven out as much as possible.

If a project manager is controlled by fear, it is likely they will withhold negative information or delay it because of a fear of reprisal. Of course, the best scenario would be for problems to be understood and addressed as soon as possible. EVM reporting and other types of status reporting can easily by manipulated by crafty project managers who are fearful.

Project managers who have a fear of failure because of the environment they are working in will never try anything new. How can progress be made unless you try something new, and take some educated risks? It can't.

Fear of the unknown can paralyze project managers, sponsors, and stakeholders alike. A big part of project management is supposed to be about dealing with uncertainty, and making the unknowns known. Good project management in itself can alleviate much fear associated with unknowns.

Ah yes, relinquishing control. This is a big one. I know project managers who feel they must micro-manage their projects because if they don't, thing will never get done correctly. They might be afraid of failure, but more than likely they are just control freaks. In order to properly lead and achieve the best results, a project manager must be able to give guidance and direction, then get out of the way. A good indicator that a project manager may have this fear is when you hear them purposefully talking PM jargon and trying to make themselves look smart and sophisticated in meetings with the customer. This attempt at razzle-dazzle is inevitably a symptom of the "it's all about me" syndrome.

Fear of change is a big one. Change management is probably the most difficult thing I've had to deal with on my projects. People are resistant to change by nature, unless they are the ones initiating it. For that reason, I've found it is always best to make the WIIFM (what's in it for me) painfully obvious, and involve experts from the stakeholders as much as possible when working the project. The more people you can involve that are at the lowest end-user level, the better. Do not just include the managers of these people in your project....that is a sure fire way to ensure the end-users are fearful of the change when it comes.

(Back to Deming's 14 Points)

Point 6 - Deming in Project Management

Job/task-related training

A quality organization understands the value of the people who work in it. The same goes for project management. Training project managers, analysts, and everyone else who regularly works on projects in the company methodology, soft skills, etc. can bring significant rewards.

Many companies use the cop-out of "on the job training" to sidestep any responsibility to have a formal system in place to ensure their people are constantly learning how to do their jobs better. I am not saying that OJT isn't valuable, but it can't be the only training "effort" put forth by the powers that be.

The companies I have experience with that get this have the following resources and programs in place:

• A project resource center with books, periodicals, and other materials
• Time specifically scheduled for training and learning each month
• Presenters, either from the team or externally, giving a talk monthly to the whole group
• A significant amount of funds in the budget earmarked for training
• Sending a few people each year to seminars and events like the PMI Global Congress, etc. --And then those people present what they learned to the whole group when they get back
• A formal mentor program whereby new employees are paired with a vetran
• Company methodology and process training

There are many other ways to show commitment to project management training and education, these are just a few. Please leave your ideas and experience about best practices as a comment below.

(Back to Deming's 14 Points)

Point 5 - Deming in Project Management

Continuous Improvement

This is one of my favorite points from Dr. Deming. I see so many mistakes that are made again and again, and lessons learned that are either completely undocumented or filed away after a project, never to be seen again.

Do all of the other project managers in the firm get exposure to lessons learned from other projects? Usually not, in my experience. Surely, individual project managers and sponsors learn from their projects, but organizational learning and continuous improvement require a formal process for the documentation, analysis, and incorporation of lessons learned into a common methodology.

Of course, I believe the only way to truly be committed to continuous improvement is to have a common, shared project management methodology in the first place. I'm not saying that project managers should be drones working within a system telling them how to eat, breathe, and sleep. The common methodology should provide a structure and guideline however, with some components on the more mandatory side while some others may be a guideline in which the project manager can work.

If a project manager has a suggestion based on personal experience as to improving the methodology, there should be a process in place to do so. Any proposed change should have a clear correlation to a problem that needs to be solved. The continuous improvement process should not be left up to volunteer suggestions, however. It should be a part of the methodology and how the business runs a project.

I can suggest a skeleton process:

1. Establish a formal process by which lessons learned are documented regularly while executing projects, and put in a format and location where they are visible to all and can be later analyzed.
2. After each project is finished, analyze the project in terms of performance in the triple constraints, stakeholder satisfaction, and other metrics important to your organization.
3. For negative points identified in #2, use the 5 Why technique to document root causes. Do some statistical analysis on these root causes to determine their frequency, correlation to the negative points identified, and the estimated cost/time involved with potential solutions.
4. Implement selected solutions on a beta test with one or a few projects, clearly defining the points at which the test process diverges from the firm's common methodology.
5. Analyze the results in the beta projects of these specific changes.
   
6. Based on the successes or failures of the beta testing, implement changes in the common methodology.
7. Rise and repeat.

You may notice that the skeleton process above fits within Deming's Circle. That is:

• Plan - 1-3
  
• Do - 4
  
• Study - 5
  
• Act - 6

(Back to Deming's 14 Points)

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)

Point 3 - Deming in Project Management

Inspection is a tool for improvement, not a whip


Deming's third point urges practitioners to design quality into processes, using inspection as an information-gathering tool to do so. In project management, the processes and systems make up a methodology. Does your organization have a consistent methodology, or does everyone run projects their own way? Inspecting project performance through the lens of continuous improvement facilitates applying lessons learned to a consistent and ever-improving methodology. This can not be done effectively unless there is a consistent system of managing projects in the first place.

Because projects are inherently unique, the specifics of how they are managed may require modification on an individual basis. If a consistent methodology is used as the basis however, deviations can be reviewed and further enhance the methodology by documenting best practices for specific categories of projects. The “deviations” can be developed into subject-specific best practices within the common framework. Furthermore, various components of the methodology should be a guideline, whereas critical planning processes should be standardized as much as possible to facilitate the formation of sound theories and best practices. For example, the methods of estimation should be consistent, while some aspects of management style should be left up to individual project managers.

Too often, inspection on projects is used as (or believed to be) a method of blaming project managers when their projects are behind, or applauding them when the projects are ahead of schedule. They should be neither. A performance report indicating a significant discrepancy in the planned time, cost, or quality should be viewed as an opportunity to go back to the planning process and figure out why it was so inaccurate. If the project manager followed the planning processes outlined in the methodology, this is new information with which to enhance those planning processes. If the issue appears to be execution, find out if the project manager is abiding by the guidelines set forth in the methodology, or if they are ignoring them. Compliance can be a people problem, but Deming would argue that over 90% of the problems in any situation can be traced back to flaws in the system, not the people.

When appraising the performance of project managers who work within a consistent methodology, performance to plan should not be such a large factor. Instead, the (1) ongoing contributions to improving the methodology and (2) compliance and success of execution should be considered. Not using the methodology can lead to poor performance, but it is better to measure the cause, instead of the result. To me, this is a key distinction in the Management by Objectives philosophy of people management versus Deming’s view on how performance should be evaluated. Think on the incentives in the MBO versus Deming management philosophies.

In MBO, a project manager may be enticed to add so many schedules and cost padding that they are always the hero when they come in under budget and ahead of schedule. They can negotiate out many beneficial features and other quality elements of the final product, and then if they add a few back in because of all the extra time and money, they win again. This factors into why many projects only meet most of the customer needs, not all of them. In my opinion, this is what makes project sponsors slash schedules and budgets….they know what is going on. The project managers add even more fluff because they know it will be cut down, and the vicious cycle continues. Where is the incentive for continuous improvement? The focus is clearly misdirected.

If one were to apply Deming’s philosophy to project management, much of the struggle from above is avoided. The focus shifts to creating and continually improving a consistent system from which project managers plan and execute projects. The addition of arbitrary amounts of fluff time and cost by project managers is not possible if there is a specific, universal method for making estimates. Contingency reserve is still there, but in a consistent manner based on what makes sense for the organization.

Project managers are encouraged to embrace and improve the methodology. Rewards and recognition result from actions that truly enhance the entire organization’s ability to provide quality to the customer. Regular reviews of lessons learned and other input from project managers can be used to enhance the methodology, one small step at a time. Statistical measures across multiple projects such as standard deviation from plan and EVM metrics can provide useful insights into opportunities for improvement.


Performance excellence does not happen overnight, and it does not happen to an organization as the result of a few great individuals acting in silos. Performance excellence occurs over years of embracing a consistent set of systems and processes that everyone seeks to continually improve.
Project management is about dealing with uncertainty. The point is to eliminate as much of it as possible through careful planning, and deal with the inevitable unknown-unknowns appropriately. Deming’s third point when applied to project management eliminates much of the uncertainty in projects by using an invariant framework which can be continually improved.

(Back to Deming's 14 Points)

Point 2 - Deming in Project Management

Adopt a philosophy of cooperation where everyone wins and teach it to everyone

Often, projects can become battlegrounds where the project manager and team are at odds with the sponsor and other stakeholders. These conflicts can arise when the project environment is not conducive to a win-win approach.

In project planning and initiation, clearly define the WIIFM (What’s in it for me) for everyone on the project. This includes the sponsor, stakeholders, project team, and project manager. When you keep all parties in mind when planning your project, it helps create a win-win strategy in which everyone benefits. The functional managers from which you are pulling resources need to understand the benefit of the project to their department and the organization as a whole. This is important, and should be clearly communicated to everyone early and often.

During execution, a win-win philosophy will help keep individual issues from turning into project-killing conflicts. It creates the ‘one big team’ environment where people are willing to be creative and take educated risks, because they know they are supported by their team from all angles. If someone makes a mistake, they should not fear retribution from other parties, and they should not want to cover it up. The win-win environment spearheaded by the project manager and sponsor should make everyone think about issues and conflicts in terms of what is the best method of dealing with it for the whole project and everyone involved.

In the case of two or more project managers with their own teams working on a single complex project, Deming’s point #2 is even more important. In this situation it is easy to start pointing fingers at the other groups, withholding information, and other counterproductive practices. An acquaintance who works for another company told me about their situation. Any software development as part of a project is sent to a separate group. The software development group doesn’t care about her project; they just get sub-projects that are prioritized based on pre-determined criteria. The communication is sub-par, and she never knows when she will get her deliverables. I envisioned a big question mark on her project schedule. This is not a win-win project environment, and you can imagine the finger-pointing that inevitably results.

Additionally during execution, a project manager should not hold so tightly to the original requirements and throw up artificial barriers to positive changes. As long as the formal change management system is in place and utilized properly, any request should increase value for the whole project, period. If more money or time is required to increase the scope, the net effect should still be win-win for the organization. Sponsors must realize that increasing the scope will do one or more of 3 things: increase cost, delay the project, or decrease quality. The team atmosphere created by a win-win philosophy helps everyone get on the same page about these considerations.

When the project is finished, everyone should be involved in the celebration together. In the ‘us versus them’ scenario, a project team is segregated from rest of the stakeholders, and they usually celebrate separately.

If you have ever had the pleasure of working for a project manager with a win-win attitude, you know exactly why that is the way to run a project.

(Back to Deming's 14 Points)

Point 1 - Deming in Project Management

Commitment from the top to continuous improvement as a way of life

Deming’s first point is an important one. There needs to be commitment from the top to make continuous improvement a priority. To do it right, most firms would probably implement a Project Management Office from which continuous improvement activities can be based, one that has dominion over methodology and training at a minimum. The PMO should implement systems to ensure best practices and lessons learned are gathered and implemented. Sharing them will not be enough; they must actively be incorporated into the methodology.

Fully embracing this point should also include a strategic basis within the PMO, or even a separate portfolio project management group. Don J. Wessels, PMP does a great job of laying out the vision of a truly strategic focus on projects in the 2007 ISSIG Review, Volume XI No. 1. The article is titled “The Strategic Role of Project Management” and is a wonderfully insightful read. In this work, he references the PMI’s Standard for Portfolio Management by saying, “While project management and program management have traditionally focused on “doing work right,” portfolio management is concerned with “doing the right work.” It is like allocative efficiency versus productive efficiency in economics. As I read this article and thought about the concepts more and more, I realized it is very true that much of project management today is very tactical and without strategic basis. Embracing Deming’s first point requires viewing continuous improvement from the perspective of the whole system.

In a large company like the one that I work for, various groups have their own versions of a PMO. While this may not be optimal, it does allow for groups with a specific subject area focus to tailor their approaches. This is fine, as long as the group or individual overseeing projects has made a long-term commitment to continuous improvement, and they are committed to ensuring projects are in alignment with organizational goals. So often, the alignment comes at a departmental level at best, and can actually be detrimental when looking at the whole organization. A long-term thought process is required. The leader of the project group must have the ability to not let fire fighting overpower the improvement strategy.

(Back to Deming's 14 Points)

Deming's 14 Points in Project Management

Dr. W. Edwards Deming was recently re-introduced to me in my Project Performance and Quality Assurance class. I have heard of him before and touched on some of his philosophy in other classes, but focused much more in-depth this time. The majority of his philosophy around quality and organizational management resonate with me. So, I've decided to do a series of articles on Deming's 14 points, and how they relate specifically to the field of project management. I may decide to not touch on all of them or I may. I am not really sure at this point.

Here are Deming's 14 points, paraphrased in my words:

The goal of the 14 points: To help everyone enjoy their work, and produce excellence.

1. Commitment from the top to continuous improvement as a way of life
2. Adopt a philosophy of cooperation where everyone wins and teach it to everyone
3. Inspection is a tool for improvement, not a whip
4. Consider Costs and Benefits of the Entire System and Deliverable Lifetime
5. Continuous improvement
6. Job/task-related training for everyone
   
7. Teach and institute leadership
8. Drive out fear and create trust
9. Break Down Departmental Barriers in Pursuit of a Common Goal
10. No slogans or disingenuous pep talks
    
11. Attribute results to processes
    
12. Enable pride of workmanship
13. Training Not Related to Job/Task
14. Total Participation Starting From the Top
    

References and Resources

Managing for Quality and Performance Excellence
Deming and Goldratt
Out of the Crisis
The Deming Management Method
The New Economics
Four Days with Dr. Deming
Deming Route to Quality and Productivity
Deming The Way We Knew Him