Jan 4th, 2021
Lessons From the Field
Part 3: Like for Like
Written by: Craig Vosper, Chief Delivery Officer
So far, I’ve only focused on our ‘good’ lessons learned, so today, we are going to talk about our more painful lessons learned. This one is the good old ‘like for like’ – “I want a new application that works just like my current one”. Nowadays, hearing something like that makes me cringe, but the first time I heard it, my mind went right to: “well that should be easy enough!”
The project I’m referring to was focused on migrating away from a legacy status/reporting tool that was being used for sales planning and projections. Their current solution required manual spreadsheet imports of data from a third-party CRM tool into their access database. Users would then generate other reports (spreadsheets) that could be sent to different sales groups throughout the organization for planning and tracking progress.
Our proposed solution was to build an integration with their CRM tool and then build a reporting interface for the users to make required adjustments and release the reports to the necessary sales groups. Once completed, the business would see reduced errors, minimize manual changes, and experience a vast improvement in the latency of their data.
Unfortunately, our business partners thought that because this project was a ‘like for like’, that meant we didn’t need them involved in the project. This led to several detrimental issues:
- Lack of true business priority
- Lack of clarity on requirements and process
- Lack of user testing along the way
These issues resulted in more time being spent by our team trying to understand the current solution before they could appropriately estimate the work. Testing delays lead to more bugs and changes late in the release; causing significant delays. It also resulted in a greater time commitment from business users than they had originally hoped – in order to help answer questions and resolve issues throughout.
Ultimately, these lessons led us to require business involvement and testing throughout all our projects. We need our stakeholders and SME’s to clarify objectives, define the business processes, and validate what we build. Now our sprints result in software that is tested and accepted by our business stakeholders. This helps us ensure we spend the least amount of time building the right things for them!