Why do organisations struggle to improve their approach to managing requirements.
Essentially because the industry doesn't present a common view of best practice, and frequently doesn't distinguish between different approaches to requirements management – i.e. high level vs low level –, or between the different possible approaches to low level requirements management.
Ideally at a high level enterprises should have a common way of defining requirements and assessing that they are met. At lower levels the methods should diverge depending on how the requirements are to be met – and the role the enterprise needs to play.
We can think of the ways that requirements might be met under four broad headings:
Package customisation is where a package or service (such as SAP) is purchased and it is customised, configured or extended (as little as necessary). In this case we usually recognise that we will need to make some adjustments to how the business operates, as presumably the package reflects industry best practice.
Package OTS is where a product or service is used as purchased with no changes made – for example MS Word. This is usually done where an enterprise does not seek to achieve competitive advantage through the use of the tool. Few businesses seek to differentiate themselves based on how well they use a word processor.
Integration may involve all of the above and how different components (including external services) from each area work in concert.
It should be clear that the ideal approach to requirements in each of these fours area differs. The failure in most requirements management approaches is that the lower level methods pollute the higher level approach. By way of analogy - the way the plumber or electrician or bricklayers needs to define what they do, and how they notate their detailed designs, is foisted upon people who simply want to describe what need in their new garage).
The approach to requirements management also needs to be aligned with the approach to project management. This introduces another issue: project management in IT.
The failure of requirements management is matched with the failures to recognise the difference between project management in IT and project management for buildings. The reality is that in IT the requirements and specifications often evolve right to the end. This is because what people want to do with the technology elements is partially determined by what the technologies can do: the technologies change behaviour. To pick to generic consumer oriented examples: a GPS navigation phone changes how one navigates, a video conferencing phone changes how one communcates (as do a texting/SMS phone, instant messaging, etc.), and Google and others have changed how we find things. By contrast, with buildings this is far less often the case: we pretty well know exactly how we want to use, say, a toilet, a door, a bed, a bedroom or a lift.
In IT delivery a great deal of the time is spent on understanding precisely what the requirements are, and therefore what the design is (including engineering calculations), what construction is required, and how things should be tested. In buildings the requirements are far more precisely understood at the start, the design is well articulated and precise before construction starts, the testing is usually more obvious (or it is covered fairly well by defined industry conventions), and so on. In buildings the scope is very well defined and the focus of the project is far more on costs, time and variance - whereas in IT the scope is seldom well defined at the start, and the focus of project management is on managing the refinement of scope (while seeing how cost and time can be contained).
For organisations in which this is not a main focus, asking how they want to manage requirements is probably unrealistic. It is a bit like a building architect asking a home owner how the plans should be drawn up, or an electrician asking the home owner how the electrical diagrams should be drawn.
So what is needed is to show some leadership . Clients need an explanation of how requirements can be managed – and how this is related to detailed SDLCs, approaches to project management, and enterprise architecture. The enterprise architecture is a logical starting point for understanding the needs as it should describes:
Sadly few organisations have a mature EA processes, and it is if anything less mature than the processes which it should be key to co-ordinating e.g. those associated with requirements, business cases, development, operations.
Ideally at a high level enterprises should have a common way of defining requirements and assessing that they are met. At lower levels the methods should diverge depending on how the requirements are to be met – and the role the enterprise needs to play.
We can think of the ways that requirements might be met under four broad headings:
- Development – where major components of software are developed
- Integration – where a number of mainly existing components are integrated
- Package customisation – where essentially an existing solution is customised, configured or extended
- Package off-the-shelf (OTS).
Package customisation is where a package or service (such as SAP) is purchased and it is customised, configured or extended (as little as necessary). In this case we usually recognise that we will need to make some adjustments to how the business operates, as presumably the package reflects industry best practice.
Package OTS is where a product or service is used as purchased with no changes made – for example MS Word. This is usually done where an enterprise does not seek to achieve competitive advantage through the use of the tool. Few businesses seek to differentiate themselves based on how well they use a word processor.
Integration may involve all of the above and how different components (including external services) from each area work in concert.
It should be clear that the ideal approach to requirements in each of these four
The approach to requirements management also needs to be aligned with the approach to project management. This introduces another issue: project management in IT.
The failure of requirements management is matched with the failure
In IT delivery a great deal of the time is spent on understanding precisely what the requirements are, and therefore what the design is (including engineering calculations), what construction is required, and how things should be tested. In buildings the requirements are far more precisely understood at the start, the design is well articulated and precise before construction starts, the testing is usually more obvious (or it is covered fairly well by defined industry conventions), and so on. In buildings the scope is very well defined and the focus of the project is far more on costs, time and variance - whereas in IT the scope is seldom well defined at the start, and the focus of project management is on managing the refinement of scope (while seeing how cost and time can be contained).
For organisations in which this is not a main focus, asking how they want to manage requirements is probably unrealistic. It is a bit like a building architect asking a home owner how the plans should be drawn up, or an electrician asking the home owner how the electrical diagrams should be drawn.
So what is needed is to show some leadership . Clients need an explanation of how requirements can be managed – and how this is related to detailed SDLCs, approaches to project management, and enterprise architecture. The enterprise architecture is a logical starting point for understanding the needs as it should describes:
- how the business operates or seeks to operate, which is turn grounded in the business drivers and constraints,
(which include technological, organisational and environmental considerations) - the existing asset inventory e.g. systems, skills, services (it is also a logical bridge to operations and costs)
- known issues and constraints e.g. issues, risks
- key design standards and preferred practices e.g. standards, patterns, template
