Delivering Project Success to Customers – A Step by Step Approach

The Ascertus Change Management in Digital Transformation Blog Series

It’s not good enough to merely implement technology successfully. The real test of success for a system lies in the tangible value it delivers to the business, which in turn depends on the technology’s user adoption levels.

For users to willingly and earnestly adopt a new system, the solution must be intuitive, user friendly and easy to use. It must integrate into their day to day workflow and most importantly, take away the grunt work so that they can focus on the key activities that abet the organisation’s business. Additionally, the system must be a step ahead of their current requirements – so that as users’ requirements evolve, the technology is already equipped to deliver.

To deliver against all of this, a lot of work needs to be undertaken, at both the back and front end. In this blog series, I’ll walk you through the key components – including everything from discovery through to change management and training – that will deliver project success.

Deep Discovery
This foundational phase is the most critical. It’s at this stage that the team gains an understanding of how people currently work in the organisation, what problems they face, and what they need in their new system. The technical team maps out configuration options, undertakes infrastructure health checks to determine current and future risks, technology requirements and more. Driving and underpinning all this discovery must be the project objective of delivering the best possible end user experience. Far too often, as project teams capture the business and technical needs, the end user experience requirements get lost, which can significantly impact user adoption and hence project success.

Here are some top considerations when embarking on this phase:

• Don’t assume: Don’t assume that you know how people currently work and collaborate, or the impact the change will have in the organisation. Even a slightly wrong assumption can have a negative impact on the project. Make decisions based on evidence. For instance, project teams often cluster users into groups – managers, lawyers, support staff and so on – and presume that everyone in the respective groups work in a similar manner. The reality is that every individual has a personal style of working. One fee earner may delegate most tasks to team members, while another may be entirely self-sufficient. Use Discovery to create an accurate picture of end user personas that cuts across role-based assumptions.

• Think outside the box: This goes beyond technical integrations – think about people, behaviour and collaboration. For example, the role of some users requires them to regularly download or share large volumes of documents or create reports. Determine how these processes will be impacted by the change and how it can be made more efficient. If it’s currently a labour-intensive process, are there additional software solutions that could be integrated with the new system to better streamline the activity? This is a good time to look for opportunities for improvement, even if they fall outside the main scope of the project.

• Don’t start with ‘why’ – what, who, when, where and how must precede: Starting a conversation with a ‘why’ during the discovery phase, especially with users, means that you’re really asking them to justify what they want or how they work. This limits the scope for objective analysis. User discovery must focus on behaviour, motivation and context. What tasks do you perform? Who for/with? When and where do you do this? How? In essence, understand the ‘why’ by asking ‘what’, ‘who’, ‘when’, ‘where’ and so on.

• Group and prioritise pain: Map and group user behaviour and pain points in a structured way. Patterns will emerge that will enable you to find technical solutions and/or, develop new processes. You may even find that the solution to some user pain points merely lie in education, and so are easily resolved. For example, the user may not be aware that there is a more efficient way of working. Recently, at a client site it became apparent that many users were struggling to efficiently navigate between the numerous applications and documents open on their PC. This was a major pain point that was outside of the project scope, but only emerged during Discovery. It was easily fixed with information and user training.

• Define and measure success: What does project success look like to the organisation and employees? The discovery process should help you define the success factors, of course, but also determine how you know when success has been achieved. Success factors, measurement criteria, methods and milestones should all be defined with clear quantifiable metrics for each criterion. Data trumps perception. To illustrate, if you’re introducing a document management system, measure print volumes (great for demonstrating cost savings), support calls, the number of documents and emails saved, mailbox sizes, the number of versions created, and such – before and after the new solution’s implementation. These metrics can act as a barometer for success.

This approach will ensure engagement with users right from the start, greatly facilitating a positive mindset towards change. Users will appreciate the business reasons for the new project as well as understand how the solution will help them achieve their individual goals and targets. The technical team will be able to ensure that the system configuration accurately reflects the needs of the users and the business. All round, all the stakeholders will have confidence in the new project.