Changing Model Ownership When Needs Must: Experiences within the
Business Consultancy Department of Shell International Petroleum
Company Ltd.
Alan Hocking and Jane Orford
Business Consultancy (ICA/41)
Shell International Petroleum Company Limited
Shell Centre, London
Introduction
Advocates of the "Modelling as Learning" philosophy would not endorse a policy of handing
over a ready-made model to a. new client. In commercial environments, however, consultants
and clients move on and there is pressure to maximise return on investment. This often means
that existing System Dynamics models must be transferred between consultants and clients.
Within the Business Consultancy department at Shell both the consultants and clients change
jobs every three years or so and model handover is an issue that must be managed.
This paper details cases where, even though the rules of problem-ownership are broken, a
successful result can be achieved. The authors show that some of the learning experienced
during the initial modelling process can be shared with newcomers after the event and a
framework for thinking through model handovers.is offered.
Much of the value of the System Dynamics approach to problem structuring is in the learning
that goes on during the process of building the model, rather than in actually delivering a finished
model at the end of the project. One of the keys to a successful modelling project is that the
client, whether a collective or an individual, is confident that the model represents his view of the
problem. Problem ownership is a very personal matter, as anyone who has seen a client's eyes
glaze over at the sight of a pre-prepared causal loop diagram will know (even if the consultant
believes it to be a more complete representation of the problem than that of the client)!
There is no shortage of texts that propagate the 'Modelling as Learning’ point of view and the .
Business Consultancy team within Shell International advocate this approach in all new System
Dynamics projects: Not all projects a consultant works on, however, are new. ones; some involve
the continued support of an existing model over time. The challenge is then one of managing
model transitions between consultants and clients.
SYSTEM DYNAMICS '93 203
The importance of such transitions is accentuated in the case of Shell for the following reasons:
System Dynamics projects are usually led by a consultant, rather than the client. . That is to say,
the consultant is both facilitator and model builder and there are few cases where the problem
owner will build his own model. This style of relationship magnifies the effects of any hiatus due
to client or consultant handovers.
The second reason accentuating the need to manage handovers at Shell is that it is common for a
person to be in a job for only two to three years before moving on, sometimes to a different
function or to a different Shell company altogether.
When consultants move job, they take their expertise with them but when clients
move on, the problem (and partial solution) stays behind, for it is a function of
the business, rather than of the individual.
The extreme case is where a new client is faced with an old problem (inherited from his
predecessor) and is supported by a new consultant (who inherited very little). In such a case, the
only thing linking the two individuals is the model, built by another consultant for another client.
This situation is extreme, and undesirable, yet asking the right questions and looking for the right
signs can help both parties capitalise on the investment in time and resources made by their
predecessors. In other words, a framework for handling model transfer is required. Such a
framework should be easy to use and help the consultant and client understand both what their
objectives are and how they are going to attain them.
A Framework for Thinking Through Model Handovers
This framework is built on two main assumptions. The first assumption is that a System
Dynamics model, or any other for that matter, will typically follow a life cycle similar to that
shown in Figure 1, below, where contribution to the client's understanding (of the problem
investigated in the model) is measured along the vertical axis and time along the horizontal axis.
In the case of a new System Dynamics Model Life Cycle
project, it can be expected that most of the
learning takes place during —the
developmental ‘phase of the model. “This is
where the consultant's role is to elicit the
client's core:assumptions, values and beliefs,
in order to make explicit the client's view of
the problem. In Shell, this phase is typified
by the use of problem-structuring tools, such
as magnetic hexagons and causal-loop
diagramming in a workshop environment. Figure 1
The next stage of the project life cycle sees the development of an Ithink model, during which
time the client and consultant work together to ensure that the model is a fair representation of the
problem. At this time, the usefulness of the model is at its height, as the consultant helps the
client to test out scenarios and his own assumptions about the how the system will react. This
phase can be called maturity.
204 SYSTEM DYNAMICS '93
It is hoped that the client found the exercise useful and that his new understanding of the issues
involved in the system modelled will help him address these issues in a more enlightened way and
make better business decisions. If this is the case, then it can be expected that the model has
served its purpose and further time spent on the analysis will offer diminishing returns. The.
length of the model's useful, mature life will, naturally, vary from project to project, as issues
within projects change focus at different rates.
The second assumption reflects the scope of this paper and the authors' experience to date. It is
that handovers from ‘old client’ to ‘new client! and ‘old consultant’ to ‘new consultant’ take place
during the maturity phase of the model life-cycle.. This is seen as a valid assumption because it is
unlikely that a client/consultant pair would undertake a new project, were either expected to move
on before the completion of the development phase. Similarly, investing in model handover is not
an issue if the model is no longer suitable for addressing current business problems and is
regarded to be at the end of its life cycle, i.e. in ‘decline’. At best, this latter case is one of modal
redefinition, rather than managing the transition from one individual to another.
Now that the assumptions have been established, it is. possible to transpose the most common.
forms of client/consultant transitions into the matrix shown in Figure 2, below.
CLIENT
Old New
Old
Carte Gain buy-in
Blanche (to model)
0) i)
CONSULTANT
... Technical
Technical ~.Handover|
New Handover .
Model . ©
q@ | Buy-in . “w.,
Figure 2
This matrix takes the simple case of a one-to-one client/consultant modelling project and
considers two possible states for each of these players. Either they were involved in the original
development (labelled ‘Old’) or they have taken on this role since the project reached maturity
(labelled 'New’).. In this. context, ‘New Client’ does not suggest that the successor will
automatically become a customer of the consultant. Indeed, this is one of the unknowns that must
be established during the transition.
SYSTEM DYNAMICS '93. 205
This categorisation leads to the following client/consultant relationships, each one requiring a
different focus to the handover process:
Quadrant (i) Old Client - Old Consultant
This is the original pairing that is taken to be the norm for the development phase
of the model. It does not involve a transition to new players and handover is not
an issue.
Quadrant (ii) New Client - Old Consultant
This pairing arises. when the client who commissioned the project moves on and
his job is taken on by a new person who, at that moment, has no relationship with
the consultant. In fact, until this person is established in his new job, he may
even be unaware that the project has been carried out.
Quadrant (iii) Old Client - New Consultant
This pairing is often the case in Shell Business Consultancy, where consultants
change jobs or take on new projects more rapidly than the average client, leaving
the original client to be supported by a consultant who was not involved in the
development phase of the project.
Quadrant (iv) New Client - New Consultant
This is the situation where neither the client nor the consultant were involved in
the early stages of the project. In Shell, moving from quadrant (i) to quadrant
(iv) is simply a matter of time. This pairing is not merely an example of "the
blind leading the blind", for it is unlikely to be reached other than via quadrant
Gi) or quadrant (iii).
With this as the framework for the pairings commonly found in Shell, a practical guide to dealing
with each of these cases is offered, bearing in mind the assumption that handovers are expected to
take place during the ‘maturity’ phase of the model's life cycle (see Figure 1 above).
Guidelines for Managing Model Handovers
In any situation where a model is being handed over, the first thing to determine is the type of
handover under consideration, in other words, which quadrant of Figure 2 best describes the
situation. This question is fundamental, as the factors affecting the success of the transition can
differ from case to case. Having determined this, the following serves as a guide to managing the
transition from a consultant's point of view, although the key questions are equally valid for the
client.
Quadrant (ji) Key Issue: Gaining model buy-in from the client
- Handling the transition of a model from an old client to a new one is an issue of general
consultancy skills. The consultant should not assume that the successor has an obligation to
continue with initiatives taken before his arrival and will automatically be willing to spend time
learning the model. ‘This approach is likely to be seen as unwelcome ‘technology push' and could
very well deter the new client from continuing the project. The consultant should bear in mind the
original reasons for undertaking the modelling effort. It is more likely to have been an approach
to a problem articulated by the old client, rather than because the consultant and the technology
were available.
206 SYSTEM DYNAMICS '93
Check list of issues to be aware of:
1
The new client's perception of his new responsibilities: Does he face the same business
problems as his predecessor ? If not, then the model is unlikely to fit his perceived needs.
The personality of the new client: Some people are keener than others to stamp their
identity and make their mark, especially at the start of a new job. If this is the case, then it
may be difficult to interest the new client in work that was initiated by his predecessor.
Conversely, others may’be keen to assimilate any tools and techniques available which
might help them in their new job.
It has been said that within Shell there
is.a tendency for a person in a new
job to go that little bit further than the
person he replaced. When this is the
case, it could even be possible to raise
the height of the maturity plateau to a
new level of ‘contribution to
understanding’, or at least get the
‘same value’ from the model with the
new client. Figure 3
However, the contribution the model makes to problem-solving will fall, until the new
person is settled into the job. Figure 3 shows the path of the model life cycle during a
successful handover.
Handing over models takes time: how busy is the new client? Is he prepared to invest the
time necessary to understand the model and interpret the results? The new client ultimately
has three choices: invest time in understanding the model, have a new one built, based on
his understanding of the system, or scrap the exercise, in which case the handover process
will not have capitalised on the previous modelling effort.
System Dynamics models capture the experience and views of the problem owner and
these are woven into the model logic. One important consideration, therefore, is the level
of respect the new client holds for his predecessor's views and work. If these are held in
low esteem, it is unlikely that the new client will buy into the model and its logic. without
challenging them first. It is therefore important that the consultant be able to explain the
assumptions and logic in the model. To this end, there is no substitute for clear and
comprehensive documentation and records of the original problem-structuring sessions.
Issues surrounding trust in the model can also stem from the actual data used in the model.
Again, the consultant should be able to quote the data source and be prepared to
incorporate new data, if this is helpful to the new client.
The new client's experience with Systems Thinking: If this is limited or non-existent, the
best approach may be to first introduce the principles of feedback, system/behaviour pairs
and the factors that make this modelling approach different from, say, spreadsheet
modelling or discrete-event simulation. Without this appreciation, the model could be
perceived as an impenetrable "black box".
SYSTEM DYNAMICS '93, 207
6 Getting the timing right: Handovers stand most chance of success when the consultant is
introduced to the new client at an early stage. Avoid calling unannounced but do not wait
until the new client has established his own approach to his job (which, of course, could be
superior to that of his predecessor!) as the right moment will have been missed.
7 Building confidence: Encourage the new client to see the modelling work as an approach
toa business problem, rather than just another computer model he must become familiar
with. If possible, give a presentation of the project, not only a. demonstration of the model.
The consultant can be an important source of continuity and should be seen as an aide to
problem-solving, not just as technical support for the model. The consultant should be
sympathetic to a new client who is sceptical of the logic behind the model and receptive to
any comments he makes. Data validation and logic checking are common ways of building
confidence in the model (see 8)
8 Beware of ‘reductionism’: If the new client is interested in the model, it may be tempting to
‘reduce’ the model to its component parts in order to understand how it works. Although
this is justified, the consultant should always encourage a holistic view of the model, in
other words, not only ‘what! the model is, but 'why’ it exists at all and ‘how’ it got to be that
way.
9 Managing expectations: At first, the new client will not know what to expect of the model.
It is important for the consultant to make this clear, as high expectations can lead to
disappointment and lack of confidence in the model. Low expectations can result in inertia
and uninterest in a potentially useful tool.
The authors have had success with this type of handover by showing a willingness to incorporate
the new client's assumptions and data, rather than protecting the integrity of their modelling work.
At all times, the model is viewed as a decision-support tool, not an end in itself.
Quadrant (iii) Key Issue: Technical handover between consultants
Compared to handovers involving a new client, those between consultants are fairly
straightforward. This is because the transition is more a question of on-going support than
problem ownership; achieving model buy-in from the client has already been established. The
challenge of managing the handover is retained within the consultancy department and issues
relate to resourcing and training.
If, as we have assumed, the model is at the
peak of its life cycle at the time of handover,
the aim of the consultants should at least be
to maintain the current level of ‘contribution
to understanding’. Depending on the skills
and experience of the new consultant, it may
even be possible to raise this plateau to a
higher level, as shown in Figure 4.
Figure 4
208 SYSTEM DYNAMICS '93
There is always a chance, however, that a new consultant will find inconsistencies in the model
which, once highlighted, could pull down the contribution curve. In extreme cases, the value of all
the previous work could be brought into question, resulting in a total lack of client confidence.
Check list of issues to be aware of:
1
Maintaining expertise within the consultancy department: ensuring the availability of a
replacement consultant with the right skills and experience requires careful planning. It is a
difficult task in the context of an internal consultancy department, where there is pressure to
do ‘paid’ work. A long and smooth handover is a luxury, since opportunities to gain
experience in the particular problem area are often sparse. In some cases, it may be
impossible for the consultancy department to provide a suitable replacement. This can be
extremely frustrating for the client!
Who pays for the new consultant to be brought up to speed? Is it the client's right to
expect expertise to be retained in the consultancy department at no cost to him?
Taking the handover seriously: Internal consultancies, especially within Shell, can be busy
places and it is natural for a consultant to want to work on those projects he finds most
interesting. For the new consultant, therefore, getting to know a model that has already
been written can sometimes be given low priority. This can only be managed by fostering a
sense of responsibility for old products at a departmental level. Indeed, the consultancy
group should establish policies and procedures for handovers, whether these be agreed at
project level, or become a standard practice.
Training the new consultant: To maintain service levels to the client, the new consultant
must be competent, not only in the model functionality, but also in the business reasons
underpinning the project. If this is the new consultant's first experience in System
Dynamics, he should undertake to learn about the Systems Thinking approach, not just the
technical aspects of the modelling language. In this respect, the comments on reductionism
made in the previous section (point number 8) are valid. .
Competence in front of the client: It is possible that the client will be anxious about the
replacement of his original consultant partner. The old consultant must take the lead in
introducing his successor to the client. This is best done gradually by attending meetings
together, until such time as the client appears to be satisfied and the old consultant can
withdraw. Though the client may have little say in the choice of replacement, the more
gradual the transition, the more receptive he is likely to be.
Model documentation: This can be very helpful in introducing the new consultant to the
model. Old models, however, can be big and may not necessarily lend themselves to
documenting assumptions and scenarios, which makes handovers all the more difficult. The
new consultant should be encouraged to challenge any assumptions in the model he does not
understand,
Status quo or push for change? A new consultant would always have done things
differently and will have inherited a model he is not entirely happy with. He now faces a
dilemma: to stay with things the way they are or to push for change with the client. In this
situation, attempting to lift the model contribution plateau by introducing new ideas could,
in fact, produce the opposite effect by casting doubt on the model's fitness-for-purpose.
There is no solution to this dilemma. Pointing out pitfalls in the model could highlight the
new consultant's technical competence, but any adverse implications need to be considered.
SYSTEM DYNAMICS '93 209
Quadrant (iv) Key Issue: Depends on the route taken to get here
There are two routes to the new client/new consultant pairing. Either the client changed first or
the consultant did. In both cases, the issues affecting the success of the handover will be the
combination of those listed under quadrant (ii) and quadrant (iii) handovers. Regardless of how
smoothly the previous handover went, there is no hiding the dilemma of a.consultant supporting a
model he did not create, for a client who did not commission it.
For both the old client and the old consultant
to have moved on, it is likely that quite
some time has elapsed since the model was
originally conceived. This distance from the
origin nieans that it is no longer valid to
assume that the model will be at the top of
its life cycle at the point of handover as the
business may have changed significantly.
The diluted sense of ownership felt by the
new client/new consultant pair towards the
model will only accelerate the model's Figure 5.
decline. %
At this point, the client and consultant are best advised to 'return' to quadrant (i) and approach the
current issues with a carte blanche; see Figure 5.
Conclusion
In commercial environments, the success of a System Dynamics project depends not only on the
mathematical correctness of the model code; the most elegant of models is only as valid and
current as the problem it sets out to solve. The success of any System Dynamics model with a
business focus depends on modelling skills, consultancy skills and the changing business
environment.
Handing over models adds a potential threat to the return on modelling investment, but this
can be managed, to some extent. The issue is one of change management where the
circumstances (context) of the transition and the way it is managed by the consultant/client
pair (process) are as important as the model (content) itself. These issues are summarised
in Figure 6, below.
210 SYSTEM DYNAMICS '93.
Figure 6
Clients and consultants involved in any type of model handover should take a holistic view
instead of a purely reductionist attitude to understanding the model. Due consideration of these
points, and those given within each of the handover quadrants, will help client, consultant and the
business gain value from the initial modelling investment.
SYSTEM DYNAMICS '93. 211
