IT Directions

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.

In my last post, I described a framework that can be used to guide business change - the OMG’s Business Motivation Model (BMM) - and suggested that you also need other techniques in the early stages of an initiative, project or venture. In fact a tool such as BMM is only the start.

Any form of business change must take into account a number of varied factors, any of which can derail the effort if not dealt with properly:

• Organizational structures both old and new
• Dependence and impact on external supppliers
• Perceptions both inside and outside the team
• Timescales and associated resources
• Risks and associated mitigations
• People and associated interactions
• etc.

To deal with all this harmoniously requires a clear understanding of governance. The methodology associated with Human Interaction Management distinguishes 2 forms of governance: how to set goals and stick to them (strategic control) and how to make the work fit into an organizational context (executive control).

Shown below are illustrations of the key governance roles:

… and of how these roles work both together and with lower-level roles for management control:

TAKE AWAY

In my experience, if there is a single key factor that distinguishes successful initiatives, projects or ventures, it is transparency. If everyone involved can see what is going on generally, they can understand their own part in it and make sure they are working effectively, safe in the knowledge that their work will be recognized. They can also help identify general issues as early as possible, and see why it is in their own interest to do so.

If, on the other hand, the waters are generally muddy, people go into back-covering mode. They work to rule, not only doing the minimum necessary but also spending valuable time proving that they have done so - time that would have been better spent making productive contributions. In extreme cases, in which there is little reason to believe that the work as a whole will succeed, people will devote most of their daily effort to saving their own reputations - much like a run on a bank that is suspected of failing.

In the next posts to this blog I will explain the pictures above, and show how the simple practices depicted help to ensure success both for the teams you work in, and for you personally.

(more…)