Whether it’s a new lending program, a core conversion, or building a new branch or main office, every project your team approaches is going to have multiple sets of requirements and multiple definitions of success.
And this isn’t a bad thing, just the nature of the dynamic and complex nature of these projects and the different people and roles involved.
Think about the requirements for your next project like the ingredients in a pizza, and you can only order one pizza for the team.
This would be chaos, right?
Sam in IT would like pineapple, but Lisa in marketing hates pineapple on pizza. Sally in lending is the only person who likes olives on pizza. A few team members like meat lovers’ pizzas, but Devon in HR got bit by a lone star tick and has a deadly meat allergy.
Folks talk over each other, there’s confusion, it takes a long time, and nobody is happy with the pizza that eventually arrives.
But there is a better way.
We’ll let you in on the secret sauce that leads our projects to consistently successful outcomes: the alignment session.
Our alignment session is a proven process that involves building a broad list of requirements and then collaboratively sorting them into different categories. These are Must Have, Should Have, Could Have, and Won’t Have.
The team must have a large pizza, and it must have sauce and cheese. Sam lists pineapple as a should have, but multiple other people placed it in won’t have. It turns out that Sally could have olives but doesn’t feel that strongly about them. A few people list meat lover’s as should have, but Devon’s won’t have due to allergies cancels them out. There is structured conversation around these requirements that efficiently sorts out the requirements of this pizza until the definition of a successful pizza order converges around something that everyone will enjoy.
Now apply this to a project.
Imagine projects that have gone south in the past. Last-minute stakeholders jumping in with requirements that change the scope or direction of the project. Expensive architectural changes at the end-stage of a new branch design. Selection of a software platform that doesn’t meet many team members’ needs.
Now imagine you could go back in time to the planning phase of these projects and kick them off with all the stakeholders in one room building a list of requirements collaboratively with an alignment session.
How much differently would the project have turned out?