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)

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

Quality Perspectives in Project Management

In Managing for Quality and Performance Excellence, Evans and Lindsay point to 5 distinct perspectives when defining quality. They are transcendent, product-based, user-based, value-based, and manufacturing-based. The authors discuss the topic in terms of defining quality within organizations and products. I see parallels to defining quality when running projects.

Transcendent Quality

This perspective makes a judgment as to quality in comparison to a “standard of excellence”. This is a highly qualitative measure of quality, and is normally a function of all aspects influencing the perception of quality combined. On projects, this is your complete package, and could be judged by whether or not sponsors want you to manage their projects, customers ask for you by name, or team members love to work with you on your projects.

Product-Based Quality

Are the details taken care of? In manufacturing, product-based quality could be the thread count in textiles, or well things fit together. In a project, I interpret this perspective as looking at:

(1) Did the project manager do a great job of managing the details (communications, risk planning, resource planning, etc.) and

(2) Did all the solutions satisfy the requirements fully, or did some of the solutions only solve the problem 80%?

User-Based Quality

The customer is always right. Or at least from this perspective, quality is based on whether or not the customer got what they wanted. Suppose the exact same IT solution is implemented for two groups. For group A, this is the perfect solution for their needs and so it represents high quality. Group B is impacted by limitations that don’t matter to group A, and so they perceive this as a low quality solution.

Additionally, this relates to how well the requirements are written and implemented. Do they truly address the customer needs? Poorly written requirements can be executed on perfectly and still represent a poor quality job from the user-based perspective. This would happen if the requirements were poor to begin with and did not accurately reflect the customer needs.

In short, the user-based perspective all comes down to the accuracy and precision of requirements, and how well they are executed.

Value-Based Quality

Many times people jump towards a custom-built or proprietary solution to a problem when there are commercially available alternatives that would meet the same needs for much less cost. Project A and Project B solve the same problem and have comparable value added when finished, but Project B costs twice as much. Project A has twice the level of quality from this perspective.

This could also play into resource allocation. When people and tools are used in the right place at the right times, they work more efficiently and cost less than disorganized, adhoc projects. Whether it’s the solution or resources involved, this perspective is all about return on investment.

Manufacturing-Based Quality (or Specifications-Based Quality)

In business, this is defined as the level of conformance to specifications. A tolerance specification of .236cm +- .003cm is a standard of quality. In projects, I see this as conforming to the original scope and plan. Scope creep reflects poor quality in this regard, and so does being over (or under) budget or time constraints set forth in the beginning. EVM practitioners and project controllers may be able to relate with this very well. If you stick to your original plan, then you’ve got high quality on your project from this perspective.

Another angle on this might be how closely the actual solution matches up to the requirements. Although the User-Based perspective speaks to requirements also, it is geared more towards what the stakeholders actually want. This perspective assumes that if the stakeholders signed off on their requirements, and you provided solutions that address those requirements, you have high quality. This could result from taking a pre-conceived solution from a customer and running with their requirements, without worrying about what business problem you are actually trying to solve, and if there is a better way. In that case you could end up with poor user-based quality, but high specifications-based quality.

I'm looking forward to delving into the rest of this book. So far it is very promising and I believe it will provide many insights into how to create and manage quality projects.