Aligning organization strategy and data: assuring continuity between needs and development

A good way to ensure the need and the solution are aligned is to ensure the implementation traceability. It means we do not lose the "continuity" between needs, analysis, design, and implementation. 

It will help formalize the out-of-scope, minimize scope creep, improve consistency, and maximize the implementation value. This "continuity" is also important to evaluate and manage change in the project.

A continuity model has been developed to help to manage complexity.

What is the continuity model?

It's a model with 4 layers: Need, Analysis, Design, and Implementation. The objective is to model the four layers to minimize the changes and ensure each implementation answers a business's needs.

They will be dependent on each other because each one is the result of the previous one.
They will also be independent, as they are modeled separately. They will last during the project, and it will help to evaluate the change impact.

The Need: clarifying the "Need" ("the snowflake" in the metaphor: link): this part is your business and organization objectives.

Analysis: analyze and formalize and interpret the need to functional requirements. At that stage, some needs are excluded from the scope.

Design: Defined the technical requirement. How the solution will meet your functional requirements.

Implementation: It's the physical implementation of the technical requirement. Ie: the script generated to implement the design.

This model could appear a little too theoretical at first, but it's beneficial to manage changes.

Formalizing the out-of-scope

Some time conversations on scope between stakeholders and project team are challenging. This continuity model helps to clarify the difference between the need and the scope.

Going down the continuity model, the team will estimate the cost (time and money, resources) of the solution. 

Then, it will be needed to match and prioritize the resources of the initiative. It will appear.

How it's helping to manage change?

To manage a change, only linked components in the model's downstream layers need to be considered. 

 

Let's take an example: a company sells products in stores.  Due to COVID, they change their strategy and decide to sell online too. You need to integrate the new online sales to the datamart. If you clearly defined the model and documentation, you will link the needs, requirement analysis, design, and implementation. You can identify (without much effort) which component is affected by the change and what needs to be done.

Maximize reuse and minimize side effects

It will help to figure out which component can/should be reused. Many users ask something "same same but different." They will express the need with process, reports, business unit organization already in place. Looking at your model continuity, you will be able to see which component is reusable. 

As you can see, if a component is filling more than one component from the previous layer. You can analyze the impact of a change on the previous layer.

Conclusion

This model is handy when the project is experiencing a lot of changes or scope creep. It will be beneficial to not end up with a "spaghetti plate."

How to do it? It could be done with a goal tree, a traceability matrix, or many other ways. Some softwares are implementing this traceability.

References

Engineering and Managing Software Requirements- Aybüke Aurum and Claes Wohlin (eds.) Springer Editions. Ch 3: Specification of Requirements Models. Ricardo J. Machado, Isabel Ramos, and João M. Fernandes.

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.

Why do we need more Requirement Engineering in our life?

Can we live in a perfect world where "scope creep", "out of budget" can be prevented and projects delivered on-time, on-budget, on target? 

Everything starts with "business needs". Getting the requirement right for any data project is crucial. Everyone is talking about the "needs", "client focus", "customer focus".... but still a large part of the data projects are not succeeding fully. Who's at fault?

Did you see any crime? What can the experts say about it?  What do we know about our suspect? How can we know it better?

Did you experience any symptoms?

 

Raise your hand if any of those sentences look familiar. 

You need more requirement engineering in your life!

What the experts say?

It's pretty rare to find data specifically on business intelligence projects, but we can still find interesting research in the project management and software engineering fields.

The project management area says...

Karls E Wiegers in "Inspecting requirements" states 80% of solution rework and 50% of project errors can be attributed directly to a requirement engineering. Also, according to the Project Management Institute (survey: "Pulse of the profession 2017"), to the question "Of the projects started in your organization in the past 12 months that were deemed failures, what were the primary causes of those failures? (Select up to three), respondents answered (in order) "Change in organization's priorities", "Inaccurate requirement gathering", "Change in project objective", "Inadequate vision or goal for the project".

The requirement engineering area says...

The project SMART (2004) identifies software projects main failure factors. Requirements management is the directly incriminated area in 52% of cases. Let's repeat that: half of the project failures are directly related to requirement management. Astonishing, isn't it?! We got our principal suspect!

This obscure suspect.

If more than half of the project failures involve requirement management, we probably need to fill the gap.

Compare to the technical and development fields, only a few degrees exist. In reality, the requirement gathering is usually done by a BA with a business or technical background, developers directly, PM... It's quite rare to find people with a specific degree or even certified.

If we look at the bookstore shelves, they are full of developments and project management books, but only a few to none are dedicated to gathering requirements. In most of the bookstore, we cannot even find a dedicated shelve or a book. 

Get to know it better.

As we saw, the room for improvement is important... so the room for success! It's such great news.

First, we need to challenge the status quo. Let's say it: all the sentences starting this post have the same synonym: "we need to understand why and improve our practices!"

The objective of this blog is to give you some new tools, new perspectives you can apply. I will break down the theory and hope while you are in a meeting, you can be more creative, minimize scope creep, and evaluate the risk.

What are your main challenges and thoughts about data requirement process?  

Bibliography

• Karl E. Wiegers – Inspecting Requirements – StickyMinds.com Weekly Column, 30 July 2001 link

• PMI – Requirements Management: A Core Competency for Project and Program Success – link

• Project Smart. (2014), The Standish Group, 1995 Chaos Report. Available from: link.

• The Role of Requirements in the Success or Failure of Software Projects - International Review of Management and Marketing - Azham Hussain, Emmanuel O. C. Mkpojiogu, Fazillah Mohmad Kamal link