Why no project should exist in isolation and what needs to be done

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-what should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

How requirements language can contribute to the solution

The very thing that brought about the project as a business entity can also be it’s worst enemy, especially when it comes to technology. The project isolates the goal from the rest of the business by providing its own governance and budget and treating like a mini company with a project board in place of the board and a Project manager in place of the CEO. The stakeholders take the role of shareholders and the sponsor that of Chairman.
Project structure is necessary in order to get important tasks completed quickly without having to fall in line with all of the political and process barriers that would otherwise smother it. The problem however is that this isolation often leads to forgetting to ask simple sensible questions like ; “Do we have something already that can do this?”.

I once was engaged by a large public sector organisation to look for a solution to their string of failed web projects. In the course of initial investigations, I discovered that they had no less than 6 content management systems any one of which could have provided for all 100 plus websites that they managed. Each project had been considered in isolation and nobody had considered whether more software was needed.

How requirements language could have solved this problem.

The reason things happened the way they did is that nobody said “We need to deliver our messages 24/7 on demand”.
Nobody said “We need a way to encourage feedback from our audience” etc etc.

Nobody said “we need John to be able to publish stuff instantly and get it reviewed and in front of our customers within 30 minutes”.
The reason nobody said these things is because nobody asked them, or at least nobody asked them the right questions, or asked them in the right way.

Here’s how it works best.

The Business person says: “ I need to influence the market to purchase more of our products”
Here we have a business requirement/business problem/probortunity. The terms you choose depend on your viewpoint. In this example it could any of the three. The key is that this is the goal which kicks off the business case and which is ultimately measured in the KPIs you define for benefits realisation.

The Business Analyst then adds some deeper definition like ballpark estimates at timescales, size of increase and other key constraints.

The Business Analyst then speaks with Marketing people who tell him:

“We need to reach these segments.
We need to deliver these messages; we need to make these things available at these points in the buying cycle on a 24/7 basis.
We need to encourage them to approach us in these ways.”

Business analyst then brainstorms with technical people, designers marketers and everyone with a stake and they decide on a high level plan of how this goal can best be achieved.

At this point we have high level requirements. I prefer to refer to them as high level process requirements just in case anyone starts designing systems yet, but they have not developed beyond business requirements and are dealing with “how” rather than with “what” we want to achieve.

The Business analyst then draws use cases from these requirements that provide some detail on the everyday activities of users and the systems they need in order to support them. He/she does this iteratively, continuously checking back with business stakeholders until he/she has a clear understanding of everyone’s role and what they will need to achieve/do (use cases) in order to deliver on the high level requirements.

The Business analyst gathers high level costs and timescales and organises a scoping session when the team make a first draft at deciding how much of this they can afford and which bits will give the best returns for lowest risk.

Verifying the detail behind the more complex use cases is beyond the scope of this blog, yet it is critical to at least acknowledge that this verification must be done to bring time, place, and sequence to these simple use cases and to get an understanding of the processes required and how they differ from, or add to, those which exist and equally importantly, how they can reuse existing processes.

At this point the business analyst converts the use cases, business rules, models and scribbles into a formal set of requirements written down in a straightforward requirements language and taking great care not to define the solution at this point, simply to define the requirements so that a technical team can decide how best to meet these requirements technically, while taking into account the tools they already have.

The rules for writing good requirements.

Below is a simple list of 10 rules that you can use to test your requirements once you have written them.

Value – Traces directly back to a business requirement in the business case, i.e. it adds value
Clarity – Give it some thought, be aware of your audience and don’t use three words where two will get the job done. Above all don’t use jargon including company jargon and if it is absolutely necessary to use technical terms add an explanatory footnote.
Design Free – This is by far the most important rule. Don’t even hint at the design. Stick strictly to outcomes. How it is delivered is down to the specification.
Achievable – There’s no point in asking for things that can’t be done technically, are beyond the budget, or are not going to be accepted in the user culture. This last part has been the downfall of many CRM implementations. If the culture is not ready, then don’t do it yet.
Complete – The requirement must give the reader sufficient information to work form the document without your standing beside him/her.
Consistent – Language and style always depends on individuals, the most critical thing is to be consistent so that the reader can learn your style and be confident in understanding your meanings.
Unambiguous– Don’t be woolly and don’t be coward. Spell it out clearly. Words like nice, fast good have no place in requirements. Define what will be nice or fast or good and make it measurable.
Verifiable – Assume that you will also have to write the test cases and test scripts and ask yourself how you will test this requirement. If the requirement doesn’t give enough information for this, then it is not verifiable and not complete.
Atomic – Take your requirement down to the smallest unit you can. Always ask, could this be broken into two requirements. If the answer is yes, do it.
User experience – This one applies mostly to products, but increasingly it is important in business change scenarios. Ultimately your user will feel an emotion or reaction when using your product. This the ultimate test for your product, the one where it wins or loses. This is where you describe the reaction you are trying to produce.

The last and very important step in requirements definition

Now that you have a requirements list, and assuming that all the context of this project has been communicated to the recipient of your list, the next step is to take this list to your supplier.

Regardless of whether the supplier sits at the next desk or is Microsoft Corporation, the same rules apply.

Add an extra 5 empty columns to your requirements list with the following headings: OTB (Out of the box), CON (Configurable), CU (Customisation required) New (New feature needed) note (Here they enter the number of any footnote they need to include.

My personal preference is to ask for ballpark time, cost and risk estimates alongside of any new code or customisations,

This simple exercise will give you an immediate heads up on how much new code, new systems and other effort, risk and expense will be involved and it will take you one step closer to defining the final scope of your project and/or choosing the best supplier.

Today we talked about the issues of language and viewpoint when setting out to define system requirements and we defined the Ten Commandments of writing good requirements.

We did however gloss over a very complex and important area in terms of exploring, defining and verifying process, rules and business rules in order to write requirements that you can feel confident about.