In the corporate world and in technology companies, despite the evolution of countless software development methodologies, one great challenge remains: defining requirements. Under the influence of the Lean wave — including Eric Ries’s Lean Startup — and of rapid, Agile development, technology companies have deconstructed traditional methods and their documentation, reaching for different formats (user stories, canvases, use-case diagrams, prototypes, mind maps, and so on). And yet, to this day, the consensus holds: any documentation format is error-prone, quickly goes stale, and often fails to express the real business objectives that motivated the project in the first place.
Do software requirements exist?
This is where the challenge becomes real and concrete. Mark Schwartz, Enterprise Strategist at Amazon Web Services, argues in his book A Seat at the Table: IT Leadership in the Age of Agility that software requirements simply do not exist — they are merely a format created to “package” the communication between the business and the company’s IT function, wholly exposed to the difficulty of communication between the two. Schwartz offers several examples, among them requirements that aren’t truly necessary: features that bring no real benefit to the target process, bloating the solution — in other words, requested requirements that never needed to be built.
Startups versus the corporate world
More recently, this awareness of how fragile requirements documents are popularized agile methods and encouraged integration between development, operations and business teams (DevOps) — a strategy that has worked well for technology startups around the world. The challenge is that, in the corporate world, the collaborative DevOps approach is not easy to implement: more than synergy, it demands genuine joint work among Product Owners, developers, key business users and infrastructure professionals.
There has to be a better way to deliver
Precisely in search of practical answers to these dilemmas, Mark Schwartz points to Impact Mapping: Making a Big Impact with Software Products and Projects, by Gojko Adzic, a consultant who specializes in software projects. In just 86 pages, Gojko proposes a way to visualize a project’s scope that is simple, almost trivial — and that can make the difference in corporate software work. In his words: “Today, software is everywhere. Yet countless software products and projects die slowly without making any impact. The result is a huge amount of time and money wasted on wrong assumptions, lack of focus, poor communication of objectives, misunderstanding and misalignment with wider goals. There has to be a better way to deliver.”
Frameworks don’t fix culture
Gojko’s outcry echoes in every technologist who has suffered through large projects whose deliverables never met the expectations of the business. Before laying out his method, I think it’s essential to bring you, the reader, to a reflection a friend and PMO once shared with me: “Frameworks often make crucial contributions — but not to the cultural and political questions that are, most of the time, the main causes of failure in process change.”
In other words, adopting any method or procedure is pointless if the organizational environment — the existing culture, including the interests, expectations and competence of the people responsible — hasn’t been taken into account in the plan to implement it. The success of a new strategy is tied to inserting it correctly into a company’s ways of working, in full sync with the aspirations of the people who make it up. If that environment isn’t ready, with the right people in the right positions, the framework won’t be used well and will soon be forgotten — or become just another piece of bureaucracy, in the pejorative sense.
A McKinsey study found that most failures are not about the absence of a good plan or of resources, but about the lack of engagement of the organization — whether of employees or of leadership itself. The organization never “bought” the change.
“Organizations waste a lot of time and effort building the wrong software.” — Gojko Adzic
The Impact Map
Gojko’s book offers a relatively simple approach — the Impact Map — that struck me as useful to run in just one or two meetings at the start of any project. It answers, visually, the problem the solution is meant to confront, based on only four questions: Why, Who, How and What. The approach distributes responsibility and maximizes the effectiveness of communication, above all between IT and the business. An Impact Map is also a storyboard of our conceptual understanding of how to reach the project’s goals. For Gojko, these questions are far too important to be left to the “client” or the Product Owner alone. Below, a summary and my own thoughts on the four pillars of Gojko’s Impact Map:
Why?
The center of an Impact Map answers the most important question: why are we doing this? What is the goal we’re trying to reach? It may sound obvious, but development teams frequently make decisions with no clear knowledge of the objectives at stake. Knowing why we’re doing something is the key to good decisions about cost, scope and timing — both at the start and when scope changes. Conversely, if we deliver exactly the scope requested and the project doesn’t reach its objectives, it will be judged a failure.
Who?
Who are the actors that should influence the final product of a development project? Some requirements models care only about “what the software should include” and completely forget the users who will benefit from it. Especially in solutions aimed at operational efficiency, end users must come first. As Gojko puts it: “…most requirements models ignore this completely — they focus on what the software should do, not on who will benefit after it’s delivered. Then, at some point mid-project, a new actor appears out of nowhere and everything changes, or someone with enough decision-making influence simply halts delivery midway.”
Gojko suggests defining a project’s actors carefully, in this order:
- Specific individuals
- User “persona”
- Roles or job titles
- Groups or departments
Unfortunately, Gojko explores this little in his book, merely laying out the four groups with a few practical examples. My tip: not only in this initial Impact Map exercise, but above all when reviewing the requirements you’ve defined, it’s essential to review them together and from the perspective of each of these groups. I place special value on defining the user “persona” — a common concept in advertising agencies, but one I rarely see applied in software development. I like to say that we in IT (myself included) always think we know more than the end users do.
How?
How will these actors’ behavior change? We need to pay attention to the activities users perform day to day, rather than simply listening to their ideas about a product or service. Seeing this clearly lets us decide which features best serve the defined objectives — and prioritize them. Visualizing end users’ activities in the processes the new software will improve can yield valuable insight for building the ideal solution, and for mapping the risks that might compromise its adoption — including the cultural changes required and the best way to train users on the new software.
What?
For Gojko, only after the first three questions are answered can we finally talk about scope. Without a clear map of deliverables tied to the project’s objectives and justified by the impacts to be achieved, it becomes hard to make investment and prioritization decisions. In large corporations with many stakeholders, requirements routinely appear driven by the “wish” of some interested party, with no correlation to the defined objectives.
Building an Impact Map, as suggested, is valuable for justifying the project — a fundamental component of a solution’s business case — and should be revisited throughout development, serving as a trail for wrapping up the work, deploying the software, and validating the results achieved: the benefits realized by the business.
Regardless of context, project size, or the methodology adopted to organize development, the Impact Map concept can be applied with ease.
References
- A Seat at the Table: IT Leadership in the Age of Agility — Mark Schwartz (IT Revolution Press, 2017)
- Impact Mapping: Making a Big Impact with Software Products and Projects — Gojko Adzic (Provoking Thoughts, 2012)
- The Secret to Successful Company Transformations — McKinsey & Company