Aligning organization strategy and data: changing the requirement conversation.

The next few articles will focus on aligning the company strategy with the solution.

One way to ensure the need and the solution are aligned is to shift the requirement conversation from "what we can do?" to "tell me more about you?"

Too often, we deliver solutions, not meeting the users/business expectations fully. The delivery is not trilling anyone so much. It's also increasing legacy costs, rework... 

 

The pullover metaphor

 

When we talk about requirements, usually the conversation often swings between technical and functional requirements. The user says, "I need a pullover," the project team and techies answering, "Ok, we have sheep, we can make wool out of it." Are we actually talking about the business need or how to support it?

In this metaphor, the pullover is the functional requirement. In the requirement engineering(RE) domain, it's called the "Usage domain." How the solution will be used when delivered. We can also say it the "WHAT."

The sheep and wool are the technical requirements. In the requirement engineering (RE) domain, it's called the "product domain." How the solution is made off. We can also say it the "HOW."

Let's introduce another time of requirement: the domain requirement. It's the "WHY." Why do you need wool to make a pullover? Because your user is cold. 

To align the organization needs and the solution provided, we need to engage the conversation from domain to technical :

 

User "I'm cold..."

Project team: "ok, when are you cold? what is your life style?" 

User "I'm Mike Horn, going to an Antarctica expedition soon".

Project team: "mm... ok... Is it more critical for you too get a warm pullover or a raincoat?"

User "...a pullover, it's not raining." 

Project team: "ok, we have sheep so we can make wool."

 

More than having the conversation on how to support the users (technical and functional requirement), we need to shift the conversation to the real problem needing support.

How to start the conversation?

As a project team, we need to listen to our users...I mean it! Let them talk about their daily challenges. Be curious. Delay your urge to "bring something on the table." Refrain the yen to talk about the data, the report, and how fantastic is your solution.

Try to engage about the feelings: "About the challenges you are facing: what's an awesome end of the year looks like?", "what the conversation you don't want to  have with your manager?" "What keep you awake at night?" "what a dystopia looks like?".  They are likely to express their annual KPIs, priorities, and risks. You can still narrow the conversation on your particular topic after. It will help the user feel listen to, and you will understand the context of your initiative.

As a user/client, keep in mind the team is here to support your business, don't be afraid to talk about your challenges. Let them offer the opportunity to show how they can support you. Refrain the urge to tell them how to shape the solution. You will see many benefits.

 

What are the benefits?

 

Avoid data bulimia.

If you don't know your user has a Mike Horns lifestyle or just wants to go to a beach party, you cannot really predict the type of material you need. If you are lucky, users will open to you about it. More likely, your project will try to cover everything in one: "in case."  It's often what happens when we store data without linking it to the domain need... and then data bulimia starts...indigestion.

Scope creep management

Letting the user express a domain need is a good way to prevent scope creep. As the technical and functional needs are harness to and justify by domain need, he is less likely to change his mind. It will seriously minimize the scope creep.  At least, it will be justified! As if your user Mike Horns doesn't leave for the next expedition anymore. He just wants to play beach volley in the evening. The pullover features will change for a good business reason.

Empowerment

The team will feel empowered. They will come to the table with an offer. This offer is the optimum between all the constraints they have. Challenge their understanding of the "why" but trust the "how". If your team is empowered, they will be happy to catch any low hanging fruit, quick wins, and out of scope requirements (we will address that later).

Innovation

The techies know best the technical environment. They can come with innovative solutions: new platforms, a way to use the tools, similar data already prepared, saving a few months of work. Engaging in the domain needs leaves the opportunity for creativity.

 

"If I had asked people what they wanted, they would have said faster horses." 

Henry Ford 

Long term benefits

The project team sees where we are heading, they can prepare the architecture and data for quicker future achievements. Many technical choices are based on software, standards, company policies, team capacity and capability, data governance, security, technical constraints, architecture, budget. On the medium and long runs, those are critical. It will be easier to implement them.

Conclusion

Shifting the conversation from solution to domain requirement will dramatically help align the organization's objectives.

As a user, talk about your challenges, your feelings, and how you plan to sort it out. Allow the project team to come to the table with another.... you might be surprised.

As a techie, BA, PM, project team: refrain from the urge to give solutions before stepping in your users' shoes. 

For both, using this metaphor can really help to engage the conversation.