UAT – me, how do I do that?

Previous installments

IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
Requirements gathering the first big mistake
Contract negotiation and on we go

Well here we are, though dragging slightly due to the unexpected holdup when everyone was so inconsiderate as to take a long break in the Summer and get all relaxed. It seems like a very short time despite the months that have passed, but we are now nearing a milestone when the vendor delivers the systems to us and according to both the vendor’s project manager and the IT manager, we are expected to do something called UAT.  Of course it’s not written in law anywhere, but to our project manager, it may as well be because he is following the conversation two sentences behind and trying not to look too foolish.  The vendor is still driving the agenda alone and the IT manager is still sulking, but gaining in confidence as the project approaches his territory.

The problem with COTS purchases and traditional testing methods is just that.

Well, it’s just that the methods were designed for a world where teams of engineers spent months writing code and then began to stabilise it and introduce it slowly into the business environment until it was a stable release and a good match for the tightly defined requirements.  At least that was the theory, there were usually problems about interpretation of the requirements and about how the outcome was actually achieved, but at least the bits did fit together and they followed a well established pattern. Vmodel was and still is the standard.

 That was a simple theory, you had to created business requirements, the analysts translated this into designs, the developers translated that into systems, then it was refined to make it usable and fill the gaps in interpretation of business requirements.

Logically therefore, you tested the business requirements with stakeholders and got it agreed, then the designs with business analysts to make sure it was properly interpreted, then the system to make sure it fitted the design. Along the way, there had to be technical testing to make sure it could run on the clients environment correctly and then a bit of testing to make sure it worked well enough for testers to commit weeks or months of their time.
Finally you arrived at the point where you had a working system that had no major bugs and appeared to meet the needs of users and it was time to let them loose on it.  That was UAT.

It usually flushed out little bugs that had been missed, it also flushed out poorly interpreted requirements that just didn’t work in a live environment. Additionally, it served as a way to win over key users and pre-empt any likely resistance to the process change aspect.

For a simple explanation, that has taken a bit of effort and probably lost me some readers, but it’s not a simple business.

So how does our project manager apply this to a piece of kit arriving on a CD with a few minor customisations and integration endpoints?
Maybe not the million dollar question, at least not every time, but an expensive one often.

Our friend has no detailed requirements to work to, because the initial ones were not adapted, but instead, the sales guy sold an existing package and said it will meet the requirements you described. If our friend hires a tester, he will need to go to the vendor’s and ask them to help him list exactly what this system is expected to do for the client in order that he can test it.
Were he to do that, alarming as it may sound to many readers, at least a start would be made on understanding what has been agreed, what is expected by whom and what the likelihood is of all these stakeholders being in the same book let alone page.
Now I am not a sadist, despite what you may be thinking and I have no intention of bringing up the business case and the business goals at this point, our poor friend is in enough trouble already.

The IT manager is now beginning to ask awkward questions and making apparently unreasonable demands about some sort of complicated and time consuming testing before he lets us install our system on “his” environment.  Is he out to get us? He never really was supportive anyhow, because he felt he should be in charge.

So where have we got so far?

We identified the need for change and made a business case for investment of the businesses capital based on some modest assumptions sound process change and cost reduction due to efficiency and we got the go ahead to do it.  We have not tested these assumptions against the new system being proposed and we have no idea whether any of the goals will really be met other than a stirring presentation and “good feel” from the vendor’s sales rep.

We found a supplier that we felt we could work with and agreed a contract, we know of course that that contract was tipped 90% in favour of the supplier, but we hoping that all will end well.

We are now approaching eminent delivery just a little behind schedule, but nothing to worry about and we are very confused about the communications coming from the vendor’s team. We are expected to complete “UAT” in three weeks and then sign off acceptance and pay the final instalment for services and we will begin to pay the support and other fees immediately. This has a very final and serious ring to it.

We are gathering up a few people and arranging a room where they can sit and “play with” this system for a few weeks. Then hopefully all is well and we are done.

We have met our milestones so far, the budget is at or below forecast and the CEO is very impressed with us, let’ s hope these IT guys don’t spoil the party.

Next:

Whose fault is it anyhow ?

 

Reblog this post [with Zemanta]

Get a bridger badge and publish your link

Get your Bridger badge and get a link to your web site or profile.

Background to the bridger group.

Recent research has returned a unanimous demand for a bigger effort from IT professionals to communicate with businesses, to serve business need and to become more user friendly.
While there are rights and wrongs and more to this than meets the eye, we can all benefit ourselves direclty and via successful clients and employers by demonstrating our commitment to these ideals.
Only by making our clients successful will we prosper and only by convincing them that we can be trusted to put their interests first will we be chosen to work with them.

The first step in this journey is to demonstrate publicly your commitment to these worthy principals by displaying the badge and promoting the principal of bridging as a way to reassure clients and employers to trust us, hire us and follow our advice.

Why get backilinks?

Marketing professionals spend vast sums annually on text adverts (URL Links back to their web sites). The reason is simply to please Google into placing your web site or profile close tot he top of the list when someone searches for a business analyst, change manager, or project manager and related terms. Google judges you by the company you keep. Expensive text ads are cheating, but free links for friends and colleagues in the business are the fastest way up the ratings, so start getting links now and I will be sending you more introductions as suitable profiles are added to the list.

Why be a bridger?

The one thing an independent consultant or a professional lacks when t comes to convincing a potential client or employer to meet with you is a strong brand. They just don’t know what you stand for and are nervous about taking a risk with you, especially if they can call a well known firm or get a recommendation form a trusted adviser or recruiter.

By publicly demonstrating your commitment to the stated needs of your potential client and being seen in the company of many more like minded professionals, you can go a long way closer to alleviating this weakness.
The more of us that display the bridger badge and talk about our commitment to the principals of briding, the sooner we will have clients entering the word Bridger in Google when they have a new project to begin or need help with an old one.

How do I do it?

There’s only a few steps and I will make it as easy as I can.

1. Choose one of the badge styles from below and then copy the code supplied beneath it.
Pasting this code into your web site or blog will produce the badge you chose with the links back to the bridger.

2. Fill in the form at the bottom and submit it to me for attention. Within a few days I will add your profile to my new associate page with a link back to your web site, blog or profile and I will include any keywords you provide to catch the attention of the search engines.

3. Soon afterwards I will begin to send you more members who would like to exchange links with you.

Note: If you have difficulties with the form below, you can simply give me your LinkedIn profile and I will create a profile out of this.

Option one

Committed to bridging the gap between business and IT Bridger


Option two

Committed bridging the gap between business and IT Bridger

Often operating as Business analysts or Project managers, Bridgers are committed a philosophy that says "1+1>2" and going the extra yard to speak simple English, Spanish, French, German . . more


Option three

Committed to bridging the gap between business and IT

Often operating as Business analysts or Project managers, Bridgers are committed a philosophy that says "1+1>2" and going the extra yard to speak simple English, Spanish, French, German . . more

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]

Agile development is the opposite of Fagan type process inspection, is this a phenomenon or another short lived fad

 

Programming is the discipline of talking pure logic to a machine that will unfortunately take everything you say literally and act upon it.
Process, is continuum of actions or mini processes that have inputs and outputs is repeatable.
The programme is a process and the programming too is a process.  It is therefore not surprising that many old school programmers simply can’t accept the principals that make agile development successful.  Are they right?
The Fagan method of code review is a milestone in the thinking that developed around software engineering in the seventies. Invented by no less an authority than IBM, the same organisation that taught me agile fifteen years later, the Fagan method set out by code review and manufacturing strength measurement, to eliminate errors and produce perfect code.
This was not Six Sigma, but a measurement of sufficient opportunities to eliminate reworks at the earliest stage. IBM claimed substantial improvement in case studies published.  The impact on software success rates was not however significant  and I, at least, am not shocked by this revelation.

Here’s my take:
Software is built by trial and error, simple as that. Anyone who doesn’t know that has never written code and needless to say , few people who have written code ever get involved with lofty ideas like quality improvement.
1. Treating something like software development as a continuous process that can be accurately measured and improved is a theory that has some purpose but is limited in scope.
2. The problem with software is not and has never been the quality of code.
3. The definition of quality is invariably wildly inaccurate when it comes to software products.
Measurement and process improvement
I have had mixed successes in the past with Fagan like measurement of exit criteria form tasks or products and from analysing the scope and quantity of bugs by programmer, designer, functional area and other criteria. Luckily I was doing this in an organisation where I was surrounded by professional researchers and statisticians and despite my best efforts to gain and follow their advice, not a single test I could devise was able to satisfy their strict criteria for reliable measurement.

The things that did pay dividends was creating over time a culture of following strict guidelines and strategies that reduce the risk both at a design, documentation, communication and process level.
The real problem with software
Any time you analyse the causes of failure in software projects, the causes are found in a just a few places:
1. The commonest cause of failure is that the system delivered does not meet the needs or expectations of the users or stakeholders. Bad requirements, bad communication, bad UAT,  took so long that the needs had changed, etc , etc
2. The business case was built on flawed assumptions and it should never have been completed, but pulling the plug is seen as failure while a poorly performing, or even stifling system is not.
3. Too little time was spent on the core needs and too much on the flora and fauna around the edges
The definition of quality
I’m not going to quote anyone , but t bravely state that the proof of the pudding is in the eating.
This system must satisfy users by helping them to perform to the expected level or exceed it and that includes keeping them motivated or better still re-motivated. It must also satisfy stakeholders that it is delivering an acceptable return on investment
Not a definition I know, but definitions are not all they are cracked up to be

What’s the verdict then
Well my verdict is that we should use process intelligently whether at a detailed level or a framework level and bearing in mind the power of a motivated workforce, but should not try to drive a square peg into a round hole in terms of ordering something that is about intense and accurate human interaction between professions that share little understanding of each others worlds. What delivers the goods or gets the job done is thing that delivers quality.

At IBM, not so long after the Fagan era, I learned to my astonishment that, in direct contradiction of his earlier paper, the cheapest way t fix bugs was not to fix them until you had to. This was measured very simply on the basis of whether  the bug was preventing testing form continuing. If not, the developer could decide to ignore it and usually did. Once a week we all got round a table with a huge projector screen and we analysed the bugs together, drawing simple dependency  links as we predicted the relationships between them. Every programmer knows how one bug causes several and sometimes the one causing them is not manifesting itself in any other way.
A group of switched on brains after the first coffee of the day could generally choose one or two bugs each to work on which resulted in most of the remainder disappearing and not returning.
If these bugs had been tracked down doggedly by tired individual programmers we would have lost cumulative weeks chasing shadows and ignoring the power of collective minds over large areas of complexity.

My belief is that well managed agile approaches to software improve communication immeasurably and eliminate the chance of a system not being what was expected. I think this is already applied to other processes from having a suit made to furnishing your home.
I also believe that quality in delivery is as much about motivation and peer review and recognition as it is about process, testing, logging and measuring. Real quality is built in and can’t be applied afterwards.  In my view, well managed agile creates a vibrant team environment where programmers have direct contact with end users and stakeholders and receive regular feedback and recognition.

How quality should be measured
Quality is measured very simply by how the software performs for the user and delivers for the stakeholder and the two go hand in hand. The quality controller is mostly the user with input from the stakeholder and a technical reviewer.  Perfect software with nill defects is not only unnecessary, it is not wanted in a world changing so fast that it will most likely be discarded in a short period of time. Fit for purpose is the ultimate measure, once purpose has been agreed.

Why you still need business analysts and change managers when you do agile.

The first reaction to the theory of agile is to think something like, ”great, now we don’t to pay business analysts and change manager”.

It is logical without a doubt. You are not going to interview stakeholders, try to merge all the information, improve the waste and perfect a new process or design like we did in the good old days are you?No, you are going to very carefully select knowledgeable, committed and influential stakeholders and make them part of the team. Then you are going to facilitate them while tey design the changes.

What a splendid idea that really is. In one fell swoop you have created champions, educated them and built their commitment. You have fed the grapevine, the only truly effective channel of communication, with positive accurate messages delivered with conviction and enthusiasm by respected influential people.
At the same time you have gathered the most important knowledge into one place and not only got their input but had it bounced around amongst them and built up in increments.

How could it possibly be wrong? and how could it fail to win loyal support fast?

Welltheory is a fine and wonderful thing, but experience shows us a couple of important things: >

1. When analysts go about requirement the formal way and they interview everyone who could possibly be important to the project and hold workshops and demonstrations, it often emerges that:

 

a.

yes;”> Stakeholders are often deluded about what really goes on, they think big, but don’t do detail.

Senior stakeholders have imaginations just the same as programmers and when they suddenly get the feeling that they have box of lego and nobody
is watching, they begin to get creative in their thinking.

If this is allowed to happen in an agile project, then it will quickly begin to flounder
. Here’s where an experienced BA can test the theories, verify the processes and police the scope.

2. When change managers tackle a major change there are two forces in particular to be reckoned with:

a. The early adapters and champions that are encouraged and developed and who spread the word and are a generally positive force for change. Amongst these will often be people who resist and challenge things because they are taking ownership and are very serious about the project.

< b.

The blockers who initially grumble and then sit in ambush. Some of them are very powerful generally and amongst them will be people who are always agreeable, appear to be the picture of cooperation and are a joy to evangelise to, because they have not the slightest intention of taking any of it seriously and don’t feel even a little threatened.

These people will wreak havoc left to their own devices and a strong experienced change manager is critical to identify and manage the threat in a safe and appropriate way.

 

So how agile is agile?

Agile is very clever stuff and it can deliver an awful lot very quickly and cheaply when used by an intelligent , experienced team, but is a methodology, not a wonder drug, so use it to the limits, but use it in the appropriate setting and don’t throw away all the safety nets.

Ed Taaffe

A Bridger or a BA how do I choose?

At first glance it may seem that there is little difference between a BA and a Bridger.
First off, it is important to realise that there is more than one flavour of BA and end also more than one flavour of Bridger so every opinion is completely valid. Additionally it is likely that a Bridger will also be an experienced BA or Product manager and some BAs will, knowingly or not, be Bridgers.
In principal I do think it is easy enough to draw some clear comparisons that differentiate the Bridger form the BA.

  1. The profession of BA within the world of IT systems and process automation has evolved almost entirely form the IT profession as opposed to from the Business . Even with a large number of Universities now producing Business Analysts, this has changed little and the curriculum is heavily flavoured with IT as opposed to business. These BAs are really much closer to requirement engineers than Business Analysts in my view.
  2. The BA almost always operates as part of an IT lead project and under the leadership of a Project manager employed by the IT department or indeed by the external system supplier.
  3. The BA is invariably an analyst by nature, extremely oriented towards process, mathematics and systems as opposed to being business savvy, intuitive or people oriented.
  4. The Bridger is an experienced business person with a business training and an ability to empathise with business managers, to understand and champion their concerns and to help them find business solutions.
  5. The Bridger is a people person with experience and knowledge of human motivation and the fundamentals of behavioural change within an organisation and as such is able to define solutions with an eye to their impacts at an organisational level and the likelihood of their enthusiastic and successful adoption
  6. The Bridger also has training in IT and sufficient understanding of what is possible to be able to translate between the language of systems and the language of Business.
  7. So when should you use a Bridger instead of a BA?

    When you are approaching a project that you intuitively expect to meet with a level of resistance within the business, it is critical that you choose someone with a heightened awareness of change management issues. Much of the potential risk can be eliminated at the business process or requirements engineering stages as opposed to surfacing on launch day. Requirements engineering can and should be used as a tool to communicate the rationale and potential impacts of change and to build in a degree of acceptance early on.

    When you have complex business problems to solve that require more than just basic process engineering to resolve it and requires the continual engagement of senior stakeholders both as contributors and accepters.

    When you have a history of conflicts between IT and the business in terms of IT investments it can be beneficial to have an arbitrator and fixer who can understand both sides of the argument, present them effectively to the other side and gain critical agreements that allow for progress to be made.

    When you want to understand how technology can deliver competitive advantage as opposed to which is the marginally better technical architecture.