A new worldview

using electronic meetings to reach consensus

 

How Citibank used Joint Application Design techniques and groupware to crash through barriers to implementing software development project management on a global basis.

by J. LeRoy Ward

SOFTWARE DEVELOPERS around the world have long been known for their stalwart independence in the face of standards and methods. Although most software developers act as change agents in their organizations by providing new ways of doing business through applications of all sorts and sizes, they themselves can be as difficult to change as any of their users or customers. And while achieving consensus on a corporate-wide methodology is a challenging task for any organization, it's especially difficult when that methodology ushers in a new way of managing global projects for a corporation whose project managers have grown accustomed to a high degree of autonomy.

Citibank, N.A., is one of the world's largest banks, with operations in more than 90 countries. Increasingly, software development projects undertaken by the Bank's Global Relationship Bank Operations and Technology (GRBO&T) office are truly global efforts involving technologists (the Bank's term for an information technology person) from around the world. A typical global project may have the following team makeup: the project manager may be located in London, the development teams may be located in Bombay, Toronto, and New York, the application being developed may be for customers in 40 countries to be processed on computers in Singapore; Silver Spring, Maryland; and Lewisham, England. Given that these types of projects are becoming more commonplace, it became apparent to the Bank's senior IT managers that a consistent project management process was required for all the obvious reasons. Needless to say, with such a diverse organization, the need to speak a common language across projects and countries created the impetus to develop a consistent approach to global project management.

After evaluating a number of approaches, the Bank developed a project management process that was subjected to scrutiny by project managers throughout GRBO&T worldwide. In fact, the new project management process was the subject of no less than five reviews by hundreds of people at all levels in the organization. As a result of this iterative, inclusive approach, the new process was modified; however, outstanding issues remained that could not be resolved through relatively informal means. A formal meeting was required to resolve those comments that were either controversial or, that if adopted, would cause a major impact on the scope and use of the process. Naturally, not everyone who commented on the process could be invited to such a meeting; the Bank therefore selected approximately 20 IT project managers who were well-qualified to speak to the issues at hand and whose opinions would be respected by other technologists throughout the Bank.

img

The Bank also decided to engage the services of a third party to facilitate the meeting. Because many of the issues would evoke strong opinions and vigorous debate, it was important that the facilitator not have a vested interest in the outcome of the discussions. Educational Services Institute (ESI) had been working with the Bank on a number of fronts related to project management and was invited to facilitate the meeting. Within ESI, I was presented with this most challenging and interesting assignment.

Choosing a Project Approach. It became apparent that there were too many issues to resolve in a three-day session using conventional meeting techniques. ESI proposed, and the Bank enthusiastically agreed, to conduct an “electronic meeting” using a modified Joint Application Design (JAD) approach.

Tips for Successful Electronic Meetings

Here are some general recommendations for those who may want to explore conducting an electronic JAD session, derived from Samantha Drake's article “Electronic Meeting Rooms,” in Human Resource Executive (July 1992).

■ Use a meeting facilitator who has no vested interest in the subject being discussed and who won't allow the meeting to spiral out of control.

■ Decide on clear deliverables and goals of the meeting.

■ Let the attendees know who has ultimate decision-making authority when all the input has been collected.

■ Vote early and often, and use the results to open up further discussion.

■ Be flexible: change gears when necessary. Let other people talk more than you do. Don't be “the mouth that bored.”

■ Do be aware of the participants’ attitudes and inclinations. Ensure that you have time to correct any problems that surface during the session.

■ Be prepared to turn off the machines and talk for at least 50 percent of the meeting time.

■ Don't assume that the results of voting activities are statistically valid. Use the results to probe conflicting attitudes and opinions and to gather additional information.

■ Keep the number of participants to no less than four or five and certainly no more than 20. Also, try to limit the number of “observers.”

■ Ensure that people know how the computer and software work before proceeding.

JAD is a technique based upon a formal, structured meeting protocol to facilitate decision-making in a group setting. Originally developed in 1977 by Chuck Morris of IBM to get users together with the MIS organization to develop plans to install distributed systems, JAD helps groups reach decisions quickly using a defined set of meeting rules. We elected to use JAD simply because the Bank had to make decisions on a large number of issues in a relatively short period of time. We knew that conventional meeting techniques would not produce the results we needed to achieve.

We jointly established a five-step approach to the meeting that more or less coincided with the five-phase JAD project approach described in Jane Wood and Denise Silver's Joint Application Design (Wiley & Sons, 1989). These phases were project definition, research, preparation, the electronic JAD session, and the final report.

Phase I: Project Definition. Defining the project was no problem. This would be a decision-making meeting to resolve approximately 100 comments. Of paramount importance was the attendance of the Bank's key players, who were willing and unafraid to make decisions. The appropriate people were identified and invitations were prepared. People responded favorably and enthusiastically and everyone who needed to be there attended. Most important, everyone knew why they were invited and what the objective of the session was. This was communicated to the attendees, plainly, simply, and to the point so that there was never any confusion as to why they were there and what their mission was.

The attendees were also informed of the electronic format of the meeting. The attendees knew that groupware was going to be used and that issues would be resolved using a multi-voting technique. If there was an overriding objection to a majority decision and the group could not resolve an issue by consensus, the attendees knew that the final decision would be made by the project sponsor, who was in attendance.

Phase II: Research. In a JAD approach, this phase generally entails becoming familiar with the subject at hand, gathering preliminary specifications, and preparing the session agenda. Participants must be brought into the process early to give them an opportunity to become thoroughly familiar with the issues and the issues must be presented in a manner that they understand and that can be voted on using the groupware's techniques.

In our case, the subject was the Bank's project management process. Although the attendees had commented on several drafts of the process, they were each sent the most recent version of the document, including an enumeration of all the comments received and a report describing the status of the disposition of those comments. The issues to be specifically addressed at this meeting were highlighted in a separate document.

Phase III: Preparation. This phase consumed the most time of all the phases, partly because the electronic meeting site and the software required for it were not already in place. VisionQuest was the software used in the meeting. Like many packages, it is extremely powerful, but it doesn't work by itself. Conducting a successful electronic meeting requires that the “electronics” are ready to go.

This technology enables meeting participants to express their thoughts anonymously through a “brainwriting” function, which encourages honesty and allows them to reach consensus on a larger number of critical issues than would be the case in a traditional meeting.

One of the more interesting features of VisionQuest is the group voting technique using criteria developed by the participants themselves. Because we were going to use a multi-voting technique to dispose of the more than 100 outstanding issues, the comments had to be analyzed and rephrased in a manner that would allow the attendees to comment and vote on them. This analysis alone consumed two person-days.

Loading the comments into the software took another day, and acquiring, testing, transporting, and setting up the equipment at the meeting site consumed two additional days. Furthermore, the administrative overhead of arranging the session also consumed approximately one day. The total amount of time to prepare for the meeting, when all was said and done, was roughly twice as much as the length of the meeting itself. It would have taken much longer had the Bank not accomplished so much of the research work before deciding to conduct the meeting.

Several valuable lessons were learned during this phase:

1. Think through the entire meeting, hour by hour. Develop an agenda. Think of what could go wrong. Think of this type of meeting as though you are going to be a participant. What would your expectations be? How would you want to see the meeting conducted?

2. If you're using computers don't expect them to work the first time.

3. If you're bringing computers to the meeting, test them at your site first, and allow plenty of time to install and test them at the meeting site.

4. If the customer has an established electronic meeting room, get there early, and do not expect your software to execute properly the first time.

5. Expect to have software problems (groupware, operating system, network, etc.).

6. Bring more supplies than you need. Even if the facility has plenty of supplies, assume that they don't, and bring everything with you. Ensure that there are a sufficient number of electrical outlets in the room and that the load you are going to place on the internal circuits can be accommodated.

7. Bring along a back-up copy of all the software you're using.

8. Have telephone numbers of hardware suppliers and software experts just in case things don't go as planned.

9. Get to the site early. Chances are that, if you are using a conventional meeting room, you will have to do a lot of rearranging to accommodate all your equipment.

10. Think of how you want the seating arrangement so that you can elicit the highest level of interaction. There are many good books on JAD, in particular the Wood and Silver publication, which provides many practical ideas on room arrangement as well as all other facets of conducting a JAD session.

Phase IV: The Electronic JAD Session. This is the where the fun began! The Bank had invited project managers from the United States, Canada, India, and the United Kingdom. Many of these people had worked for the Bank for many years and were or had been members of the Bank's international staff: people who are assigned to various locations around the world for an indeterminate period of time to gain a better understanding and appreciation of all facets of Bank operations.

The attendees were quite enthused about the prospect of working with groupware and found to be it an interesting experience. Because all the participants were technologists, and because VisionQuest is very easy to use, very little training was required during the session. One of the first agenda items was a review of the meeting's objectives, followed by the VisionQuest orientation. After that, we got down to business.

There was a noticeable learning curve associated with our meeting. This was the first experience for all participants using this electronic format. Therefore, we started out somewhat slowly but quickened the pace as time progressed. Many of the participants really enjoyed moving so quickly through issues that in a conventional meeting would have taken much more time to resolve. They also commented on how much more frank and open the electronic discussions were given the anonymity provided by the software.

JAD technology enables meeting participants to express their thoughts anonymously through a “brainwriting” function, which encourages honesty and allows them to reach consensus on a larger number of critical issues than would be the case in a traditional meeting.

Criticisms tended to revolve around too much emphasis on collecting ideas electronically, thereby severely limiting the amount of time available for oral debate and discussion. About halfway through the meeting, the attendees agreed that more of a balance between the Groupware focus and traditional idea generation and discussion methods was needed. Thus, as the facilitator, I proposed a scheme that had the participants openly discuss the issues before reducing their thoughts to the brainwriting exercise, followed by multi-voting.

Additionally, we limited the collection of comments on the issues to be resolved to one round of comments. Initially, we had collected comments on the issues and then collected comments on the comments! This grew wearisome for us all.

On several occasions, we turned off the computers and returned to flip charts and overheads to gather, analyze, and decide on issues. There were also instances in which no decision could be made for a variety of reasons and situations in which it was necessary for the project sponsor to quell debate and make the decision himself after hearing all sides of the debate. As the participants knew the rules before we started the meeting, these instances did not cause anyone great concern.

The following lessons were learned during this phase:

1. Recognize that the usual tips and techniques for conducting successful meetings apply in these types of meetings.

2. Be prepared to shift gears every once in a while. Typing on computers becomes tiresome, so use a variety of techniques during the meeting, especially if it's three days.

3. Keep up the pace. IT professionals get bored quickly, so keep the meeting moving.

4. Establish objectives for each meeting day, track your progress, and report the progress on the morning of the next day. People will see what they have accomplished and generally be energized by their results.

5. Break often. Electronic meetings are more tiring than regular ones. Allow people to go out to lunch—don't have lunch brought into the room, and most important, don't have a working lunch!

6. Ensure that you're backing up the software and files regularly.

7. Have additional administrative support. For example, we had one person making copies of documents for review and otherwise assisting the facilitators during the session.

8. Don't conduct a meeting of this magnitude alone. At a minimum, have two people: one to act as the facilitator and the other to be responsible for the system.

9. Ask the participants and the meeting sponsor during the session if they are deriving from the meeting what they expected. If you ask this at the end, you have no time to adjust your approach. Asking such questions at periodic intervals guarantees that you will, at the very least, meet most of their objectives.

Phase V: The Final Report. The value of VisionQuest was underscored when it came to documenting the meeting: every keystroke was recorded for posterity. I have never attended a meeting that was so thoroughly documented. Because VisionQuest is self-documenting, there was no need for a scribe at this meeting. What was required, of course, was a software expert who knew how it worked and could interact with the software to make it do what we needed it to do.

There is quite a lot of clean-up to be done to the documentation to make it understandable for our client after the meeting concluded. Although VisionQuest documents every keystroke, it doesn't summarize findings. If you have a large number of issues, a meeting summary is very important, especially to the project sponsor and other key managers. Also, we had to format the VisionQuest output to a Microsoft Word document to give it a more professional appearance. Additionally, we edited many of the major topics discussed to be more self-explanatory in the final report. We did not edit any of the comments collected from the participants. The VisionQuest documentation needed no editing in the voting results.

Four lessons learned can be summarized from this phase. First, expect to spend time preparing a final document summarizing the meeting. It's a rare manager who will be satisfied with your handing him or her a verbatim transcript of the session. Secondly, make sure that you and the customer agree before the meeting on what the documentation requirements will be when the meeting is completed. It's also important to ensure that everyone who attended the meeting receives a copy of the documentation. Finally, use the documentation as part of your action plan to implement decisions.

ALTHOUGH MANY THINGS could have gone wrong with a scenario that involved 100 points of contention, three days of meetings, 20 personalities, an untried meeting format and new software, the key decision-makers who attended made the necessary and oftentimes difficult decisions. When the meeting concluded, the decisions that needed to be made had been made—and the world of Citibank had a standard project management methodology. ■

J. LeRoy Ward is the vice president of management programs at Educational Services Institute, where he is responsible for worldwide delivery of project management curricula to Fortune 100 corporations.

PM Network • February 1997

Advertisement

Advertisement

Advertisement