In Practice: The System Tracking Project

In her career as a senior project manager, Ainsley Nies encountered many challenging projects. In a consumer electronics company, an IT team had the task of supporting customer services and support systems. Here Ainsley describes how a project manager used agile chartering to facilitate a smooth adoption when asked to develop a new tracking system that would require a significant coordinated effort among many teams.

A New Challenge

Product manager Tom accepted a new challenge. He would guide the development of a new system for tracking support calls. The challenge? It required a complicated, coordinated effort between the software developers and the support reps. They would collaborate to build, install, and bring the system online.

The software development team for this project included three developers, a business analyst, and two testers on-site, as well as two remote developers. The support reps interacted with a global customer base and worked from three sites to cover international time zones: one in the U.S. West Coast home office, a site in India, and another in Spain.

Tom thought that having an agile charter led to the success of his previous project, and he wanted to repeat that experience. He discussed the business value of the project with the director of IT, the customer service manager, and the help desk manager, then spent a few hours drafting an initial purpose. He thought about the technical difficulty and the political issues surrounding the project.

When he felt his draft was good enough for discussion, Tom asked the software development team, the customer service and support manager, a few support reps, and two IT ops staff to come to a meeting to review and amend the draft. He knew a manager who had great facilitation skills, so he asked her for help in keeping the meeting focused and on track. With good group-process support, Tom knew the group would get more from their conversations about the project purpose than they would from the words he had written. Furthermore, those conversations would help the group gel into a project community focused on achieving that purpose. They would have the chance to explore the political issues and technical difficulties and would almost certainly add information that he lacked.

During the meeting, Tom noticed that the support reps weren’t saying much. He asked for their perspective, and one of them replied, “I don’t understand why we’re changing the tracking system we have. It’s hard to use, but we know how to work with it, and learning a new one will slow us down. And we’re evaluated on how many calls we can complete. This will set us up for bad reviews.”

One of the developers said, “Maybe that should be a mission test. The new system should be easy for the support reps to learn and use. It shouldn’t slow them down.”

Tom said, “That’s not phrased right for a mission test. And you’re right: we need this to come online with as little difficulty as possible. How can we make it better?”

It’s the Charter-ing

The whole group began a lively discussion and created a mission test that they all agreed would suit. The support reps became more engaged in all the subsequent conversations after they saw how the rest of the group respected their concerns.

Later, over lunch, Tom remarked, “It’s just as I remembered. It’s the chartering process that’s important, more than the charter itself.”