IT Directions

The new process modelling - visualizing processes

2011-10-27T07:50:06Z

You can't improve collaborative human work unless you can see it. In other words, you need a means of visualizing what is going on before you can even start to standardize then manage work with an eye to making it more efficient and effective.

For complex, high-level work, this is pretty much impossible without using Human Interaction Management (HIM). Planning and workflow tools show you task sequences but not the team and communication structures that enable productivity, empower negotiation, and increase use of knowledge. Further, task sequences in themselves embody a danger, in that using such an inappropriate means to describe complex human work typically results in either a restrictive level of constraint or a dangerous freedom (and often both).

By contrast, HIM provides a simple, business-oriented way to understand what is going on in a complex, high-level work process, by grouping work into goal-directed Stages, in each of which specific Roles work together in a structured way to produce and share Deliverables.

HumanEdj, the software tool for HIM, provides a number of visualizations. There are core operational views for current Plans, showing your personal outstanding work items and the status of each Stage. There are multi-layered views to provide context, showing the structure of each Plan and Plan template in terms of Stages or as conventional GANTT charts (but with advanced features about which I'll say more in future posts). There are tabular views of Plans and Plan templates that can be copied and pasted into a spreadsheet. Finally, there are resource allocation views, that show by Plan and by person the amount of effort allocated to different processes.

Many of these views identify forms of action that may be required by managers to keep work on track, either by adjusting the structure of work processes or by re-allocating the people assigned to them. In the next posts I'll look at this in closer detail. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - what about DCM?

2011-10-20T10:00:56Z

Traditionally, the worlds of project management and process management have focused on different areas. Managers who use project planning techniques are strong on forecasting and monitoring the allocation of people to tasks and the resulting costs. Managers who prefer process-oriented techniques are strong on improving the way in which work is carried out, for example via techniques such as Lean Six Sigma. The project planning approach works well for one-off situations and the process improvement approach works well for work that repeats in much the same way. But what about work that doesn't fit neatly into either category?

Much human collaborative work not only repeated (i.e., a candidate for improvement) but also highly adaptive - so flexibility on the ground is critical for success. To deal with both concerns, you need a combination of the forecasting/monitoring supplied by project management tools with the structured approach supplied by workflow tools.

This may appear to be close to the domain of Dynamic Case Management (DCM). However, cases do not have the same kind of formal structure as workflows, so it is hard to improve them. Their operation can be tightened up using business rules, but this is not the same thing as finding new and better ways to execute the work. The DCM approach is fine for the sort of low-level work in which it is safe to let the operator make their own judgements about how to do it (simple problem resolution, licensing, medical diagnosis, mortgage processing, invoice discrepancy handling, equipment maintenance, insurance claim processing, and so on). However, DCM is unsuitable for the sort of high-level, business-critical, and often very expensive work that typically crosses boundaries (complex problem resolution, research & development, marketing, complex sales, services delivery, merger & acquisition, organizational change, and so on). This latter kind of work needs careful management, for which managers need to see its structure in a helpful way, and tools that empower people from different organizations to collaborate naturally.

In particular, this means providing a combination of the resource and cost planning/monitoring features found in project management tools with the simple, clear depiction of underlying structure found in workflow tools - although with human collaborative work, you need a different kind of structure. Assigning tasks in sequence and describing their outputs is not enough.

In the next posts I'll look at how HIM makes repeated, adaptive human work visible, thereby empowering people to improve it via the 5 principles. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - a typical Activity

2011-10-19T08:26:07Z

In the last post I explained why HIM Activities provide a way to capture, maintain and re-use knowledge gained during execution of work items. Here I'll give an example to illustrate.

Consider a project to set up a new government organization. In HIM terms, there will be a Stage with the goal of setting up premises with associated physical network and computing equipment. Let's suppose that the number of staff is large enough that creation of this IT infrastructure will be outsourced via request for tender.

A key Activity in the Stage will be to gather requirements for the IT infrastructure, including details of the components required: illustrative usage scenarios, deployment types, benefit profiles, state changes, related service processes, service-level agreements, and so on. These requirements will be used as input to a Request For Quotation (RFQ), so the key output from the Activity is text, appropriately formatted for use in a RFQ document.

However, the Activity will also produce a number of other outputs. For example, gathering and analysis of the requirements will make use of a dedicated requirements management tool, to assist with completeness and consistency checking. Hence the repository created via use of this tool is also an output of the Activity - it may not be directly used to create the RFQ, but represents valuable knowledge that may well be used by the supplier that wins the bid, both to set up the infrastructure initially and also for on-going maintenance.

A further, even more indirect, output of the Activity is the way in which it was carried out - in particular, the work that was done to select a requirements management tool. This may involve, for example, a feature comparison using reports from analyst firms as well as a price comparison that required contacting vendors for quotes. The selection of the tool may turn out to be quite a time-consuming and complex task in itself, so its outputs are certainly worth re-using on future occasions that staff of the organization need to gather requirements. Even if their needs are different on other projects, it is bound to save them time if they can refer back to the outputs of this selection process.

In both cases, the value of the indirect outputs are enhanced immeasurably by their association with the requirements gathering Activity - without that, they are unlikely even to be found by the people that need them on a later date. Especially as the organization grows, knowledge such as this will become buried in a vast network of documents and data - unless HIM processes are used as a route map to traverse the network. HIM Plans provide a means to join up all work in an enterprise, from strategic decision-making at the very top, to low-level automated workflows at the grass roots.

In the next posts I'll look at resource and cost planning/monitoring using HIM processes. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - what do Activities produce?

2011-10-18T12:35:45Z

In my last post, I asked what an Activity actually produces? Is there anything else than the expected outputs that come from doing a particular piece of work?

The answer, of course, is that knowledge also arises from doing an Activity - both knowledge of how to do the Activity efficiently and effectively, and also ancillary knowledge gained during execution. Both these forms of knowledge may be as important to your organization and to its clients as delivery of the expected outputs.

However, most organizations make a poor job of capturing, maintaining and re-using this knowledge, for several reasons. This is mainly because context is critical - without this, you get information (which just has a maintenance cost) rather than knowledge (which also has a business value).

The way forward is to ensure that you define, execute and manage Activities in such a way that knowledge, both execution-related and ancillary, is automatically captured and maintained. This is what HIM process modelling provides.

A HIM Activity has well-defined inputs and deliverables, but these can be updated during execution. The final Activity along with all its inputs/outputs are preserved as part of the Plan, which not only provides a human-friendly audit trail that forms a useful part of the knowledge base of the organization(s) concerned but can also be used as a template for future work.

A HIM Activity is a place to record not only the outputs expected by management, but also the way you produced them and any supporting artefacts - all in its proper context. This is a very different thing from the pure task-based approach of traditional project planning and workflow definition.

More about Activities in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - Activities

2011-10-17T16:07:29Z

In th next few posts, I will look at Activities in HIM. For now, I'd like to offer regular readers of this blog a (hopefully thought-provoking) question to mull over.

In most descriptions of business processes, Activities are described as a means of converting inputs to outputs, optionally with the aid of supporting resources and under the control of business rules. But are the stated outputs all that arises from an Activity? In other words, is there something else that is there after doing it, that wasn't there before?

Answer in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - improving processes

2011-10-14T09:58:33Z

At this point in the series on the new process modelling, it might be helpful to have a reminder of why it is important.

For each piece of work, do you do the same tasks, in the same order? Do you create the same documents and data? Do you work so perfectly that there is no room for improvement?

Most people do not find it helpful to describe their work processes in terms of task sequences or concrete outputs, so lack a means to determine the true structure of their work, agree it with colleagues, then manage it to increase productivity, contribute more to organizational goals, and streamline their work with partners.

Time and motion studies on knowledge workers in the US show that that this problem is a very expensive one. They spend an average of 28% of their working day organizing their interactions with one another (rather than doing useful work). The cost of this wasted time to employers, and hence to the US economy, is estimated to be 650 billion dollars per annum - i.e., a cost to the worldwide economy of something like 2 trillion dollars.

However, even this figure is an underestimate. The true impact of poor human interactions is not just on efficiency, but also on effectiveness - on how well people align their work with the tactical and strategic goals of their employers. As an example, further research shows that although 82% of all organizations are undertaking some form of change initiative at any one time, 70% of change initiatives fail.

The underlying cause is that management science was not invented to deal with human collaboration - it was invented to deal with manufacturing. Current management thinking, and hence current software collaboration tools, are based on the "Scientific Management" of Frederick Taylor and Henry Ford. This task scheduling and approval approach fails to deal with the modern collaborative workplace. To manage knowledge worker interactions, we need a new management science: Human Interaction Management, or HIM.

HIM is based on 5 simple principles, which are also the basis for a software tool called a Human Interaction Management System, or HIMS. The reference implementation of a HIMS, HumanEdj, empowers people to take control of their own work, do it better, and work in a structured way with colleagues from other organizations.

HumanEdj does not compete with other workflow or collaboration tools. Rather, it unlocks the true value of such tools by providing a way to use them in higher-level, manageable Plans. HumanEdj is the missing link that organizations need to join up their collaborative work, to extend it to partners, and to improve it over time.

In the next post, I'll return to the details of how to model processes using HIM. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - how Roles help you maintain processes

2011-10-13T08:16:50Z

I entered the IT industry in the mid-1980s, at a time when developers were just starting to transition en masse from procedural to object-oriented languages. Some people saw the advantages immediately, but others found it hard to get their heads around the new approach. In particular, some developers found it difficult to understand what programs that were made of objects would actually do. Where did they start? Where did they end? And what happened in between? It seemed so much easier to design and maintain systems when you had a single procedural control flow.

The truth, of course, is exactly the opposite. Object-oriented programs are much easier to design and maintain, which is why very little software development, even in the small scale, is now procedural - mainly *nix shells (which haven't changed much for decades) and a few other specialized scripting languages.

But why are OO programs easier to design and maintain? Because they separate concerns, by grouping together the code and the data that addresses a particular area of interest. You can then deal with each area in isolation - for example, you can monitor the functionality and performance of each area, and adjust it as required. For example, you can deal with exceptional cases that crop up by specializing the object's type definition (typically by adding a sub-class) to change its actions or content in certain situations.

This is part of what Roles in a HIM process give you. Unlike swim lanes, Roles are true objects, so they can be used as templates for new objects. The last post showed how this can be used to duplicate Roles within a Plan. It can also be used to make new, customized versions of a Role to deal with special situations, either during execution of a live Plan or when preparing a template for a new Plan.

A simple and common customization is to introduce new documents or data into a Role, that can be done at any time either by the owner of the Plan or the player of the Role as part of a Stage. This information is automatically shared with everyone else in the Stage.

Another common customization is to alter the scheduling of the Role's activities. Like Stages themselves, Activities in HIM are not one-off steps in a control flow, but have a status that is set collaboratively, and may be returned to as needed. To manage this, each Activity is given an estimated number of days effort, a start date and a deadline. This scheduling information is then used to manage the Plan.

For example, the HIMS will warn you if an input to the Activity looks unlikely to be ready in time for it to complete on schedule. The Plan can then be adjusted in various ways - to declare the input ready for use when it is only partially complete, to remove the input from the Activity altogether, or to adjust the scheduling information assigned to the Activity.

It is also common to make such adjustments when preparing to start a new Plan - for example, if the template usually used for a particular type of work process would result in a cost that in this case is too high.

By contrast, if you are using BPMN, the UML, S-BPM or any other procedural process definition technique, it is not even visible how data and documents drive the process forward, and the options for adjustment are both more limited in scope and more complex to implement.

More about OO process modelling in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - adding people to a process

2011-10-12T09:24:46Z

In my last entry about object-oriented process modelling, I described HIM Roles and started to explain why they are nothing like swim lanes in procedural notations such as BPMN and the UML.

In this post I'll look at another crucial difference. This one may have you wondering how you ever managed to use procedural process notations in the first place.

Taking an example at random, let's suppose you are describing a process for creating a series of marketing brochures. One key player in this process is a graphic designer, responsible for creating the fonts, colours, images, and so on that are used in the brochures. Now let's suppose that the deadline for publication is brought forward, which results in there being too much work for the graphic designer alone. You need to bring in another graphic designer. How can you do capture this using (for example) BPMN?

The short answer is that you can't. There is no simple way to duplicate a swim lane, and even if you manage to do so, it is almost impossible to share work between the new swim lane and the old swim lane in a natural way. This is because the procedural approach is based on tasks carried out in order - as described in my last post, the swim lane itself only exists to group its tasks. There is nothing in a BPMN diagram to represent the people that do the work, or how they share its inputs and outputs.

By contrast, in a HIMS such as HumanEdj, all you need to do is copy the graphic designer Role, and assign to the copy to a different person. The new Role immediately has access to all the same information as the old Role, since it belongs to the same Stages. By default, the new Role also has a copy of each Activity in the old Role - this can be left intact, on the assumption that the Roles will negotiate informally which items of work to carry out (they may, for example, work together on all brochures) or alternatively, some Activities can be deleted from each Role to partition the work more precisely.

More about OO process modelling in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - Roles are not swim lanes

2011-10-11T10:46:38Z

People new to object-oriented process modelling often confuse HIM Roles with swim lanes in procedural notations such as BPMN and the UML. This is an easy mistake to make, since at first glance, both appear to be a way of assigning people (or machines, or organizations) to tasks.

This is exactly what a swim lane is. However, a Role in HIM is not this at all, but rather a set of responsibilities. Taking on a Role in a HIM Plan means accepting those responsibilities - and you may wish to decline.

Taking on a Role also means that you get what you need in order to fulfil its responsibilities:

Understanding of the goals to which those responsibilities pertain (the Stages in which your Role is included);
Membership of the appropriate teams (the other Roles in those Stages);
Structured communication channels with those teams (Messages sent within a Stage);
Definition of the expected Deliverables (defined as part of your Activities in each Stage);
Access to the Resources required to produce them (the inputs to your Activities in each Stage).

A Role is much more than a way to group tasks - it has purpose, behaviour and content. In particular, your Role actually contains data and documents (or more likely, links to data and documents stored in enterprise systems), and you may well add new data and documents to it as you do the work required to meet its responsibilities. A Role is therefore also a mechanism for creating, sharing and maintaining knowledge.

More about Roles in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - more about Stages

2011-10-10T11:46:21Z

In this blog series, I am describing a new, object-oriented approach to process description, that dispels the "Coordination Fog" around workplace collaboration (see Peter Denning's columns of March and September 2011 in "Communications of the ACM").

Project management and workflow systems treat collaborative activity as sequences of tasks, which is unhelpful for understanding its purpose and structure, and systems for analyzing communications history provide no means to design, manage and improve collaboration.

By contrast, Human Interaction Management (HIM) draws on research in multiple disciplines to propose that successful human collaboration is based on 5 principles - effective teams, structured communication, use of knowledge, use of time, and collaborative planning - and the HIMS lets you describe a collaborative work process as a set of related objects. Rather than focusing on the order in which activities are carried out, HIM planning, forecasting, monitoring, and improvement focus on objects of business interest such as goals and their resource usage.

One such object of business interest is the Stage, which represents a set of related goals. in previous posts, I described Stages and some of their properties. Here I will give a real-world example that illustrates how unhelpful it is to try and define real-world collaborative work by putting activities in a pre-defined order.

Let's consider a process for what in the jargon is called Complex Sales - i.e., not buying something from ebay, but rather the work by a product/service supplier to turn interest by an enterprise client into a realized sale. A typical HumanEdj Plan for such work might include the following Stages:

Record Lead - for example, update CRM with the details of a lead
Qualify Lead - assess whether or not it is worth pursuing the lead
Create Opportunity - obtain the client's requirements
Develop Opportunity - devise a solution for the requirements
Negotiate Proposal - work with the client to agree a way forward
Prepare Provisional Delivery - while waiting confirmation, start putting in place arrangements for solution delivery
Close Opportunity - act on confirmation or rejection of the proposal

Here are some key observations.

First, each Stage has different people involved (including in some cases, the client) - i.e., the Roles that take part in each Stage are different. Hence, grouping work by Stages not only makes it clear who you are working with, and why, but provides a way to group communications - in other words, messages sent within a Stage go to all and only the people playing Roles in that Stage. No more need for complicated, wasteful CC and BCC lists.

Second, it is unlikely that the Stages wil be carried out neatly in order. As anyone who has ever helped put together a sales bid knows, it will be sensible in some cases to jump about between Stages, return to "previous" Stages, omit certain activities, and so on. This is the natural way of working in HumanEdj, but means jumping through artificial hoops in a workflow or project management system.

Third, Stages mean that it is possible to plan, forecast, monitor, and improve work using in HumanEdj via objects of business interest (such as goals and their resource usage) rather than misleading and superficial characteristics of a process (such as the order in which tasks are carried out). This is a huge boon to managers.

There are many more advantages than this to the Stages mechanism. However, for now that is probably enough. In my next post, I will describe Roles in a HIMS, and how they are in fact nothing like swim lanes.

In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling - objects, not sequences

2011-10-07T06:02:42Z

In my previous entry, I explained how the HIM approach to process description offers a new, simple and powerful way of dealing with repeated, adaptive human work, as well as work that crosses organizational boundaries. In this and following posts, I'll go into more detail and explain how to get started.

The first thing to understand is that HIM is nothing like conventional process modelling. Capturing a business process using a workflow or BPM tool means drawing some kind of flowchart, using the UML, BPMN or another notation. The idea is to capture the order in which activities occur. Some activities may be carried out in parallel, others are optional or dependent, but the basic principle is to put things in sequence.

By contrast, HIM appreciates that collaborative human work is not about the order of activities, but about their purpose. You may be able to look back at a particular project, for example, and observe that certain things were done in a certain order, but this tells you nothing about why they were done in that way - particularly since similar work may be carried out in a different order next time, for all sorts of reasons. It is common to revisit or omit certain tasks, for example. People use their judgement about the situation at the time to do activities in the most efficient and effective way, rather than working in strict adherence to a fixed sequence.

However, guidelines are helpful - it is useful to have some indication of the general order in which things should be done, without being artificially constrained to working like a robot. This is what HIM provides via Stages.

Stages group activities by their true purpose - the goals of the Stage to which they belong. It is then possible for people to understand what the indicative order means in a process, and to make informed judgements about when to do specific pieces of work. People are also empowered to repeat or omit activities in a structured way, for example by re-opening or cancelling Stages. Similarly, Stages can be left open while "later" Stages are carried out, to avoid introducing unnecessary delays into a piece of work.

In general, HIM provides the same advantages over conventional process modelling that object-oriented programming did over procedural programming - and look how that changed the world. In particular, I'll say more about Stages in future posts, and show some specific examples from real-world processes.

In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

The new process modelling

2011-10-06T03:15:26Z

I often discuss in this blog how Human Interaction Management (HIM) provides a simpler and more powerful means of capturing processes where humans collaborate - the repeated, adaptive work that is central to many organizations and networks. So it might be helpful to show exactly why the HIM approach works.

HIM is based on 5 principles, that underpin all collaborative work - and HIM process modelling is an object-oriented approach in which the core object types are derived directly from the principles. However, this derivation (which is explained in my 2005 book) is too technical for people who wish just to use the approach. So here is a simpler explanation, that relates more obviously to the user interface provided by the HumanEdj tool:

1. Build effective teams: Roles each have their own responsibilities
2. Communicate in a structured way: Messages are specific to Stages
3. Create, share and maintain knowledge: Activities create and use Deliverables
4. Use your time to meet strategic goals: Activities are specific to Stages
5. Plan work collaboratively as you do it: Plans and sub-Plans are flexible and manageable

When reading the above, it is important to understand that Stages are usually given in sequence (1, 2, 2.1, 2.2, 2.2.1, 3, ...) but this sequence is only indicative. Many Stages can be in use at once, and in general the status of a Stage (started, completed, cancelled, error, etc) can be changed at any time. So, for example, a Stage can be returned to as necessary during the life of a process.

What a "Stage" actually represents is not a time period (like a project phase), but a related set of goals of the process. Hence, all Messages, Activities and Deliverables of the Stage are also about this related set of goals. Similarly, each of the Roles assigned to a Stage has its own specific responsibility for helping to achieve these goals.

You will see that this paradigm is simple (non-technical), real-world (it matches what people actually do) and helpful (it groups work along natural boundaries).

In future blog posts, I will explain more about the HIM approach to process description. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Collaboration vs communication

2011-09-22T04:58:36Z

There is a lot of discussion and advice online about use of collaboration technologies. Unfortunately, however, most of this discussion is really about communication technologies.

Collaboration technologies help manage work by multiple people, whereas communication technologies are point solutions that enable messaging and content-sharing.

This distinction is poorly understood in general, so here is a picture showing the landscape for collaboration technologies:

My own interest is in the Human Interaction Management System (HIMS), the most recent development in collaboration technology.

The HIMS is unique in letting organizations manage collaborative work that is either:

Repeated and adaptive

The Stages/Roles/Deliverables model of a HIMS is a more practical means than GANTT charts, cases or flowcharts to describe, carry out and manage such work.

or

Cross-boundary

A HIMS automatically synchronizes all participants' copies of a process via email, removing the need for all parties to login to the same server.

In future posts to this blog, I will show how simple it is to use a HIMS to describe human collaborative work that is repeated and adaptive.

The Architecture for Collaboration Tools (ACT) Initiative

2011-09-19T03:21:16Z

The HIM approach to collaborative work is one of many new and transformational approaches emerging in response to a working world that is more connected than ever. In today's rapidly changing business environment all organisations must collaborate both internally and externally to meet stakeholder needs, make the best use of resources and optimize the benefits they deliver.

This is a challenge, since organisations are aware of the need to develop collaboration strategies but the range of collaboration tools is bewildering. New techniques, methods and technologies emerge continually and hundreds of these tools overlap in functionality. In short, there is no standard way to identify the right combination of tools for your own needs - the best tools to support your collaboration strategy.

If this challenge resonates with you, then you may be interested to know of a new international research project: the Architecture for Collaboration Tools (ACT) Initiative. The ACT Initiative brings together organisations and individuals with collaboration expertise in order to provide a generic, independent collaboration framework that will enable organizations to develop their future collaboration strategy and identify the most appropriate supporting collaboration methods, techniques and technologies.

As well as myself, the core ACT Team includes Amanda Crouch, CEO and founder of the Global Business Partnership Alliance, a research led organization that enables organisations to develop effective business relationships and collaboration, and Frits Bussemaker, who is partner with CIOnet, an European Community of over 2500 CIOs and direct reports, and founder/chairman of Dutch BPM-Forum, the Dutch chapter of strategic-alliances.org and a community for Dutch members of parliament.

Organisations already participating in ACT include leading commercial companies, government departments and industry bodies in many different sectors, as well as research organizations, management schools, universities and independent thought leaders in the collaboration field. If you would like to join them, get involved with ACT and be among the first to use the ACT framework, then the first step is to support our work by taking our survey:

http://bit.ly/act-survey-2011

Your input forms a critical part of our research, and we value it highly.

Using conversations to manage change

2011-05-23T05:43:00Z

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.