In my previous role, I wore the hat of the local authority ICT specialist. I, therefore, am acutely aware that it can be somewhat daunting for local authority ICT colleagues when leading and managing integration projects that draw together separate 3rd party technology vendors to complete the activity.
Now wearing the hat of the 3rd party technology vendor (Abavus Limited), I have during the last six months completed two separate major waste integration projects for local authorities in collaboration with their outsourced 3rd party waste technology provider.
Drawing experience from both engagements within this blog I wanted to reflect on the key factors and steps that have contributed to both their successful implementations.
The following are my steps to success:-
For the collaboration to succeed it is really important from the outset to set up early initial engagement that involves all the stakeholders, this includes project leads both technical and programme based. It is also good to have senior stakeholders from the authority available (if the engagement is of significant strategic importance), including the Heads of Service who may be footing the integration bill. In short, it is an opportunity to make key introductions, ensure that everyone is on the same page, address any risks or issues immediately, and exchange if not already done so all technical information.
Scoping customer requirements
Technically planning the solution is critical – completed comprehensively it will save a lot of headaches and head-scratching down the line. The output from this phase is a detailed requirements document, which if done well will challenge existing working practices, offer methods on how to enhance current working practices, and which ultimately provides the customer with the right solution they require.
Ensuring the requirements are fully signed off
Once the requirements document is complete it needs to be formally signed off by all stakeholders, not just the authority stakeholders. Once everyone is satisfied and comfortable to sign the document off only then can the vendors work in partnership to begin technically building the solution.
Translating customer requirements into a developed product
Once the customer requirements document is complete and signed off, a further internal technical document is produced for the technical team to work from. In my recent integration examples, this is a low-level base coding document, detailing each process flow and how we map the required interactions from our platform into the waste providers system via webservices.
System and User Acceptance Testing
Once the solution is designed and built, we run through agreed rigorous system testing with the customer and the other 3rd party technology vendor. This ensures the solution meets the customer requirements as specified within the requirements document. Once completed and signed off we then hand the solution over to the customer to independently complete User Acceptance Testing, having created testing scripts for users. This testing will be completed in our Demo environment before moving the complete solution into our live production environment
Migrating from Demo to Live Production
Significant efforts are made in our demo environment when designing any solution to ensure that it fully matches our live production environment.
The migration from demo to production is comprehensive, ensuring all configurations, processes, integration mappings, etc are either copied into production or are diligently recreated.
Once the migration is complete, we work with the customer and 3rd party provider to carry out further testing in the live systems on pre-arranged sample data.
Where possible we always look to complete migrations at weekends or out of hours to ensure that if any issues are encountered during the cut-over they don’t affect the wider customer platform and can be resolved without any serious impact on the day-to-day ongoing business.
Formal Project Sign-off
Once all parties are satisfied with the final solution, we request a formal project sign-off from the customer.
Snagging during a short warranty period
Whilst every effort is made to capture all elements in the solution there may be some minor snagging pieces to resolve.
We provide a minimum 14 days project warranty period for the customer to resolve issues covered in the originally agreed requirements document. This is usually sufficient time to resolve any minor snagging that arise.
Training for Business as Usual
Finally, during the warranty period, there are two important pieces of knowledge transfer and training to provide. The first is to ensure that the ‘business as usual support team’ understands the integration that is being passed over and can quickly resolve any related problems that may occur in the future. The second is to ensure that the customer also technically understands the integration and similarly can quickly identify issues if they occur and importantly from which vendor the errors are occurring.