Problem-solving from the stakeholders' point of view.
Understanding the landscape is critical whether you're facing any new situation. One technique that I consistently use is Wardley Mapping. Let me share with you a concrete example to visualize the landscape.
Understanding the landscape is critical whether you're facing any new situation. One technique that I consistently use is Wardley Mapping. At least in my head, sometimes in writing. A Wardley Map is a structured (mind) map visualisation that helps visualize movement/change in the parts of the stakeholder challenges.
GOTO
I have been using Wardley Mapping since 2020. I have used it extensively to visualize strategies in the testing space in my first book below. (The "GoatS Book" initially had the above goat as a cover, but I needed plural goats.) Wardley Mapping is about a visual way to make better strategies in general. Let's make more goal-aligned cyber compliance!
Jesper Ottosen
In a current delivery as of January 2025, I'm following up on 50 contractual requirements for a large SAP solution. The requirements are part of a set of 500 requirements for a large €50 Million outsourcing agreement. All the requirements are there for the customer organization to control what they want and get. But not all requirements are created equal, when going through them some are general clauses around GDPR and data protection, while other requirements are specific backup and password management procedures. Some are new/improved and some are there for historical reasons.
So we have to read into the stakeholders' point of view and have smarter interactions. We need to problem-solve from their core needs. The first exercise is to distil their requirements into a few key needs - their "top of mind" or their "pain". Perhaps what they are really saying is that they value data integrity, system segmentation, and general system health. Remember to ask them: If I put these three topics on top of the pile (and the map) do they agree?
Side Quest: What are they not saying explicitly? Perhaps with 500 requirements, they are communicating a need for details and a thorough approach.
If they agree, we can break down the top items. Something like this, as a case:
- Data Integrity
- Encryption at rest
- Encryption at transport
- System Segmentation
- Separate networks for dev, test and prod
- Segmented accesses in the stack (DB access, admin access, ...)
- System Health
- Operating systems are patched
- Systems are monitored for intrusion and vulnerabilities
- Any external files being uploaded are scanned for malware
While part of the exercise is to break elements further down, the key value in Wardley Mapping is to score the elements on an evolution scale. The original Wardley Mapping site has an extensive characteristics cheat sheet.
In this situation I'm evaluating each of the requirements in my scope on the following scale:
- Unknown/Novel to us: We don't know if the solution has any file uploads.
- Describe/Emergent: We need to think, write and execute a solution. Design a segregated network, as an example.
- Execute/Existing "Product": We need to configure something we know how to do already. It's on the shelf but needs a context fit.
- Known Practice/commodity: We already have procedures/solutions for this in place. We know how to patch and monitor the infrastructure.
This helps me to understand the effort needed in delivering and documenting the requirements. About half are things where we need to design something, and about half are known solutions. As I drill down into group #2, we have templates and previous work to support us in getting a #2 to a #3 or #4. From a custom build to a product or commodity solution.
It helps me focus on getting the unknown #1 out of the way fast, while not spending too much time on those we know how to solve. It helps me prioritize the efforts, that I would not have been able to do using classic project management methods. I am considering setting this up in backlog with a scrum-like approach.
It's early days let's read the landscape first. Let's ask open questions and be curious as to what is on the stakeholder's mind. Perhaps the external files are not as high up as I hear. Let's problem-solve from their point of view.
