We’re all guilty of sometimes hearing what we want to hear – but when it’s a client, is it their fault or ours? Now there’s not a lot you can do to change how other people interpret information, so let’s assume the onus is on us to make sure this doesn’t occur.

We need to be crystal clear in our communications and have a something in writing to back us up, such as a Terms of Reference (TOR), Scope Document, Statement of Work or Requirements Specification – one of the essential deliverables of the requirements investigation phase of a project.

However, the title of the document isn’t as important as what’s in it – and who signs it off. In terms of content, typical headings will cover:

• Business problem/opportunity – This is the first thing a business manager will read so it needs to be relevant and expressed in business terms. If it’s a problem then what’s it stopping us from doing – what’s the impact on customers, on the organisation and on staff?If it’s an opportunity, what will we be able to do that we can’t do now? Avoid general statements like improved communications between departments as these types of projects are to easily cancelled in tough times. Try to describe opportunity projects in terms of a problem e.g. poor communications between departments is costing us X hours per person per week in performing re-work.
• Customers – Everything starts and ends with the customer, they buy our products which in turn pays out wages. Government departments have customers too – the public and politicians. How will this project impact our customers?
• Project sponsor – Who is sponsoring this project? Every project needs a sponsor – a senior manager who is behind it, who is prepared to back it and, depending upon the business culture, prepared to finance it. Sometimes the sponsor may not have the budget to pay for the project but will have the authority to seek funding from upper management. If in doubt as to who the sponsor is, find out who’s hurting the most then work up from there.
• Objectives – Describe out what the project must achieve. Aim for one or two statements that succinctly and precisely say what is to be achieved. Not how it will be achieved – that’s the solution that you’re going to derive.Be careful not to have too many objectives – you can only shoot an arrow at one target. A good test of whether an objective has been met is to ask if the problem described above has been solved.
• Users – Who will use the new capabilities that the project delivers? The department or teams affected need to be identified.
• Stakeholders – Are there other people, departments, or outside organisations that have an interest in this project? Name them and list their contact details.
• Scope – Set out clearly what is included within the project scope, and what is not. This may include facilities, organisational areas or functions. Use the words ‘this project includes…’ and ‘this project excludes…’. It is a rare project where the scope is fully known at the beginning, you may have to re-visit this paragraph later.
• Constraints – Set out the constraints within which the project must be conducted. The more you have of these, the more difficult your project may be to manage. However, you need to be aware of implied and assumed constraints, as well as the ‘obvious’ ones. Most constraints will be in one of three categories – time, money and functionality(quality) of the end deliverable.
• Justification – Some initial ideas on the likely savings and benefits to be achieved by the project. This information should be sourced from the project sponsor. Explain the impact the problem is having – it needs to be big enough to be worth fixing. Management often request a cost-benefit analysis (CBA) at the TOR stage. Be aware that this is impossible to derive without some idea of a project plan, a likely solution and an implementation plan. In other words, it would be nice to have a CBA but it can’t be done accurately at this stage unless a separate Feasibility and Costing Study has been performed.

Resist the urge to put any dollar figures in this section – otherwise you’re just guessing and will get caught like our friend in the cartoon!

If you enjoyed this article, you may also enjoy these:

Writing Better Requirements

How Clear is your Writing?

How to Deliver a Recommendation

The post How to Manage Client Expectations appeared first on IRM Training.

In the fashion industry, models are used to communicate (to bring to life) a designer’s ideas and creations. But they also go one step further – helping us the consumer to imagine how the clothes might look like if we were wearing them.

Models in business analysis perform a similar role, they stimulate our imagination so that we can analyse problems, explore solutions. The case for modelling is neatly summed up in this quote from the book Business Analysis Techniques: 72 Essential Tools for Success:

Models reveal the inconsistencies, loops, delays and bottlenecks involved in a process. A systematic analysis of “as is” process models provides a business analyst with the opportunity to think analytically and creatively about what the organisation really needs to do to achieve a better “to be” solution.

Modelling is one of those timeless techniques that transcends business analysis and is used in virtually every discipline from Accounting to Zoology – in between there’s engineering, design, construction, research, etc. Incidentally, accountants use modelling techniques to analyse financial data, zoologists use modelling techniques to analyse, amongst other things, animal behaviour.

Just as accountants and engineers have specific modelling techniques which are used across their respective professions, so too business analysis. But this article is not about which technique should you use – there’s plenty to choose from – it’s more about what are you trying to achieve.

So what are we trying to achieve? It boils down to two things. First what’s the problem – what’s wrong with the “as is” system? To get to the bottom of this we need some dialogue with the stakeholder. If the problem is well documented and understood then great – but often as not the stakeholder will only see the problem from a particular perspective. It’s up to the analyst to dig below the surface and find out the real cause.

Here you’ve got two choices, write a step by step description of the process under investigation – or draw a process model. Which do you think is easier and more likely to draw out the inconsistencies, loops, delays and bottlenecks in the current process? And a (very important) by product of doing the latter is you get to work collaboratively with the stakeholder rather than them dictating and you taking notes. And you don’t have to be the artist – take every opportunity to hand the whiteboard marker to the stakeholder and say “can you draw that for me?”

The second of our objectives is to decide what the “to be” system will look like. Modelling again offers a rich choice of options. It might be as easy as modifying an existing “as is” diagram or as liberating as asking draw me a picture of what you’d really like to see happening. Very few people would say they can’t understand the following diagram:

A final world on models – they can also clarify the often confusing steps in the business analysis process. Whether your project is agile, iterative, waterfall or a mixture of all of these, they all have the same objective…

…to reach an end point and produce a deliverable.

If you liked this article, you may also enjoy these:

Event-Based Analysis & Modelling

Stakeholder Communications – Pictures not Words

Data Modelling & Object Oriented Development

The post There’s More to Modelling than Runways and Catwalks appeared first on IRM Training.