Requirements engineering strategy can make or break your project .

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists in 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

If you’ve been reading my blogs on the subject of requirements, you will no doubt appreciate the level of importance I place on getting requirements right and then testing them before committing yourself to a contract or a technical specification.
Just in case you are thinking that this is in some way anti agile, then nothing could be further from the truth. Please read my blog on agile requirements engineering for a discussion on this topic.

Let’s take this opportunity to recap on why we do requirements. The simple fact is that once a development team start work on creating a technical specification, the till begins to ring up with costs and every time you make a change after this point more costs are added. The closer you are to rollout when you make the change, the greater the extra cost will be and that time phased increase is exponential, therefore the first purpose of requirements engineering is to contain costs and eliminate or reduce slippages.

The second purpose is to make sure that the end product delivers value by meeting the needs of the business precisely in order to meet or exceed the benefits targets set in the business case.

Getting requirements right therefore, is absolutely critical if you are to contain costs and deliver value

Developing a requirements engineering strategy

Each organisation and each project are different and requires a tailor made strategy for getting the requirements right by recognising, exploiting and working with the capabilities of the organisation.

To do this successfully, you will need a few things:

  1. A detailed analysis of the stakeholders involved in the as-is process in order to make interviewing efficient and thorough.
  2. A strong feel for the past experiences of the organisation in terms of successes or failures with software projects in terms of meeting business need and staying within budget and time constraints. This along with some tactful exploration of causes will give a strong steer about the current capabilities of the organisation to engage with a formal requirements process and to take seriously concepts like change control.
  3. A feel for the organisations ability to take on and successfully adapt change will help you decide whether and how far you might decide to upgrade their skills and attitudes to requirement engineering
  4. A good indicative plan that indicates the products to be created, their acceptance criteria, time scales for delivery and the amount of effort that will be needed from stakeholders.
  5. The understanding, agreement and total buy-in of key stakeholders to the proposed approach with full support in terms of making people and facilities available for the process

 

Stakeholder analysis for requirement engineering

Step one

Using RACI to identify stakeholders for the Requirements function.

In my blogs on business case techniques and models I discussed the importance involving the right stakeholders to gain buy-in and get a real picture of what success will look like.
In order to design the system, you will need a different type of stakeholder list, one that describes roles, responsibilities skills and communication. This list will give a clear view of where the knowledge skills and the responsibilities lie within the organisation and therefore point you at the right people to describe requirements and take responsibility for their quality. My favourite tool for achieving this is a well known HR instrument known as the RACI chart. Responsibilities Accountabilities, Consults, Informs and it provides a two dimensional view of a team that helps you quickly analyse the team for adequate skills, supervision, communication and quality control. It can be adjusted in form or emphasis to suit your precise needs, but the fundamental principal serves well in any circumstance straight out of the box.
Here’s an example;

RAACI example

The table above lists nominal roles across the top and Activities down the left, each cell is then marked with one or more of RACI to show who has what role in that activity.
The example is for a software development team, but if you were building a hospital it would list things like planner, builder, architect and activities like approve plans, complete design, etc.

A software project for a builders might involve, Construction director, surveyor, cost controller, quality controller etc and Liaise with clients, agree costs, sign off completion, etc.
Apart from being a huge benefit in helping to highlight the important stakeholders for your requirements process, the RACI chart also provides a quick but effective sanity check to make sure that your team is adequate and that there no duplications, conflicts or gaps.

Horizontal analysis of each task will quickly tell you whether there are sufficient doers and accountability exists and is in the right place.
Vertical analysis of roles will quickly highlight overworked, underworked, misplaced authority or responsibility and lack of or too much consultation and information.
Too much consultation stifles decision making and too little leads to dangerous decisions. Corporate culture can lead to busy bodies who don’t always follow through, or teflon in-trays. All of these issues need to be understood and ideally addressed ahead of system design, because the system will only perform as well as the people who use it.

Once you have created this chart, the next thing is to create a list of names with contact information to place in each of the role areas. If the project is large and/or complex, there may be more than one name in each box and there may be further sifting to do in order to resolve any doubts.
Don’t be surprised to find skeletons in the cupboard and lack of agreement over who does what. If you uncover these issues, now is the time to discuss them at a high level and attempt to get them resolved ahead of requirement gathering.

Step Two
The second step is identify the Actors, the people and systems that carry out tasks as part of this process and the sources of all the skills, knowledge and decisions required to complete the process successfully. This will generally begin with the R people in your RACI chart and will usually expand to people who do the work with or for the R person. E.G. the R may be in your chart as the Technical architects for design, but on investigation, you may find a DBA, a SysAdmin and many others who play key roles and these people also need to be interviewed.
The actual actors may be more usefully broken down to specific skill sets or disciplines as opposed to specific roles. E.G you may have Document writer, Interviewer, modeller all of which are actors within the BA function. This approach gives a slightly more abstract approach that lends itself to reorganising roles for efficiencies, or to adapt to a new system.Never be tempted to accept the assurance that a supervisor can tell you the whole story and you don’t need to talk to her/his charges. If anything this should be seen with an element of suspicion and tactful verification is a good idea.

To better understand and communicate how the various roles influence the outcome of a process, it is sometimes useful to create a fishbone chart adapted slightly for the purpose. Here is how i like to create it:

Stakeholder fishbone chart

The fishbone can be made as complex as you need it to be in order to show all the influences on your new project. The thing that becomes apparent very quickly is that whether they are aware of it or not, most of your stakeholders rely on others for skills, support, knowhow, data, administration and other inputs that can potentially prevent the processes progressing and hence you need to know about it and to resolve, or risk manage it.
Your fishbone chart will immediately tell you who to talk to and by way of a bonus, it will very quickly highlight the areas of influence, both positive and negative when it comes to rolling out.

Organisational culture and requirements process maturity.

Once your target interviewees are lined up, your next step is to hold a number of short interviews and/or an interactive workshop to discuss past projects, how they went and how the organisation reacted at the time and now. Asking them what they felt went well and what went wrong will go a long way towards gauging what will go down well, or will meet with resistance in terms of methodology.
The aim is not to deliver the perfect project, by your standards, but to deliver the best you can within the capabilities and expectation of the clients.

The last critical aspect of this phase is to get a good feel for their favoured mode of communication within this area. Do they have requirements documentation that they worked with in the past? Are they comfortable working with it? Does technical documentation create silos that exclude valuable stakeholders to the benefit of technical people .

This aspect is vital, because the quality of decisions they make and their perception of you as a trusted adviser will be directly proportionate to your skill in communicating the concepts clearly to them. Not only that, but your ability to get their attention at all let alone hold it long enough to achieve a useful level of consultation will depend on not confusing or alienating them with technical or complex instruments of communication or use of unfamiliar jargon.

A clearly communicated strategy and indicative plan

Once you have gathered your information it is time to make some preliminary decisions about how to take it forward. How to collect information, how to verify your information and how to communicate back to stakeholders ahead of defining the requirements.

Identifying these tasks, the stakeholder and support staff needed and the order and dependencies of the work, it is time to add this to a simple Gantt chart that defines high level activities, high level milestones and products to be delivered.

Understanding, agreement and total buy-in.

If you have done your homework and worked in a consultative manner you will be very confident before presenting the plan, that it will be understood and supported and will be accepted by your stakeholders.
You should present:

  1. An introductory explanation of the approach with reasoning
  2. A list of products you propose to produce backed by a simple concise explanation of how and why and samples.
  3. A Gantt describing the timeframes and milestones.
  4. A simple, high level risk assessment
  5. An indication of the time commitments required of key stakeholders.

At the end of this you should answer questions and ask for their full support backed by a sign-off of the plan.

Ed Taaffe is a senior Consultant in Business Improvement through technology and Hi-tech Product management.

Reblog this post [with Zemanta]

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat 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

What would you like sir?

Countless reports on the reasons for project failures in the software industry point heavily towards poor requirements as a source of the problem. It isn’t too hard to see why that might be. After all if you hope to get exactly what you want, you are going to have to spell it out in some detail.

How many times have all of us left a restaurant disappointed because we misinterpreted what a dish consisted of, or had a bad experience ?

Ordering what you want in a restaurant where they speak your language is relatively low risk. There is a risk of misinterpretation and there is a risk of a poorly executed dish, a meal that arrives after a very long wait, or a nuisance at the next table making you uncomfortable.

If you want to give yourself a strong chance of being satisfied with your meal, first you will need to be aware of all these contributors and make your choices with this in mind.
Taking this approach might help you avoid the family from hell at the next table, the dish that isn’t what you expected etc and if it doesn’t work out you are at least in a strong position to seek recompense.

Software is much more complex than food and like a restaurant meal there are more concerns than simply  the ingredients. In an ideal world you would be dealing with a professional who could interpret your tastes, avoid the poorer restaurants and order on your behalf.
This is the main purpose of the Business analysis and product  development body of knowledge.

It gives you the option of working with trusted professionals that can help you achieve what you had hoped for and keep your costs down.

Product versus System.

Few people stop to consider the difference between developing products and developing systems for a private audience and will often approach both in exactly the same way, but although there is a lot in common, there are also critical differences.
1. The first and most important difference is the fact that a system will be rolled out to desktops ot devices and the organisation will train users and tell them to get on with it, whereas a product will be launched into a marketplace who have to be attracted to explore the product and then persuaded to purchase it.

  1. A system will largely be rolled out into a controlled technical environment whereas a product will be at the mercy every conceivable version of operating system and technical environment.

  2. A product must breakeven quickly, deliver a profit in the long tail and exit gracefully before it becomes a liability.

The first of these is one of the more telling differences for our purposes because it requires an entirely different approach to understanding requirements  and defining outcomes and it introduces a whole new level of financial constraints.

When developing a product, the Analyst/Product manager  is often working with a user advocate  or product forum to define the desired functionality and get requirements down on paper in the same way as with a system.

A better process will run Alpha and Beta releases with early adapters in order to learn about how users react to it and make critical changes that improve it’s chances. In an Agile world the Product Owner will release an MVP (Minimum Viable Product) and perhaps then an MMP (Marketable)
All the time the success or failure of a product rests on the likelihood of the user base receiving it will, perceiving a persuasive benefit and viewing it as value for money.
The project manager delivering a system on the other hand has the luxury of rolling out a system and only worrying about complaints that threaten it’s ability to deliver.

The project manager can learn a lot from the product manager in terms of delivering a well received output and maintaining good communications with stakeholders.

Innovation as opposed to state of the art

Projects that involve a level of innovation either in terms of process or the technology to drive it will require a different approach and a strong element of prototyping both as proof of concept and as a way of communicating to users a blue skies concept, will generally be the better approach leading to a point where requirements and scope can be nailed down and the process of delivering it can get under way.

Complex domain knowledge

Another situation requiring a different approach to requirements is the one that involves extreme complexity in a domain outside the scope of the analysts, project managers or technical staff.

Let’s say for example that we are building software to manage extremely complex trend analysis for  forex traders and only a small number of skilled individuals understand the underlying mathematics.

To get a product manger or analyst to a sufficient level of understanding could take years and it would still be a second best option. The best option is a totally agile approach whereby the statistician the analyst and the developer all sit together and build prototypes without the statistician ever needing to understand the underlying code and architecture, or the programmers and analyst ever understanding the fine detail of Monte Carlo analyses etc being used to construct models.
In this situation the requirements are written after the code has been written and unit tested and it’s purpose is to support maintenance and future development processes.

COTS versus Development

The biggest area of effort by a long shot is the purchase and implementation of COTS (Commercial Off The Shelf) software systems.

Right form early days in the industry, there was a realisation of the need for reuse of software and many of the various efforts that came and went have been sold to us on the basis of promoting re-use. In reality precious little is developed in Com or reusable classes and SOA is still not that widely used.
The theory that once you had created a “customer object” you didn’t ever need to do it again, just never caught on, but COTS systems did and today there is very little development of end to end systems outside of software houses that develop products.  Nobody builds their own CRM, or ERP, etc, because it makes no sense when you can buy it straight out of the box at a fraction of the cost. Bill Gates freely admits that he ran the business on SAP using his own products to integrate where he needed the extra flexibility.

The issues with COTS however are that businesses are all keen to differentiate their offerings and this adds to the variety of processes and business models in operation which in turn means that many of these all encompassing systems are a compromise rather than a solution and require a lot of integration and customisation in order to make them deliver benefits.

There has never been to my knowledge, any attention given to the needs of these systems. The most common problem I have encountered is people from the business assuming that you don’t need the normal skills to deal with this because it is in the box and it is like buying a lawnmower,  you bring it home and tell “the IT boys” to plug it in.

In reality this is a very dangerous mistake and pitfalls are as follows:

  • You are reading wooly,  warm and friendly descriptions of what the system will do, but no detail about how it gets there. All COTS is sold with a “Caveat Emptor” clause and unless somebody knows all the details of what it must do and whether it actually does, then you will end up with a very expensive system that just is not suitable.
  • The complexity and risk attached to integrating COTS systems with other systems can sometimes make them almost as expensive as starting form scratch.
  • The impact of the COTS systems on your infrastructure and on other critical systems can be devastating unless it is properly understood.

The job of procuring COTS software is  complex and tricky and it can often be a struggle to convince business stakeholders of the need for detailed requirements, detailed investigations, complex questionnaires, proofs of concept, and a range of testing before making the system live on a production environment.
The size and complexity of this area is such that it could not be addressed in this series, but suffice to say that all the rules about requirement apply equally and there are a number of new concerns to be addesses.

Requirements, tests, training, help files – the connection?

Part one What would you like sir

Part two Requirements,tests, training, help files

Part three Why no project exists onin isolation-whwat 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

 Really! – Have you seen this new stuff? 

This could easily have been Mick Jagger and Keith Richards after their first successful gig. In the modern world, it is more likely to be a hard working CTO talking to a COO about his systems needs.

Systems are not like any other purchase. You can go to a tailor today and he will do almost the identical things that a tailor did for Julius Ceaser.  You can call an architect and his approach will differ little from that of Hiram Abif apart from the time taken to produce drawings.  When it comes to systems though, it is more like medicine. Patients differ, you only hear what they tell you and you don’t really understand anything you have not personally experienced, you have to tease it out using your instinct and experience and play the numbers game.

There are techniques for flushing out the problems and verifying them and for getting the medicine accepted, but ultimately every doctor likes to deal with life threatening situations. If he succeeds for whatever reason, he’s a hero and if not, well, he did his best.
Apart from a lucky few, most of us in the software industry have to earn a living by delivering value in the real world through cost savings, or competitive advantage and that’s a tall order.
It calls for a mixture of calculated risk taking and good fall back positions and it requires an insight that combines real understanding of the business domain with leading edge technological ability. It doesn’t matter whether this is done by a committee or a genius as long as it gets done

The requirements challenge

So how do you meet a business person, listen to his/her needs and six, nine or thirty six months later get a well done, thank you response?

There isn’t a really good answer to this. If it is six months, you are in with a chance. If it is nine you are still in there, at thirty six, the likelihood is that before you deliver this, a much better solution will have been invented, or the problem will have been replaced by a new one.

There is a considerable number of methodologies out there, most of them geared up to coax you into paying for expensive training courses and few aimed at really bridging the divide between what a business needs and what technology can deliver with reasonable reliability.   A methodology that really works has to be able to understand business needs, translate it into process and match this with the best possible technical solution.

Defining the problem

This is not as simple as it sounds. If you read my business case blogs, you will probably remember the way I recommend tying corporate objectives in a direct and accountable way to the benefits delivered by the business case.  That makes perfect sense of course, because a good business sets a plan and then works to deliver on it.
There are other scenarios however that need to be taken into account, this example will hopefully help to illustrate the point.
Suppose we approach an Amazon tribe still living in the traditional way, tell them that we would like to give them some gifts and ask them about the problems they would most like to solve and the things that might give them the most satisfaction.  Problems and exciters. The likelihood is that having seen bright steel machetes amongst the crew, they might suggest a steel spear to make fishing more productive. We might then suggest that rather than give them a spear, we can give them a monofilament net. This way they can catch enough for the whole tribe in an hour instead of having to fish all day.Here we have seen a classic example of the two cardinal sins of analysis:

 1.       Asking a question that the object of the question can’t possibly be expected to answer well.

2.       Answering with a solution rather than a problem.

The interviewee in this example can’t be expected to know how to manage this process, so the entire responsibility lies with the interviewer. By the way, that includes the many occasions when the interviewee believes she knows exactly what she wants and is driving.
The responsibility of the analyst extends to making sure that the interviewee has explored and understood the problem and has a sufficient understanding of it and of the desired outcomes to start either designing or verifying the solution.
I include verifying here, because an increasing number of business people believe themselves to be tech wizards and arrive with fait accomplis and a budget wanting a technically trained fellow to make her vision happen.  In these cases, instead of designing a solution, the analyst goes through a process of verifying the problem, the requirements and the solution.  If these three don’t match and the sponsor doesn’t see it then it is up to the individual analyst’s conscience  and professional intergityas to what he/she should do next.

In Summary

In this part we have talked about three key issues:

1.       The unique challenge facing a systems professional in getting to the real problem before starting on the solution.

2.       Educating the client about possibilities in order to truly understand what the problem is.

3.       Tempering the part time inventor with a little pragmatism without dampening his/her enthusiasm.

The next part will get much deeper into the language and culture of requirements and and discuss different methods of achieving a reliable result.
 

 

 

 

Reblog this post [with Zemanta]

Delivering benefits is no longer about getting a system signed off

(Who’s minding the shop?)
This blog is an attempt to stimulate discussion and understanding of the balance of responsibility for delivering business benefits from IT investment.
It is now fairly widely recognised that this is not as simple as choosing a system, getting it working and reaping the benefits, but as yet we can call on very few examples of good practice in making it work.
The business argument.
We have no time for discussions about how it all works, we just want a business case and if it gives us the ROI we need with acceptable risks, we want to do it. At least that’s the CFO’s line. In reality, many of these projects begin life as pet projects of the CEO, or other senior manager and it is clear from the outset that the question is not will it work, but make it work.
This is largely an understandable attitude, because businesses must be directed and managers must manage and sometimes the outcome can be a life or death one.
The IT supplier argument.
Be the supplier an in house department or an external supplier, the situation is not hugely different. The supplier tends to confine their responsibilities and activities to making the technology work. Better suppliers provide advice and guidance on rollout, but that is the limit of the activity and there is no responsibility beyond meeting technical requirements. This is wholly understandable, because the supplier has no control over whether the business case was correctly put together, whether the requirements were detailed enough or whether the culture is sufficiently flexible or disciplined to make the new system work and deliver benefits.
So who‘s minding the shop?
Well the answer very often is that nobody is minding the shop. Rarely is anybody in the business equipped to do this job and the suppliers are not getting involved.
The most usual scenario is that the system is delivered and there are issues and misfits that become immediately apparent, then there’s a return to the drawing board and changes are made and a re-launch and things are much better. Often you’ll find a new project with a new name the following year, billed as an upgrade and it finally knocks the thing into shape. Two years late and dramatically over budget the project is complete and nobody ever asks whether it delivered benefits because at this point the busines is bus with a whole new set of issues.
The other common scenario is that a consultant is hired to manage the project, he/she is expected to have a project management qualification PMI/Prince etc and have handled one of these type of projects before, maybe even in this industry.
Often the contract is already in place, the product defined and dates and budgets set.
Where does a Consultant go from here?
1. Recommend someone else who needs a bit of experience.
2. Take it on and hope for the best
3. Challenge the client at interview and get passed over as wrong attitude
4. Take it on and then challenge the client later via a robust consulting methodology
5. Challenge the client at interview via a robust consulting methodology
6. Offer to challenge the project’s soundness for a reasonable fee and provide a dispassionate report.

Testing requirements is not optional

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat 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

Yes you read it right. If you are one of those people who believes that testing begins when the supplier drops the system in your lap, then you have missed the point entirely. Testing starts when you build a business case and you test it to make sure that the solution is feasible and the figures are sound etc.
The next important test comes when the requirements are deemed to be complete.
Here’s the summary of a good requirements definition. Depending on the size of the project this could be one document or one per viewpoint. The thing that is important is that the right problems have been addressed and the problems have been identified and described clearly to the suppliers or developers in a way that makes it easy for them to get it right first time.

Business case — Tested via a Business case review, or Stage gate review.
User requirements – Tested via user and stakeholder review. (The problem)
Functional requirements – Describe the functionality that the system will provide in order to meet user requirements. (The solution)
Non Functional requirements – Describe all the constraints like speed of operation, reliability etc.
Data requirements – Describe in detail the inputs and outputs of the system and cover both the validation of human input and the specification of machine interfaces
Business Process – Describe the time phased rules that govern how the business goes about achieving it’s goal with the system. 

Business case review

Has the scope expanded, or the costs changed, or has the timeline been impacted in such a way to negatively impact the business case.
Has the level of complexity shed any doubt on the organisation’s ability to deliver.
Does the bsuiness case still stack up

Business process review

  • Do the processes join up to deliver a result
  • Does each process receive the required inputs
  • Do they handle all exceptions sufficiently
  • Are processes efficient
  • Will new processes deliver the expected benefits
  • Are the risks managed
  • Are the assumptions sound

User requirement review

  • The aim is to discover problems like ambiguous requirements, missing requirements, inconsistent requirements
  • Check against process models to ensure that nothing has been missed.
  • Check against the ten commandments

Functional requirement review

  • Traceability to user requirements
  • Design agnostic
  • Achievable
  • Complete

Non functional requirement review

  • Measurable
  • Explainable
  • Traceable to a business requirement

Data requirements review

  • Complete
  • Clear definition of types, mandatory fields, sizes,

Prioritisation of functional requirements

Armed with best guess estimates of time, cost, risk and benefits propritise them a number scale ar a scale like MoSCoW

Reblog this post [with Zemanta]

Business rules, Process rules, Process, Data, different viewpoints on requirements.

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat 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

Requirements look harmless enough once they have been defined and it can be difficult to imagine the amount of work that may have gone into defining them. Sometimes the issues are simple and requirements are easy to define. More often the business can be very complex and the requirements can be very tricky to define. Often the consequences of getting it wrong are very serious and other times they are easily surmountable. On average more than 60% of all software defects are created in the requirements specification.

To fully understand requirements it is necessary to break them down and consider each on it’s own merit. First of all requirements come from different viewpoints and these angles must be fully considered.
The key viewpoints to consider are: Business rules, Processes, Process rules, Data rules and models, Operating environment internal and external, Culture, Skills, Adaptability.

Business rules

The key to understanding the nature of Business rules is to understand that whatever the business, there are certain rules the business must follow in order to win business, meet legislation, deliver value , get paid and make a profit. These are generally described as Business rules and sometimes they are thought of as business strategy and TOGAF often refers to them as principals..

The importance of business rules can not be overstated, because they provide the flexibility for process to adapt and alter within safe boundaries. A great example of strategy and rules being used in place of process is a football game.  Apart form a few set pieces that can be rehearsed, the bulk of any game is far too fluid to be governed by a process, instead a team of highly motivated people with deep understanding of the strategy and rules adapt and evolve their performance continuously to maximise results.

When we begin a process improvement project, we are doing exactly what that footballer does in every game, we are adapting behaviour to the circumstances while remaining within the stated rules and strategy.

A word of caution about strategy and business rules.
Most organisations fail to upgrade strategy and business rules, but allow senior people to evolve it, often in a very informal way and therefore it is necessary to valiate the current best practice against these rules and update them when necessary via consultation

Often these business rules will be referred to at a high level as the business model, though business rules for our purposes will generally exist at a level one step deeper into the detail and be much broader than  just a business model.
A business rule in a broker model might be that the business only submits to a client, candidate products that match the client’s stated requirements 100%. This might then lead to many more rules that help to better define the high level rule. These rules will most likely be implicit in documents and procedures as opposed to carefully recorded under the heading business rules.

A simple business rule might be that the business charges vat at 17.5% on all sales. Another example might be that the business never offers credit to first time customers, or that it must inspect all of it’s properties at least once a year and provide safety certificates.
A more complex rule might be that all it’s businesses must be visited by a mystery shopper on a Saturday between 12 and 3.pm at least three times a year but no closer than two months apart.

These business rules are not always cast in stone, but they tend to form part of the culture in the business and they often contribute to understanding the capabilities or lack thereof in the organisation. They also reflect the strategies and direction set by the business. Some would say that these business rules are fundamental to what differentiates and defines the business. One way or another they are critical to requirements engineering.

It is also very important to the analyst hoping to deliver well received improvements in how the business runs to understand the consequences of attempting to make changes to these rules. Challenging and changing these rules requires high level sponsorship, deep understanding, tact and respect for the organisation, its people and its essence. It should never be avoided though, when there is a clear opportunity in sight.

Process rules

Process rules are a different entity altogether, but play an equally important role in how a business gets from point A to point B. Process rules are more flexible , less strategic and more tuned into the abilities and preferences of individuals within the organisations. Process rules say as much, or even more about the past where they were born as they do about the future they are intended to support.

A process rule might say that an individual product has to be signed off by the Quality manager before leaving the premises, or that a specific type of purchase is checked individually before being added to inventory.

Complex process rules might suggest that a detailed survey must be produced before a plan of action is presented and only after sign – off by three senior managers can a project begin.

The difference between Business rules and process rules is that Business rules set a strategy for the business, while process rules are one way of delivering on that strategy, but not necessarily the only or the best way.
The power of good process is that while people quickly forget why they do it, they do it without thinking and the process hopefully results in good consistent performance. The downside is that for the same reasons stated above, people continue to follow process blindly long after it has ceased to offer value. This is especially true when that process is enshrined in a system that is inflexible. This fact also makes a very strong case for taking extra care with the design and validation of process, not just in terms of performing well right now, but providing both resilience and adaptability.
The way in which any idea including a process is made reusable is through abstraction and this is a key element in the process modelling element of requirement engineering.
Use cases are the commonest way of abstracting requirements because they are reusable descriptions of things that must be done in a way that is technology and even functionality agnostic.

Requirements

As described in detail in When is a business case not a business case, the Business requirements are the starting point for a project and provide the motivation for proceeding to the next step. They describe clearly what the business objectives are and they make a first attempt at defining the KPIs that will indicate success. They also describe other constraints such as time to market, ROI, etc that may be very important to the project.

User requirements /Use cases

Business requirements are all well and good, but the next level of understanding involves describing in detail the cases in which people will use a product or system, the goals they will be seeking to fulfil and the constraints on each of these user requirements or use cases. Typically a constraint might involve the time it takes to achieve something, or the level of accuracy.

E.G. A business requirement may be that all paper work is eliminated in the “enquiry to payment“ workflow.

This requirement can easily be measured via a number of valuable KPIs and now a whole list of use cases will emerge such as:

  1. A user must be able to record the details of a new order.

a. A user must be able to check that the stock exists

i. If it is not in stock, user must be able to order it

  1. A user must be able to get an ETA on delivery.

  2. A user must be able to retrieve an instant progress report.

  3. Etc.

You will notice that there is no attempt to describe functionality, just to describe the activities users need to carry out and the goals they need to reach.
The second thing worth noting is that we are not burning daylight hours worrying about the order in which these things happen or who does them and all the other aspects that would complicate a traditional process map.
The difference between use cases and process maps is that use cases are written as building blocks that can be used in any order to build a new efficient process as opposed to an existing process that has to be wrenched from it’s owners and painfully changed amidst powerful opposition. The answer you receive in any area of life will depend heavily on the way he way the question is asked and the context in which it is asked. This is key to the success of the business process designer and the and the use case approach lends itself to more objective questions and more accurate answers.

In addition to this, it is often folly to assume that everything is a process. In reality there is not necessarily any time or order dimension in the way many of these events occur and it is more valuable to look upon the business as a series of events to which users must react with use cases.

In my view a process describes a situation where each activity causes the next decision or step to happen immediately. Process is required to understand the functions that will support many of these use cases, but necessarily to join together, or to explain them.

As-is/To-be

An old and respected technique for achieving this understanding of process is to model the “as-is” processes and then to design improvements based on any combination of the capabilities of the new technologies and changes to the business as a whole.

As previously discussed, Use cases pay no attention to the order in which things happen or the decisions about what comes next. This is the main attraction of use cases as a clean sheet on which to design better processes as opposed to mapping “as-is”, (about to be dumped) processes in great detail before then re-designing them in the face of resistance and contention.

The problem is that an analyst must start somewhere and the approach needs to bring along business stakeholders who may have their own ideas and preconceptions.

Our preference is to define this requirements engineering approach in advance bearing in mind whether the task is closest to a new blue sky system, some process improvements, or solving a business problem.
In the latter case, the AS-is and To-Be approach is likely to be most acceptable while a blue sky project will be more successful starting from use cases and using them to design new processes.

The key ingredient in designing or even just recording process is the complete co-operation and enthusiasm of the stakeholders involved, therefore intelligent and tactful consulting combined with open and understandable methodology that stakeholders can feel part of and buy into is an absolute prerequisite.

There no right and wrong processes, there are processes that are used well and those that are rejected

Consultants dilemna

Consulting is not a job for egotists or perfectionist. Every analyst will have seen the same problem tackled in extremely different ways at different organisations and been dismayed at having to ignore hard won experience in favour of what the current client feels comfortable with. This is a fact of life and one of the biggest stumbling blocks for consultants in every walk of life.
In most cases, as-is modelling will be seen fairly quickly to contribute mainly to actually understanding and recording use cases and the time element will be seen as less important. The critical thing is to find a way of recording this information in a format that promotes discussions and input from stakeholders.

This brings us to the last aspect of user requirements. Acceptance criteria.

Acceptance criteria.

As in all things, you need to start out by defining some sort of success criteria.

No goal posts, no goals.

It’s not rocket science, but success criteria is far too often neglected.

Process that has not been verified is a dangerous base on which to design a solution and likewise the suitability of the process to the people who will need to execute it will need a level of verification.

The only way to achieve this is to agree in advance how this verification will be carried out and how the decision will be made.

Functional requirements

Functional requirements are the next level of abstraction, not the solution. Many people are under the illusion that this is a software specification, but nothing could be less accurate. The Functional specification is a bridge between the totally abstract user requirements and the very detailed technical specifications..

This is the critical time when the technical experts get involved to explain to you the possibilities you had not considered and show how your requirements can be met using existing infrastructure.

To demonstrate this, let’s return to the example we used in previous articles.

The business wants to win more new customers through leveraging the internet to keep in touch with people who are in the market for their products.

Having resisted the “Ok let’s build a website” response, we define some user requirements.

Customer users need to be able to:

  1. Study the benefits of our product at their leisure without feeling that they will be pestered

  2. Compare our offering to the other major options in the market place

  3. Do a price comparison

  4. Ask questions about the product

Marketing users need to be able to:
5. Make new collateral available to customers within an hour of proof reading it

  1. Know which collateral is most helpful to the customer

  2. Know the customer’s stage in the buying process when she finally say’s hello and reveals herself.

Turning user requirements into functional requirementsRequirement 1 is up for discussion and the options are laid out, we can have PDFs and faxes cued up ready to auto respond to an anonymous request by the customer.
We can build a website with this information.
We can find a way to attract them to a tool they need when making this decision, give it to them free and make sure it keeps our information in front of them.
Etc, Etc

The recommendations will be influenced by the infrastructure already in place and what the stakeholders and the market are most likely to feel comfortable with.

At the end of this exercise we will have a list of functional requirements that sounds like:

  1. The system will provide a way to publish collateral via webpage, MMS, PDF and mail shot in any combination by a creating a single document.
    A good functional requirement will also list the user requirements it meets or contributes to and will include constraints.

What you have hopefully noticed is that this functionality, although crystal clear, makes no mention yet of the actual technology that will be used. That will be left to technical architects.

Data requirementsAnother common aspect of the functional specification is data requirements. These provide yet another abstract view of the business that presents vital detail to the systems architect without placing too many constraints on him/her.

Data requirements will be driven by required outcomes including legislative requirements such as accounting data to KPIs and operational reporting. Data requirements will often reach far beyond the organisation to embrace sharing and integration with partners, supply chains, customers and others as well as obeying conventions and standards that facilitate benchmarking, look-ups and other collaborative uses of data.
Last but by no means least, Data requirements will define the interfaces with existing applications that make the integration work smoothly.
A set of data requirements may include things like:

Data catalogue that gives clear unambiguous naming conventions and rules for how to collect, validate and store data as well as the daa that is required in every process,.
Data Flow Diagram (DFD) that describes how data flows in the system or business.
Entity diagrams that describe the key entities and their relationships.
Yourdon diagrams that show inputs, processes and outputs.Each method has it’s own merits and it’s own uses.
Sophisticated process design methods like six sigma measure the inputs and outputs of small processes to gauge the health of the overall system. Systems integration demands vey detailed and accurate data catalogues in order to get systems working together.

Usability

Only by carrying out usability tests early on can you avoid the expensive mistakes that alienate users and waste lots of time and hence money for the organisation.
My earliest introduction to the potential pilaffs occurred when I rolled out a cutting edge online CRM system that I had designed and built from scratch for a major utility company. It was first and best of breed, we had put a lot of effort into pulling information out of systems of every conceivable type to create a single view and we had done a pretty good job. We had also presented prototypes to the user base, but we had not paid enough attention or asked the right questions.

On roll-out day, none of the risks came to fruition and everything flowed smoothly, but the union representative on the call centre floor called the rollout to a halt pending her problem being resolved.

The problem was this, all users at developed a way of using speed keys to enter data very quickly while handling inbound calls. This meant that they were able to met targets and earn bonuses worth up to 20% extra on their base pay. With the new browser based system, the speed keys were not available and the bonuses were gone. Staff were threatening to leave and a strike was just 24 hours away.

Eventually we negotiated around this, but it took the gloss off an otherwise successful launch and it taught e a lesson that I’m not going to forget in a hurry. You must carry out well orchestrated usability tests on good prototypes in near perfect replications of the end user environment and go the extra yard to find out the problems from the viewpoint of real users.
Once these constraints have been encompassed into requirements and verified in UAT, you will be in a much more solid position to roll out a winning system.

 

Part two Requirements, tests, training, help files

Part three Why no project exists in 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

Requirements look harmless enough once they have been defined and it can be difficult to imagine the amount of work that may have gone into defining them. Sometimes the issues are simple and requirements are easy to define. More often the business can be very complex and the requirements can be very tricky to define. Often the consequences of getting it wrong are very serious and other times they are easily surmountable

To fully understand requirements it is necessary to break them down and consider each on it’s own merit. First of all requirements come from different viewpoints and these angles must be fully considered.
The key viewpoints to consider are: Business rules, Processes, Process rules, Data rules and models, Operating environment internal and external, Culture, Skills, Adaptability.

Business rules

The key to understanding the nature of Business rules is to understand that whatever the business, there are certain rules the business must follow in order to win business, meet legislation, deliver value , get paid and make a profit. These are generally described as Business rules.

Often these business rules will be referred to at a high level as the business model, though business rules for our purposes will generally exist at a level one step deeper into the detail.
A business rule in a broker model might be that the business only submits to a client, candidate products that match the client’s stated requirements 100%. This might then lead to many more rules that help to better define the high level rule. These rules will most likely be implicit in documents and procedures as opposed to carefully recorded under the heading business rules.

A simple business rule might be that the business charges vat at 17.5% on all sales. Another example might be that the business never offers credit to first time customers, or that it must inspect all of it’s properties at least once a year and provide safety certificates.
A more complex rule might be that all it’s businesses must be visited by a mystery shopper on a Saturday between 12 and 3.pm at least three times a year but no closer than two months apart.

These business rules are not always cast in stone, but they tend to form part of the culture in the business and they often contribute to understanding the capabilities or lack thereof in the organisation. They also reflect the strategies and direction set by the business. Some would say that these business rules are fundamental to what differentiates and defines the business. One way or another they are critical to requirements engineering.

It is also very important to the analyst hoping to deliver well received improvements in how the business runs to understand the consequences of attempting to make changes to these rules. Challenging and changing these rules requires high level sponsorship, deep understanding, tact and respect for the organisation, its people and its essence.

Process rules

Process rules are a different entity altogether, but play an equally important role in how a business gets from point A to point B. Process rules are more flexible , less strategic and more tuned into the abilities and preferences of individuals within the organisations. Process rules say as much, or even more about the past where they were born as they do about the future they are intended to support.

A process rule might say that an individual product has to be signed off by the Quality manager before leaving the premises, or that a specific type of purchase is checked individually before being added to inventory.

Complex process rules might suggest that a detailed survey must be produced before a plan of action is presented and only after sign – off by three senior managers can a project begin.

The difference between Business rules and process rules is that Business rules set a strategy for the business, while process rules are one way of delivering on that strategy, but not necessarily the only or the best way.
The power of good process is that while people quickly forget why they do it, they do it without thinking and the process hopefully results in good consistent performance. The downside is that for the same reasons stated above, people continue to follow process blindly long after it has ceased to offer value. This is especially true when that process is enshrined in a system that is inflexible. This fact also makes a very strong case for taking extra care with the design and validation of process, not just in terms of performing well right now, but providing both resilience and adaptability.
The way in which any idea including a process is made reusable is through abstraction and this is a key element in the process modelling element of requirement engineering.
Use cases are the commonest way of abstracting requirements because they are reusable descriptions of things that must be done in a way that is technology and even functionality agnostic.

Requirements

As described in detail in When is a business case not a business case, the Business requirements are the starting point for a project and provide the motivation for proceeding to the next step. They describe clearly what the business objectives are and they make a first attempt at defining the KPIs that will indicate success. They also describe other constraints such as time to market, ROI, etc that may be very important to the project.

User requirements /Use cases

Business requirements are all well and good, but the next level of understanding involves describing in detail the cases in which people will use a product or system, the goals they will be seeking to fulfil and the constraints on each of these user requirements or use cases. Typically a constraint might involve the time it takes to achieve something, or the level of accuracy.

E.G. A business requirement may be that all paper work is eliminated in the “enquiry to payment“ workflow.

This requirement can easily be measured via a number of valuable KPIs and now a whole list of use cases will emerge such as:

  1. A user must be able to record the details of a new order.

a. A user must be able to check that the stock exists

i. If it is not in stock, user must be able to order it

  1. A user must be able to get an ETA on delivery.

  2. A user must be able to retrieve an instant progress report.

  3. Etc.

You will notice that there is no attempt to describe functionality, just to describe the activities users need to carry out and the goals they need to reach.
The second thing worth noting is that we are not burning daylight hours worrying about the order in which these things happen or who does them and all the other aspects that would complicate a traditional process map.
The difference between use cases and process maps is that use cases are written as building blocks that can be used in any order to build a new efficient process as opposed to an existing process that has to be wrenched from it’s owners and painfully changed amidst powerful opposition. The answer you receive in any area of life will depend heavily on the way he way the question is asked and the context in which it is asked. This is key to the success of the business process designer and the and the use case approach lends itself to more objective questions and more accurate answers.

In addition to this, it is often folly to assume that everything is a process. In reality there is not necessarily any time or order dimension in the way many of these events occur and it is more valuable to look upon the business as a series of events to which users must react with use cases.

In my view a process describes a situation where each activity causes the next decision or step to happen immediately. Process is required to understand the functions that will support many of these use cases, but necessarily to join together, or to explain them.

As-is/To-be

An old and respected technique for achieving this understanding of process is to model the “as-is” processes and then to design improvements based on any combination of the capabilities of the new technologies and changes to the business as a whole.

As previously discussed, Use cases pay no attention to the order in which things happen or the decisions about what comes next. This is the main attraction of use cases as a clean sheet on which to design better processes as opposed to mapping “as-is”, (about to be dumped) processes in great detail before then re-designing them in the face of resistance and contention.

The problem is that an analyst must start somewhere and the approach needs to bring along business stakeholders who may have their own ideas and preconceptions.

Our preference is to define this requirements engineering approach in advance bearing in mind whether the task is closest to a new blue sky system, some process improvements, or solving a business problem.
In the latter case, the AS-is and To-Be approach is likely to be most acceptable while a blue sky project will be more successful starting from use cases and using them to design new processes.

The key ingredient in designing or even just recording process is the complete co-operation and enthusiasm of the stakeholders involved, therefore intelligent and tactful consulting combined with open and understandable methodology that stakeholders can feel part of and buy into is an absolute prerequisite.

There no right and wrong processes, there are processes that are used well and those that are rejected

Consultants dilemna

Consulting is not a job for egotists or perfectionist. Every analyst will have seen the same problem tackled in extremely different ways at different organisations and been dismayed at having to ignore hard won experience in favour of what the current client feels comfortable with. This is a fact of life and one of the biggest stumbling blocks for consultants in every walk of life.
In most cases, as-is modelling will be seen fairly quickly to contribute mainly to actually understanding and recording use cases and the time element will be seen as less important. The critical thing is to find a way of recording this information in a format that promotes discussions and input from stakeholders.

This brings us to the last aspect of user requirements. Acceptance criteria.

Acceptance criteria.

As in all things, you need to start out by defining some sort of success criteria.

No goal posts, no goals.

It’s not rocket science, but success criteria is far too often neglected.

Process that has not been verified is a dangerous base on which to design a solution and likewise the suitability of the process to the people who will need to execute it will need a level of verification.

The only way to achieve this is to agree in advance how this verification will be carried out and how the decision will be made.

Functional requirements

Functional requirements are the next level of abstraction, not the solution. Many people are under the illusion that this is a software specification, but nothing could be less accurate. The Functional specification is a bridge between the totally abstract user requirements and the very detailed technical specifications..

This is the critical time when the technical experts get involved to explain to you the possibilities you had not considered and show how your requirements can be met using existing infrastructure.

To demonstrate this, let’s return to the example we used in previous articles.

The business wants to win more new customers through leveraging the internet to keep in touch with people who are in the market for their products.

Having resisted the “Ok let’s build a website” response, we define some user requirements.

Customer users need to be able to:

  1. Study the benefits of our product at their leisure without feeling that they will be pestered

  2. Compare our offering to the other major options in the market place

  3. Do a price comparison

  4. Ask questions about the product

Marketing users need to be able to:
5. Make new collateral available to customers within an hour of proof reading it

  1. Know which collateral is most helpful to the customer

  2. Know the customer’s stage in the buying process when she finally say’s hello and reveals herself.

Turning user requirements into functional requirementsRequirement 1 is up for discussion and the options are laid out, we can have PDFs and faxes cued up ready to auto respond to an anonymous request by the customer.
We can build a website with this information.
We can find a way to attract them to a tool they need when making this decision, give it to them free and make sure it keeps our information in front of them.
Etc, Etc

The recommendations will be influenced by the infrastructure already in place and what the stakeholders and the market are most likely to feel comfortable with.

At the end of this exercise we will have a list of functional requirements that sounds like:

  1. The system will provide a way to publish collateral via webpage, MMS, PDF and mail shot in any combination by a creating a single document.
    A good functional requirement will also list the user requirements it meets or contributes to and will include constraints.

What you have hopefully noticed is that this functionality, although crystal clear, makes no mention yet of the actual technology that will be used. That will be left to technical architects.

Data requirementsAnother common aspect of the functional specification is data requirements. These provide yet another abstract view of the business that presents vital detail to the systems architect without placing too many constraints on him/her.

Data requirements will be driven by required outcomes including legislative requirements such as accounting data to KPIs and operational reporting. Data requirements will often reach far beyond the organisation to embrace sharing and integration with partners, supply chains, customers and others as well as obeying conventions and standards that facilitate benchmarking, look-ups and other collaborative uses of data.
Last but by no means least, Data requirements will define the interfaces with existing applications that make the integration work smoothly.
A set of data requirements may include things like:

Data catalogue that gives clear unambiguous naming conventions and rules for how to collect, validate and store data as well as the daa that is required in every process,.
Data Flow Diagram (DFD) that describes how data flows in the system or business.
Entity diagrams that describe the key entities and their relationships.
Yourdon diagrams that show inputs, processes and outputs.Each method has it’s own merits and it’s own uses.
Sophisticated process design methods like six sigma measure the inputs and outputs of small processes to gauge the health of the overall system. Systems integration demands vey detailed and accurate data catalogues in order to get systems working together.

Usability

Only by carrying out usability tests early on can you avoid the expensive mistakes that alienate users and waste lots of time and hence money for the organisation.
My earliest introduction to the potential pilaffs occurred when I rolled out a cutting edge online CRM system that I had designed and built from scratch for a major utility company. It was first and best of breed, we had put a lot of effort into pulling information out of systems of every conceivable type to create a single view and we had done a pretty good job. We had also presented prototypes to the user base, but we had not paid enough attention or asked the right questions.

On roll-out day, none of the risks came to fruition and everything flowed smoothly, but the union representative on the call centre floor called the rollout to a halt pending her problem being resolved.

The problem was this, all users at developed a way of using speed keys to enter data very quickly while handling inbound calls. This meant that they were able to met targets and earn bonuses worth up to 20% extra on their base pay. With the new browser based system, the speed keys were not available and the bonuses were gone. Staff were threatening to leave and a strike was just 24 hours away.

Eventually we negotiated around this, but it took the gloss off an otherwise successful launch and it taught e a lesson that I’m not going to forget in a hurry. You must carry out well orchestrated usability tests on good prototypes in near perfect replications of the end user environment and go the extra yard to find out the problems from the viewpoint of real users.
Once these constraints have been encompassed into requirements and verified in UAT, you will be in a much more solid position to roll out a winning system.

Ed Taaffe is a Senior Consultant in the areas of Improving business through use of technology and hi-tech Product Management

Reblog this post [with Zemanta]

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-whwat 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 it’s 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.

Reblog this post [with Zemanta]

When is a business case not a business case (part two)

Read part one   part two Read part three  Read part four

In this section I will be talking about benefits, why they are so important to the business case and how they can be tracked right through the project, thus making the business case  a key document in successful project delivery, rather than just a tool to get the budget released.

Benefits map diagram expains the bridger method of mapping requirements to benefits

The model above illustrates our basic theory of benefits delivery.
On the left side of the diagram, we represent high level requirements.
This is intended to illustrate the level of requirements that is generally outlined in the business case.

This requirement is then tied indirectly to the composite benefits illustrated on the far left of the diagram. These benefits are the ones providing the key arguments for action.
That part of the model is very simple and intuitive. We have high level requirements and we expect to deliver the identified benefits.  The denotes that this metric is to be measured.

A key element of this approach is to remember at all times is that the requirement exists in the business case only to deliver the identified benefits and any change to the requirement or surrounding circumstance that impacts it’s ability to deliver these benefits is a red flag issue and must trigger a business case review.

The devil may be in the detail

 Between the high level requirement and the composite benefit, naturally, lies a lot of very important detail.  While this detail is not represented in the business case, but in other documents such as requirements specifications and benefits realisation plans, the exploration and bottoming out of this detail, will be critically important to the final conclusions of the business case process.


We look at this benefits mapping activity in terms of feature level requirements I.E. identifiable succinct features of the product or deliverable and with this we associate two things:

  1. The measurable benefit that is expected as a result of this feature, along with a suggestion of how it might be measured.
  2. The risks management attached to realising this benefit.  We describe it as risk, because we want to confine the change management activities to those that are necessary in order to deliver the benefits.

By taking this approach, we are proactively testing the likelihood of our successfully delivering the benefit and we are planning the change activities required to ensure that they are delivered.

Benefits realisation example

E.G. In the CO2 example, we may have assumed a fuel saving of 1000 gallons per month resulting in a measurable reduction CO2 emissions.
In order to actually realise these benefits, we might have to take steps to ensure that all the lean cars are not last to be taken from the car pool, while the big luxury ones are first choice. The approaches can vary considerably, but they have to be planned and in many cases included in the costs of the project.

Without this risk assessment and change management activity, the likelihood is great that the potential impact of replacing luxury cars with lean ones will deliver little or no benefit to the environment or to the organisation, No ROI and a project failure.

Now if we look again at our diagram, it may become obvious that we will have quite a few of these feature level requirements and that each will have it’s own mini business case including the level of ROI and the level of risk attached to delivering benefits.

 As the project takes shape and more is learned about each of these requirements, this mini business case needs to be constantly reviewed and updated so that poorer candidates can drop off the radar and stronger ones get promoted to a higher priority.

Approaching the business case in his way and continuously managing it as the development continues from outline business case to full business cases will keep the business in control and minimise the likelihood of pursuing projects that perform below expectations.

 Read part one   part two Read part three  Read part four

 

Return of the OMLB prepare for the Rescuing Angel

The power struggle rumbles on.

Am I hitting an unlucky patch, or is there an epidemic out there. Two projects in succession that I have been involved with at two large organisations have suffered the same problems. It goes something like this.

The organisation has a large IT department and like all large IT departments it has a fairly rigid set of processes and constraints. These were put in place some years ago by a rescuing angel who untangled the glutinous mess they had created and explained that now things are running again, to keep things running they need a few rules and processes.

Bit by bit over a few years, two things happened simultaneously;
1. The IT department began to abuse the rules a bit in order to wield their newly discovered power and slowly, but surely the tail began to wag the dog.

2. Certain people in the business, the ones most responsible for creating the mess, became increasingly irate at not being able to buy toys at will and play with them without having to explain themselves. A career based on the “One eyed man in the land of the blind” (OMLB) strategy had suddenly found itself on rocky ground and they disliked having to discuss these things with people that understood the manual and could ask awkward questions.

The upshot of all this was that IT shot itself in the foot once again. Their rulebook waving and power broking created the perfect opportunity for the OMLB to retake the high ground.

Now you have the situation whereby the OMLB has a new title like Business Project Manager or Business Change Manager and instead of representing the needs and responsibilities of the business in IT projects, he rules every IT project totally.
He has banned business analysts, they are too technical and he doesn’t understand their UML and work flows so he has a junior creating squiggles on Powerpoint slides. He has alienated the IT project manager and he has a supplier who is his trusted adviser and uses the OMLB as a blunt instrument to batter IT into providing them everything they need.

Testing, Change control, detailed requirements and all the other tools that help reduce the risks are viewed by the OMLB as IT placing barriers in his path and he has regular ranting sessions in the canteen with others of his calling where they bemoan the constant battle with IT.

The IT project manager manages nothing, in fact in many cases the recruitment is done very deliberately to hire somebody with no formal or other IT training, he just attends meetings with a gant chart and ticks off what is completed and he has a full set of Prince 2 documentation that often bears little relationship to the project and will never be read by anybody. He is kept well out of things other than to warn him of when he must be ready to run the application. When things go wrong of course that ‘s where the IT project manager comes in, it will be his fault.

Just to make this muddle even more confusing and hopeless, the IT Project manager reports to a matrix manager in charge of Project managers, who knows and cares nothing about any projects.
There is a PMO and they have a planner who actually manages the gants and updates a master program plan. He knows nothing about IT projects, just gants. There’s a Matrix manager for Business analysis too, but he also keeps well below the parapet.
Success for each of these so called managers is a green light or a tick in a box in a map of a journey that has no known beginning, middle, end or real purpose, It just has a map.

It has a few guide books, but they are not reliable and nobody is interested in whether this system is really beneficial, whether it will do what it promises, whether it is the best way to deliver on requirements, if there are any.

In the background, behind all of this activity, there is a huge IT department struggling to support last years white elephant and the one from the previous years. There are several projects afoot, with new names and budgets of course, adding on the requirements that were missed out on previously implemented systems and fixing the ones that didn’t work. Doing it this way hides the abject failures and overruns

Duplication of systems and data stores is epidemic and burning money in vast amounts. The inside of the IT department is once again a bulging spaghetti bowl and the day for wringing hands, IT directors resigning, OMLBs retiring and the return of the rescuing angel is becoming ever closer.

When is the IT profession going to start behaving professionally? When is it going to start engaging senior managers in business language and becoming a trusted adviser instead of an enemy?

 

Managing requirement scope

Sometimes the definition of requirements and management of their delivery is described as Scope management.  Scope management is composed of five distinct phases:

  1. Scope initiation
  2. Scope planning
  3. Scope definition
  4. Scope verification
  5. Scope change control

Scope initiation refers to the justification phase. This is when a Product management team create Market requirements and Product requirements documents or a  corporate change team will create a Project mandate and produce a Feasibility study.  It is high level, but it is critical to establish clearly that there is a need or justification and to understand the early boundaries.

Scope Planning is a lot more than it sounds and the danger in glib descriptions like this one is that they can easily lead to not taking the work seriously enough.  This is the time when the established high level need at strategic level or market level is translated into a clear product definition with features that hopefully trace right back to the benfits put forward in the outline business case.
This phase is where the real requirements engineering happens and where the product  design ideation and design phase product development will happen.

You may well be sitting there saying yes, but I only wrote down requirements for a simple off the shelf system and purchased it. Well if that was the case, going through the motions of making sure you understood the  benefits and that the product would really be able to deliver them will have been quick and easy.
 In my personal experience, the purchase of a cheap printer can be fraught with problems unless you go out with a clear scope in mind.

Scope definition.

This is where you either define work packages for the various teams of developers or suppliers, or you place and manage a procurement contract.  Without a sound plan and careful management, the best possible plans and designs can come apart very quickly at this stage as requirements are misinterpreted, deliverables fail to deliver and tests fail to impress.

Scope verification.

This is best started at the earliest possible time. Ideally it starts as soon as there is a single deliverable that can be tested alone.  This is the process of verifying that the deliverable performs, that it meets performance specifications and finally that the end product is capable of delivering the benefits.

Scope management.

This is another part of the project that can continue right through the process. It is the positive act of keeping  everything form the earliest designs to the final deliverables within the scope that was agreed and signed-off and just occasionally invoking a change request procedure to accommodate a truly great idea or a serious oversight.

These five activities applied judiciously to the definition and delivery of a product of any kind will greatly increase the likelihood of success and reduce the risk of failures.

Ed Taaffe