Your Project Team is Spinning its Wheels. Here’s How to Get Traction
Sometimes you need to put the Gantt chart aside and use soft skills to get everyone 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 FBI’s Virtual Case File 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.
It’s quite remarkable that, despite a well-developed project management discipline and certification process, IT projects still have such a high failure rate.
One big reason why is misunderstanding 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 alignment will stick and that they need only check in on the critical path going forward. Big mistake.
In fact, new 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.
Over a period of 10 years, researchers 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, 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.
Uncertainty is like kryptonite for any IT project, and managers use agile methods and other management techniques to deal with the inevitable fog. But such methods don’t always work. In the more successful projects, team members tried to reduce 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. The study cites 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 engage all stakeholders in regular check-ins, the interactions are not necessarily performed with much gusto.
The Rules of Engagement
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. Project leaders should consider mapping out cross-functional meetings and working groups to ensure these engagement opportunities actually occur, and to use surveys of project team members to diagnose potential issues.
As for the timing of stakeholder engagement, the sooner the better.
Don’t Get Complacent!
This study had the unusual advantage of observing IT projects at two organizations over 10 years. The researchers 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. The skill is to know when to go off script and put methodology aside. In the short term, that decision may leave a project leader feeling exposed but it is better than watching the project drive off a cliff down the road.
