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]

Learn about Agile from Keith Richards

Keith Richards of Keith RichardsConsulting gave me my first formal training in DSDM nearly a decade ago and I am thrilled to have him contribute to our blog. If you would like to know more about Keith’s methods, you can purchase his book;
‘Agile Project Management: running PRINCE2 projects with DSDM Atern’ by Keith RIchards published by TSO’

What is Agile?

The word ‘agile’ has now become the hottest term being used in the methodology arena, but what exactly does it mean?

Amongst project managers and process mentors there is a broad understanding of the ethos of ‘agile’ but equally there is little agreement on the exact specifics of the genre.

Here are the views of KRC about the ‘new wave’ of approaches which are challenging the traditional view on how to deliver business benefit in the most effective way.

KRC believe that to be ‘agile’ means satisfying a set of criteria. These ‘criteria’ can be described as follws:

Responsive to change

Scope tolerant

Collaborative

Iterative

On time

Built incrementally

KRC also believe that the highest level of performance in the agile space can only be achieved if there is also compliance to a further three criteria. These are:

Business Focus

Quality Focus

Communication Focus

Over the coming weeks KRC will add to these criteria – in the meantime please get in touch if you would like to contribute.

 

Keith Richards