With project management improvements, fear is the highest fence!

Improving project management maturity can be a slow, painful process.

An early hurdle to overcome is convincing the senior leadership team of the benefits of project management.  Presenting sufficient local evidence of the impacts of a “just do it” culture coupled with advice from unbiased third-party consultants may help to convince executives of its merits.  Once this light bulb goes off, a flurry of activity usually occurs with introduction of governance changes related to project intake and prioritization, and implementation of a few standard practices & tools.  This change may translate into some modest improvements in project success and predictability.

But at some point, progress stalls – project success rates don’t appear to continuously improve and flare ups increase between project and functional managers.  If this plateau persists for too long, someone is likely to use project management as a scapegoat, and it gets marginalized.

One way to avoid this is to recognize that most of the resistance to change originates from fear.  This could be fear of loss of power (e.g. the shift in responsibility from functional to project managers) or fears of what greater visibility might imply.  When we feel fear, there is a strong tendency to rely on our lizard brains and to invoke fight or flight responses – the former is seen in conflicts between project leaders and other staff while the latter shows up as passive resistance or lack of compliance to practice changes.

Beyond the usual change management doctrine of involving affected staff, socializing the changes, and rolling changes out incrementally, an additional tactic to consider is to help staff identify, explore and manage their fears. With acknowledgement and open discussion about staff concerns it can demonstrate empathy and could help to debunk many of the myths and misconceptions they might have about project management.  Understanding their fears can help you to prepare effective communication strategies and implementation plans.

Bill Cosby said it best: “Decide that you want it more than you are afraid of it.”

 

Project managers should not be the default scapegoat for ineffective change management!

Where project managers used to be regularly blamed for schedule delays and cost overruns, in organizations that have gone through the growing pains of instituting project management practices, the realization has dawned that in most cases, the fault for such issues rarely lies with just one person.

Sufficient data has been gathered to indicate that blockers such as Teflon sponsorship or unpredictable resource availability are as much to blame for project failure as ineffective stakeholder management or poor communications.  It is also less common to see project managers falling (or being pushed!) onto their swords when project constraints are not met;  in many instance such variances get redacted through baseline revisions.

Unfortunately, the same can’t be said when there are organization change management issues.  While I’m certain there are still a few project managers who feel their jurisdiction ends at the triple constraint, most have understood the need to facilitate achieving the expected benefits from their projects.

So when is it fair to blame a project manager for poor implementation of their project’s deliverables?

1. If they didn’t perform thorough stakeholder analysis during initiation as well as at regular intervals
2. If they didn’t leverage available change management expertise
3. If they turned a blind eye and deaf ear to factors that could impact value achievement
4. If they didn’t insist on a communication strategy and progressive information sharing campaign with affected stakeholder groups
5. If they didn’t engage influencers from key stakeholder groups throughout the project life cycle
6. If organization change management deliverables were not built into the project’s scope definition and work breakdown structure

Assuming the project manager had done all of the above, what are invalid reasons to blame them if the operation succeeded but the patient died?

1. A lack of timely resource availability or commitment to change management activities
2. Directives to the project manager to not engage certain stakeholder communities
3. Ignorance by sponsors to change management risks raised by the project team
4. A change that is too bitter a pill to swallow in spite of how much it has been sugar coated

Recognizing that change management immaturity is common, effective communication, risk management as well as understanding the post-project impacts of decisions are good defenses for a project manager to reduce the likelihood of their becoming a scapegoat.

 

 

 

 

Agile enables efficient decision making

Some senior agile evangelists might feel that the movement has gone too mainstream – after all, once you have been lampooned in a few Dilbert cartoons and have spawned a PMI certification, surely you have jumped the shark!

In spite of such cynicism, appropriate usage of agile principles continues to be a gift that keeps on giving.  I’ve written a few articles on the better known benefits of agile including increased predictability for schedule and cost constraints, objective progress assessment, earlier value recognition and reduced waste, but another reward is a leaner approach to decision making.

In traditional organizations that have instituted consistent project management practices, an undesirable side effect might be the introduction of onerous governance for project decision making.  While I advocate appropriate engagement of stakeholders, the slippery slope of inclusiveness and consensus-building can create critical delays.  As decision makers begin to question their authority, the symptoms of this disease materialize as project meetings where more people show up than were invited or decisions (regardless of magnitude) being escalated to steering committees or executive sponsors.  This behavior begins to fuel itself and project budgets get impacted (after all, all those meeting attendees need to log their time somewhere!) and executives become accustomed to operating at tactical levels.  People working without process can generate chaos beyond a certain scale of work, but “process gone wild” is equally dangerous.

The difference with agile approaches is that decision making is a fundamental expectation of the product owner and project team.  The team is expected to be self-managing which includes empowering them to know when a decision will require outside blessing or input.  This shouldn’t be taken to mean that all governance gets jettisoned on agile projects – there is still a critical role for executive sponsorship and for steering committees.  However, the expectation should be that recommendations brought forward by the team should require rubber-stamping as opposed to detailed analysis.

Such empowerment might sound like heresy to traditional organizations but since a critical success factor for agile projects is putting the right people with the right tools to figure out how to do the work right, isn’t it reasonable to also demand right-sizing decision making?