Position of full study

Although the slide shows the full study starting after project initiation, in reality there is an overlap. Often in ones I've helped initiate, a quick scoping and sizing exercise is carried out as part of building the business case.

(The business case is used to approach the board for project funds. Not quite a feasibility study, these exercises tend, by their very nature, to only need a high-level DFM, together with a quick and dirty impact analysis covering some or all of: customer, products, processes, organisation, location, data, applications and architecture. The impact analysis also includes volumetrics and degree of impact.)

Ideally a feasibility study will have been completed prior to the full study. This will give the assigned business analyst(s) a head start. The key products of DFM, LDM and Requirements Catalogue will be present - albeit to a high level. And importantly the User Catalogue, list of stakeholders and authorisers of the original study report will be documented, too.

Depending on how long ago the feasibility study was completed, these products will need to be re-assessed at the project's inception. You'd need to factor in the rate of business change prevalent in the environment in which the need exists, to guide how deep that assessment should be.

The result of the Full Study is some form of business requirement specification document. This has to be fit for purpose to hand over to a supplier. Remember, in this briefing, the arrangement with the supplier is (as stated on the first slide) that they are responsible for the part of the lifecycle from conceptual, functional and physical design, through code, build and test, to delivery for UAT by the business.

If being used as part of an Invitation To Tender document set, the business requirement specification should pretty much be fit for purpose as long as all the products of the Full Study are included. Of course, during assembly make sure that any particularly commercially sensitive material is kept out, even if there is a non-disclosure agreement in place with the suppliers. Confirm with senior business representatives.

Where exactly does the supplier get involved in the lifecycle?

Well, a high level Impact Assessment will come back after feasibility and before full study, as a response to an ITT. Where there is an existing contract with a particular suppler in place the high level IA will have been used to help inform Business System Options, prior to selection and publication of the Feasibility Report.

Where the ITT route is being followed, once a tender has been selected and the supplier chosen, the Full Study is entered with the IA. Following this route, it is possible that another round of BSOs or TSOs is needed with the business as a result of the IA.

Once the full study is properly entered and the detailed requirements are being elicited, the supplier is best involved as the requirements are being firmed up. This gives them early exposure which is always a good idea.

The supplier really starts to lead as you get properly into logical system design. They would be responsible, for example, for the rest of Dialogue Design, after the business has identified the critical dialogues (see later slide) and for things such as leading RAD or JAD workshops. In these last two, a business analyst should always facilitate / chair, to help keep things restrained and within scope. But remember, always to stress at such sessions that until something is in the signed-off requirements spec, agreement about requirements reached at such workshops have no contractual significance.

The reason for a supplier to take the lead during logical design is that so much of this stage is seen by suppliers as being constrained by their in-house approach, methods and by the platforms on which they are prepared to build / support systems. Another crucial reason is that the detailed requirements specification is best done by their "systems analysts". Why crucial? Because it gives them the direct contact with the key business users and the time to build good relationships with them that will carry them all the way through their design, code, build, test and interaction with UAT. It also gives the opportunity for knowledge transfer into the supplier at an early opportunity, helping de-risk the project. Finally, the supplier side can achieve a much deeper and more accurate understanding of the requirements.

Where does that leave the organisation's business analyst base? Where it belongs, focused on the business and helping get solutions delivered that meet the need, and not becoming immersed and embroiled in detail that detracts from this. It takes a bear of tremendous brain to be able to perform well at both ends of the spectrum and, as Winnie-the-Pooh knows, there aren't that many such bears around!