I was asked to help on a project where the sponsor and project manager knew what the problem was, they just didn’t know how to solve it.  The problem was Ed.  Ed (not his real name) was the business lead/expert assigned to the project, and Ed’s mission was to torpedo the project.

Ed was the person who would own the system to be developed when it was completed.  He would be the lead tester, trainer, and would help approve designs.  The project team found Ed to be very negative about everything.  He didn’t want to follow the project processes, he was negative about early design concepts, he wouldn’t get his assignments done and would blame others.  He was clearly the main problem to be solved.  Everything would be OK without Ed.  But, the business owner was having no part of replacing Ed on the project.

I’ve found so often that the problem presented to me as a consultant or new project manager isn’t the real problem to be solved.  You have to understand what lies behind the circumstances that you initially see.  Seldom are the villains totally villainous and the heroes totally heroic.  Seldom have the villains and the heroes sat down and talked through their differences and why they exist.  So, I set out to understand what was behind everyone’s current stance and what could go right once we understood it.

It turned out that the system being built had been built a few years before with disastrous consequences.  Ed had been the business lead on that project, too.  His partners, an outside IT development consultant, had made a good impression, brought in their tools and approach, and set out to deliver the perfect solution.  Ed was looking forward to the results and enthusiastically did his part.  His partners saved time by talking to Ed about what he wanted rather than travelling around to see Ed’s clients and asking them what would work.  Ed did his best and the system got built as he hoped.  Ed prepared training classes and hit the road to introduce the new system.  Demos failed and what did work wasn’t liked.  Ed looked bad. The IT partners hustled to fix what they could within the system they built and got it good enough to implement, but not good enough to be used as it was intended.  The implementation stopped after meeting only a small fraction of the hoped for results.

Fast forward a couple of years.  The owning organization has gotten funding for another shot at this important system.  The timing is concurrent with a reorganization that moved the IT support staff from Ed’s organization to central IT and put central IT in charge of new development for business units.  The new IT team shows up to fix the bad system and do it right this time.  They know that having users run projects is a bad idea.  The indirect message comes through loud and clear to Ed.  He’s not looking forward to the new project.  No more getting thrown to the lions for him.  Let these smart smug new developers sell their own system to his skeptical users.

The new central IT organization has great intentions.  They are doing all the right things – coordinating standards, training, learning agile development methods, planning to actively involve users, and setting up usability testing.  They were intelligently preparing for success.  Why wouldn’t the business unit want them to be a partner?  The business unit appreciated the IT organization’s intentions, but resented the situation.  Their unit had grown smaller as their dedicated IT folks – who did all sorts of things to support the unit – were swept into the new self-righteous central IT unit.  Their new partners knew the business better, but didn’t really know how their business partner felt about the deal.  Trust was at risk.

So, my challenge was to understand where they were, and what could go right.  The most important need was trust.  Trust would start with a mutual understanding of one another’s wants, needs, and concerns.  It would grow from working on making things better and following through.  What could go right was to build a strong partnership based on trust, respect, accountability, and collaboration.  It wasn’t off to a good start.  Ideas were questioned, questions were taken as challenges, and challenges were seen as disrespect.  A downward spiral ensued.

We made progress by bringing out the potential cause of Ed’s concerns.  The plan would be to leverage his strengths and show trust and support.  Everyone also needed to lighten up and have some fun.  The project manager changed his tone and the team worked on small successes.  Things started to turn around.  One thing that helped was to get everyone to express what they thought were the project’s “risks.”  Many of the risks expressed – things that could go wrong – presented opportunities to get to the roots of why people were reluctant to trust.  Working to define the most positive outcomes as the alternative to the occurrence of the risks allowed the team to plan what they needed to do and how they needed to work together to get to a better place.

Ed didn’t leave the team.  The party after the new system went live recognized everyone’s contributions to their success.  Ed hadn’t let go of his apprehensions, but the team understood and accepted his concerns.  Together they described what could go right and a credible plan to get there.  They worked the plan and got where they wanted to go.  They stopped focusing on what could go wrong and found what could go right.

Thanks for reading.

Copyright Glenn Briskin and “The Other Side of Risk” 2012