By Shannon Kalvar

Sitting in an airport recently, I was looking forward to heading back home after the completion of a server deployment when I got an urgent page from my boss. When I called him, I found out that he was growing concerned with the status of a project at a new client site. He needed me to fly in as an advisor to the architect and do some quick Q&A.

After I arrived at my new client’s site, I spent a few hours talking with the project teams. (This IT replacement project involved several different divisions in my company. My peers handled the network design and deployments. Other groups handled telecommunications and operations management.)

After the meeting I felt uneasy. Something was not quite right, but I couldn’t put my finger on it.

The next day I sat in the back of the teams’ client meeting. The client asked specific questions about this or that piece of functionality. In response, the team leaders hemmed and hawed. Finally, they started pointing fingers at one another. The client sat there shaking his head.

The whole thing disturbed me. I spent the next day going over the project documents, the scope, and the change control records. Everything seemed in order. Then I asked the client for an hour of his time.

During that hour, we wrote all of the scope requirements on the board. We grouped them into categories. Then we boxed them out by team. I hoped that everything was covered. In the end, only nine of the 30 or so requirements fell into a team’s current scope. Some of the out-of-scope issues related to esoteric aspects of the client’s business. Others, like basic business continuation planning, were basic aspects of our business.

The client left the uncontained problem on the whiteboard in our hands. We had four weeks to finish the project or lose the long-term contract between our companies.

What really was the problem?
Somewhere something had gone horribly wrong. That something presented us with two distinct tasks:

  • Reorganizing the scope so that enough of it got covered to allow for successful implementation.
  • Identifying the core communication issues that caused the scope to drift so far without responsibility assignment in the first place.

Before we could address the second task, we needed to finish the first. I suggested to the project manager from my group that we should have a meeting in the same room with the damning scope diagram. The next day the three PMs and I sat down. We worked on the critical path to implementation. Milestones on the critical path were then tied back to the open scope items. Teams with expertise in the appropriate area received the assignments. Everything else we put into a “post implementation” bin. In order to meet the deadline, those things would just have to wait.

With the project momentarily secured, we turned our attention to the second issue. It proved more difficult to tackle. The forms of project and change management were followed to the letter.

A deeper inspection revealed three separate problems in play. One dealt with basic communications. Another had to do with our company culture. The final one stemmed from a resource problem that was not fixed until very, very late in the project itself.

The leadership team did not meet without the client being present. All three PMs tried hard not to bring up interteam conflicts in front of the client. Therefore, they never actually talked about who should do the work. When assigned a scope item outside their comfort zone, they just let it slide.

In our company, the separate divisions rarely mingled. We barely even saw one another on projects. This separation generated a fair amount of distrust among the teams. Even worse, the divisions’ reputations with each other were not good. The three teams honestly thought of their coworkers as well-meaning buffoons.

Finally, the project architect let his duties slip because he was job shopping. He did not spend time with the client or the various project managers/team leaders outlining the vision and the scope of the project. Once the team lost vision, the project managers moved into management mode, divvying up work and changes without considering their impact on the whole system. No matter how hard anyone worked, without the architectural vision, we were doomed to wander off target.

Tackling the problem head-on
After the all-day meeting, the project managers went to talk to their teams. I went off to grab some dinner and get ready for the meeting the next day.

During a second meeting, we decided to tackle all three problems head-on. We decided to:

  • Have weekly meetings without the client’s presence. During that meeting we agreed that no topic was off limits. We also established a meeting norm that we could disagree, to the point of shouting, with one another if necessary.
  • Bridge the cultural divide. We started by having mixed team lunches and dinners. Traveling consultants eat out all the time anyway. A bit of schedule juggling made it possible for members from different teams to fall into lunching together naturally.
  • Re-establish the project vision with the project managers. I then handed that vision off to a new architect who managed it though the completion of the project.

We didn’t talk about it at the time, but in hindsight a lead project manager or a lead architect might have allowed us to avoid these problems entirely. A strong leader can provide direction and cohesion.

It was a tight squeeze, but we got the implementation done. Then we tackled all of the outstanding scope items, working them into the general operations of the client one step at a time.

Fast forward
A few years later I joined a project team at a smaller client as an engineer. The client wanted us to take over its IT operations. As had become my habit on such projects, I diagrammed the project scope and team responsibilities. The number of uncontained scope items was not comforting.

I pulled my project manager aside. We talked it over. He saw the same things, but didn’t have an effective tool for expressing them. I gave him my chart and my best advice.

He pulled his peers off into a room. They agreed to hold weekly meetings without the client present. They also divvied up the unassigned scope items. As an added bonus, they agreed on milestones for those scope items. With milestones, they could measure their progress towards the project’s completion.

In the first case, our internal lack of cohesion and inexperience in working together almost lost a contract. In the second case, we identified the problem early on. By taking steps to solve it before it became obvious to the client, we preserved our professional reputation and the contract.