Five shortcuts to managing IT Project stakeholder expectation
I've noticed a bit of a trend. Of the IT Projects that I've seen fall into ‘special measures’ of late, they've all had something in common - a gap between stakeholder expectation and reality.
It's actually (paradoxically) both easy and hard to nail this. Some project teams struggle but, like with most things, you just need someone to show you how and from then on, it's easy! I believe with a little effort you can ensure that EVERYONE involved with the project knows what to expect and when.
Five shortcuts to managing stakeholder expectation
1 - Plan the journey together before fixing on an eta
One of the first questions a lot of clients and stakeholders ask when you meet to discuss a project is "What will be the delivery date?"
Would you plan any other journey like this? I mean if we decided to travel to Buenos Aires - how accurately could you predict an ETA? You wouldn't take a guess before breaking the journey down into its different parts, would you? You'd have to work out which airport to fly from; what time the departures are and how long the flights are; how to get to the airport and how you get from the airport to your destination at the other end.
Too many IT Project delivery dates are agreed without due attention to the tasks and milestones along the way. Like our journey to Argentina, break down the project into chunks and agree on scope and delivery timetables based on proper measured thought.
Funny story, back in the day some friends of the family who are London based Arsenal football fans, set off for an FA Cup tie in Wrexham. It was the days before Satnavs and the task of planning the route was left to an uncle. It was a good hour and a half into the journey before they realised that the route he had planned was taking them to Wroxham in Norfolk rather than Wrexham in North Wales. The moral is that proper journey planning may take a little time up front but it will pay back later with accurate timescales and clearly defined and agreed expectations.
2 - Your plan - KISS
KISS - Keep it Simple (for) Stakeholders
What this means, in essence, is don't overcomplicate documentation and plans. I recall a project where the team detailed each task within the project, each milestone, in microscopic detail. The business stakeholders didn't care about any of this, they just wanted to know when the project's deliverables would be transitioned into service and when they would start seeing a return on investment (ROI). This vital information got lost in the noise and the stakeholders created an unrealistic expectation that was different to what the project team had been trying to communicate.
The project delivered in line the project team's expectations, on time, on budget and delivering the business change promised but it was not within the false expectations of the stakeholders. This resulted in the project team having to engage in some pretty awkward conversations with disgruntled stakeholder clients who had misunderstood the over complex planning documents. You know the adage, "The customer is always right"? Having to tell them that they're not is never easy – especially when it’s kind of your fault they got the wrong end of the stick. K-I-S-S!
Avoid this by playing to your audience, deliver it in their language. If, as in this case, your stakeholders are business minded, deliver your plan to show you clearly understand business need, expectations and requirements. Ensure that they are documented in a way that cannot be misunderstood in your scope statement. Less is more!
3 - Keep it REAL
Realistic Expectations Allowing (for) Lag
When planning, you work backwards from project delivery and work out timings for tasks. You add these timings together and that gives you your project lifecycle. OK, that's a little simplified but that's pretty much it - but what happens to your project and by default your client or stakeholder expectations if something goes wrong?
The most successful project leaders and CIOs allow time in their project timelines for 'eventualities' and conflicts.
Say the project's task add together to five months, rather than agree five months with your stakeholder and communicate that to your team push for six or seven months. If the team delivers the project in five then they feel like rock stars, their morale is lifted, and you get to carry that confidence onto your next project and the best bit - your stakeholders think you're the best because you delivered with a month or two to spare.
Keeping it REAL requires being mindful of business needs and pressures. I mean, don't take the mickey, if the project needs to deliver to market in five months to compete with a rival, then it’s in your interests to bust a gut to achieve that.
BUT if you can buy some time it's a very wise investment.
4 -Update, update, update
The most important part of setting and achieving milestones isn't that you've set and achieved milestones. It's that you have communicated them with your client.
Many project teams see milestones as internal progress markers but actually, they are crucial for managing client and stakeholder expectations too.
If you hit the first few milestones late but advise your client, you can either assure them of steps that you'll be taking to catch up or begin to prepare them for later than planned delivery.
I was on a train recently that was a minute late leaving the first station, two minutes at the second and so on. The Train Manager announced each delay with an apology but what he failed to communicate was the impact on our final arrival. A near riot was about to ensue among passengers as they speculated and advised those collecting them from the station that they may be late. Then the guy explained over the loudspeakers that despite delays along the route we would arrive at our destination on time (the train companies are very good at point 3 and pad their journey times to avoid fines!!).
A final word on the bit about updating. Be honest when things go wrong - when it comes to managing expectations nothing beats the truth and the goodwill that this honesty generates (almost) always buys you some understanding should you hit further issues along the way.
5 - Pick your best team
It's amazing how far a client's or stakeholder's confidence in your team goes towards how they create their expectation of your capability to deliver. Breaking down tasks and knowing who, on your team, will perform them best and knowing who will work well together when required is a real skill; the better you become at it - the better your team will become at delivering successful, high quality, business case led projects.
If you identify a capability gap the Project Management as a Services market has an abundance of resources ready to plug straight in - so don't feel that you have to chance it. Allow me one last football analogy? It's like the difference between when a football manager fields a weakened team in a cup tie and they get hammered and knocked out of the competition, and when a manager fields his full strength team and they scrape a win. The benefit of the doubt from the fans is far more likely to be forthcoming following the latter scenario - and so it is with stakeholders of IT Projects. Always field your best team (and that includes drafting in external resources if you need to).
In conclusion, managing setting and managing expectations can be one of the hardest things to get right in IT Project Management but it’s also one of the most rewarding. Making sure that EVERYONE is always on the same page should be a priority for us all!
If you have any thoughts, ideas to add or you need some help with this in your projects, I EXPECT that you know how to get in touch.