It’s decided – we are using a vendor to replace four of our bespoke software systems. They do much of what we need, and now we just need to make sure we can still do all the other bits they CAN’T do.
So, we were clear on the goal. We were clear on the benefits. We even had some basic (aspirational) milestones from our very capable project manager. And our team had a pile of processes, functionality gaps, and requirements.
The power of focus
This ragtag band of business analysis heroes needed a way to create order from chaos, a way to focus the users input on this massive effort in a way that helped our development team and the vendor understand how to swap out a major part of our technical ecosystem.
I had the chance to sit down with the team and brainstorm our approach and this is the plan we drafted:
- Taxonimize (yes, I made that up): We picked the right set ideas to organize our work around. In a fresh new application, these would be our epics, but since we were walking into very established and complex territory, we chose to focus on the list of processes that our business architecture department had written down last year.
- Create a repeatable framework: I love simple “greenfield” apps and have had the pleasure of working on a few. But for this replacement of existing software, we had to churn through stacks of preexisting features and flows. To manage the volume of work, the team created a list of steps (process flows, comparative analysis for similar processes, ideal future state, management decision on future state).
- Execute: With the framework in hand, we are testing out the framework and it seems to be working so far (2 processes in-flight, 18 to go). We can lay the processes side-by-side and hopefully just pick 1 of the 3 ways we do everything for the vendor and dev team to implement.
A bright (and efficient) future
If this works out, we save as much as two-thirds of the development cost and have a simpler, more scalable future ahead. The less we do, the better we can focus.
Anyone else out there doing monster-sized vendor package implementations in a big organization? Would love to hear your thoughts.