GET WHAT YOU WANT
So, tell me what you want, what you really, really want …
Pinnacle has worked on hundreds of projects in legal, helping firms to make the most of their business applications. So, I speak with some experience when I say that, in spite of all the procurement procedures and MoSCoW lists (a prioritisation method) used during selection, all clients were underprepared to implement. They were unable to articulate their requirements, especially subtle elements such as “in this situation, it must do this, except when …”.
After selling their software, most vendors have a relatively simple process – design, build and test, and then deploy/go live. When it comes to design, they assume that the client can quickly provide their requirements.
If it’s evident in the sales process or at project kick-off that this is not the case, vendors will never say: “You’re not ready. Go gather your requirements.” Both client and vendor just want to launch into implementation. The clock is ticking; the client wants to realise the benefits of the investment and the vendor wants to schedule resources and execute deliverables. As a result, requirements can be inadequately documented – sometimes never signed off. That inevitably leads to problems down the line.
Detailed requirements are independent of the software: they are simply requirements. Some won’t be met by the chosen technology – some are not even technology related. However, it’s possible to articulate them before the final product selection
The point is that detailed requirements are independent of the software: they are simply requirements. Some won’t be met by the chosen technology – some are not even technology-related. However, it’s possible to articulate them before the final product selection is made – and it’s a task that requires experienced business analysts, not selection consultants.
Some advantages to articulating detailed requirements early on are:
• Implementation gets underway quicker: there’s both less design time and less consulting.
• Development involves less reworking and fewer change requests.
• Firms can test the design against the requirements. This bakes in quality.
• Firms can know which requirements will and won’t be met.
• Testers will know the requirements, rather than testing against a design that might not meet requirements.
• Often, the detailed requirements will illustrate that a percentage of the requirements could be delivered today – using the current toolset.
• Issues with data and firm policies will be highlighted earlier and remedied quicker.
I’m not saying that firms should delay the purchase of the software, but that, while procurement is underway, firms should gather and document the detailed requirements. It will cut cost and increase certainty around delivering the project.
To illustrate this point, let’s look at two recent Pinnacle engagements.
In the first, a client had a preferred supplier in mind, but didn’t procure the solution until we’d helped them workshop their requirements – invariably the optimum approach.
In the second, a firm had already procured software and cracked on with swathes of ultimately abortive solution design workshops. To get it back on track, we worked with the firm to shape and capture its detailed requirements, articulating them in a coherent way before they were given to the vendor’s implementation team. This was less than optimum, but it had many of the same positive outcomes. Testing proved easier, useful changes were made to current systems and working practices, and the firm realised immediate business benefits rather than deferring them until the new solution had been implemented.
This article can be found in Briefing’s October edition: Buying signals
