In any process or technology transformation project, there is a risk of not going far enough. The comfortable state is to make something similar to what we already have. This is especially likely in a legacy modernization project where the default path forward is to build a carbon copy of what we already have, just based on a different technology. This can result in a tragic lost opportunity. It is common for teams starting a new project to be unaware of what the current “art of the possible” is. They may set their sights too low, or have some preconceived notions about what's possible, and those can really limit invention and box teams into an incremental change mindset.
To avoid these problems we use an envisioning project to help business people see beyond where they are today and envision the appropriate future state. The goal is to see what is technically possible, very quickly, and zero-in on the highest value definition and scope for what can be done. An Envisioning project is typically short - two or three weeks.
Clarify Business Concepts
One of the key outcomes of the Envisioning project is to clarify business concepts. It's common for all of us to use terminology in the domain we work in without a rigorous definition applied. It is very common for people to use the same words for two different things or two different words for the same thing. This is what separates Domain Terminology from the mere vernacular. One of the key parts of an envisioning project is getting clarity on the domain that we're working in so that everybody can say the words and mean the same thing.
"This kind of project requires precise language. The right terminology in this work is critical. You see this in medicine. The doctor in an OR doesn't say, 'Hand me that knife-thingy.' Precision terminology cuts down on mistakes in medicine, and the same is true here."
Imagining the Solution
The second major object of envisioning is to build prototypes. Prototyping is important because it gives a tangible example that a group of people can use to make sure that they are imagining the same thing. When we talk only in the abstract, different team members might be thinking of completely different things - a prototype gives a common point of reference.
It is easier for most of us to design something that we can see. Part of the Envisioning process is to make these abstract concepts tangible enough that imagination, expertise and creativity can work together to achieve solutions that work at the edge of the possible.
We use these visualizations to evolve our thinking about what this thing is we're trying to make. We agree on a well-defined shared terminology, clarified through concept maps and other techniques. This deep understanding is extended through daily builds and iterative prototypes.
What is a Typical Work Cycle in an Envisioning Project?
A typical cycle in an envisioning project is spending time in the morning with the business team, understanding the terminology, brainstorming concepts, talking about what they're trying to achieve. And then in the afternoon, we build a prototype based on what we've heard that morning and the next morning we play it back, meaning we demonstrate it and talk about the concepts as they're shown on the screen and that triggers new discussions and new ideas. And we iterate like that daily, usually after a week or a week and a half, we have zeroed in very, very well on the business terminology, the data models that comprise the business, the relationships between that data, and the goals of the project outcomes within this well-defined ecosystem.
Scoping Your Modernization Project
The Envisioning project also has a deliverable that comes in the form of a User Story work breakdown of the domain you're working on. This is extremely helpful in determining the probable scope of the project. Your output will be a hierarchical set of User Story titles. From these we generate estimates on the level of effort probably required to deliver working code for each. We can also apply some placeholder estimates of actual time required to do this work which will help in making a more accurate project design in terms of cost and effort.
The business team then can help you tune what the scope of the first project would be. What is the minimum viable product and how long will it take us to achieve that? So when you think about those things coming out of Envisioning - the concept maps to clarify terminology and key concepts, a working prototype to illustrate you usability and user interaction concepts, and a big list of user story titles with rough order of magnitude estimate, you have a lot of material that is a direct input into planning the development project.
But the most important output of Envisioning is the clarity of mission. History is littered with projects that had a vision, had people with a picture of what they wanted to achieve, had a motivated and skilled development team, but somehow still didn't end up producing what they needed. Envisioning is a strong defense against that kind of outcome.
How to run a Successful Envisioning Project
What do you actually need to run a successful Envisioning project? The easy part is that you likely have most everything you need in terms of human resources already in play. These are the business experts and technical people who keep your company running. You will also need a trained and experienced Envisioning Facilitator, ideally two of them. (Having two facilitators allows you to run some of the activities in parallel.)
But the more challenging part of the project comes down to leadership at your company. You will need to have full engagement and cooperation to get this kind of work completed effectively. This is a project that can transform your business, and help everyone be more productive and effective - but all participants will need to cooperate towards the same goal of making a better future for themselves and for the business.
Conclusion
It is difficult to overstate the importance of using the Envisioning process before trying to start your software project. The time and money spent on running the project continuously has shown to cut down on lost time and effort and to produce products which are cohesive and thorough at achieving the business goals you actually need. The improvement and clarity of your defined domain models and relationship maps will continue to be useful even after the software project is in production.
