A voyage of discovery
The benefits of digital transformation have been well and truly realised – and at the highest levels too. According to a recent Nimbus Ninety report, 88% of organisations are digitally transforming, and in 60% of those transformations the CEO is a key stakeholder.
However, the road to digital transformation often entails large development projects, as organisations look to upgrade legacy systems and introduce new platforms in order to become more digitally-focused. And while the CEO and other senior stakeholders may be bought in to the concept of digital transformation, securing sign-off (and budget) can still be difficult.
Here, we’ll look at how an initial discovery phase makes it easier for your stakeholders to say yes to digital plans – giving you the green light to move forward and start driving results for your business.
There goes the fear
It can be frustrating when people aren’t as quick to buy in to a project as you – especially if they’re the ones in control of the purse strings – but it is understandable. Overhauling a technology platform or developing a new piece of software is a huge undertaking, and senior stakeholders may be reluctant to step into what to them is the unknown. There’s not just the impact on budgets to consider, but also on dependencies, processes and organisational culture. This is compounded by the rapid pace of technological change we’re currently experiencing – something that 58% of CEOs cite as a challenge in the latest PwC CEO survey.
It’s your job, then, to help these stakeholders understand what a project’s going to involve and the expected outcomes, as well as reassure them that it’s the right decision for both your business and your users, and that potential risks have been assessed and mitigated.
That’s exactly what discovery activities are designed to deliver. Focused on getting to the bottom of your goals and objectives, and providing a clearly-defined solution, this phase gives you a valuable head-start going into development – and helps encourage others to get on board, too.
Get the picture: requirements gathering
Taking the time to gather requirements at the start of a project is something of a no-brainer. It’s pretty difficult to embark on development without knowing what you want, after all. This can be easier than it sounds, though, as different groups bring their own aims and expectations to the table, and in some cases these can be difficult to resolve or even articulate effectively.
The support provided here by consultants experienced in discovery activities can prove invaluable – enabling insight from internal stakeholders and end-users to be translated into clear and concise requirements and user stories. These user stories can be employed in a whole host of ways, from providing clear, prioritised objectives against which to measure success to helping foster a shared project vision.
Importantly for our purposes, these prioritised requirements can also be used by technical specialists to identify the most effective solution based on what’s really important to you, and provide a more accurate idea of the likely cost, timescales and effort required to deliver it. Jaguar Land Rover, for example, was able to make an informed decision about the future direction of vital diagnostics software following a research and evaluation project to understand the implications of different development approaches (full disclosure: this was a Box UK project, and you can read more about it here).
Following this phase, then, you’ll understand exactly what you’re getting into before committing significant investment and, what’s more, you’ll know that the proposed solution has been objectively validated by technical experts. And that makes it much easier to justify to senior stakeholders.
Look before you leap: prototyping
Technical input is vital to provide senior stakeholders with confidence in the early stages of a project. But there’s another element that should be addressed at outset, and that’s your users. Your requirements gathering activities should ensure that their needs and expectations have already been taken into account, but you can take it even further in your discovery phase, to confirm that specific concepts and designs work in practice before you go too far down any single path.
This is achieved with representations of your site, system or application that can be tested against user objectives, with any findings informing the refinements you’ll make when it comes to the build itself. These initial assets can be as rough-and-ready or as detailed as you like, from early sketches and interactive wireframes to working prototypes that can be navigated through and interacted with as you would in reality.
To take another Box UK project as an example, when the Royal College of Nursing undertook a comprehensive rebuild of their digital platform, they wanted to be sure it served the needs of their 425,000-strong membership base. Consequently, once we had built up an understanding of requirements, we produced prototypes to demonstrate how critical areas of the site would look. These were demonstrated to senior stakeholders and end-users alike – helping the project team gain the support they needed to proceed with such an important transformation project.
All systems go
Discovery activities are a great way to make sure requirements from all areas of your organisation are addressed in any proposed software solution, and enable you to ‘fail early’ in the prototyping phase before committing significant budget to development. So, if you’re struggling to get started with a large and/or business critical development project, take the time for discovery.
Learn more about requirements gathering by reading our series of blog posts on the subject.
