CHAPTER 10
Team Management
A team that understands what needs to be done and knows how to do it is an incredible asset to the manager of a maintenance team. If you did not take over an existing team that is at this level, then it is your job to develop the team to this level. This chapter is designed to help you and your teams get to that high level of performance. Figure 10-1 shows the progression that we will follow in developing an effective team. We will assume that there is no existing maintenance team.
Team Development
I have led several different maintenance teams throughout my IT career. Some teams were outstanding, seeming as though they couldn’t do anything wrong. Things just ran smoothly, even when system issues arose. Of course, I attributed this to my management skills, but I really felt that the team managed itself. But then there were the other teams that required more time to manage and develop. Managing those teams was slow and had a fair number of glitches. This chapter provides an approach to developing your newly created team into a smoothly running group that almost manages itself.
Maintenance/Project Team Structure
Thus far this book has assumed that the project team and maintenance teams are separate. This section can be useful to you if you are the decision maker who must determine if the teams should be separate or combined. If you are not now faced with this decision, and will not be faced with it in the future, you can skip this section.
This section looks at the higher-level structure of maintenance and new development projects, before we delve into the low-level structure of a maintenance team. Will maintenance and projects be managed from the same group, as shown in Figure 10-2, or will they be two separate groups, as shown in Figure 10-3? Or will they be a hybrid between the two choices? These decisions should be made at the IT department level.
The combined maintenance and project structure has the following advantages:
• Utilizing the same group of skilled people
• Common customer engagement
The separate maintenance and project structure has the following advantages:
Figure 10-2: Combined Maintenance and Project Structure
• One group entirely focused on maintenance service; the other group entirely focused on project deliverables
• No sacrificing the maintenance effort for completing project deliverables
• One manager dedicated to project management discipline
• One manager dedicated to delivering quality maintenance
You can build a hybrid option by using the advantages of each of these options. Start by keeping the maintenance and projects separated, with separate managers. Doing this will provide all the advantages listed for separate maintenance and project structures. Then you can temporarily staff some of the maintenance team members onto the project team. This would provide the project with knowledgeable, experienced people.
Figure 10-3: Separate Maintenance and Project Structure
At the same time, the maintenance manager could serve as a liaison between his customer and the project team. The maintenance manager already has an established relationship with the customer and would be valuable to the project manager. This would eliminate the additional cost due to duplicate communication channels. This approach provides all the benefits of each option.
As a further option you can have some of the project team members back-fill and service on the maintenance team. This would provide a good experience for them to broaden their skills and knowledge.
Decision
As stated previously, the decision on which option structure to use will be made at the IT department level. Large organizations tend to separate projects from maintenance.
There are several factors to consider when making the decision. The following would tend to keep the teams combined:
• The IT organization is small.
• The project requires the same skill sets as maintenance.
• It is critical that the production system is available to the business.
The following would tend to keep the teams separated:
• The IT organization is large.
• Development projects require new skill sets not currently used on maintenance.
Considerations
There are considerations to take into account if the maintenance and projects are separate teams. It must be clear who “owns” the source code at any time. At a point when the project is starting, the “ownership” of the source code becomes the project’s and is returned after the system changes are in production. Challenges arise when the maintenance team has to code a fix during the time that the project team has control over the source code. Accommodations will have to be reached.
No matter what structure is selected, the funding for keep-it-running maintenance, enhancements, and projects should be separated. This will provide the business greater understanding of cost drivers.
Lastly, due to changes in the workload between projects and maintenance, and between one system and another, team members may no longer be needed on one team while another team is understaffed. This is a natural cycle, and the need to rebalance people due to the changing workload should be expected.
Determine Skill Need
When you know how the maintenance will be structured, you can work your way to staffing the team. But before you can look at resumes, you have to know what skills you are looking for. By now you should have a good understanding of the scope of maintenance from the SLA, the transition plan, and other sources. Now is the time to put together a Skills Matrix.
The more systems (including system components and interfaces) you have to support, the more likely your team will need a variety of skills to provide proper maintenance. Producing a Skills Matrix is a simple way of keeping track of the skills you need on your team. The matrix lists all the supported components and the needed technical skills. The Skills Matrix is simple but provides an effective way to document what skills are needed for each supported component.
Figure 10-4 provides a template for the Skills Matrix. The first column of the matrix lists all the supported components, such as systems, interfaces, and reporting tools. The remaining columns are titled with the skills (programming language, database, and operating system). Place an X in the column of a skill for a system that needs the skill. Doing this can provide you with a quick view of what is needed to support your entire scope and can help identify any training needs of your team, as we will see later.
Select Team
Now, armed with the Skills Matrix, the SLA from Chapter 5, “Service Level Agreement,” and estimates from Chapter 7, “Cost Estimate,” we are ready to select our team. But don’t start looking through resumes yet. There are other items to consider first. You need to consider if a vendor maintenance agreement will reduce some of the work that your team would have to perform and if contractors will augment your team. Then you can select employees for your team.
Vendor Agreements
Any vendor maintenance agreements should be reviewed to clarify what services will be provided. In a case where the vendor will provide all defect fixes and enhancements, the maintenance team does not have to be staffed at levels sufficient for it to perform those tasks. But don’t forget to include internal team members who will need to communicate issues and requirements to the vendor and drive the vendor to deliver the code.
Obtain Contractors
As an alternative or adjunct to having actual employees staff your maintenance team, you could use contractors. There are several advantages to doing this:
• You can obtain people who are not otherwise available in your company.
• You can obtain skills that your team does not have.
• You can staff contractors for peak demand and roll them off after the peak.
Contractors can be obtained from many sources, including staff augmentation companies that provide skilled people of various levels and larger consulting companies that can provide appropriately skilled staff for larger engagements. There are also technical support people who can be contracted from the specific vendor providing software for a system.
Using contractors can be tricky. In the United States, the Internal Revenue Service (IRS) requires that if a contractor is treated as an employee, the company must:
• Pay Social Security taxes.
• Provide standard company benefits to the contractor.
• Use the standard company termination process for removing the contractor, not just terminate the contract.
The general rule is this: If a person is treated as an employee, is subject to the work schedule required of company employees, and is directed in his or her work by a supervisor, then the person is viewed by the IRS as an employee of the company. On the other hand, if the person agrees to deliver documented deliverables defined at the beginning of the engagement and determines what he or she will do day by day to complete these deliverables, then the person is viewed by the IRS as a contractor, not an employee of the company.
To protect themselves, some companies limit how long individuals can serve as a contractor in the company. This limit ranges from 12 months to 36 months. Other companies are engaging contractors only if there is a clear, documented Statement of Work.
Employees
You can either hire new employees or transfer employees into the maintenance team from elsewhere in your company. The best situation is when the manager gets to select the team members. But many times the selection may have been made already, or there may not be a sufficient range of people from which to choose team members. In all my cases, I either inherited the team members or had minimal say in selecting them. You may find this true in your circumstance, or you may be able to exert more control over the selection process. Your company’s hiring and Human Resources department policies will dictate how to hire or transfer people.
When looking for new team members, keep in mind the following:
• The person’s desire and motivation to work on your team
• The person’s match with needed skills
• The person’s knowledge of the system
• The person’s knowledge of the business and business processes
• The person’s obsession with satisfying the client
Divide Up Coverage
The more systems, applications, application components, and interfaces you have to support, the more difficult it is to keep track of who is supporting what, especially when you first create the team or take over an existing maintenance team. It is equally difficult to track how many alternate team members you have as backups to the primary support person. The Coverage Matrix (Figure 10-5) provides a tool for charting who is supporting what systems, applications, and so on. You won’t need it if you have only a few systems to maintain.
The example shown in Figure 10-5 shows some problems with our team’s coverage. We are in good shape with System 1, with a primary team member and a backup able to support the system. But the same person supports the next three systems and interfaces with no one providing backup support. This team member may thus be overloaded, while team members 4 and 5 are not supporting anything. This example of a Coverage Matrix gives you an idea about where to start making changes if this is similar to the starting point of a team that you are taking over.
You may or may not be involved with a yearly performance review cycle with your team members. There is an advantage to having such a review, because it will help focus the team members on what you define as important. A good thing for you to do before the performance review cycle is to write expectations for each member’s role/responsibility. Review these expectations with your team members so they completely understand what is expected of them. The Coverage Matrix can be used to help write the expectations.
Train Team
The information from the Coverage Matrix and the Skills Matrix can be cross-referenced to determine who needs what skills. A further assessment can be made to determine at what level each individual can be placed for each skill (Expert, Working Knowledge, or Beginner). From this assessment, the training needs of the team can be derived, and a training plan can be established to fill in any skill gaps.
Manage Team
The key to the management of the team is to keep the team motivated to delight the customer and address any customer concerns.
Unlike projects, where the main focus is on the delivery of a system, maintenance is focused on the service required to keep that system operating. The Disney Corporation is an example of an entertainment company renowned for its delivery of quality service. In several ways, our maintenance teams are delivering a service similar to what Disney delivers. Chapter 12, “Customer Care,” presents details about how to satisfy the customer and the role the team members play in that endeavor.
An example of harvesting team member ideas comes from a well-known restaurant chain. Who better to innovate customer care than the team members serving the customer? At one point, Ray Kroc, the founder of McDonald’s, used the top-down, command-and-control model of management and tried to squash ideas from lower ranks. As stated in Dan S. Kennedy’s book How to Succeed in Business By Breaking All The Rules, “In his later years, Ray Kroc came around to supporting and even celebrating this, ‘from the ground up’ inventionism. He was even quoted as saying, ‘We have to invent faster than our competitors can copy—and we need all the minds we can access to do that, be that a fry cook or a corporate executive.’ But early on, Kroc was a very big, stubborn obstacle to change.”
“We need all minds.” We sure do! We need to use the ideas and insights of our team members and even of people outside our team to continually improve our systems and service. If it is true for making burgers, it is even more true for software maintenance: Relying on our team members is the way we can innovate faster than our competitors.
The four categories of actions shown in Figure 10-6 can provide methods for continuously improving the team members. Each category is described in the sections that follow.
Figure 10-6: Team Management Sub-Sections
Motivate
The team members must be motivated to maintain the systems and communicate well with the customer. But there is a specific challenge that must be surmounted by maintenance managers. Maintenance isn’t the most exciting assignment offered to IT professionals. Motivating them can be challenging.
One way to address motivation is not to plan on having each person remain in his or her role forever. Set up a structure in which team members can roll onto other projects and then roll back to maintenance. Set up a career path for them internally on which they can progress, be recognized, and be promoted.
Another method of motivating is letting your team members know you are there to support them and that they are not alone. You need to be active in communicating to the customer, and you need to support your team members when you deal with the customer. Defend your team members if a customer is not treating them fairly. Praise team members in public. But be sure that discussions of a personal nature are held privately.
Look for ways to provide your team members with what they need. One way to do this is to motivate them by telling them what you would like for them to do—not how to do it. Doing this encourages them to apply their creativity to the task at hand. I have seen people come up with much better ways of working than I could have, and they get the satisfaction of having done something valuable for the entire team.
Reward
Rewards and recognition let your team members know that you appreciate their efforts. Even a word of thanks said right away can go a long way. A quick word in e-mail or a stop by the person’s desk can mean a lot to someone who puts in long hours to make sure the systems run without negatively impacting business productivity.
It is best to reward alignment with the metrics. Doing this will help send a consistent message about what is important. Also, reward other desired behaviors such as satisfying customers, demonstrating broad skill-sets, and possessing and using business acumen.
Celebrating team successes along the way is also important. Plan out in secret when you will celebrate even small successes. You may find milestones that may otherwise be overlooked when you do this.
Cross-Train
Building team expertise by cross-training members to provide backups for all systems is a never-ending process. Whether you’ve built for the future or not will not be obvious to people outside your team unless you don’t have backups and you lose a key member. If that happens, you will be seen as not managing risk well.
Cross-training team members may seem like an activity that only helps the business risk and the overall team, but it actually also helps the individual. A cross-trained team that has been trained well ensures that the manager can afford to free any team member for a promotional opportunity on another team. Even if an individual loves what he is doing, he or she will not be content to remain in that position for an indeterminate time.
Encourage team members to build new skills. Most people in the technical profession value learning and view training as an opportunity. But don’t rely on volunteers alone. Plan out what team members should be backups and what steps they should take to obtain the needed knowledge and experience. Then track their progress in becoming fully capable to back up the primary person.
Address Performance
When you see a problem with a team member’s performance, address it quickly. Doing this will help to prevent the problem from worsening. It will also prevent others on your team, and the customer, from thinking that poor performance is acceptable to you.
Restate expectations of the individual having a problem, and make it clear that the team member must resolve the problem. State the consequences of continued poor performance clearly. If necessary, consult and escalate to your Human Resources department.