The Three Musketeers on a Project
Does stakeholder management beat the holy trio: project scope, budget and timing? Which three project professionals contribute to well-managed stakeholder expectations?
Conventional project thinking looks at a project as three points in a triangle: the project scope, budget and timing. Each of the three points can be quite malleable and must be, given that project scopes can be pretty fluid. Unexpected events impact project timing, and the Project Manager has the unenviable task of then seeking more budget if scope and timing change.
Yet this conventional project thinking overlooks another element: stakeholder expectations. If stakeholder expectations are well-managed, then variations to our three points on the triangle don’t matter as much. Yes — stakeholders won’t be overjoyed by the prospect of forking out more money. Or they may be slightly disappointed that the future state doesn’t have all the bells and whistles expected. They may also be unimpressed that their cherished future state’s go-live date has been pushed back a few months.
A Business Analyst (BA) ensures you have everything needed to create a successful future state technical solution. An Organisational Change Manager (OCM) supports stakeholder management and encourages feedback loops between the project team and stakeholders. And finally, a Project Manager (PM) manages project resources and diligently follows up on task progress.
Most seasoned professionals in either role might shake their heads when reading this. They might consider the above definitions as a gross understatement, and they may be right.
Also, there are many more roles on a project, and these extra roles include both project-specific resources and professionals embedded in the organisation. This article does not downplay the roles nor importance of these professionals. Yet, in the interest of keeping the scope of this article tight and well-managed, I wanted to focus on three roles in particular.
There is far more to each role; all projects have different expectations or resourcing. Some projects don’t have a BA, while others don’t have a dedicated Change resource. Some projects need seasoned “hands-on” practitioners who have a strong task orientation and need to get on with the job. Other projects — including Programs — may need practitioners with a more strategic orientation. They may not need a strong task orientation as the program of work may span many years. Professionals in this context may instead need to play the long game with their stakeholders.
Regardless of project size and complexity, our thinking must go beyond the three points of a project “triangle”. Each role plays a part in managing stakeholder expectations. With well-managed expectations, projects tend to garner support from decision-makers. Yet sometimes support comes from an unexpected angle: influencers operating in the background. Projects with well-managed expectations are likely to reap another benefit. Decision-makers are likely to provide tolerance for mistakes, slippage and other disappointments.
How do these three roles contribute to well-managed stakeholder expectations? While each project will vary, you can have projects where Change professionals briefly step into the BA role. Or a courageous PM has no choice but to win hearts and minds in addition to managing project delivery. Even so, each role ( regardless of who performs the role) takes a different lens to stakeholder management.
One way to look at each role is to ask: what is this particular professional obsessed with?
As the above diagram suggests, PMs are likely to be obsessed with informing stakeholders of progress. Many PMs inform progress using their “Red / Amber / Green” (RAG) status report. The PM’s beloved colour is green, indicating the project is on track, and no executive action is required. Amber suggests a warning indicator but is often a chance for the PM to show that they are on top of the risks or issues inherent in the amber task.
A good day at a Project Control Group (PCG) meeting is when the PM presents a wall of green to decision-makers. Maybe with a tinge of amber (or orange) here and there -that’s okay.
A high-performing PM’s contribution to stakeholder management is profound. They are often the stakeholder’s “throat to choke” when things are going well. They need incredible tenacity and resilience to manage upwards as well as downwards. PM is with excellent leadership skills allow their team to flourish and give the credit where it is due. They are adept at removing blockages and often have an entrepreneurial bent in figuring lateral ways to solve problems.
The BA is likely to be obsessed with capturing precise requirements from their organisation. They will likely be obsessed with overseeing a future state which is built “to specification”. They translate requirements into technical or functional specifications. These specifications inform the build or development of the future state system. Great BAs appear to gain immense job satisfaction from turning the stakeholder’s vision into reality.
There will be a robust analysis of both the current and future state. BAs may examine pain points from a system configuration perspective. How can the future state minimise the number of these pain points? How can the final system delivered to the business meet expectations? BAs may also look at the data layer of both current and future states as part of this analysis. They may need to work with product owners, system or enterprise architects within the organisation. This collaboration means that any changes to data models for the future state fit within the long term and the bigger picture of the organisation’s data model.
I tend to think of an organisation’s data level as the flow of electricity through complex machinery. This complex machinery may be likened to a series of electrical appliances bolted together into a bit of a Frankenstein’s monster. What happens if we design a beautiful system that meets stakeholder expectations? Yet it can’t actually “plug in” to other essential appliances that make up the organisation? That’s the importance of getting the data layer right.
The system configuration and data layer have significance for change practitioners. When data is updated in an upstream system, when does the data integrate with the future state?
Users will inevitably ask questions like this. Similarly, if the user interface validates and provides cryptic error messages to users, can we redesign these error messages to be a bit more user-friendly? Or do we need to update training materials to help shepherd users through an experience that might not make sense at first?
What is one common feature of high-performing BAs I have had the pleasure to work with? All are great listeners. When facilitating requirements workshops, they are truly present with their stakeholders, and they genuinely understand the stakeholder’s context. Their impact is in the power of listening and the persistence in transforming requirements into reality.
A change practitioner on a project is likely to be obsessed with user adoption. With changes to the employee experience imminent, change practitioners need to smooth the way. Smoothing the way involves helping employees adjust to new ways of working. Firstly they need to be aware of the changes ahead. Change practitioners will work with both employees and executive stakeholders to identify obstacles to this adjustment.
While the BA looks at the configuration and data layer, change practitioners look at the layer on top of these two. The “top layer” is the employee experience layer, and this layer looks at changes to the employee experience and removes obstacles to adoption.
Change practitioners worth their salt will jump on a BA’s current versus future state analysis, and this analysis informs their change impact assessment (as a minimum). Both roles inform the PM’s risks and issues management and also help the PM signpost projects.
All three roles work shoulder to shoulder. As the future state begins to take shape, change practitioners work ramps up. Initial awareness communications have set the scene for the impending system. Training often begins in earnest, keeping change practitioners busy. User Acceptance Testing (UAT) keeps both the PM and BA equally active, and their world becomes one of defect capture and management.
Change practitioners may assist UAT efforts, sometimes by introducing UAT workshops. Their innate curiosity about the employee experience often extends to sitting with users. Ensuring conversations with users illustrates their thoughts, feelings and behaviours about the system. This data informs change practitioners understanding of a user’s perception of pains and gains for the future state. Pains and gains then inform pre-go live communications. These communications tend to manage expectations in advance.
Do we have any prickly or contentious parts to employee experience changes? Leave it to the change practitioner — they can often find the right words to manage expectations. Most of the time!
It is fair to say that each of the three roles on a project takes a different lens to manage stakeholder expectations. It is exhilarating to be a part of a team operating effectively to manage stakeholder expectations.
If you are involved in projects, what part of your stakeholder’s expectations are you obsessed with?
