| Navigating business requirements |
 |
 |
 |
|
Recently I was talking to a client who was part of a technology implementation project that failed after go live. The post mortem threw up all the usual suspects; change management, ownership, leadership, testing, training and of course inadequate requirements definition. This paper is going to focus on understanding and defining requirements and given this is a broad topic, I am only going to express my views on the subject as opposed to summarising other authors contributions to the subject. Contemporary business jargon has developed and grown to become the language of projects. Expressions or phrases such as facilitate, functional, change management, process, scalable, seamless, delight, reengineer, transformation, value chain, etc are now common place in project rooms and business documents. Although these phrases are widely used their meanings are not universally understood. Consider the following: When person ‘A’ talks about change management, he means listening to peoples issues and ensuring they are communicated to senior project staff. When person ‘B’ talks of change management she is referring to taking the organisation on a journey of discovery. Ensuring the staff understand why change is happening, ensuring they feel included, heard and engaged in the project and that there is a formal organisation structure in place specifically set up to manage the change process. Both definitions are right and both have their place depending on the size and nature of the project and to whom you are talking to. But imagine a business manager interviewing both consultants for a project. She might ask “Do you have experience with change management?” Both truthfully say yes and both are ‘right’ from their own perspective but without substantial digging, how does the manager draw a useable distinction between the two? It is probable the manager will use her own frame of reference to make the determination thus introducing a third definition for change management. The absence of a common vocabulary is most pronounced in workshops held to gather requirements. Those contributing to a project in the requirements gathering stage are frequently unknowingly unable to express their thoughts in a manner that ensures their intent is clearly heard and understood. When a participant says “we must be able to recover a 98.5% yield from the de-boning process”, is that a business requirement, functional requirement, capability statement or what. Depending on how that statement is classified, depends on how much further information is gathered to support the requirement. Here are my definitions for some of the commonly used terms. It is not important that you agree with my definitions, just that your project audience agrees with yours.
I have read many publications that define three levels of requirements:
I prefer to think of the term ‘business requirement’ as the collective noun for goals & objectives, capability, competency and capacity, functional & non functional requirements, rules and policy. But as I am not averse to using three levels to define the requirements I would do so as follows:
The shortfall in the above is the forth level of requirements – information requirements.
Information requirements glue the technical requirements to the functional requirements. This requirement comprises screen and field definitions and attributes which are in practice the physical manifestation of the functional requirements.
Putting it all together in a simple graphic. The above is a basic traceability model. Correctly constructed it links business objectives to fields, skills and finance. So far I have not referred to business process. A process provides context for the requirements. It is not a requirement itself. It represents the preferred sequence for the functional requirements to manifest themselves to maximise business efficiency. An individual process is the aggregation of some of the requirements. By extension, all processes should be the sum of all requirements for all capabilities. However it is not unusual to have processes that do not contribute to a capability and conversely capabilities without having a process to deliver them. Introducing business process to the graphic you get: I close with the following observations Functional requirements are generally associated with a process step. If you write up a functional requirement for a process you are in danger of describing a capability rather a functional requirement. This is a rule of thumb. Commonsense should prevail. Non functional requirements for human resources are generally associated with an individual (entire) process and financial and indirect technical requirements would generally be associated with a group of processes. It is often very difficult to adequately classify a requirement – is it a capability, rule, functional requirement etc. My definitions are a good guide and if you classify most requirements correctly, then the remaining incorrect classifications are probably of little consequence. The important thing is that the requirement was noted in the first place. Technology spans all processes. You define functional requirements for a specific process/process step, but you implement technology for multiple processes. The technology is the aggregation of all the requirements. Business process reengineering projects spend huge amounts of time and money defining future state processes and comparatively little effort on functional and information requirements and almost no effort on non functional requirements. Then they question why the project is not delivering the benefits promised in the business case. I welcome your comments on the above. If you disagree with me let’s have the debate as it drives the learning process for both of us. |
