7
The Interproject Team

One of the most successful methods that we have employed during the planning phase involves utilization of the interproject team. Everyone who has ever worked on a development project is familiar with the project team; we have expanded this concept to include multiple projects to facilitate the change process. Their importance for implementing productivity improvements is fundamentally the same as their importance to any development effort. We will first discuss the relevance of project teams to the development process and then the relevance of interproject teams to the change process.

Relevance of Project Teams

In most data processing organizations, staff members are placed in work groups by function (e.g. system test) as well as application (e.g. payroll system). This grouping of people is necessary from a management perspective; however, it does not usually promote a team approach to development. There is a tendency for individual groups to view the situation as “them versus us,” especially when the development of a particular system is not going well. To counterbalance some of the organizational pressures, a project team can be established for the development and maintenance of systems.

The major goal of the team approach is to ensure that all groups consider themselves responsible for all development phases. One group will always have the primary responsibility at any given time, but the others cannot be permitted to be totally uninvolved. For example, the systems analyst has primary responsibility for user requirements, but can also be an active participant in other phases, such as design, test, and deployment. The project team concept requires participation in meetings and other activities throughout the whole development process and therefore discourages the “them versus us” situation which can arise when individual groups view something as “not their responsibility.” Everything becomes everyone’s responsibility—it is just a question of degree.

The same organizational pressures that sometimes prohibit optimal development of systems can present even greater barriers when you are attempting to change the environment. Turf issues become intensified. It is no longer a question of simply holding on to your empire, because there is a real threat that the entire kingdom may be redistributed into different fiefdoms.

Working Within the Organizational Structure

Keeping in mind these organizational pressures, let’s examine your role as an agent of change in connection with the organizational structure itself. One of your objectives during most of the process is to work within the structure of your organization. It is not one of your goals to restructure your department, even though during and after the implementation there might be several reorganizations (related and unrelated to the productivity improvements). Obviously the unrelated ones must be survived, and surprisingly enough the related ones must also be survived (see Chapter 12).

Actually, if at the outset you could arrange a realignment to position your department more favorably to receive change, it would not be helpful. You are about to enter into a process during which people will be adjusting to major changes. Therefore, it will be quicker and more effective if the jobs they are performing and the people they are working with (the basic structure of their daily work lives) remain virtually unchanged.

Given the fact that it is in your best interest to work within the current structure, the best methods available to you for achieving your goals are as follows:

• The commitment and support of upper management, which you have already secured

• The utilization of your informal network, which you have already begun

• The formation of the interproject team, which you are about to undertake

This interproject team approach can be very useful during the planning phase of the change process. From every group in your organization that is a candidate for the productivity improvement, there is a potential member of your interproject team. One goal of the interteam approach is to ensure that as many individuals as possible view themselves as active participants in the change process. The more people you enable to have this perception of themselves, the more people you will have who view the success of the productivity improvement as their responsibility.

Forming the Team

When you are forming the team, the first task you must address is actively seeking commitment of people resources in the form of team members. In general, it is true that you will not have the option of actually selecting all the people. However, based on the management commitment, it is reasonable to expect that you will have significant input. Also, you can and should use all your influence (by virtue of your network) to offer strong suggestions concerning exactly who will be the team members.

There are many issues to consider when you are forming your team, and they will, of course, vary depending on the tool and the target area; but here are some items to address in any case:

• Optimally, the team will consist of representatives from all concerned areas of development.

• It is helpful to obtain representation from as many projects as possible.

• Utilize information gathered, such as who are the key people on each individual project team.

• Accept the option of commitment without representation.

The first item, wide representation, is essential for the development of a viable implementation plan. Although the planning phase would be less stressful if the complexion of your team were homogeneous, the detailed plans, schedules, and standards would not be robust enough to stand the test of time. You must also not limit in any way the breadth and scope of groups that will be represented. We have found that you can never predict who will be the real users of the productivity tool or technique.

In the previous chapter, we described the brainstorming activities associated with an implementation of data management. When we began that particular change effort, we thought our primary user community would be the people who gathered user requirements and provided the system definition. In actuality, during the planning phase the first group to support us was system test, and our very first users of production data were the strategic planners. At the first team meeting, the system test representative eloquently expressed her view of the relevance of data management to the software assurance environment. It was immediately then obvious to us also; any means of accurately portraying any aspect of the application that is being certified is highly beneficial to system test. Exactly why the strategic planners were our first users will be explained fully in Chapter 10. But the point is that since the extent of your user community is not going to be totally clear from the start, do not restrict team membership because of any preconceived ideas.

One group that is often neglected but should definitely be considered as a candidate for representation is your end users. The end user community can be very important, depending on the type of product you are introducing. If you can gain their interest and support at the very early stages of the planning phase, it will facilitate your ability to justify time and expense as you proceed through the change process. We do not mean business case preparation, because that has already been done. However, it is a fact that at many points during the implementation you may be called upon to justify the time and cost already expended, as well as the continuation of such expense. It is certainly our experience that nothing justifies any data processing effort as well as the loud and complimentary voices of the end user community. Moreover, these end users will be the people who will largely drive the priorities of your organization’s ongoing and collective development work effort. Therefore, it would certainly be beneficial to the change process if these same people viewed the productivity improvement as one of their priorities.

A prototyping tool is a good example of a product that would be noticeably beneficial to end users. This type of tool offers an opportunity to sit down with users and to have a dialogue that is very specific about what the system will look like. Misunderstandings you might have had will be highlighted, and requirements that were not quite clear to the user may become more refined during the prototyping sessions. For example, you may have thought the mailbox function was supposed to be on the welcome screen; however, when the user sees the prototype, he may decide that this function should be part of the main menu. This discrepancy would have been resolved sooner or later, but it is highly beneficial to have this specification clearly stated so early in the process, and this benefit will also be obvious to your user. Despite beliefs we might have to the contrary, end users are highly motivated to facilitate the on-time delivery of quality systems. Thus, it is reasonable to expect that they may champion your productivity improvement once they are able to appreciate it.

Prototypes (as well as other tools) can also be useful in the sense that the users will have an opportunity for some “hands on” experience with a product. The fact that this product is concrete and was introduced by your group indicates a certain level of competence, and this belief in your competence goes a long way toward building confidence. As we have stated previously, building confidence is one of the prime ingredients in creating a proper environment for change. Thus, there are many reasons to involve your end users early in the change process, if there is any likelihood of their relating to the tool or technique.

Another group you should seriously consider including on the team is operations. For some reason, this group is usually ignored, and yet we have found substantial benefits to be gained by including this group from the beginning. They have a wealth of experience and information to share and a totally different perspective from the other team members. Moreover, in many organizations there tends to be a rift between operations and the other data processing groups; if you are truly committed to building a project team, you will want to bring this group closer to the others. Moreover, unless you are dealing with a PC-based product which you are sure will never require interfaces to computers that reside in a data center, it will be a critical success factor to obtain and maintain the support and commitment of operations.

In Chapter 3 we discussed the importance of centralized groups; in fact, the example provided there dealt with a new editor that improved productivity and as a result dramatically increased on-line usage. The point emphasized in that chapter was the necessity of including technical support in your evaluation. Technical support was involved to provide capacity studies; however, in the same scenario, it was quite obvious that operations would need to be involved in the planning phase so that the increased load on the network could be addressed. With other products it may not be clear whether or not operations needs to be involved, but our experience dictates that it is better to invite them. Then, their representative can accurately determine if there is any impact on the operations environment.

Before we proceed with item 2, project representation, let’s take a moment to summarize the suggestions for obtaining wide representation:

• The more diverse groups that are involved, the more robust your detailed plans, schedules, and standards will be.

• Do not have any preconceived ideas about the extent of your user community. Many groups may perceive applications of the product that you did not foresee.

• Consider including end users on your project team. If they begin championing your cause, it will greatly facilitate your effort.

• Consider including operations to avoid the traditional rift between them and other groups.

Item 2, gaining representation from many projects, is also a very important issue to consider when you are forming your team. Since you have worked effectively in the previous phases to obtain substantial management support, it should be relatively easy to achieve this objective. In fact, on some productivity projects, there have been complaints about having too many team members. Our answer to that complaint is that you can never have too many team members! The more people who want to be part of the process, the better your chances of success, because they have already bought into the idea. The buy in indicates that they have accepted the change in some small measure, and you have that much less resistance to overcome.

On the other hand, if a high degree of interest results in a team of 75 people, that is a reality that will have to be managed. All of us have been part of a team and many have been leaders of teams. Therefore, we know that in order to interact in an efficient manner, the team must be reasonably small. So it would seem that we are faced with a paradox: Teams must be small to be effective, yet we cannot limit the size of our team. The solution is to make the official or theoretical team limitless in size, while developing and managing several “working” subcommittees that are the real teams. How to manage this process will be discussed later in the chapter, when we discuss team dynamics and team building.

Item 3 deals with key people as potential team members. If you can clearly identify these key people and they seem even reasonably receptive to what you are trying to achieve, it will certainly promote the success of your effort to have them as team members. Therefore you should utilize all the influence of your informal network to secure a few of these people. Avoid being excessively zealous, however, and consider the possibility that a modest amount of opposition may actually prove beneficial to the project team. For example, if the team has several members with strong opinions that differ somewhat, there is a higher probability that there will be more thought and discussion prior to development of deliverables. The reason is that if two people begin discussing different viewpoints, there is a strong possibility that other team members will also begin to express their opinions. The results will then be a well-negotiated consensus of all their ideas. However, do not carry this advice to the extreme; we are not suggesting that you select only people with strong personalities who are openly hostile to each other. We are merely attempting to suggest that a modest amount of discord is healthy. How to manage this discord will be pursued in the team building section of this chapter.

The final item for consideration in connection with team formation is the concept of commitment without representation, or active versus passive team members. It may happen that certain groups, when approached about team participation, will be too busy or too distracted to participate actively. The manager of the group may be convinced of the efficacy of the productivity improvement, but the current project schedule may just not permit committing a person to participate. There are several issues this situation should suggest for your consideration:

• Accept her decision gracefully.

• Ask if she could personally attend the first meeting to provide public support.

• Ensure that she is kept informed of all team activities, decisions, etc.

• When she approaches you privately with concerns about the decisions, listen effectively.

• If appropriate, act on her suggestions, even if it is inconvenient.

The main thing to consider is whether or not you really have support. If so, then you need to nurture it just as surely as you would if the person was actively participating. You must also react to her concerns, because if the decisions made by the team have serious flaws, it is better to face that fact and deal with it during the planning period than later in the implementation. On the other hand, if you do not have support, then pressuring her to send representation will accomplish nothing. In either case, you must accede to her wishes. Finally, you must consider all the possibilities available to you in terms of who is on the team as well as the specific form that their participation may take (see Figure 7–1).

Figure 7–1 The Issue of who is on the Team.

Team Meetings

Now that you have successfully formed a team composed of both active and passive members, the next thing you need to do is clearly communicate to all interested individuals in your organization the following facts:

• You have formed a project team.

• The purpose of the team is to develop an implementation plan for the entire change process.

• The time and place of the first project team meeting.

You should hold project team meetings on a regular basis. We recommend once a week initially, for the following reasons. The team has considerable work ahead of it, so the team members must meet fairly frequently. However, it would be difficult for them to meet more often than once a week because your group will need some time between meetings to document and synthesize information provided by all team members.

These project team meetings can be a powerful means for coordinating the planning and implementation of the productivity improvement. They offer an arena for gathering and understanding information that affects the implementation’s progress, such as a new user requirement that was not discovered during the information-gathering phase. The team meeting is the proper context for uncovering critical activities that are not getting accomplished, discovering the reasons, and then arranging for labor and support to reverse the situation.

On the other hand, these meetings can be frustrating and dissatisfying experiences, and in extreme cases even a complete waste of time. The difference will depend upon you. To ensure that your meetings are useful, you should adhere to these guidelines:

1. Keep your meeting reasonable in terms of time—a half day maximum.

2. Have a specific agenda and follow it as closely as possible.

3. Publish the time and place of the meeting and the agenda well ahead of time.

4. Publish any items of interest as soon as possible after the meeting.

Items of interest might be schedules or activities that the team agreed upon and the names of the persons or groups designated as responsible. Publishing information (both before and after meetings) is important for several reasons. As we noted in the case of the over-worked manager, not all team members may be able or willing to attend all meetings; however, they need to be informed not only of what has taken place, but also of what will be discussed at the next meeting. Then, if there are particular issues about which they are concerned, they can attend a specific meeting and share their opinions. If the meeting has already occurred, they can still share their concerns with you. Of course, you will always welcome their input and if necessary reopen that specific issue at the next project team meeting. Again, as we stated above, you need to address potential and real problems as early in the change process as possible.

We also have some advice to help you keep your meetings reasonably short while still adhering to the original agenda. There will be a natural tendency on the part of team members to digress, and a certain amount of this is healthy in terms of team building. People will begin to feel comfortable expressing themselves, and they will become confident that the others are listening. Problems will have a chance to surface that might not have been uncovered until they caused tremendous repercussions in the change process. But you must bring people back to the main issues and reach some point of resolution for each item on your agenda. One technique for achieving this is to establish action items for issues that cannot be resolved easily at the meeting. Another technique that can be utilized when a team member becomes concerned with an issue that does not affect the others is to offer (and politely insist if necessary) the option of a private meeting following the team meeting. Always remember that you are running the meeting—be polite and flexible, but firm.

Building the Team Bond

It is also important to remember that you must truly work at building a team during, before, and after the meetings. To begin with, you should arrange to have a conversation with each potential member prior to the first meeting. This provides you with an opportunity to explain your objectives and to answer any questions the individual might have.

During the meetings, you will be strengthening the team by the manner in which you conduct the meeting. Here are some of the techniques already identified, along with some new ones:

1. Clearly define the objectives of the team and their importance to the organization.

2. Eloquently communicate the commitment of all levels of management to this change process.

3. Provide a structure for the meeting, in the form of a well-thought-out agenda.

4. Be flexible with the agenda so that the ideas and concerns of the team can surface.

5. Ensure that every team member has an opportunity to express himself.

6. Listen effectively to every team member throughout the entire meeting.

7. Utilize the ideas, experience, and knowledge that are being expressed.

8. Never allow any team member to be intimidated by other team members.

9. Understand the interpersonal dynamics between individual team members.

10. Capitalize on the positive relationships and diffuse the negative ones.

Another thing that you must do is maintain the team bond from meeting to meeting. One method that helps achieve this objective is to make sure you have some interaction with each member between meetings. This interaction can take the form of stopping by the person’s office to share an idea that you will present at the next meeting or to hear his ideas about how the planning phase is proceeding. This one-on-one meeting does not have to be long, but you need to give the other team member your full attention and not just rush in and rash out. If your offices are not all in the same building, a phone call is fine. The main point is that you need to believe you are all truly united in a common effort, and then share this belief, both during and between meetings.

The next technique for maintaining the team bond between meetings has the potential of realizing additional benefits for the entire productivity improvement. You should assess the experience, abilities, and interests of all the team members. Then, when action items or scheduled activities are assigned, try to arrange for people with complementary assets to work together between meetings. For example, there might be a hardware expert from operations and a software expert from technical support who are friends and on your project team. There might also be an open action item that deals with projections for capacity in the time frame immediately following the implementation of your product. This item would be a good candidate to assign to both the technical support and the operations representatives. You might include the team member from the database administration group who has privately expressed a desire to you (during a one-on-one meeting) to learn more about the hardware your product will use. The result of this assignment might be beneficial in many areas:

1. It is highly likely that the cooperative effort of the three people will produce very good capacity projections.

2. They will probably provide some informal cross training for each other.

3. This will be a bonding experience, and the whole team effort will be strengthened.

Needless to say, you will want to avoid grouping people who dislike each other or who have overlapping skills and experience. However, occasionally the needs of the project may force such groupings. In that case, you can ease some potential tension or lack of experience by remaining closely involved with this subgroup.

As we mentioned at the beginning of this chapter, the whole concept of sub-groups is one that lends itself to accommodating extremely large project teams. The idea is to assign responsibility for each scheduled activity, action item, and deliverable to a subcommittee. You and your group will manage and track the progress of each item, and if necessary become involved with different groups whenever they are having difficulty. The project team meetings then become an arena for providing schedule status and review of critical deliverables, and therefore would probably not need to be held more than once or twice a month. The subcommittees are where you will provide team building and team support (see Figure 7–2).

Another piece of advice on the subject of team building is that it is very important to feed the team. Provide coffee and rolls in the morning, soda and cookies in the afternoon, and always have lunch brought in. Going back to ancient times, man has understood the importance of breaking bread together; capitalize on this fact. Catering lunch is a key factor to promote team bonding; it guarantees that there will be at least one hour of fellowship for the entire team every single week.

Figure 7–2 Team Management is Balancing Size and Efficiency as well as Forging the Team Bond.

Team Leadership

One point that needs to be clear in your mind concerns team leadership. Every team needs a leader. Since you have formed the team and are the person who is keeping the team together and on the right track, you have that role. In Chapter 6, we menuoned the concept of position power and personal power in the context of situational leadership. Both types of power apply to your leadership role in the team. Since you have been given the mission of implementing this productivity improvement at a fairly high management level, you certainly can command a certain amount of position power. However, the people on your team are the members of some other manager’s group, and thus they are an essential and critical resource that is not directly under your control. In fact, there is considerable potential for them to be dealing with a set of conflicting priorities. There are several ways in which you can avert the apparent hazards. First of all, you should utilize all your personal power within the team arena. You must convert these people to your crusade for improving the environment; they must believe in the mission; and they must perceive you as their leader in activities that will accomplish this collective objective. Do not falter in the face of such a task; remember your own commitment and your sales abilities. Once they are committed to the cause, they will influence their managers to maintain and even increase their team involvement.

The other method at your disposal to obtain and maintain this critical resource is to utilize your influence with their managers. Do not forget that many of them will be part of your informal network, and therefore you can press a little if these other managers begin to pull team members away during their own group crises. In addition, you can and should utilize your influence with other managers who are not part of your network. Do not hesitate to point out the advantages of the productivity improvement for them personally, in addition to the potential glory for them for being associated with it, and by all means reiterate the support of upper management.

Let’s summarize the techniques available for building and maintaining the team bond:

• Maintain regular one-on-one contact with all team members between meetings.

• Share your objectives, commitment, and enthusiasm during and between meetings.

• Conduct the meetings in such a way that every team member feels comfortable about expressing himself.

• Truly utilize the ideas and knowledge of the team members, and never commit the sin of politely listening and then following your own preconceived notions.

• Be aware of and act upon both the positive and negative dynamics between team members, in terms of grouping people to work together on action items.

• Feed the team to promote pleasant and regular fellowship.

• Never forget you are the leader of the team. Utilize your position power, personal power, informal network, and management commitment to keep the team intact and on target.

Duration of the Team

The final comments about the project team have to do with its duration. This interproject team is unlike the development project team in a fundamental way. The development project team has a reason for being for as long as there is a system that is growing (new development or major enhancements). The team leader (who is usually the project manager) has as an objective keeping the team as intact as possible. She does not want to lose their collective experience, nor does she want to lose the team bond; a lot of effort was invested to develop both the expertise and the team spirit.

On the other hand, the interproject team cannot and should not be an ongoing team; it has a very specific purpose with a very definite time frame. When the objectives have been achieved and the time is right, the team must be dispersed. (Exactly when this time occurs will become clear as we proceed.) Moreover, this time will occur long before the change process is completed, so it is conceivable that you will, somewhere along the way, require another interproject team. In this case, you may be wondering why you should not just maintain the original team. This is not a viable option. You are a proponent of improving productivity, of making your environment better, and thus it would be contradictory if you wasted resources (people and time) along the way.

Summary

• The interproject team is necessary to counterbalance organizational pressures and to effect the change process within the existing organizational structure.

• You must encourage representation from many different types of groups (system test, planners), as well as from many different projects.

• Diverse and widespread representation will produce a robust implementation plan and increase the number of people actively participating in the change process.

• The team bond, which will be established by you as the leader, must be maintained during and between meetings.

• Unlike the development project team, the interproject team brought together for the change effort cannot be an ongoing team; you will have to disband it in the spirit of productivity.