"We have the solution, what's the problem?" That questioning statement pretty much sums up what technology vendors are saying to their customers. From the vendors' perspective, it may seem to be a compelling mantra in their pitch to the market. But for IT project managers (PMs) and business analysts (BAs), it's a potentially poisoned chalice that induces the increasingly addictive and damaging symptoms of 'solution dependency'.
And it's easy to become addicted and damaged. The very term 'solutions provider' is surely a strong intoxicant, with its alluring promise of solving business challenges with technology. The reason why mature PMs and BAs avoid becoming dependent is because they recognise their challenges are business challenges as opposed to solutions challenges. In other words, they want technology configured to satisfy business requirements rather than configuring the requirements to provide a technology-based fix.
Business requirements and system requirements are two very different animals.
Business analysis is not systems analysis and the detailed requirements the two functions produce are quite different. In a nutshell, business requirements define what business must achieve, while systems requirements define what the IT solution will provide so that business can achieve its objectives.
Divide and conquer
To avoid solution dependency, it's vital that the requirements produced by BAs are clearly distinct from those produced by systems analysts (SAs). If the two roles are not separated, there is a danger that they will interbreed. The typical consequence of this unnatural union is that systems analysis emerges as the dominant gene. After all, the gene is essentially produced and nurtured by the considerable strengths and influence of solutions providers and the relationships they cultivate with IT departments.
By comparison, other than confidence in their own professional integrity and abilities, BAs often lack that sort of heavyweight, constantly in-your-face support. Unless, of course, they are 100% backed at an executive level by a commitment to ensuring that business requirements are routinely prioritised above system requirements. Without that calibre of support, it can be extremely difficult for BAs to prevent a project from being driven by solutions, rather than by the challenges the solutions must address.
The damaging consequence of allowing a project to become solution-dependent is that companies end up with the proverbial mega-buck hammer instead of the screwdriver they actually wanted and budgeted for.
Prioritising business requirements
"We have a problem, what's the solution?" Simply by switching the statement around, companies can avoid solution dependency and the enormous damage it can cause. They can put the horse back in front of the cart, which is obviously where the horse belongs.
It's the task of BAs - not systems analysts - to discover the exact nature of the problem before any potential solutions are either examined or proposed. A detailed understanding of the problem is then translated into a set of business requirements - not system requirements - that clearly describe what the business needs and the reasons why.
Business requirements and system requirements are two very different animals.
It is only once a comprehensive set of requirements has been produced - and ratified by business as truly reflecting their needs - that the interaction between BAs and SAs can begin. By creating an accurate and detailed set of requirements, the BA is in effect providing a briefing document or blueprint for the SAs. This empowers SAs to suggest potential solutions that will precisely comply with the business requirements.
Business requirements are therefore not only a high level, generalised description of what is needed; to function as a practical blueprint for SAs, they also need to be detailed. And it's the BA's task to produce sufficient detail according to what is referred to as 'the correct level of abstraction'. The process of abstraction provides the right amount of detail - not too much so the SAs are swamped; and not too little that they don't know exactly what is required and head off down the wrong path.
In industrial design and modernist architecture, there is a concept that "form must follow function". This emphasises that the way something is designed must be based on serving its intended function or purpose. In IT-based projects where software development is a core activity, 'function' can be regarded as the business process which is assisted by 'form' - the systems architecture.
Solution dependency repeatedly and inevitably occurs when 'form' dictates how the business will 'function'. A simple rule of thumb to prevent that happening is to ensure business requirements always come first and systems requirements always come second.
If solutions must be 'fit for purpose', then the key question is what purpose?
The idea of an IT solution being fit for purpose has no value unless there is firstly a clear understanding of the purpose - and that means the business purpose as defined by the business requirements.
If those requirements have been abstracted into sufficiently small components then there is the potential for project managers to adopt an 'Agile' approach to their development and delivery. And the elephant that needs to be eaten can be served in bite-size chunks.
To coin a phrase, a 'purpose-oriented' approach means that - based on each requirement - the following activity-sequence can be deployed: develop, test, sign-off, and deliver. It can then be repeated as necessary until all the working components are combined to produce the solution required by business. On time, on budget, and on spec.
Share