A Project Management Primer – Scope – Requirements Capture – Conflicting Requirements

A Project Management Primer – Scope – Requirements Capture – Conflicting Requirements (#19 in the Hut A Project Management Primer)
By Nick Jenkins

One or more requirements may contain elements that directly conflict with elements of other requirements. For example, a performance requirement may indicate that a core system must be updated in real time but the size and scope of the system (as defined by other requirements) may preclude this. Updating such a large system may not be possible in real time.

One of the most effective ways of resolving conflicts between requirements is to impose some form of prioritisation. This allows the potential for negotiation since it provides a basis for assessing conflicting requirements. For example if, from the previous example, the requirement for real time updates was rated at a much higher priority than the inclusion of full customer data, then a compromise could be reached. The main ‘online’ database could contain only the barest essential of customer details (allowing real time updating) and a separate ‘archive’ database could be established which contained customer histories.

Requirements are often heavily interlocked and much of the time it seems your stakeholders have diametrically opposed points of view and cannot come to terms. If you pick apart any set of requirement however you can come to some sort of compromise with both parties and achieve consensus. This can be a difficult and even emotional process.

The very best way I have seen to resolve conflicting requirements works like this :

1. The stakeholders draw up a list of their requirements
2. The list is organised in strict priority order with the most important at the top, down to the least important at the bottom.
3. The project team then looks at the schedule and draws a line through the list based upon what they believe they can deliver with the time/money available
4. The stakeholders assess the development position and can then re-prioritise their requirements if required or negotiate over the nature and importance of requirements
5. Once consensus has been achieved both sides sign-off and work starts

This is not a simple or easy way to achieve consensus however. Even the basic ordering of the list of requirements is no mean feat in a project of any size.

Next in the Hut A Project Management Primer:

A Project Management Primer – Scope – Documenting Requirements – Introduction

Previously in the Hut A Project Management Primer:

A Project Management Primer – Scope – Requirements Capture – User Observation

Nick Jenkins is an IT manager with 10 years experience in software development, project management and software testing. He’s worked in various fields of IT development in Australia, Britain and the USA and occasionally he learned something along the way. Now he lives on the banks of the Swan River in Perth, Western Australia, and he publishes the odd guide to help aspiring IT professionals. Nick’s website can be found at www.nickjenkins.net.