After 15 years as a project and programme manager, I’m pleased to say there’s only one thing that ever goes wrong with projects. It doesn’t matter what it looks like now, what you’re trying to do, where you are or when you’re supposed to be finished, and it never matters who is blaming who, there’s only one fault that ever derails a project.
Sadly, it’s so fundamental to success that when it occurs, it unleashes a wave of symptoms familiar to anyone who has experienced a few projects: scope creep, insufficient budget, unrealistic timescales, technological incompatibilities, personality clashes, unrealised benefits - to name just a few. You may be thinking that these are all faults that wreck a neat project plan.
However, they’re not. When those things happen, the project has already wandered off course - because effective communication didn’t happen. It’s as simple and complicated as that.
Some years ago, at the start of my career, I was given responsibility for implementing a VPN solution for a network of dealers. The vendor explained that the VPN tunnels had to be ordered by Dec 2. Perhaps their explanation was unclear or perhaps it had more to do with the fact that I was emailing during a conference call, as so many of us do.
I ended up convinced they were telling me that the telco infrastructure needed to be ready for that date. I focussed on the infrastructure and confidently scheduled the launch of the VPN for mid-December. Unfortunately, I hadn’t placed the order for the VPN tunnel in time and the vendor could not meet the timescale.
The frantic running around and worrying certainly taught me a valuable lesson. The launch - by the way - was saved, but it should never have needed saving in the first place.
One organisation I worked at adopted agile, which promises to overcome some of the communication barriers in other methodologies. Yet when the product owner announced the scope for the current sprint, he met immediate resistance. The users didn’t recognise the list of user stories as the one they’d outlined a week before. He had assumed that these new stories were extras, to be worked into his plans as and when he felt it appropriate.
They had assumed their list would replace his. He felt his scope had been ‘nuked’; they felt ignored. One week into an eight-week sprint and an agreed scope was still outstanding.
I might have sympathised more had he not had the habit of disengaging from the meetings he was in. With phone and tablet to hand, he worked while others talked. Sadly, that meant he didn’t listen, didn’t spot the possible issues and didn’t ask the pertinent questions. It doesn’t matter what methodology you use, it’s down to the people to communicate.
A more expensive example was when a software supplier pitched a major solution to a large UK corporate client. The client had an operating system in extended support and wanted to know whether the software would run on it. The sales team asked the developers, who said that it would eventually be certified for the OS. This was communicated to the client as ‘yes, it will work’.
Come the proposed kick-off date two months later and the product still wasn’t certified. Meanwhile, another communication failure meant the client’s servers didn’t meet the minimum specification the supplier had said was required.
Two years later, the supplier was losing money on the deal and having to offer discounts on other work to keep the client on the hook. The client was having to buy in consultants to try to get the product working. And the solution wasn’t solving anything for anyone.
But get it right - it is as if you have worked some magic. As if you’re privy to some arcane knowledge the rest of the world can only dream of understanding.
Getting it right
A great example of getting it right was a friend who was given responsibility for an IT project in the Ministry of Defence. Dropped into post with just a few weeks before the next Gateway Review, he visited each stakeholder individually, listening, then explaining or adapting things. When it came to the meeting at which the project was to be presented, it went through smoothly. Colleagues and bosses marvelled at how quickly he had grasped what one manager described as ‘the dark art’ of government procurement.
In fact, it was not his grasp of the rules and methodology that had delivered success, but his grasp of the human dynamics. Each person who could object had been given time and attention, an opportunity to make objections and suggestions, and an explanation of any areas of concern or misunderstanding. By heading off possible complaints before the big day - ‘I haven’t been consulted…’ ‘I’m concerned about…’ ‘Shouldn’t we do…’ - and giving each person a feeling of individual ownership for the plan being presented, approval to proceed was inevitable.
Each project is a network of people, often within a wider network of people in a programme. Staff, contractors, consultants, stakeholders, supplier staff; some doing the delivery, some administering it and some as customers. Applying a bit of network theory, if there are just 50 people involved, that’s 1,225 connections, any one of them able to damage progress if misunderstanding or ill feeling is allowed to fester.
Manage those relationships (which include your own relationships with others!) to avoid misunderstanding and conflict and you’re most of the way to managing the project.
Network management tips
- You can’t use email to get to know someone. Even a phone call is better if a face-to-face meeting is impractical. You won’t really get to know someone and what matters to them just from that small part of their business correspondence that you see. People’s email personality can differ from their real one - especially under stress - and if you can tell the difference, you’re more likely to spot issues or avoid mistaking tone. Take the time to invest in relationships and you become a person they know rather than a faceless disembodied email address, which makes it easier for people to give you the benefit of the doubt or to forgive your own hasty emails!
- No one is a bad person. It’s hard to remember when someone is refusing to let something go, denying something can be done or blaming someone else rather than fixing the current issue, but they’re not actively evil. Most people want the project to succeed. Take the time to understand why they’re taking a particular position and you’re closer to bringing them with you
- Listen and pay attention. If you don’t know what they just said, you can’t know what you just missed. If you don’t listen to someone telling you the safe route through a minefield, it’s entirely your fault when you step on a mine. Multi-tasking - reading email being the classic example - may seem like a good way to use the time but it is also an excellent way to miss critical information. On top of that, the words people use can tell you a lot about their unseen thought processes and motivations. Sometimes, just changing the way you explain something can cause opposition to melt away
- Watch. When a person speaks, what reactions do you see? If they’re telling you things can be done in a week and their subordinates look doubtful or studiously neutral, that might be a warning. If they’re talking about a piece of work and people from other teams involved in it are making faces, there might be a conflict to resolve
- Speak plainly. The more complicated your language, the more room there is for misunderstanding and unhappiness
- First, the bad news. Be upfront with bad news and people will learn that they can rely on you to be straight. A moment of discomfort now can bank a lot of goodwill for later
- Check understanding. Especially if it’s bad news, people may not want to grasp the reality. Asking people to agree a quick plain summary, reiterated in any relevant documentation, allows less room for delusion. But do give them time to ask for clarification. Checking your own understanding, meanwhile, protects against any lapses of attention earlier in the process.
More articles relating specifically to Project Management can be found in the two latest editions of our Digital Leaders publication:bcs.org/digitalleaders
