My previous post mentioned three obstacles that need to be overcome so that end-users trust analytics and the organization becomes data-driven. In this article I will discuss the alignment phase, why it is needed, who needs to be involved, and what you should have by the end of this phase. I won’t focus on analytics per-se but building any solution should start the same way. If you want users to believe in the next great thing, you need to get them to see things from a new angle and to do this they need to buy into what you are doing.
Why do you need alignment and how long do you dedicate to this phase?
I am an engineer and I love solving problems. My goals have always been to deliver the best solutions to end users, so it took me a long time to understand the value of change management. Even when we know exactly what people need, we still need to get their buy-in and I have found that working through a structured discovery process not only uncovers aspects of the problem the core team may not have considered, but also builds a true collaborative environment where people feel they are being heard and everyone understands how priorities are determined. At every single workshop I have led, there is someone who mentions how pleased they are that they were part of the process.
Developing this network of champions across the organization is key to the success of any initiative. These people will be your marketing arm and they will be there to support you when you need help.
Without getting the right people together early, you will find that the project stalls and the team spends an enormous amount of time on politics and what I would call just-in-time alignment throughout the project. People will question why feature X was not prioritized and while they may seem like they are aligned with what you are developing, you will find that they are simply being “team-players” for management. People will deliberately or unintentionally sabotage the initiative or they will stand in the side lines and wait for the release to “discover” all the problems with the new solution.
But wait we are supposed to be agile, you may think. Some people think that since agile allows teams to adjust priorities before each sprint, then they will “figure things out” as they go along. Have you ever started a road trip where everyone gets in the car and you just start driving without a good idea of your destination? You can adjust your direction at every intersection, but you probably need to have an idea if you should head toward Florida, New York, or Montana otherwise you will waste a lot of time adjusting, a lot of money on gas, and a lot of time getting the family aligned on the target.
Just because you are agile, doesn’t mean your team doesn’t need to understand the goals. More importantly, everyone needs to agree on decision making criteria. Is cost more important than usability? Should you wait until all features are done or is releasing early and often more important?
The good thing is that this process does not take that much time. I worked on a Supplier onboarding automation project in 2012 where we brought in stakeholders from different parts of the organization. We spent 5 half days on this process. People had to clear their calendars and there was a commitment they had to make to the workshops, but this project was extremely successful. The system is still live in 2021, very few custom systems last that long in large organizations, but I attribute the success of that system to this initial phase. Spending dedicated time upfront pays for itself many times over. I remember telling the project sponsor to trust the process and luckily she did because gathering requirements this way was radical in the organization at the time, now she’s an advocate for this way of discovery.
The most important thing you will get out of this exercise is not what you are doing, but what you are not doing.
Who needs to be involved?
There are two extremes I have seen when it comes to getting people involved in a new initiative.There is either too much involvement or too little. Sometimes you have leadership that feels that you need to get total buy-in, so you end up with full representation from all the key stakeholder departments. Other times, leaders feel they don’t want that extreme, so they go off on their own and build their field of dreams. Both approaches fail. You don’t need to have workshops with 20 analysts and 10 data scientists to learn their pain points and design a good solution. But you do need some. My rule of thumb is to break things up into a few groups.
- Core team: These are the people who will work very closely on a daily basis to deliver the project. It doesn’t have to be very big and the smaller the better. This is the 2-pizza rule at Amazon.
- Extended team: These are your key stakeholders. These are the people you need in the discovery sessions along with the core team to define the project. These people will be involved throughout the project, but their primary involvement is before you start building. Here you want representation, but you don’t need full representation. You want one or two analysts and one or two marketers. Your goal is not to involve everyone. You want to keep this to between 15 and 20 including the core team.
- Extended Influencers: This is everyone else. You need them to be aware of the project and have a clear channel of communication to the core team, but they don’t need to participate in the workshops because they have nominated trusted representatives. You will have a few meetings throughout the project to keep these people informed. There’s no limit to the number of people who can be in these meeting since this is more of a town hall where people can see what's been going on and ask questions.
Doing this is hard, it’s like determining a list of your wedding guests, but it must be done. I have seen cases where some key extended influencers like a training department or information security are not made aware of a project until late in the process and their objections can cause delays and rework. So, thinking through the different teams and who belongs in each will help the project in the long run. You will have to make many choices in your project, so start with choosing the right participants.
The job to be done does not change
I am enamored with technology, efficiency, and the dream of what we can create. Even non-engineers think about all the possible things new systems or processes should do, but few people think about what they are really trying to change.
Imagine you purchased a new house and you start thinking about all the possible things you can do, change the flooring, paint the inside, paint the outside, redo the kitchen or the bathrooms, change the roof, etc. But you have limited time and resources, so you focus on the main jobs you are trying to accomplish, and you prioritize those jobs. The job of the roof is to keep you and your possessions dry. If the current roof is doing that and there is no immediate need to change it, you move to the next item. The external and internal paint make you feel good and if it's not too bad, you can put that off for a few years.
Your kitchen’s job is to feed your family, is the current kitchen meeting those needs? Maybe the stove or microwave don’t work, so you narrow the change to that. Doing the same exercise for the bathrooms you put those off to a later date. Finally, you get to the flooring and since you have a new baby that will be crawling around you realize that changing the old yucky carpet is your top priority, the job of the carpet is to keep your baby safe and germ free. So without even realizing it, you have gone from a long list of potential projects to the things that were most important to you and your family and stayed within time and budget constraints.
We don’t do this at work. We try to come up with all potential features and it’s not always the best features that win. While at home you only have a couple of influencers, in a company you have many and all with a different agenda and different perspectives.
So, what should you focus on? Focus on the job. The goal of whatever you are trying to improve does not change, what is changing is how you do it and how it builds on that process.
The supplier onboarding process I referenced above had a straight forward goal; get a vendor record created in the ERP system so we could receive purchase orders and pay invoices. That’s it, that’s the main reason to have an onboarding process.There are many ways to accomplish that job, people could call a representative at a supplier and get all the needed information and enter it into the ERP. There could be forms in Excel,Word, or PDF that could be emailed around to collect the information and routed to a data entry person to get the information into the ERP. What we did on that project was about integration and validation. We didn’t change the goal of the process, but we revolutionized it. Instead of emails, there was an end-to-end workflow. Instead of fixing bad data after it got in the system, we validated it as it was being entered. Instead of having separate processes for compliance, information security, or country specific needs, we dynamically integrated all these processes into one. If you focus on the job, and do that well, then you can improve surrounding objectives because you can focus on what can be truly different and help you do the job better.
"As leader of three major global project improvement initiatives over the last several years, I have found the inception workshop to be hands down the most effective means of pulling together key stakeholders to identify actionable pain points, define requirements and prioritize user stories. The inception workshop without doubt set the project on an effective trajectory from the onset and ensured a unified project team resulting in an extremely successful outcome. I wouldn’t want to start another major project without it."
Product Owner, Global Supplier Onboarding project
What should you have by the end of this process?
We have started the change management process, figured out who should be involved, and narrowed down what we want to build by focusing on the key jobs we are trying to do, but what should you expect to have at the end of this exercise? You should have your roadmap.
If we go back to the metaphor of going on a road trip, this process helped us decide that we want to go on a trip that exposes the family to the wonders of nature, the job. We selected the Grand Canyon and we mapped out the route along with approximate pit stops (milestones), as well as trip duration, budget etc.
This is exactly what we will have for any initiative because when everyone aligns on the goal and what’s out of scope you can determine timeline, costs etc. We also understand stakeholders, risks, and we have built the prioritized backlog. Now you can start your agile project the right way. When new stories are identified you have an evaluation criteria, not everything is the same priority. I always tell project sponsors to start with “no” because every time you say yes to something you are not only committing to additional scope now, you are committing to it forever and you know what, a lot of times these things are “nice to have.” You will find that “must have” features come up repeatedly and are the ones that really have a big impact on the job to be done.
Conclusion
It’s easy to fall for the illusion of progress when you think you see what needs to be done and want to get to solving the problem, but you can have the best solutions and if you don’t bring your stakeholders along the project is doomed from the start. There are countless stories in history of great products that failed and projects that floundered. I attribute this to not getting everyone on the bus from the start.
You need to put value in the process not just the final product and get the right people involved, focus on what’s important, and develop a plan the whole team can endorse. It may seem impossible, but I have seen it work and with a structure approach you spend some focused time upfront which pays for itself throughout the project and you build a network of champions who will “spread the love” throughout the organization and who will feel valued because you listened from day one. Trust building takes time, but the first step in building trust is listening.
