As a software development business there are two things we care about:-
- The technical development and continuous improvement of our flagship product, My Council Services, to ensure that its design, functionality, reliability and security are the best they can possibly be
- Working together with our clients to ensure they’re getting maximum business benefits from our products and services.
We work exclusively with the UK local authority sector, so we recognise that there’s an investment of public money into every project we work on. With that in mind it’s vital that we can demonstrate value for money on every project and ensure that all the councils we work with see a clear return on their investment. This concern is clearly visible in the efficient and agile way that we work.
We know how important it is for you to start seeing benefits from your investments quickly. We won’t spend weeks and weeks onsite with you simply documenting ‘as is’ processes and writing reams of technical specifications. Instead we put strong organisation and planning at the core of all projects, large or small, ensuring that we capture your full requirements up front in a systematic and affordable way.
The scale of the projects we work on varies widely dependent on the scope of delivery, the number of service areas affected and the range of My Council Services modules that are included in the offering. The number and intricacy of system integrations also has an impact. That said, most projects follow a broadly similar process. Here we provide a high level description of a typical project which we hope will serve as a guide to what to expect if you’re considering working with Abavus.
What happens before the contract is signed?
Your project begins with us agreeing a clear scope of delivery and a realistic delivery timeline. This process is iterative, but it begins as part of the commercial discussions prior to signature of the contract. Of course, the scope of delivery and the pace at which a project is to be implemented has a direct impact on the resources required and therefore the underpinning commercial agreement.
It is not always possible to get into the granular project details prior to award of contract – this is often due to the understandable constraints of procurement rules. That said, the use of procurement frameworks such as G Cloud Digital Marketplace help here and allow us to have the sensible and often more detailed conversations necessary as part of the due diligence process.
Prior to contract award and to contract signing, we work closely with you to identify any potential delivery gaps that maybe overlooked during the award process and to make clear any underlying assumptions that may later have a bearing on the project. Any working assumptions are always captured and documented at this stage in order that there is no ambiguity when the project is underway. There is nothing worse than realising part way into a project that there is a glaring gap which has been overlooked and which will cost time and money to resolve.
What happens once the contract is signed?
1. Identify the principal stakeholders and the resources available
At the start of any project we’ll work closely with you to identify the right people to form the core project team. It’s also important that we have a good understanding of the resources that you have available to support the project. In the first planning meetings we have, our aim is to gauge the amount of support that we’ll need to provide to your project to ensure that it succeeds. Typically we’ll ask you to think about the following types of questions:-
- Is this project something that has to be resourced in addition to ‘business as usual’ for your staff or third party contractors, or do you have access to full time dedicated resources?
- Will third party contractors, outsourcers and other consultants be involved in the project?
- Have third party cost considerations been factored in?
- Who will manage these third-party relationships during the project?
- How will Abavus engage with your third party suppliers?
- What is the project structure?
- To whom do we go to for help with the different project elements?
- To whom do we escalate to if problems emerge during a project?
- How will problems get resolved?
2. Project organisation
Once the project team is assembled, the next stage involves working with you to understand more about how you plan to deploy the technology so that we can structure and plan the project accordingly. During this phase we’ll be working together to understand:-
- How your organisational priorities and challenges are driving the project – For example, perhaps you need to make specified savings during a particular financial period, and the My Council Services technology implementation is critical to this. Knowing this, we can structure the implementation to meet these challenges.
- Political considerations and how these map to the wider organisational objectives – If your services are being changed or reengineered, then the timing of the project implementation may have political ramifications. It’s critical for us to understand these considerations from the start of the project so that we can help you plan accordingly.
- Identification of potential ‘quick wins’ – We find that projects often run more smoothly when a few quick wins can be delivered relatively early on, as these help build momentum and confidence in the project plan within the project team, as well as with wider stakeholders and customers.
3. Identify project risks
We’ll work with you to create and monitor a register of potential project risks. Top of that register is always resource availability. Projects that are not properly resourced (whether with people, budget or other relevant assets) are destined to underdeliver and, ultimately, to fail. The kinds of questions we’ll be asking at this stage include:-
- Does the project team have access to people with the appropriate levels of skill, knowledge and experience?
- Have clear priorities been set for the project, and have these been clearly communicated to all stakeholders?
- Is there a clear broader communication approach as part of the project strategy and plan?
- How is your internal user community being included in the project? It is crucial to ensure that users have early visibility of the technology and that they take ownership of whatever new technology they’ll be using in the future. Don’t simply impose something on them.
- Does the council have clearly defined roles? For example, where is the delineation in terms of IT ownership and business ownership in the council’s different service areas?
- Are all affected staff suitably represented and engaged in the process design phase? Do they have the opportunity for meaningful input? Without this, the project will almost certainly run into difficulties in the testing and sign off stages.
- When do you want to be able to put each product live? It’s vital that each product has been properly tested before being deployed as live. Equally, it is too easy to constantly defer live deployment on the basis of very minor imperfections. The key here is to have mutually agreed acceptance criteria for ‘go live’ and to work on the basis of going live as soon as a viable product has been tested.
4. Project planning timelines
Together with you, we’ll agree a realistic project plan with SMART deliverables:
We’ll schedule regular project review meetings, and make sure that these are actually adding value to the process – there is no value in project meetings for their own sake. Each project meeting will focus on practical outcomes and generate clear actions. It is important that there is a measure of pragmatism on all sides of a project. Managing the detail is important, but it’s also useful to step back from time to time to consider the wider project objectives and make sure that the project as a whole is still heading towards delivering identified benefits to your business.
What happens once the project is underway?
No two projects follow exactly the same project path, but the following is a summary of the different elements of a small to medium-sized project.
1. E-form design
Almost every process that is being considered as part of a digital transformation programme will use an electronic form of some description. This may be for a citizen to use in a self-service context or it may be connected to a task or inspection for a council officer or outsourced partner operative. Thus well-designed e-forms are central to successful projects and, where appropriate, we will challenge the process owners to think laterally and to ensure that the full scope of the technological capabilities are being exploited.
Considerations here include:
- Are we replacing legacy forms or designing forms from scratch?
- Are we delivering training for users who will be responsible for form design and delivery or are we completing form design on your behalf?
- Are there opportunities for re-designing and improving processes?
- Can we reduce form length without compromising the effectiveness of the process?
- Can we improve customer experience for users of the form?
2. Back office and automated workflow
A significant element of the project activity will be concerned with setting up the back office processes and rule driven workflow. Activities in this phase will include:
- Identifying opportunities to fully automate processes that will fundamentally change, for the better, the efficiency of the specific process and therefore contribute to your organisation’s ability to transform
- Supporting the business in setting up automated workflow and ensuring that your users are able to manage and modify these processes once the initial implementation project is complete
- Enabling users to be able to create automated processes and rules from scratch using the system
3. Custom development
In any project there is likely to be some requirement for product customisation to ensure that the product delivered meets your specific requirements. This should be considered early in the project, so we can decide together whether custom development is appropriate.
Before we embark upon any custom development we’ll work with you to identify any acceptable (and potentially lower cost) alternatives, such as perhaps using the platform in a different way to achieve the same objectives.
If custom development is needed then this will be delivered by the Abavus development teams in line with a detailed product specification and timelines that we’ll agree with you in advance.
4. Systems testing and user acceptance testing
Once e-forms have been created, back office processes and automated workflow rules configured and any custom development completed then the testing phases can commence. There are two aspects to consider here: systems testing and user acceptance testing.
- Systems testing – Systems testing usually takes place during collaborative workshop sessions between your IT staff and the Abavus team during which end-to-end processes are tested e.g from creation of a service request via an e-form through the entirety of the back office process, including secure data hand off to single or multiple third party systems. Where possible we try and run systems tests all in a room together rather than remotely.
- User acceptance testing – This process works best when it is driven by staff from the service areas that are being affected by the project and who will be the primary users of the solution, however we can certainly provide support during the user acceptance testing process. The focus should be on testing whether the processes that have been built are working as they should. It’s really important to resist the temptation to start redesigning the business processes at this stage. That’s why it’s so important to involve users in the process design phase rather than introducing them to the processes for the first time at the user acceptance testing phase.
We will work with you to set appropriate testing acceptance criteria and the documenting of stage gate acceptance criteria. Financial settlement for some elements of the contract is often linked to successful completion of systems testing and UAT testing.
5. User training
As the project nears completion we’ll conduct a training needs analysis. We’ll talk to representatives from the relevant service areas of the business in order to discuss their requirements and to create a training plan that ensures that the appropriate staff receive training, at the right time and in a way that is relevant to their daily activities and responsibilities.
6. Go live and post go live support
Towards the end of the project we’ll discuss with you the best time to go live with the new solution. On a practical level, we recommend going live at the beginning of the week when key staff are returning from the weekend break or during peak annual leave periods – a mid-week go live date is generally better. We also advise you not to choose a go live time during a period of of peak demand e.g. don’t launch a new revenues and benefits process in the middle of a high volume billing cycle. Select a lower risk launch date.
We also recommend arranging a ‘soft’ go live which takes place before the official go live date. A soft go live gives customers, staff and other users reassurance that the new solution can be used effectively but without the pressure of a high profile, high volume launch.
During a go live process the Abavus project team are available through out to respond to any ‘snags’ or problems. We’ll work with you to create an effective ‘cutover’ plan which outlines the steps needed to move processes from their legacy state to the new solution and from the non-production, testing environments into the production environments.
We will also agree with you a post go live plan with a critical response period included. This means that the standard support level agreement (SLA) does not apply; instead there will be an elevated SLA with heightened response time during this phase of a project, which could run for up to 30 days following the go live date.