Internal Consultants

Successful implementation of new technology is more efficient if there are experienced people available to answer questions. The first time an organisation uses a new technology it makes sense to employ external specialists to provide guidance. To get maximum advantage from investment in external consultants, an organisation should only have to ask them each question once. Rather than continual reliance on external experts, Project Clinics can be used as a mechanism for gathering the answers to questions and communicating those answers throughout the organisation. This paper explains how the Polish State Railways have used Project Clinics to progressively gather knowledge from external consultants, and build a knowledge base along with a team of internal consultants. The internal consultants are able to guide project groups in the application of core object-oriented skills like: data modelling, context modelling, event partitioning, process , data and state correlation, allocation modelling, component reuse and viewpoint modelling.

Keywords: Internal Consultants, Project Clinics, Technology Transfer.

Context

Today's systems involve a growing variety of products and disciplines and need more and more technological and organisational skills. Whenever an organisation does not possess a required skill, it makes sense to buy the services of an appropriate external consultant. The consultant works with you to answer your questions and help you to make effective use of a product, tool or technique. Next time you have questions, the consultant returns and you go through the same cycle. The questions are answered, you are making progress and everyone is happy.

This use of external consultants is an effective investment providing you are using them to answer new questions. If you are continually using external help to solve the same problems it is a sign that the organisation is not learning and you need to develop some mechanism for trapping and transferring knowledge. Consultancy is a product, and like any other product it can be made visible, tangible and transferable. In order to take full advantage of external consultancy, an organisation needs a procedure for capturing and communicating experience. This paper describes how Polish State Railways are building a knowledge base by developing their own team of internal technical consultants.As part of a restructuring effort, Polish State Railways (PKP) are doing a large project. The aim of the project is to build systems to improve quality of service, reduce operational costs and improve financial results of operations. The project, started in 1993, consists of 80 applications to be developed by the year 2000. The central project office is in Warsaw, but the application teams, users and developers, are spread over nine locations from Gdansk in the North to Krakow in the South. The teams are using the Coopers & Lybrand Summit D methodology and a mixture of Systems Engineer and Oracle CASE tools. Data modelling, context modelling, event partitioning, process , data and state correlation, allocation modelling, component reuse and viewpoint modelling are all skills that are used on the project. The challenge was to design a way to transfer experience and good ideas between the project groups.

The Concept of Project Clinics

Our courses in core analysis and core design skills provide training in how to think in appropriate abstractions and how to understand and communicate systems knowledge. The developers learn how to build a variety of systems models and how to use those models to analyse, design and build systems. When the developers apply the core skills on their own projects they need a feedback loop which we provide via project clinics.

We introduced the project clinic as an alternative to advanced training. Instead of taking additional courses, the project clinic provides on the job training. The aim of a project clinic is to keep a project healthy. Think of a healthy project as one where tools and techniques are being effectively used to assist the project team to build the system. It is also a healthy sign if the same tools and techniques are helping the project manager to estimate the work and manage the project. Hospitals are places where people go when they are sick and need to be cured. On the other hand, clinics exist to keep people healthy. When people go to a clinic they are taking preventive measures to make sure that they stay healthy and are kept aware of developments in health-care techniques. Project clinics do the same thing for software projects. The clinic is designed to make sure that the project stays healthy by identifying and solving problem areas and ensuring that the project continues to make satisfactory progress.

The clinic is a mixture of formal lectures, informal discussions and work sessions. The subject of the clinic is driven by the needs of the project. To give you an idea of how varied they can be, here are some examples of the subjects for previous clinics:

Get the project started
Verify the context of the system
Explain how to model an event response
Show how interact with customers using analysis models
Review the estimates for the project
Plan best use of a particular CASE tool
Define the interfaces between projects
Review the systems architecture map
Design and implement sample transactions
Hold a tutoring session on interface design
Plan the best way to identify reusable design components
Plan a management presentation using the projects' models
Inform managers about measurable deliverables
Build design templates for an object-oriented environment

During the clinic, the clinician identifies project problems with the team members. He or she demonstrates how to solve the problems, and how to avoid creating new ones. The clinician answers questions from the team members, and explains the best ways for the project to proceed. The clinic is a hands-on workshop using material from the real project.

In 1994 we ran two project clinics for the PKP project teams. One clinic reviewed a project data model and answered questions about alternative ways of using the modelling technique. The next clinic was on the subject of defining and controlling inter-project interfaces. Both clinics were effective in meeting their objectives and plans were made to run a series of clinics during 1995. It was then that we considered ways of how to make the clinics most effective.

Considering the large number of projects involved, it was clear that the same questions were likely to be raised by different people, and repeating the same work is not an effective use of external consultants. PKP would be gaining more from their investment in the clinics if there was a way of making the experience from each clinic easily communicable to whoever needed it. We needed a way of gathering the answers to clinic questions and a technology transfer mechanism for making that knowledge available when needed. We proposed to solve the problem by using the 1995 clinics as a way of "growing" internal consultants.

Training the Internal Consultants

At the start of 1995, 14 developers (at least one from each of the nine locations) agreed to do the training to become internal consultants. The training takes the form of: attendance at all of the project clinics, special technical sessions, sessions on how to do technology transfer. By the end of the year the aim is for each internal consultant to be able to run his or her own project clinics. Figure 1 summarises our plan for running the clinics.

Figure 1: The subjects covered in a project clinic are gathered and packaged as tailored material for running another clinic on the same subject.

Clinic participants are members of the project team for whom the clinic is being run together with the fourteen technical consultants. All clinic participants must have attended core analysis and design skills courses. Important facilities are a quiet room with plenty of writing surfaces: whiteboards, blackboards, flip charts. We start by stating and reviewing the aims of the clinic and explaining the structure that we have designed to address those aims. The project team members raise technical questions and present specifications for review, we work together to answer all the questions and to provide guidance for the project.

After the project team's questions have been answered, we have a review session with the technical consultants. We talk about the questions that were asked and how we answered them. We review the technical topics that were discussed and make sure that everyone has the understanding necessary to answer the questions. We also use these sessions to teach technology transfer skills like: how to identify the real question, how to identify a useful abstraction, how to answer questions, effective listening.

After the clinic we review all the notes and models built during the clinic and produce written guidelines for the project team. We also package the experience from the clinic so that it can be used by the internal consultants when running future clinics. We organise the material into subject matter related groups called clinic modules. The modules take the form of slides (pictures, summaries, example models) that can be used in clinics and consulting sessions together with a detailed consulting guide. Some clinics produce new clinic modules, some update existing modules. We send copies of the clinic modules to the technical consultants and ask them to review them before the next clinic. We ask them to tell us whether we can make the material more usable for them. We also remind them that, when they are running their own clinics, they will have the responsibility for producing and updating the clinic modules.

The timetable for the 1995 project clinics is:

January '95 3 days

April '95 3 days

June '95 10 days

September '95 5 days

December '95 5 days

Between the June and September clinics each technical consultant was asked to build up experience by running a project clinic in his or her location.

The Results

We kept a record of all the questions (a total of 114) that were asked at the first 4 clinics, here they are summarised into high level groupings:

Jan Apr Jun Sep

Context Definition 1 4 - -

Analysis Details 1 4 2 1

Event Partitioning 1 1 9 -

Inter-Application Interfaces 2 10 8 1

User Involvement 6 2 1 12

Analysis/Design Connection - 6 11 3

Data Modelling 2 5 5 5

Requirements Strategies - 2 1 5

Specification Maintenance - 3 - -

The clinic session on each of the questions involved:

Listening to the questioner/s and understanding the real question
Making the question visible by drawing some sort of model or diagram or note
Interactively working through some solutions
Recommending a solution
When necessary, running a working session for participants to experiment with a solution
When necessary, conducting a refresher session on a related technical subject

The variety and spread of the questions illustrates how the technical consultants were exposed to a wide range of topics.

After the January clinic we built 6 clinic modules which were reviewed by the technical consultants and discussed at the April clinic. At the time of writing, after the September clinic, we have captured the clinic experiences by building the following 14 clinic modules:

1. Project Clinic Planning

2. Defining Project Scope

3. Event Modelling Strategies

4. Data Modelling Strategies

5. Users and Systems Development

6. External Design

7. Interfaces Between Applications

8. Models, Summit D and CASE

9. Systems Thinking

10. Incremental Implementation

11. Controlling the Project

12. Reusing Knowledge

13. PKP Examples

14. Technology Transfer Skills

Each of these modules contains from 15 to 25 slides and includes a detailed consulting guide. Wherever possible the consulting guide refers to the question and project that prompted the need for that portion of a clinic module. For instance there could be a note that says: "The Wagons Inventory Project, raised this question because there was conflict between different users' requirements." The idea is to remind the consultants of the circumstances of the question in order to help them recall as much as possible about what happened at the original clinic/s.

Apart from being an aid to running project clinics, another function of the clinic modules is to act as a communications device between technical consultants. Every time a consultant runs a project clinic he or she is expected to produce material to update and enrich the current library of clinic modules. As we gather more examples from projects, it is likely that module 13, PKP Examples, will be subdivided into smaller, subject matter related groups. The integration of new clinic material will be the responsibility of one of the technical consultants attached to the quality assurance team.

After the June project clinic, each of the technical consultants was asked to conduct a project clinic, produce a report and raise any questions about the form or conduct of the clinic. In September the consultants presented their clinic experiences. Each consultant explained his or her plan, showed us the material that he or she had used and told us what had happened and what had been learnt as a result of running the clinic.

For example, one consultant planned to run a clinic to explain the data naming conventions and project scoping to 9 project staff. She learnt that her clinic plan was too ambitious and she would have done better to restrict herself to one topic. In the clinic report, the consultant says "Naming conventions did arouse a lively discussion.....Since the discussion went on, I was unable to cover the second topic".

Each of the clinic reports provided useful insights and the consultants had a good opportunity to learn from each other. During the last year, the 14 developers have become a strongly cohesive team of technical consultants. They have all learnt new technical skills in parallel with technology transfer skills and most importantly have improved their ability to listen to, ask and answer questions. As one consultant said: "It was good experience, though not an easy one. But it is always most difficult to start".

Conclusions

Our experience has taught us that the skill that is most difficult to learn is the ability to think in abstractions, especially the high level abstractions needed for successful object-oriented systems development. When learning a new technology people need tangible, physical characteristics in order to relate the new technology to their world. We have addressed this problem by encouraging the consultants to consciously take multiple viewpoints of each of the problems presented to them. In other words, no viewpoint is more "right" than another, they are just different for different purposes. This is the most difficult single concept to learn. Developing an acceptance of multiple viewpoints builds up the confidence and ability to take the more abstract viewpoints which are necessary to take advantage of concepts like reuse. Development of these abstraction abilities need training in core skills independent of method or tool, plus the opportunity to apply the core skills on a project. The learning curve can be minimised by a feedback loop provided by the internal consultants and the project clinics.

To provide a common starting point, all new developers will be trained in core analysis and design skills. The internal consultants will continue to work on projects and will also spend part of their time running project clinics to answer the developers' questions. The training and experience that the consultants have had qualifies them to be able to replace the external consultants in answering many of the common questions raised by project groups in their environment. The consultants will use the growing body of clinic modules as a way of capturing and communicating experience on PKP projects. As part of their continuing training it is important that the consultants continue to meet as a team to review their progress and discuss new clinic module material that they have created.

As the project groups become more experienced it is likely that they will raise more advanced questions. The involvement of external consultants should be limited to answering questions that the internal consultants need help with. External consultants should be used as a way of introducing new techniques and tools to the organisation. Once a question has been asked and answered, PKP has the mechanism in place to record and communicate that knowledge. Internal consultants, project clinics and clinic modules provide a means of learning by and reusing experience.

References

DeMarco Tom and Tim Lister, Peopleware - Productive Projects and Teams. Dorset House, New York. 1987.

This book steers you away from the technology mindset and makes you think about creating a culture so people can work effectively together.

Gause, Donald and Gerald Weinberg, Exploring Requirements - Quality Before Design. Dorset House, New York. 1989.

This book does not teach any methodology. Instead it teaches the much more fundamental issue of why analysis is important and why it is so much concerned with people.

Jackson Michael, Software Requirements and Specifications , a lexicon of practice, principles and prejudices. Addison Wesley, ACM Press, New York. 1995.

A collection of insightful essays dealing with the thinking and principles behind requirements analysis.

Lipinski Adam, Integrating Users With New Techniques When Overhauling a Management Information System. The First European Conference on Software Methods. London U.K. Presented by Technology Transfer Institute and The Atlantic Systems Guild, 18-20 October, 1994.

Some observations and experiences from the Polish State Railways OMIS project.

Palmer John, Remembering the Client. In Object Magazine, 5(5), September 1995, Page 24.

A thought provoking article on object-oriented methodologies and how they affect the client.

Robertson James and Suzanne, Complete Systems Analysis: the Workbook, the Textbook, the Answers. Dorset House New York. 1994.

This book contains a complete project which you can work through as a way of learning analysis modelling techniques and thinking. The book is partitioned so that it can be used either as a textbook, for management familiarisation or a step by step case study with explanations and worked examples from a large project.

Robertson Suzanne, Visibility: The Key to Quality Improvement. In IEEE Software, Volume 12, Number 4, 1995, Page 95.

A discussion of how to make thinking visible and start testing early in a project.

top of page