As one of the founders of Solarvista Software, a leading UK-based developer of field service management software, I’ve been involved in hundreds of service management software implementation projects, large and small, complex and simple. These implementations are usually shaped as a result of the pre-sale procurement process with the “RFP” or Request for Proposal being at the heart of the “definition”. When software was purchased “the old way”, i.e., with large commitments (the “license fee” and let’s face it, “heavy contracts”) in advance, this made perfect sense. The customer wanted to know what they were getting and be sure of it. Of course, a completely understandable position. These RFP documents are usually a collection of individual requirements, gathered from submissions made by multiple individuals within the organisation.
And this is where the problem starts. Most individuals working in field service organisations are not used to defining functional and non-functional requirements. They are experts in their industries… but not, understandably, IT systems. And the result is usually “over scope” (asking for functions that aren’t really needed) or “under scope” (not asking for functions that are really needed). It gets worse. The way in which a requirement is described in words, can often mean something very different to another reader/person approaching it from a different perspective.
We often receive RFPs with hundreds and hundreds of requirements. And we are asked to respond with a compliance statement; often within a short timeframe (the customer already being under time pressure due to the requirement gathering phase being harder than first thought!). Of course, our personnel respond as they see fit. Some single line requirements are easy to understand. Some are topics in their own right. It’s very easy for us to, at worst, mislead the customer and at best mislead ourselves.
The revolution provided by Software-as-a-Service doesn’t just stop at “the software itself”.
At Solarvista, following software industry trends, we adopted an Agile Methodology to software development. This methodology prescribes the mantra that “you don’t plan upfront because you will likely get it wrong”. It is certainly delivering significant benefits for us in getting often risky technical research and development to produce results in the shortest possible time.
Which led us to think about software implementations…
If we could apply the same methodology to customer implementation projects, we should be able to harness the same benefits. We knew this because in analysing results of the RFP-driven projects in the past, we knew that most projects asked for (and of course we ‘costed’ in) about 15-30% of functional requirements that were simply never used. Worse, another 15-30% of “definitely needed but forgotten about up front” functional requirements were added in later. These would often extend a project and incur additional costs.
It is time to move to Agile Projects.
In any project, there are three aspects that affect the timeline and therefore cost; Resource, Scope and Quality.
Quality cannot be varied but Scope and Resource can be fixed with the right approach.
With Agile Projects, we define the project timeline and the project budget. Yes, that means they are fixed. In other words, and “on time, in-budget project” is a must have, which is so important to all stakeholders. To do this, we adjust scope by a ruthless focus upon actual need. This isn’t easy. But it’s easier to do when the thinking is not done upfront. In our case, we prescribe 2-4 weeks “sprints” where deep, low-level thinking is done within the remit of the objectives of the sprint. Everything is challenged and nothing that isn’t truly absolutely utterly mandatory is implemented.
It’s the perfect companion to Software-as-a-Service because it enables softer engagement between customer and vendor. It means that as a customer, you can “prove as you go”. The old adversarial procurement relationships are tired and not productive.
The results? Well, it’s early days yet but we think we can eliminate 20-40% of costs from any given project. Not all our customers can handle Agile Projects. The old ways are generally too entrenched, especially with professional seasoned procurement people. This year, we will have completed several Agile Projects and I look forward to updating you with the outcomes soon.
"Everything is challenged and nothing that isn’t truly absolutely utterly mandatory is implemented."
Paul Adams
Emma James : Mar 21, 2018 2:19:45 PM
