Serge Thorn provides the following definition - “Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project”. This triggered the thought that most manage requirements practice that I have seen operates from a project perspective rather than a business perspective. That is, we take requirements in and ensure that we deliver them.
What is wrong with this? I think we generally gather requirements adequately. We sometimes don’t have a common understanding. We sometimes miss changes in requirements. But we have approaches that will pick up these issues. We have established practices to ensure that we implement the requirements. In general, I think we manage requirements into projects pretty well. Where I think we often fail is managing requirements outwards into the business.
First, let me sequence these requirements categories (and add an extra one) to this list. …
- Business requirements – this starts with the perceived gap between where the business is headed and where the executive wants the business to be. We need to make more money – new channels, new products, new customers, new markets, sell more to existing customers, etc. Or we need to get better value – reduce costs, increase volumes, improve quality, squeeze suppliers, etc. Alternatively, there may be slightly softer objectives such as improve customer service, gain insight into customer behaviour, contribute to CSR, etc. Often there will need to be a balance between such objectives.
- Commercial / financial requirements – constraints on costs, on timing, sourcing requirements, allocation of scope to different parties to the project, etc.
- Process requirements – the business requirement will typically drive changes in business processes. These may be macro level transformation changes – completely new processes – or more often small adjustments to existing processes.
- Functional requirements – this is where IT people start to get comfortable. How will data be transformed, what transaction will be implemented, what sequence of screens will be delivered, etc?
- User requirements – users are usually interested in getting their jobs done, they want it to be easier and quicker. But don’t go too far because I may lose my job. Or sometimes, it’s the other way round.
- Technical requirements – NFRs, performance, security, availability, backup & recovery, business continuity, etc
What’s the problem? First, we often see the business requirements as “context” rather than project objectives and frame our project objectives at a lower level. Second, we sometimes forget that implementation is a business and IT activity. Third, we don’t give the correct priority to users. Fourth, non-functional requirements are poorly collected, poorly understood, poorly planned into the project, and inevitably poorly delivered. Fifth, the commercial, financial and contractual aspects of a project are often poorly designed or poorly communicated.
I said that we usually gather requirements adequately, I’ll withdraw that because my experience is that we very often only get the functional and user requirements down well. It is generally easy for analysts to talk to middle managers and end users and they generally know what they want to do their jobs better. Getting senior executive time is difficult, getting them to walk through the business requirements in detail is near impossible – lack of time and confidentially are the excuses. Very few businesses are process aligned and very few managers are process aware. NFRs are usually vague, incomplete and wrong!
A project is a means to an end not end in itself. I was once the chief architect for a business transformation that was all about making a complex business model work successfully. The business had been making poor profits selling a wide range of products to multiple customer segments, the transformation was to streamline processes across the business, reducing costs and improving sales. Just as we were kicking off the programme, the board had a brainwave – simplify the business! Reduce the product range, pull out of unprofitable segments, and eliminate poorly performing channels. They cancelled the IT enabled transformation and set about a business led transformation which delivered results in 12 months instead of 3 years.
We were implementing a customer service system, we scheduled a workshop with a manager and his team to develop a caller authentication process – how would we identify them, how would we know what information they were allowed and what actions they could instruct us to take, etc. The manager turned up and proudly displayed a flowchart that he had put together. It was flawed, a caller refusing to give any information would have been given access to administrator functions!
I joined an organisation and one of the projects was to provide an information service to about 80 other companies. The project team did not understand that part of the project was to host the use of the information not just provide the information. The result of this lack of understanding of the contractual requirements was a hasty and expensive procurement and commissioning of servers at the back end of the project.
A typical approach to ensuring that requirements are met is illustrated below as a ”V-model”.
There are some problems with this approach which reflect the problems with the testing approach that it mirrors. Acceptance activities are back-loaded in the delivery plan which means that any change raised is likely to be expensive to deliver and delay implementation. The more fundamental requirements which have the biggest impact are reviewed even later. The benefits review which assesses whether the project actually has contributed requires several months of live running. In the worst case the solution could have had a negative impact. This approach also gives a project momentum which encourages “good money to be thrown after bad”.
Testing professionals developed the “W-model” to address the issues of their “V-model”. I have tried with limited success to illustrate a sort of “W-model” for requirements:
Business alignment reviews – the steering group should continually review the business objectives, the commercials and the project or programmes contribution to these. If another initiative has already delivered the benefits, the financials are off plan, the sourcing arrangements are not working, the goals or the anticipated benefits have changed then the project may need to be cancelled or its remit changed. These reviews should take place frequently for the duration of the project or programme as a steering committee agenda item.
Business readiness reviews – it is important to ensure that the business really understands what it is getting and that it has put in place the business component of the solution. This may be training, procedure manuals, publicity, staff changes, relocations, contractual agreements, etc. As change requests are raised any of these items may need to change as well. This is a continual process which will ensure alignment at a detailed level. It reduces acceptance risk by ensuring that either change requests are raised in the project early enough for them to be handled without a schedule impact or allows business changes to be made.
Commercial reviews – this is an area which can degenerate into an adversarial relationship with damaging consequences for the project. In reality, problems in this area are created by people trying to second guess the motivations of the other parties. They get it wrong but act on these wrong assumptions. When provider and customer are acting in this way you get escalating misunderstandings. Regular free and open discussions are important, understanding the commercial goals of all parties is important, stating assumptions is important.
Conference room pilots / prototypes – CRPs and prototypes of various sorts make the requirements visible in a form that is similar to the delivered system. They bring requirements to life and allow changes to be captured much earlier in the project lifecycle. They bring forward acceptance risks and can in some cases be used to support business and IT operations training.
Model office – a model office can be treated as an extension of the CRP / prototyping phase. The model office will involve more users and the solution will be at a more advanced stage. The purpose is testing rather than demonstration.
Infrastructure simulation – a typical approach to testing infrastructure is to specify - build – instrument – test – revise. While there is nothing wrong with this approach of itself. It does require environments, it does require procurement, it is time consuming and expensive. A more effective approach is to use infrastructure simulation software prior to this activity which gives a much more robust specification – it also allows multiple scenarios to be examined.
Infrastructure proof of concept – the specify – build – instrument – test – revise process can be usefully extended to give greater confidence the NFRs will be met by developing a proof of concept application that is a “mock up” of critical functionality . This can be performance tested on the proposed infrastructure much earlier than the actual application bringing performance risk forward in the schedule.
The approaches outlined are based on practices that I have applied to large programme delivery that have helped ensure we deliver the right thing.