It probably seemed like a good idea at the time: ‘rationalise’ part of the company’s research-work, and merge two small technical groups into a single specialist team. The reason it wasn’t such a good idea was that one group was composed of scientists, the other of engineers and technicians: and despite the surface similarities, they’re types that don’t easily mix. In terms of energy-dynamics, the scientist’s mind-set is ‘wood’, ideas, beginnings, hates doing anything twice; whereas the engineer’s is ‘metal’, production, immediate practicality, hates doing anything new. So there was real risk that the new team would spend most of its time and energy arguing within itself (‘fire’, in the energy-dynamics model), with the engineers most likely to ‘win’ – at the expense of the team working at all. Fortunately, the young manager placed in charge of the combined team had practical experience of both sides of the fence, to speak; and he asked us to advise on the design of a total-system – policies, procedures, information-technology and a few ‘tricks of the trade’ – which would enable the team to work as a whole, and provide the very long-term data-management needed by the parent organisation.
Part of the job was a straightforward data-flow/workflow modelling exercise, adapting a database analysis we’d previously carried out for another group within the parent organisation, and using interviews and Class / Responsibility / Collaboration (CRC) card sessions to develop a preliminary UML schema for a formal requirements specification. What wasn’t quite so straightforward was that the team needed not just to gather information, but to provide a means to assist in the process of identifying and recording the meaning of information. This meant that almost any of the ‘primary reference items’ – data-items such records for inspections, photographs, drawings, measurements, tests, materials references and so on – could be cross-referenced with any other item: a requirement for ‘multi-way many-to-many’ relationships that are not supported as standard in SQL-accessible relational databases. They also needed to be able to store, retrieve and cross-reference information across years or, in many cases, decades – sometimes longer than any one person’s working lifetime – which meant that far more attention than usual needed to be paid to consistent handling and overall management of legacy data. And they needed sophisticated security and access-control, permitting almost anyone in the organisation to view research data, yet still retain tight control – down to the individual level – over exactly who could see items in progress, or carry out specific research tasks.
At first sight, this probably seems little different from a conventional business-analysis or systems-analysis task. And in one sense it is true: which is why we used standard, conventional tools and techniques for that part of the task. What’s different is that by taking an energy-dynamics perspective, we were aware that the information-technology part of the system not only had to manage data-entry and data-retrieval, it needed to do so in a manner which also helped to ‘fill the gaps’ in the energy-dynamics stages and transitions: we had ‘wood’ and ‘metal’ in the way in which the two original groups naturally tended to work, but we also needed much more support for ‘fire’ (the discussion stage), ‘earth’ (the assignment stage) and ‘water’ (the completion stage) in the overall workflow. We also needed to suppoort, yet balance, the conflicting requirements of the scientists’ need for versatility and operational freedom (‘wood’) and the engineers’ need for tight control over procedure and traceability (‘metal’).
We were also aware the the information-technology system was only one part of the total-system. So we placed just as much emphasis on the design of procedures, and identifying ‘missing’ policies and procedures both within the team and at higher levels in the parent organisation – once again using the energy-dynamics model to help us identify the role, scope and applicability of each new procedure. The result was that the procedures and succeeding work-instructions became part of the specification for the information-technology part of the system – ensuring that we did not end up (as is all too often the case) with a system in which workflows were designed more for ease of program design than for practical use!
At the present time, the project is still underway, so we don’t yet have a full assessment of the final system. The feedback so far, though, is certainly encouraging, and there’s no doubt that by using the energy-dynamics model we were able to prevent what would otherwise have been an inevitable clash between the two different work-cultures of the original groups in the team, and thus prevent what would probably have been an apparently inexplicable spiralling decline in group morale and group productivity.