My last post included a diagram showing the different high-level roles involved in the governance of a business change effort, and promised to explain more. In this post I will discuss a role that is pivotal to success, yet almost always misunderstood - Requirements Management.
Ask a range of people to define Requirements Management and you will get a range of answers. Some will say it concerns the management of a team of requirements analysts. Others will mention maintenance of a requirements repository. Many will talk vaguely about "engaging with the business".
Only rarely will you hear anything about the true focus of requirements management, which is sustainability. Anyone can run workshops and document a resulting set of "business needs". It is not even particularly hard to keep these documents reasonably up to date. What is far harder is to ensure that your requirements are key to controlling business change - that they guide all the work carried out through all the life of an initiative, project or venture.
Achieving this requirements nirvana has several aspects.
For a start, your requirements repository must contain the right sort of artefacts. The most beautifully constructed use cases and sequence diagrams in the world will not make up for there being no domain model (surprisingly often the case), process architecture, organizational structure, and so on. Here it is not one size fits all - although certain information is always necessary, the degree of detail and appropriate formats vary from situation to situation.
Then there are scope issues. What is the reach of your information and your interactions? Have you modelled enough or too much? How far do the tentacles of your requirements gathering and analysis stretch, and how should you deal with the boundaries? More subtleties that take skill and experience to handle.
A different but vitally important aspect is how the requirements are used. Here it is no good relying on informal interactions with colleagues. However good your inter-personal skills may be, everything can - and will - go to hell if you don't have formal processes to manage the flow of intent (which includes the flow of information but covers rather more). Rely on goodwill and a single calendar clash, annual leave, change of position or accidental CC ommission may throw a small but fatal spanner into the works of a huge programme.
Further, like all forms of management, it is necessary not only to define goals and provide resources but to monitor the work carried out and adjust as necessary. Requirements can be wrong, for a start, or simply need enhancement based on the in-depth experience of those charged with implementing them. Further, requirements management is closely tied to other types of high-level management, as the diagram in my last post shows. These demands make the need for formal, well-understood processes (as opposed to informal human interactions) even more vital.
The processes in question are, as regular readers of this blog will be aware, not the kind that can be described using flowchart techniques - rather they are the iterative, interactive, innovative kind that typically cross organizational boundaries. To understand and describe such processes, you need the techniques of Human Interaction Management (HIM).
Orthogonal to all the concerns above are relationship issues - within the requirements team, with those who must implement the requirements, and with stakeholders both internal and external. The best artefacts and the best processes cannot achieve their purpose if the people involved are mis-aligned. Here again it is necessary to apply HIM principles - teams, communication, knowledge, time management and planning are all essential factors.
TAKE AWAY
In my last post I emphasized how transparency was the key factor in success of a business change initiative. Many people find it hard to achieve this - the culture they are working within may discourage it, for example. The way to solve such problems is not to make a general demand for "more open-ness" or any other form of deep organizational change, but to focus on intended outcomes - one by one.
This comes down to the aspects of requirements management discussed above. Make a public case for each aspect in turn, via a formal document, using language that is simple and neutral. Those above, around and below you - whatever their priorities or agendas - will find it hard to resist the simple logic of each small change to working practice.
Working softly softly in this way, you will eventually find you are where you need to be. Look after the pennies and the pounds will take care of themselves, as they say. Or used to, before the credit crunch :-)
Stay tuned for more advice on business change made easy.
Ask a range of people to define Requirements Management and you will get a range of answers. Some will say it concerns the management of a team of requirements analysts. Others will mention maintenance of a requirements repository. Many will talk vaguely about "engaging with the business".
Only rarely will you hear anything about the true focus of requirements management, which is sustainability. Anyone can run workshops and document a resulting set of "business needs". It is not even particularly hard to keep these documents reasonably up to date. What is far harder is to ensure that your requirements are key to controlling business change - that they guide all the work carried out through all the life of an initiative, project or venture.
Achieving this requirements nirvana has several aspects.
For a start, your requirements repository must contain the right sort of artefacts. The most beautifully constructed use cases and sequence diagrams in the world will not make up for there being no domain model (surprisingly often the case), process architecture, organizational structure, and so on. Here it is not one size fits all - although certain information is always necessary, the degree of detail and appropriate formats vary from situation to situation.
Then there are scope issues. What is the reach of your information and your interactions? Have you modelled enough or too much? How far do the tentacles of your requirements gathering and analysis stretch, and how should you deal with the boundaries? More subtleties that take skill and experience to handle.
A different but vitally important aspect is how the requirements are used. Here it is no good relying on informal interactions with colleagues. However good your inter-personal skills may be, everything can - and will - go to hell if you don't have formal processes to manage the flow of intent (which includes the flow of information but covers rather more). Rely on goodwill and a single calendar clash, annual leave, change of position or accidental CC ommission may throw a small but fatal spanner into the works of a huge programme.
Further, like all forms of management, it is necessary not only to define goals and provide resources but to monitor the work carried out and adjust as necessary. Requirements can be wrong, for a start, or simply need enhancement based on the in-depth experience of those charged with implementing them. Further, requirements management is closely tied to other types of high-level management, as the diagram in my last post shows. These demands make the need for formal, well-understood processes (as opposed to informal human interactions) even more vital.
The processes in question are, as regular readers of this blog will be aware, not the kind that can be described using flowchart techniques - rather they are the iterative, interactive, innovative kind that typically cross organizational boundaries. To understand and describe such processes, you need the techniques of Human Interaction Management (HIM).
Orthogonal to all the concerns above are relationship issues - within the requirements team, with those who must implement the requirements, and with stakeholders both internal and external. The best artefacts and the best processes cannot achieve their purpose if the people involved are mis-aligned. Here again it is necessary to apply HIM principles - teams, communication, knowledge, time management and planning are all essential factors.
TAKE AWAY
In my last post I emphasized how transparency was the key factor in success of a business change initiative. Many people find it hard to achieve this - the culture they are working within may discourage it, for example. The way to solve such problems is not to make a general demand for "more open-ness" or any other form of deep organizational change, but to focus on intended outcomes - one by one.
This comes down to the aspects of requirements management discussed above. Make a public case for each aspect in turn, via a formal document, using language that is simple and neutral. Those above, around and below you - whatever their priorities or agendas - will find it hard to resist the simple logic of each small change to working practice.
Working softly softly in this way, you will eventually find you are where you need to be. Look after the pennies and the pounds will take care of themselves, as they say. Or used to, before the credit crunch :-)
Stay tuned for more advice on business change made easy.
I agree with transparency and small incremental changes in helping bring about change. So often organizations want to go transform themselves or implement a new process overnight.
You talk a bit about requirements in context of domain model process architecture and organizational structure. I'd be curious how you see organizations mapping their requirements to core values, strategic plans and vision. Have you seen examples where these are formally included in the process?
Yes, I have, Eric - my recommendations for how to achieve this are captured in the GOOD methodology associated with HIM (see the HIM Web site: http://human-interaction-management.info). I will be discussing the details in this blog series - stay tuned!
All the best
Keith
Another great article from you Keith. Very interesting to hear your views on management and the different ways of running a business. I have been an integral part of an up and coming time management company and some of the points raised here will help me in the future.
The point about monitoring the work carried out is essential in my eyes. It is not enough to just give someone the requirements as they may change or need adjusting along the way.