Given the accelerating rate of business change and competition, it is not unusual for businesses to want to deploy a major new product or upgrade rapidly. Sometimes business survival might hang in the balance and depend on such a product deployment. This is one of many reasons agile and scrum are so popular – they drive speed-to-market.
Consider as an example a company with multiple business lines in siloed divisions with little to no cross-selling. A website and mobile application that allows all businesses to showcase their products and cross-sell could bring a significant boost in revenue. However, each of the divisions sees the final website and mobile application differently. They may also have biases or preferences for their own division’s interests that prevent them from looking at a bigger picture. Should we just dive into design, sprints and coding, and hope for this to sort itself out?
Turf Wars and Inefficiency
All too often, technologists find themselves at the intersection of colliding business opinions and perspectives as companies develop solutions. Bringing together diverse opinions, personalities and perspectives is never easy. Making the picture a bit more cloudy, what customers want may not be clear even to them. In this example, our business customers:
- May simply want to defend their business unit’s interests, and not want to compromise.
- Could possess an incomplete understanding of the entire business need. Their perspective could be misleading.
- Might have a business process understanding that is less than optimal. For instance, they might assume that the website needs to mirror existing manual processing steps that could be eliminated.
Given these challenges, how can we succeed?
Alignment is Essential
Too often, we charge off on a mission, but don’t really understand where we are going and how to get there. In this case, in between the high-level problem statement and detailed tasks, there exists a wide gulf full of potential misunderstandings, disagreements and inefficiencies. Along the way, these issues surface and result in unproductive churn for everyone. Whether we are working in agile or not, resolving these differences and aligning the business behind a common goal must be a priority. Taking the time to do this up front is essential to the success of this initiative. Without it, we will fail.
To begin to flesh out what it is we are building, we start with a simple business problem statement. In this case, the problem statement is: “We need a website and mobile application that allows all businesses to showcase their products and cross-sell to boost revenue.” Once we have this simple starting point, the Vision Pattern from Leadership Patterns for Software and Technology Professionals helps us understand how to align these potentially diverse business perspectives.
In a nutshell, in between this business statement and detailed tasks, we introduce a vision document. It fleshes out the business problem statement into a slightly larger story that captures more detail in a relatively concise one- or two-page narrative. At first, developing a vision document may seem like an extra step. However, we are using this for much more than just documentation. We are using it to elaborate and define the product and to drive consensus and alignment between the technology teams and several different business units. If we do not do this, it is likely no one else will.
From Order Taker to Facilitator
Once we have a first cut of the vision, we don’t just file it. We refine it by actively discussing it with each of the different business units. We can use a wide array of techniques to engage them and surface any hidden issues, disagreements or new requirements using the vision document as a tool for feedback. A few of the many possible techniques might include:
- Informal, drive-by conversations: “Do you have a minute to review this and give me some feedback?”
- Discussing the vision in a larger meeting with key business stakeholders, asking the same open-ended questions we discussed before, such as “Do we all agree?” or “What have we forgotten to include?”
- Targeted chats or phone calls with stakeholders.
- Finally, while most executives may be too busy to review a large document, they will review the bite-sized vision document and provide feedback.
Discussing and refining the vision moves technologists from being the problem to facilitating a solution. During this process, we also root out previously hidden information. We pull people and their ideas together to sharply focus the software product.
It is important to note that consensus does not mean that each stakeholder gets their own way. However, it does mean that the stakeholders agree as a group that it is the right thing to do for the business at a point in time. We are educating the business stakeholders on what is possible, and providing them with an opportunity to comment, agree, or disagree with each other. We want to let their voices be heard and get all their opinions and thoughts on the table. Allowing stakeholders to voice their thoughts is empowering for them, and dramatically raises the probability of success for the product by sharply and efficiently refining the scope.
A Seat at the Table
One of the missing links in software and technology development of systems and products involves obtaining a consensus around what we will be building. Developing a major new product that involves multiple competing interests is never easy. Leveraging a vision document provides a lightweight and efficient solution to this dilemma. It provides a forum for interactions and engagement to build consensus and drive success. We gain clarity and a much better understanding into what the product will do. Rather than allowing hidden information to exist, we actively seek it out early in the product’s development.
This approach is not just limited to product development – there are many cases where technology teams find themselves in the middle of a heated debate. The Vision Pattern can be used to align diverse teams and businesses around a single goal for a product, initiative or business transformation. By doing this, we elevate technologists above the role of order takers and provide a vehicle for us to engage our business partners in a meaningful dialogue that results in success and understanding.
Matt blogs regularly on digital transformation and agile at Genesis10.com. Please read: Trust, Partnership and Agile.
Let’s continue the dialogue: Subscribe to the Genesis10 blog.
