Morey's Law #22: Stakeholders Don't Know What They Want...

In 2009 I moved from a Project Management role related to engineering and manufacturing to a Business Analyst (BA) role for a company's ERP implementation. As my boss at the time told me:

Boss: "Matt I need you to move to the ERP team. They need a Project Expert as a Subject Matter Expert (SME), and we picked you."

Me: "Why me? I have 3 projects going on right now, and the clients are happy. Isn't there someone whose projects are wrapping up who can take the role?"

Boss: "Matt, look around the room. How many people in this group have a background in IT and understand how this company does Projects? You're the only one who speaks 'Geekinese,' so you're it."

Me, channeling my old military days (and living up to "Old Reliable" from this post): "Yes sir."

Bear in mind, my understanding was with Network Development and Management, not software transitions and integrations. To continue with the parlance of my former manager, to an outsider it's all "Geekinese" but the difference would be like comparing Mandarin to Korean.



Shortly after arriving in my new-found role as BA and SME, I was sitting in a business meeting with a facility Maintenance Supervisor, discussing the new system that would be used to track and schedule their maintenance within the new ERP system. The manager was using almost Excel exclusively, and was excited to see what we had to offer.  I was there as a witness, to learn something about the system and the upcoming implementation.

He was (supposedly) familiar with the product, as he'd seen screen captures and been involved in most of the design decisions, but this would be his first walk through of the system, and my first recognized encounter with Morey's Law #22.

As the meeting progressed, it became apparent that the Maintenance Supervisor hadn't payed strict attention in previous meetings, and had no idea what he wanted, other than to use his existing Excel system. He constantly asked questions such as:

"Wait, in order to get to this screen, I have to be logged into the system?"

"Wait, my guys can post their time to the project tasks without having to go through me?"

"Wait, why do I have to pull this report? Can't I just pull up the tasks and look at them?"

The meeting was scheduled for 30 minutes, because the implementation team thought he would be the easy sell, but lasted more than 2 hours. He was getting fancy new screens, a dashboard, and a report that could be run at any time to indicate when maintenance was required on specific equipment, when the last time maintenance was performed, and who did it. It was everything the team thought he would need, but it turned out it was nothing like what he "wanted." Hence Morey's Law #22:

Stakeholders Don't Know What They Want, But They Know For Certain What They Don't Want

Unfortunately, this typically isn't discovered until a demonstration is provided by the project team, and the stakeholders get to see the whole thing in action at one time. This Law is most prevalent in technology projects, however, I have seen it make an appearance across a variety of projects, from manufacturing to engineering design to construction jobs. The danger of this Law is that unless properly managed it typically raises its ugly head at the 11th hour and causes a massive amount of rework. 

Why does this happen? There are several considerations. Listed are a few of the more prevalent:

• The Project Team doesn't want to show a partial product. 
• Experience has taught many project teams that if they show a partial product, the stakeholders will typically focus too much on the missing final layer of "paint and polish" than on the underlying functionality and uses.
• The Stakeholders have their own jobs to do
• Most stakeholders have their own work to perform, and until the actual delivery / go-live date they are more concerned with their day to day job than the deliverable that will magically appear several weeks / months from now. 
• This doesn't mean that they don't want to be helpful, but instead they may not be able to clearly indicate what they want because:
• Stakeholders aren't as intimately familiar with the expected end result as the Project Team
• Because the Stakeholders have regular day jobs, and other concerns, they often provide details that are their "ideal" solution, but aren't familiar enough with the solutions / deliverables to visualize what the final result will look like and won't take the time to learn until just before delivery.
• The Project Team may be in love with their own solution
• The Project Team spends significant hours working on a solution, based on their perception of the client's needs, crafting a technological or engineering marvel that is sure to impress. All the bells and whistles are included, because it is AMAZING. But they get so wrapped up in the perfect solution that they over-complicate things and the Stakeholder is lost and confused.
• The Stakeholder is comparing the solution to what they know
• The stakeholder has experiences which have taught them what works and what doesn't - for them! Anything new or different is met with automatic suspicion, if for no other reason than it is new and different. Human beings love their comfort zone, and moving out of it can be a scary proposition.

How does a leader prevent this law? Unfortunately, you can't, at least not completely. You will be navigating a very wine-dy (apparently not a real word, and I wanted to avoid confusion with wind swept) road. But let's work through some of the steps to help mitigate it:

1. First, as in Scope Creep, and How to Handle Risk, you should realize is that it will happen. At some point in the project, you will provide a "solution" that is perfect, except the stakeholders don't want it.
2. Try to get key stakeholder involvement early and often. If possible you want key stakeholders (or at least their representatives) as part of the project team. 
1. This is what my former employer was trying to do by appointing a SME related to Project Management. 
2. If you can't get them on the team, then you want to perform frequent status updates / demos / walk-throughs with them to ensure you are on the right track.
1. This means you can't leave the interaction to only requirements gathering and final deliverable. There needs to be touch points in between.
2. The demos have to be visual 
1. Show what the current process / result will look like. 
2. Explain what is missing or yet to be decided / coded / designed.
3. Ask repeatedly: Will this meet your needs?
3. This will also help squelch the rumor mill that everything is going horribly wrong, which only grows with lack of communication
4. Get attendance sheets as often as possible, to help prevent people from saying "they never saw it."
3. Build into your plan time for project adjustments
1. Make sure that you have the window built in to make adjustments if the Stakeholder comes back with critique
1. For some implementations, this means scheduling a large enough window between User Acceptance Testing (UAT) and Go-Live for another UAT. 
2. For engineering projects, this means having enough time between design submittal and procurement for significant adjustments
4. KISS: Keep It Stupidly Simple
1. Don't over-complicate or over-engineer the solution. Just because you can add all the bells and whistles doesn't mean you should, especially before the Stakeholders get a chance to review it. If you go too far you risk:
1. The Stakeholder being intimidated by the level of "complication"
2. The Stakeholder wanting a simple solution rather than a "look what we can do" version
3. Wasted time and effort on features that the Stakeholder may not even want or need.
5. Get sign-offs at the different review points
1. You want the Stakeholder to approve the work you've done along the way, and you want it in writing. 
1. This will allow you the opportunity to create change orders when something they "don't want" comes up.

This Law is one of the more insidious because it typically makes its appearance toward the end of the project. I've experienced entire software interfaces reworked, electrical panels swapped out, foundation structures redesigned, and in one particular case, a project placed on hold because the client decided that the engineering design wouldn't meet the new requirement of a 500 year loop current (when the original design called for 100 year, don't ask).

As you work through the project,  incorporate the mitigation steps, be prepared to build change orders, and finally, be aware that no matter what you do, how well you prepare, or how often you get sign-offs, Morey's Law #22 says:

Stakeholders Don't Know What They Want, But They Know For Certain What They Don't Want