Seemingly simple changes can affect the entire technology stack, from the User Interface where a customer or adviser enters information through integration and API layers on to the underlying data stores and back-end systems. It may not stop there either, as that data will need to be re-surfaced to the business in Management Information – in summary a complex cross architecture and cross business challenge.
Here are 4 key lessons from 15 years of collective Altus experience that should make initiating, designing, building and launching your change a little less painful.
At the core of making any change manageable is containing scope. A common phrase in this context is Minimum Viable Product (MVP) but we recommend substituting Value for viability.
I connect the word viable with organ transplants where a viable organ is transported on ice, needs careful handling and specialist machines to keep it alive. This is not how your new project should be seen when it goes live, and very often even that minimum viability is gradually eroded as projects suffer setbacks. Value is more tangible and will deliver something of worth to everyone that will be seen positively. Ensuring you focus on Value in every change request and scope meeting will improve your chances of delivering positively for the business.
One of the best ways to ensure you get value out of a technical change is to take a slice through the architecture touching as much of the estate as possible but with minimal disruption.
Whatever your delivery methodology: waterfall, agile, water-agile-fall or SAFE, having a clear picture of the end state is key to success. A lack of this picture is one of the most common reasons we see for project failure, while a blurry version typically leads to unnecessary complexity, cost and ultimately technical debt. This is especially true in early agile projects where very often compromises are made which later become a de-facto pattern that constrains future change.
Creating an end state picture can be straightforward and is perfectly compatible with an Agile approach. A solid vision that can be shared across the team is crucial when integrating into a complex landscape and should cover both business and technology angles.
It is easy to see an organisation’s change process and decision gates as obstacles to change. It can also be tempting to search for ways around them but this behaviour rarely ends well. Instead, it is better to embrace the rules, make friends with people, canvas and talk to the various boards. Early sharing of project benefits to get key individuals on side will usually lead to an easier route through the various gates. You may even find you get value from the process!
Promoting the vision is one of the best things you can do for your project. If people don’t know what you’re trying to achieve, or you have to explain it every time you need help, then support will be hard to come by. Conversely, if you advertise your project and its target outcomes well enough, you will attract supporters who want to be associated with it. Assuming of course that your project continues to deliver successfully...