location: home->briefing studies->requirements analysis & specification

a crocus information Briefing Study - Page updated 12 Jan 2007

position-of-feasibility-study.jpg
position of feasibility study
| bookmark | |
Index page [<< First] [< Previous] [Next >] [Last >>]
slide 4 of 25

Position of Feasibility Study

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 incepted to manage and control that work.

A feasibility study will often precede a full study. It delivers the benefits of an early view of the business and technical feasibility of meeting the requirements, and the scope, size and complexity of the following deeper study.

The Feasibility Study will produce as output a report as shown. You'll probably find a quick summary of its content and the steps to get there quite helpful at this stage.

First, a paper is prepared using the technique of Business System Options, covering various possible options for automating the required system (what's to be in scope, manual and automated). The costs, benefits, risks, high level DFM and LDM, internal impact analysis and outline project plan are all usually prepared for each option.

The project board, 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 be constructed to record the projects 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 outrefer 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 a potential supplier(s). If there is a perceived tight timescale, then involvement of suppliers at this stage can only 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, which should include 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.

NB 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 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 the meaning is of a user agreeing the sorts of requirements that will come out of these sessions.

Unless the requirement is truly a business one and not phrased in "solution speak" there are all sorts of hidden meanings or knock-ons that the different parties will 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.

Google
| bookmark | |
Index page [<< First] [< Previous] [Next >] [Last >>]
slide 4 of 25
bright-idea Related information from sponsors:

| Home | Privacy | Diagramming Notation Explained | Analysis Example Documents |
| Business Analysis CV | ACME Fashion Supplies Feasibility Study |