Is Your Project Team on the Same Page?

IT project failure is the business version of a highway crash: irresistible to watch yet a chilling reality check. After all, it could just as easily be you in that wreck.

Epic IT crashes, of course, get all the ink — fiascos such as the Canadian government’s handling of the Phoenix pay system are stupefying in all their glory. Yet let’s not forget that fewer than half of all information systems development projects reach their final destination. Inadequate controls, unclear schedules and milestones, faulty cost estimations, culture clash . . . pick your poison.

One of the maddening reasons for project failure are misunderstandings among team members or groups. They arise easily in multi-functional project teams with diverse roles and objectives. To head this off, leaders will often spend time at the start of a project to ensure that everyone is on the same page. Having done that, they assume that the alignment will stick and that they need only check in on the critical path going forward. That can be a costly assumption, say Smith School of Business researchers Tracy Jenkin and Yolande Chan.

Their research suggests that mutual understanding among business and information technology managers, users, and developers can — and often does — degrade over the life of a project. And when that happens, it jeopardizes the project’s success. 

“You can put these project management tools in place,” says Yolande Chan, E. Marie Shantz Professor of IT Management. “But the experience of being in sync is totally fluid. This dynamic experience is underplayed since we’re more focused on the toolsets and mileposts. The qualitative nature of what it takes to be on the same page and succeed is not where we’re focused on as much as we should be.”

Jenkin and Chan, with Rajiv Sabherwal (University of Arkansas), studied how planning processes and controls affect the way stakeholders make sense of a project, how mutual understanding comes about and changes over time, and whether the project succeeds. The researchers were motivated by the fact that, despite a well-developed project management discipline and certification process, IT projects still have a high failure rate.

What 10 Years of Projects Reveal

Over the course of 10 years, Jenkin, Chan and Sabherwal followed 13 projects at a global software development firm and a high-tech product manufacturer and vendor. The projects included an overhaul of a flagship product, the implementation of an order management system, and the porting of desktop functionality of a legacy product to the web. 

They found that the most successful projects had a high level of alignment and mutual understanding from start to finish. These projects had the advantage of being based on existing products and knowledge, which reduced confusion and the need for much engagement. Significantly, the most successful projects all made liberal use of user experience and design documents and prototypes early in the process, and demonstrations later, to help everyone get on — and stay on — the same page. 

The least successful projects had little mutual understanding among stakeholders at any time. Even though they “followed the rules of project management,” the researchers say, these rules didn’t help project team members develop mutual understanding. Plans lacked detail, which made any shared information of little use. Some team members failed to disclose technical issues during gate reviews, which robbed other members of the chance to make sense of the information. Not surprisingly, the projects foundered.

Dealing With Uncertainty

Uncertainty is like kryptonite for any IT project, and managers use agile methods and other management techniques to deal with the inevitable fog. But, as the researchers found, such methods don’t always work. One project they monitored, for example, involved the implementation of both new IT and business processes, and the resulting uncertainty greatly influenced “who was giving sense and who was making sense.” In the more successful projects, team members tried to reduce such uncertainty by boosting their two-way interactions with other groups, such as IT and business, and within groups, such as between staff and management. 

Stakeholder engagement is crucial throughout the life of a project, but particularly early on when there is little mutual understanding, Jenkin and Chan say. They cite the example of one project where senior sales representatives were excluded from the start until they voiced concerns late in the project. This led to revisiting an earlier decision to turn off the old system, requiring extensive post-implementation workarounds. 

Even with projects that engaged all stakeholders in regular check-ins, the interactions were not necessarily performed with much gusto. “We saw some projects that would check in very ritualistically and not mindfully,” says Jenkin, Distinguished Faculty Fellow of Management Information Systems. “They would say, We’re here for the gate review. . . check. They’d sit there and they wouldn’t disclose certain things because they just wanted to move the project on.”

How to Engage

To help all team members make sense of the project and how they fit in, the researchers suggest focusing on three dimensions of stakeholder engagement: depth of information shared; the scope; and timing. 

For depth of engagement, leaders are advised to watch out for the ways in which IT groups limit the information being shared. They may be looking to buy time to fix issues, manage how other team members interpret project developments, or avoid blame down the road. Whatever the reason, other project team members cannot be expected to stay aligned if they don’t have all the required information.

The scope of engagement involves the number of engaged groups and the direction of information flow. Both matter. If opportunities to build mutual understanding only happen within like-minded groups of project members or don’t involve two-way dialogue, important perspectives could be ignored. Jenkin suggests that leaders map out cross-functional meetings and working groups to ensure these engagement opportunities actually occur, and to consider using surveys of project team members to diagnose potential issues.

As for the timing of stakeholder engagement, Jenkin and Chan say, “the sooner, the better.”

Don’t Get Complacent

The researchers had the unusual advantage of observing IT projects at two organizations over 10 years. They could see if project leaders learned important lessons and applied them to subsequent projects. In many cases, that’s not the way it turned out. Managers often performed worse in later projects, with unresolved issues among stakeholders recurring from one project to the next.

This is not necessarily surprising. It is easy to fall back on the tried and true project disciplines — either out of expedience, false sense of confidence, or risk aversion — and not be willing to improvise when projects go off the rails. In project management circles, improvisation is often viewed suspiciously, but sometimes it is necessary to temporarily put aside the plan.

“We often lean on cookie-cutter methodology for support and say, If we just follow the methodology, we’ll be good,” says Jenkin. “Usually, if we just follow the methodology, no one can yell at us when it goes bad.” 

Of course, that’s cold comfort when the failed project ends up a rubbernecker’s delight.