We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

IT Directions

Keith Harrison-Broninski

Using conversations to manage change

Vote 0 Votes
Let's suppose that you are working in a large engineering project and you discover a problem during testing.  A particular operation is generating so much heat that some parts are in danger of malfunctioning or even melting.  You report the issue to the appropriate Quality Assurance team.  What happens next?

It is necessary to determine the cause(s) of the issue, choose a means of resolving it, and implement the corresponding changes.  Since this is likely to involve a number of people, including engineers of various different types (structural, systems, safety, ...), the work must be planned and resourced like a small project of its own.  A first step is for the QA team to find someone to manage the work - and even this is no small task.

For a start, no-one wants the responsibility.  Everyone has too much to do already!  Further, even if someone willing can be found, approval to use them as a resource must be sought from their line manager as well as from the managers of whatever work packages they are currently involved in.  It may be necessary to go round a number of loops, involving a number of different people and teams, before the work can even begin.

In effect, there are a number of different "conversations" involved in implementing a controlled change.

First, there is a conversation for "context", in which the problem is described in full - the test results that led to it being detected, the symptoms that caused concern, background to the issue, and any other information that might help in its resolution.

Next, there is a conversation for "possibility", in which people are contacted with a view to putting together a team to resolve the problem.

Then, there is a conversation for "disclosure", in which full details are shared with possible team members, and their firm commitment is sought.

Finally, there is a conversation for "action", in which the mini-project is carried out and (hopefully) approval is gained from all necessary parties for the work done to resolve the issue.

This last conversation typically requires creation and execution of structured work to fix the issue, which may be done via a shared workspace, a case management system, or even a BPMS.  However, that work is only a part of what truly goes on.  Without the surrounding negotiations in the final conversation, and without the previous conversations, the work cannot even be started let alone successfully concluded.

Further, anyone who has carried out such conversations will recognize that they do not happen neatly in sequence - rather, it is necessary to jump back and forth between conversations, adding and removing people, as the negotiations proceed.

Similarly, it will be clear to many people that the structured work at the core of the conversation for action may itself contain many smaller versions of the whole issue, as sub-issues are discovered and rectified.  Just like the main issue, each sub-issue will require its own set of conversations.

This pattern is not specific to engineering.  It is encountered wherever work crosses organizational and management boundaries, particularly if there is a need to negotiate on allocation of resources.  Other examples I have encountered repeatedly in the last few months are implementing transformational change in local government, and planning the assignment of innovation agents to multiple customers.

If you would like to know more about how to deal with such situations, you may be interested in the further information available here.

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives