Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-what should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six -Requirements strategy can make or break your project
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 or 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.
- 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.
- A product must break even 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 adaptors 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 manager 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 its 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 from 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 reusable classes, SOA didn’t really live up billing and the API world is more about tying us to public Clouds than promoting re-use.
The theory that once you had created a “customer object” you didn’t ever need to do it again, just never gained real traction, but COTS and their Cloud cousins 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, or you go around IT to free lunches with the Cloud people.
In reality this is a very dangerous mistake and pitfalls are as follows:
- You are reading woolly, warm and friendly descriptions of what the system will do, but no detail about how it gets there. All COTS and Cloud 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 and Cloud systems with other systems can sometimes make them almost as expensive as starting from scratch, especially when you count the shortfalls you had to accept.
- The impact of the COTS systems on your infrastructure and on other critical systems can be devastating unless it is properly understood and the security risks of cloud systems not to mention integration issues are equally challenging..
The job of procuring COTS/Cloud 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 requirements apply equally and there are a number of new concerns to be addressed.
2 thoughts on “Delivering the right project”