Rapid productionising – a more flexible approach to requirements gathering
Have we reached a tipping point with traditional approaches to requirements gathering? Has the acceleration of business cycles and emergence of Software as a Service (Saas) and Cloud services changed the game to a point where traditional approaches to gathering business requirements to build solutions been rendered ineffective? We’re in an environment where rapidly productionising a solution should become a key approach.
There are many techniques that can be used to gather business requirements for technology solutions but no matter what the specific technique chosen, the traditional approaches involve these basic steps:
Step 1: Identify a broad need
Step 2: Get some initial funding for requirements gathering
Step 3: Identify stakeholders
Step 4: Engage stakeholders to get their feedback on what’s needed
Step 5: Prototype solution
Step 6: Re-engage stakeholders to obtain reaction from prototype
Step 7: Write up requirements, socialize them once more to obtain signoff
Step 8: Business case and funding stage
Step 9: Go build something based on the requirements
Step 10: Deploy the solution in a production environment and hope to realise benefits
These broad steps have worked well in times where the business cycles are reasonably static but the longer the project, the more likely the business requirements will change. Thus, the validity of business requirements diminishes with time.
As colleague PEG discusses in his post Why we can’t keep up, we’re not a in a period where business cycles are reasonably static. We’re in a period where business cycles are increasing at a rapid rate. Business opportunities are appearing and disappearing in ever more shortening timeframes. In these circumstances, we’re seeing the period of validity of business requirements continuing to reduce.
Validity of requirements diminishes with time as business needs change
A common technique to mitigate this situation is to continuously engage the business stakeholders but the main problem with this approach is the difficulties of controlling scope and budget. The industry has made a number of other attempts to address this situation with approaches such as Rapid Application Development (RAD), Joint Application Development (JAD), Agile etc. and these types of approaches have their pros and cons as well.
The case for Rapid Productionising
We don’t have to design the perfect system and have a perfect business case before we start a project any more. It’s never been easier to quickly build and deploy a system if you start with the mindset that we should do something and deploy quickly to derive business value and evolve the solution from there based on live feedback from the customer. We’re moving to a mindset of Rapid Productionising.
The Rapid Productionising approach
What is making this possible?
There are three key factors coming together at the same time to make this approach possible. Firstly, infrastructure and related services can be provisioned and brought online very quickly and turned off when I don’t need them anymore. Secondly, the rapid growth in SaaS offerings means that I can rollout substantial capability across a wide category of services to stakeholders in days / weeks compared to them waiting months / years in the past. Thirdly, it’s never been cheaper or easier to quickly develop and deploy some custom software as needed to test an idea.
The evolving landscape
One of the axioms in gathering business requirements has been: how can the stakeholders tell you what they want when they don’t know what’s possible? The technology and business cycle landscape is moving so rapidly down a service-based path that we don’t even have to show them any more. Instead of showing them a picture of what night be, why not give the stakeholders something to touch, play with, use and actually use to derive value. The approach doesn’t need to be perfect from day one. Do something, attempt to solve a key piece of a larger problem, rapidly productionise it and evolve it over time.
This approach gives better value to prospective users who can have an interactive involvement with a prototype in order for them to thrash out clearly articulated business requirements.
However, many consulting firms have built service lines on the traditional systems selection approach where it
can take up to 9-12 months to select a system that only delivers 70% of the user requirements that may evolve with time. I have not come across any consulting firm that uses free software/Saas/Cloud to articulate business requirements as clients may not want to pay premium rates to the consulting firms and then later on to the vendor to develop something similar.
The reality is that times are a changing whether the consulting firms like it or not. Many are struggling with identifying meaningful value propositions to their customers to justify their traditional revenue streams.