This one is about end user engagement in change.

The point being made here is that if as a user (the people on the right) you aren’t prepared to articulate what you want, don’t be surprised if you don’t like what you get.

And no, “isn’t it obvious?” doesn’t count.

Sometimes the idea of a change can seem too far away in the future for end users to be motivated to engage. The trouble is, sometimes by the time it’s near enough to be interesting and “real”, the design is fixed, materials have been ordered and it is too late to influence the outcome.

So, how to do it better? The business sponsor could work with the project manager to create enthusiasm and support for the change, and the project manager could work with a business analyst to help the users to articulate what the problems are that need fixing.

You might say that a project without user buy-in should be stopped, but this isn’t always possible.

For example, a project to achieve regulatory compliance may involve introducing more onerous (and hence unpopular) ways of working by an immovable deadline.

Or an organisation’s lease on a building may be expiring soon, so a project may need to find new premises, design the interior, fit out and move in before the lease on the existing building expires.

But the organisation has an emotional attachment to the existing premises. Not long ago it was a start-up, it talks about itself as a ‘family’ and talks about the premises as its ‘home’.

And one team won’t engage. You can’t cancel the project, or leave that team where they are (you have to get out of the building), so what do you do?

You build a generic, standard office layout for them, and move on to designing a customised the layout for a team that WILL engage.

In that case, the business sponsor and project manager need to talk to the non-engaging party about the benefits of getting engaged, and what will happen if they don’t get engaged – the change “ship” will sail without them, and they will end up with the output chosen for them (which will probably be the one that is the easiest for the project team to deliver, rather than what is best for the non-engaging party).

If implementation is phased, one way to do this might be to play back to the non-engaging party the positive results that other stakeholders have already received from engaging with the project.

A (Programme) PMO can help with setting out the benefits case for engagement, and with gathering and replaying stakeholder feedback. If they don’t engage, they will get the ‘plain vanilla’ option delivered to them, which may or may not meet their needs. Show them the shiny benefits that Team X got when they engaged, and how much [or how little!] Team X invested to get those shiny benefits.

A (Portfolio) PMO can help with identifying why that user group can’t (or won’t engage) – is it because of something that we (the change part of the business) is doing to them with another project elsewhere? Can we temporarily relieve that pressure sufficiently to enable them to engage?

Alternatively, the person on the left of the strip could benefit from documenting their understanding of the requirements (however flawed). Then, hold a meeting for the requirements to be signed off, making it clear this is the opportunity to refine the current understanding of the requirements as it is what will be used to design & build against.

In the absence of requirements, it should be documented that

1.     Requirements were not provided when required, and

2.     It was decided to implement a generic solution.

…to both the project sponsor and the head of the user group before anything irreversible is implemented.

At least this way, the people affected by the change will have been consulted on what they want and will have had the opportunity to articulate that to the people making the change.