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.
Deming in Project Management
- Deming’s 14 Points in Project Management
- Point 1 – Commitment from the top to continuous improvement as a way of life
- Point 2 – Adopt a philosophy of cooperation where everyone wins and teach it to everyone
- Point 3 – Inspection is a tool for improvement, not a whip
- Point 4 – Consider Costs and Benefits of the Entire System and Deliverable Lifetime
- Point 5 – Continuous Improvement
- Point 6 – Job/task-related training
- Point 7 – Teach and Institute Leadership
- Point 8 – Drive out Fear and Create Trust
- Point 9 – Break Down Departmental Barriers in Pursuit of a Common Goal
- Point 10 – No Slogans or Disingenuous Pep Talks
- Point 11 – Attribute Results to Processes
- Point 12 – Enable Pride of Workmanship
- Point 13 – Training Not Related to Job/Task
- Point 14 – Total Participation Starting From the Top
Related posts:

{ 9 comments… read them below or add one }
Hi Mr. Josh,
I’ve been keenly scanning your emails for the last two months, giving me detailed insight of every aspect of Proj Mgt. I’ve a plan to appear for PMP in Nov-09.
I fully agree with the explanation of Deming Point-2, but it seems to be in contradiction of what PMBOK says for enhancing scope,ie, GOLD PLATING.
Above Reference of your mail: “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.”
Please correct me if i’m wrong.
Thanks and regards,
Imran
Thank you for the question! Gold plating is a subtle difference. With gold plating, the project team adds features or functionality that are not required. I’ve run into this on projects where the developers (and myself when I was a developer) did extra things because they were “cool”. We didn’t go through the change process, so this extra work is unaccounted for in the original plan.
As a result, gold plating leads to a slip in schedule or decreased quality of something that really WAS part of the true requirements for the project.
I’m suggesting here that we use the change control processes to ensure that these “cool” things we can add really are the right decisions for the project as a whole.
What a class of knowledge you have shared. Bundle of thanks. In urdu here in Pakistan “josheela” means an ambitious person, let me frankly tell you that your ways of explaining things are awesome and ‘You are a real JOSHEELA mentor in promoting Proj Mgt’. Though i attended 5-D training course but it was too intensive to grasp all concepts of PMBOK.
N.B. I also access your mails from helixpk@gmail.com
Hi Josh,
Pl let us know the subtle difference between Project Team and Proj Mgt Team.
Please also explain the difference between secondary risk (that arises as a result of Risk response plan-RRP) and residual risk (that remains after RRP).
Regards,
Imran
Hi Mr. Josh,
I’ve been keenly scanning your emails for the last two months, giving me detailed insight of every aspect of Proj Mgt. I’ve a plan to appear for PMP in Nov-09.
I fully agree with the explanation of Deming Point-2, but it seems to be in contradiction of what PMBOK says for enhancing scope,ie, GOLD PLATING.
Above Reference of your mail: “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.”
Please correct me if i’m wrong.
Thanks and regards,
Imran
Thank you for the question! Gold plating is a subtle difference. With gold plating, the project team adds features or functionality that are not required. I’ve run into this on projects where the developers (and myself when I was a developer) did extra things because they were “cool”. We didn’t go through the change process, so this extra work is unaccounted for in the original plan.
As a result, gold plating leads to a slip in schedule or decreased quality of something that really WAS part of the true requirements for the project.
I’m suggesting here that we use the change control processes to ensure that these “cool” things we can add really are the right decisions for the project as a whole.
What a class of knowledge you have shared. Bundle of thanks. In urdu here in Pakistan “josheela” means an ambitious person, let me frankly tell you that your ways of explaining things are awesome and ‘You are a real JOSHEELA mentor in promoting Proj Mgt’. Though i attended 5-D training course but it was too intensive to grasp all concepts of PMBOK.
N.B. I also access your mails from helixpk@gmail.com
Hi Josh,
Pl let us know the subtle difference between Project Team and Proj Mgt Team.
Please also explain the difference between secondary risk (that arises as a result of Risk response plan-RRP) and residual risk (that remains after RRP).
Regards,
Imran
Imran, have enjoyed Josh’s blog and added it to our list. You likely have already answered this for yourself but wanted to pick up your question on residual versus secondary risk – it arises often in our course delivery.
In a nutshell, secondary risk are a result of your risk management strategies for a triggered even; residual risk are those things/risks that were not identified during risk identification.
I shared more here:
http://blog.tapuniversity.com/2010/12/28/secondary-risk-versus-residual-risk/