Briefing Study: Requirements Analysis and Specification (slide 4)
Position of Feasibility Study
So, here's the thing. A situation arises that needs addressing. It may be a legislative or regulatory change, a change in the commercial environment in which a business operates, it may be a response to a loss in market share or market research that spots a technology advantage to be gained.
Whatever the reason, at some point detailed work is needed to assess the feasibility and possible directions of a solution to meet the need. A project will need to be started (posh word: incepted) to manage and control that work.
If there's not full backing, if it's risky / costly then it nearly always makes sense to conduct a feasibilty study first. It delivers the advantages of an early view of the business benefits, cost estimates, business impact and the technical feasibility of meeting the requirements.
It also gives an outline scope, size and complexity of the following deeper study, which makes project planning much easier if it makes it that far.
The Feasibility Study will produce a report as its output, with its position as shown in the slide. It'll either be followed by a full study or, if the risks / benefits don't stack up, it might not go any further.
You'll probably find a quick summary of its content and the steps to get there quite helpful at this stage. It's useful to note that if a full study does go ahead, the work of the feasibility study isn't wasted as most of it can be reused and fleshed out in the full study.
The first thing the business analyst will do is to write a terms of reference paper. In summary, this outlines the reasons for the doing the work, the key stakeholders, the expected benefits. It includes the scope of the work, supported by a high level As-is process model (dataflow diagrams supported by descriptions of the processes modelled in it).
Next, a paper is prepared using the technique of Business System Options, covering various possible ways of automating the required system (what's to be in scope, what's to be manual and what is to be automated).
For each option considered, the following are ususally prepared:
- High level datalow model (DFM)
- High level logical data model (LDM)
- Internal impact analysis
- Outline project plan
The project board, together with heavy representation by senior business management, then selects one of the developed options for taking forward. They are guided in their decision on the recommendation made by the project team and business users and, taken together with their unique perspective on policy, direction and their appetite for risk, they make their choice.
The Feasibility Report is then constructed to record the project board's decisions and the basis for them. In particular it'll give reasons for the selection of the chosen option and for rejection of the unselected options. The supporting material for the chosen option is included with the report, particularly the DFM, the LDM and the high level plans, and will usually out-refer to the material for the unselected options.
Of course, it's never quite as straightforward as that; often the project board will select a main option with features from others included. Deal with it during the next step.
The selected option (or the combination) is then used to update the various products / models, ready to feed into a full study phase or Project Initiation (if one has not already been incepted). They will set the scope, the high-level requirements (and some detailed ones) and inform the preparation of activity and project plans for the fuller study.
Once this is done, there is the possibility of involving potential supplier(s). If there is a perceived tight timescale, then involvement of suppliers at this stage can help to shorten the final project duration. It gives them a chance to familiarise themselves with the project while they are doing their work to provide a high level impact analysis and indicative costs.
Any technical options that result can usually be considered and decisions taken, as part of the normal project progression. In real life, the impact analysis may warrant project board involvement if anything exceptional turns up.
Notes on Supplier access to business representatives
The supplier will often want access to the business to understand the requirements better and perhaps to try to drive out more detailed ones.
Obviously they want to provide an accurate impact analysis / response to the requirements and they will be loathe to be too imprecise. But only allow it if you or another of your BA colleagues are there, either to participate or facilitate / chair.
Be very clear about what it means when business representatives at these sessions agree new requirements or refine existing ones; each requirement has to be a business one and not phrased in "solution speak". This is because there are all sorts of hidden meanings or knock-ons that the different parties would otherwise take away from the session - and these will often be at odds with each other.
Manage each supplier's expectations at this stage by agreeing with them that only the requirements that feature in the official Business Requirement Specification form the basis for formal agreement and anything agreed earlier is to be taken as indicative only.
Stress this again in front of the users and supplier representatives at each and every such session. It will save everyone grief later on, caused by misunderstandings now.
The softer skills of a business analyst include making sure that people don't get ahead of themselves and start making assumptions about any outcomes.
When you influence them to stop short of this and make them aware of other possible outcomes, you're 'managing their expectations'.
Who are these people?
Well, basically anyone you come across in your role as a business analyst. Here's some groups:
- business and supplier representatives
- business and systems architects
- solutioning teams
What sorts of expectations?
Here's some examples:
In sessions with key stakeholders
You have to be really watchful here. Look out for any evidence of unrealstic expectations - maybe they expect a rolls-royce solution that will solve all their problems or they perhaps believe that their requirements will have the highest priority and all be automated.
Manage their expectations by explaining that you'll ensure that, with their help, every requirement will be assessed correctly by balancing costs against business benefits.
You might also like to mention that some requirements might be better met by a manual solution. For example, if some communications have to be really secure between the business and a customer, maybe a courier service would be a better option than a riskier electronic route?
In requirements workshops
Business reps might make it clear they're assuming a certain solution - stress that nothing's decided yet. When the full extent of the requirements are known there may be a better one.
When you do this, you also avoid the danger of requirements not being voiced because they know their assumed soloution can't do it.
In project meetings
These sorts of meetings usually include key people from all the teams that make up the project.
Prior to requirements sign-off, you really need to have your feelers out at these meetings. You'll be watching for any assumptions being made within the teams about the solutions, the level of automation, assumed requirements and so on.
When you spot them, explain that nothing's cast in stone yet, so it's dangerous and potentially dangeorus to make any assumptions. If true constraints are uncovered these will need to be taken back to the business for impact and whether it's acceptable for the project to be so constrained.