Company logo of Crocus Information LtdCrocus Information Ltd

Business Requirements Analysis consultancy to blue chip companies

Briefing Study: Requirements Analysis and Specification (slide 17)

rass, supplier designs, builds s17 - using the Business System Options technique

this briefing study's slide map | previous | next

Using the Business System Options technique

Once the current system is documented and the requirements of the new are understood, there are usually a range of different ways that the requirements can be met, variations in the extent and shape of the area that is to be provided with automated support and the area that is to remain as manual.

This includes a possible range of technical options as well - things like the following may need to be considered: operating system version, web or traditional client /server, web-services, thin/thick client, content management system, call centre telephony integration, customer relationship management system, pdas / handhelds, mobiles.

Each overall option considered will result in full or partial fulfilment of the high level requirements. For those still covered, a new DFM and LDM is often needed to show the area in scope for this option, the requirements covered and the elements impacted by the option.

Depending on size and complexity of the business need, at least three options for moving forward are developed. Of course, the users help and guide their development for the to-be system, with you as a guide and scribe. Together you will build a definition of each option, with supporting material that will allow its assessment.

This will usually consist of a summary of the option and a financial appraisal and cost benefit analysis. It will usually be supported by a high-level DFM and LDM to show the scope of automation, and both a business and technical impact analysis. Finally you will need, still in conjunction with the users, to develop a set of risks and assumptions and a high-level plan for taking that option forward to delivery.

Business Systems Options are developed during Feasibility Study and Requirements Analysis.

The usual route is:

Business: Feasibility Study -> BSOs -> Selected BSO -> Feasibility Report -> Supplier: Bid / Impact Assessment -> Business: Requirements Analysis -> BSOs -> Supplier: Bid / Impact Assessment -> Business: Selected BSO -> Requirements Specification.

Go to Top
exercises on modelling process and data

Best Practice...

Golden Rule 12

I will treat everyone equally and with respect, regardless of age, religion, seniority or gender

When people at the coal face (whether in the supplier or business community) see that you treat them with the same respect as you do their bosses, you'll earn their trust.

When senior business representatives and stakeholders see how you treat the people in their teams, it will enhance your reputation with them.

A not so short anecdote

Back in 2006/7 the two UK Government departments, the Inland Revenue and Customs & Excise were being merged into one unified department, HMRC.

Pretty much the entire UK Treasury's cash flow on a daily basis flowed in via the two departments (one in Southend on the south east coast and the other in Shipley, West Yorkshire). The Inland Revenue received PAYE and company tax paymemts in the main while the Customs and Excise main cash inflow came from VAT payments.

Most payments arrived on cheques and both departments had a huge inward paymemts system supported by production lines of automated letter opening, sorting, batching and scanning machines. Manual payment checking stations galore, all sorts of exception processes and manual handling processes for excuse letters partial payments, specific circumstances etc. etc.

And both departments had their own unique blend of processing for situations specific to their department.

I was the BA for the project that was to merge both sites into one, with one set of updated machinery to handle everything. Manual processing of some exceptions still had to go to specialist teams.

During initial meetings and introductions as I was preparing the Terms of Reference, it became obvious that the number of civil servants that were going to be affected was potentially huge and that rumours were rampant leading to nervousness, worry and speculation amongst the few thousand that were affected.

Although union representation wasn't amongst the intial list of stakeholders, I put a case to the project board of involving them right from the outset.

As a result, a senior stakeholder from the largest union was invited to join the project board, with a remit to represent the other, smaller unions as well and to provide a communication plan for members.

I made sure that a number of business requirements were recorded about minimising impact on people's jobs, communicating intentions, plans and progress regularly, taking into account people's personal circumstances, offering, where possible, relocation or retraining and so on.

It was genuinely pleasing to have the unions working in harmony with the project team. Even better was to get feedback from people at the coal face that they felt included. They thought a good job was being done about removing uncertainty and that the right sorts of support were being provided during change.

Forget the emotional and morally just aspects of the above for now. What did this do for the project? The gains were many:

  • No strikes, working to rule, closures or other disruptions
  • Everyone from the business that I had to workshop with or meet one-to-one, cooperated fully and with the 'all pulling together' mentality that is so effective in our line of work.
  • There was no backlash in the media about job-losses or poor treatment of staff during the merge
  • The quality and completeness of the business requirements were better than they would have been otherwise
  • The project was de-risked, safeguarding milestones and budgets

Overall, potential threats to the UK treasury's cash flow that could otherwise have arisen were minimised.