Project Managers need to trust in their teams instead of trusting a lie they call “the plan”!

An Antiquated Approach

Even in today’s age of collaboration, teamwork, and engagement I continue to witness Project Managers (PM’s) using Machiavellian tactics to get what they want (i.e. follow the “Plan”).

Machiavellian-ism is to have a cold, calculating view toward others, and to then use manipulation and deceit to achieve one’s goals. Machiavellian’s typically have limited cognitive and emotional empathy for others and appear to have a difficult time seeing perspectives other than their own.

This behaviour is counterproductive, destructive, and rarely has the effect you desire.  Instead of relying on a commitment to the project plan (which is a lie!) PM’s should instead commit to supporting the team in their quest to deliver value to the customer (the real measure of success).

To be clear, I don’t believe most PM’s are like this.  I personally know and can recommend some really good, empathetic, effective, and people-oriented PM’s.  They are not the target of this article.

However, having worked in the software and consulting industries for over 30 years and having been a PMP for 14 years I’ve almost seen it all.  I’ve first-hand experience witnessing the deleterious impact that some PM’s have had and continue to have on their teams, on people, and on their customers.

It frustrates me to no end to see this abuse of power, and in my professional and personal opinion it is extremely short-sighted and counterproductive.  Often, rather than producing results all this approach does is create unnecessary stress, resentment, deflated morale, reduced commitment, lack of quality results, and a desire for knowledge workers to take their skills and knowledge to the competition.

Case Study

Here is a current example of this antiquated and classic behaviour I have borne witness to just this year (2020).  As you read along see if you can recognize any of these patterns from your own experiences.

Plans are Lies

Last year a project plan was created by no one that is currently on the team other than the PM.  He is not a subject matter expert, nor is he a technical expert in the domain.  He is a well-seasoned Project Manager with many years of experience in the position of Project Manager.

The work is for a complex system that services over a dozen major groups and has thousands of users.  Yet somehow the PM was able to create a “plan” that outlines what work needs to be done, in what order, how much effort it will take, how many resources (people) are needed, what skills are needed, and when each piece of the work needs to be done.

The test plan was the only part of the project plan that anyone on the team contributed to.  However, even the test plan was created prior to the requirements being known, the technology being vetted, the scope and functionality being understood, or the number of unique customers and their specific needs being explored to any degree.

To be clear, in my opinion this “plan” is a lie.  There are few if any supporting facts or data to support it is achievable or realistic.  At best it is a “guess” given the limited experience, knowledge and narrow viewpoint taken when creating it.

Furthermore, projects and knowledge work are intrinsically about risk-management.  Projects are about building something net new – it says so right in the Project Management Body of Knowledge (PMBOK).  Knowledge workers apply their skills to create new solutions and solve complex problems.  Meanwhile, if the work had been done before it wouldn’t be a project, it would be an operation.

With this uncertainty come unknown risks, so we need to accept and manage those risks as they arise rather than assume all scenarios can be anticipated when building the plan.  The evidence is real – how many substantial projects have you worked on that had no change requests?  In over 10 years of asking that question of my students and clients (well over 3000 people) only about 1-2% have put up their hand.

That means change is inevitable, and despite our best efforts we cannot predict everything when building a plan.  Therefore, we must accept the plan will need to change, so why not just use a system and approach that embraces change instead of holding to the plan.

Yet in our case study the project plan including the schedule was taken as gospel and commitments were made based on that plan.  To be clear, the promises made were by the signatories of the plan and not the people on the hook to actually build and deliver the solution.  Signatories do not have true skin in the game other than they signed a commitment for others to do the work as planned.  It is the team (that didn’t even exist at the time of signing) that has to deliver on the commitment (the “plan”).

Avengers, Assemble!

The project was then launched on the scheduled launch date on the plan.  A project to be fulfilled by unknown people to meet a commitment for unknown scope and a date that had been made on their behalf and without their contribution, consent, or knowledge.

A team was then assembled.  However, it took months longer than expected to find people with the specific skills and knowledge that could be leveraged.  In the end the team was smaller, less qualified, and less experienced than the plan had anticipated.  This new team also didn’t know one another so they were truly working from a “forming stage“.  Yet the project plan wasn’t adjusted to account for this.

Shortly after launch (back in February) the new Subject Matter Expert repeatedly raised an issue with the PM outlining the risk of the skills gap and lack of capacity to deliver based on the original plan.  A proposal was submitted that called for a ramp-up of skills and staff to help mitigate the risk.

Despite the escalations the PM ignored the perspective of the experts on the team and their call for action.  In short, the PM did nothing to manage the risk.  They discounted their team’s feedback and advice, they did not rework the plan to account for these new knowns, and they did not inform the customer of the risk.

They just kept to the original plan.

Reality Bites

It’s now four months later and work isn’t being done according to the schedule (the lie).  Numerous items on the Work Breakdown Structure (WBS) continue to either be behind schedule or not even started, and the critical path is suffering terribly.

To deal with the issue of schedule slippage the PM has resorted to publicly shaming team members for not achieving what is “clearly outlined” as expectations in the WBS, schedule and plan.  He repeatedly says if team members can’t do the work they should give it to someone else that can, completely ignoring there is no one else on the team with capacity or the skills to actually do the work.

The PM has also resorted to sarcasm towards individuals and in team meetings.  He says he “is surprised and disappointed that team members continue to call out the same issues instead of just fixing the problem”.  He also insinuates that if people can’t do the job, they should be seeking employment elsewhere.  He says this fully knowing that isn’t an option during the global COVID-19 pandemic.  If it was an option then it’s likely team members would take him up on it and leave for better opportunities (based on direct comments observed from team members).  This is exactly how companies lose good talent.

Rather than work with the customer to manage expectations and find solutions to the schedule issue the PM is repeatedly centering out individual team members in status meetings in front of the customer, citing them as the bottleneck and saying they just need to “work harder”.  He also pressures team members to doing more, and doing it faster.

The PM has also been directing team members to cut corners and quality.  One specific example is that test scripts were promised on the original contract before the scope of the project was even known.  Now that the project is in flight it has been determined over 800 test scripts are required, but not nearly enough capacity or time was allocated in the original plan to do such work (unknown unknowns).

Realizing the project is behind schedule and there isn’t enough time to do over 800 test scripts, the PM has directed team members to only write very high-level descriptive sentences for the tests and pass them off as test scripts for the customer to do themselves.  Team members repeatedly expressed extreme concern with this approach, however the PM ordered them to comply.  Just a few weeks later the customer complained about the lack of detail in the test scripts.  As a result the PM threw the team members under the bus by blaming them in front of the customer for sloppy work.

Meanwhile, the PM calls, texts, messages, and harasses all team members multiple times a day, interrupting their flow and focus to ask for another status update, and then using the opportunity to again remind staff they need to do more.  This is analogous to a coach repeatedly yelling at a baseball player to hit the ball “harder, straighter, and faster” without providing feedback, support, or guidance, and then suddenly expecting results and improvement.

Current estimates place most team members working approximately 70-90 hours a week, and they have been doing so for almost 2 months (not a sustainable pace).  There is no additional capacity.

A Deep Change in Trust is Required

In a nutshell, the PM completely ignored the risk even though risk management and managing expectations is their responsibility.  They have deflected blame to the team, resorted to belittling and abusing their staff, and continue to hold the team hostage to the project plan and schedule, a lie the PM created and promoted.  They are an ineffective PM using Machiavellian approaches to keep the team to a plan and schedule that were a lie.

What is most disappointing is that this kind of behaviour is not atypical.  As a software developer and past PM I have been witness to and on the receiving end of this kind of behaviour many times.  Eventually I grew weary of it and chose a different profession because I refuse to work with such a lack of professionalism, lack of respect for people, lack of trust of the team, lack of customer focus, and narrow-mindedness.  I naively hoped that PM’s were getting the message and were growing beyond these types of behaviours, but given what I have seen this year it appears that is just not the case.

This kind of invalid assumption based on a lie, and then leveraging professional abuse on those delivering the value has to stop.  It doesn’t result in good products or services, it doesn’t result in happy customers, and it doesn’t result in long-term retention for team members.  It is exactly what gives product development, project management, and service providers a bad reputation.

Instead, people should “Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.”  Another really good piece of advice is that they should value “Responding to change over following a plan“.  This may seem overly simplistic, but this is where it starts, because “Simplicity — the art of maximizing the amount of work not done — is essential.”  I firmly believe this is the foundation of everything that needs to change for PM’s.

Stop your fixation on the plan, and work with and trust the people (not the resources, the people) to collaboratively provide value to the customer!

If you find this useful, please consider contributing with our
“Value for Value” model.