Project Team Integration: Halting a Pattern of Failure
Ever since the early days of computing when we put users on one side of the fence and technical folks on the other, variations of these two factions have struggled to deliver new and better information systems. Yet according to a 1995 Standish Group International study, more than 80 percent of IT projects are late or not delivered at all. Thirty-one percent are cancelled outright before being completed.
Consider the top five challenges cited by participants in this study. They include 1) a lack of user involvement, 2) inadequate executive support, 3) no clear requirements statement, 4) improper planning and 5) unrealistic expectations. These findings indicate that many project teams lack the cohesion needed to bring major initiatives to a successful and timely conclusion.
Consider this familiar scenario. A business unit wants a system replaced, but cannot articulate why or how. IT executives have hired consultants to design a replacement system, but they are not working with the corporate architecture group. The existing support team, depleted by attrition, thinks any redesign effort without their input futile. To top it off, the entire project lacks executive sponsorship.
What can management do? Ultimately they must ensure that all stakeholders function as an integrated unit, working toward a common goal. Stakeholders include sponsors, users, designers, developers and support teams for the proposed system, and any systems it may replace. Ignoring this requirement can doom a project to ongoing false starts, design delays and cancellation. Turning ill-defined project teams with conflicting goals into cohesive work units requires that all stakeholders participate in a project initiation session. This session provides two key deliverables: 1) a "constitution" or governance structure for the project team and 2) an agreed-upon project strategy. Based on these deliverables, we suggest dividing the project initiation exercise into two sessions.
The first session establishes a governance structure that nullifies many of the risks found in the Standish Group study. This requires gathering all stakeholders contributing to or benefitting from the project, determining each participant's stake in the effort, surfacing and resolving conflicts, and agreeing on a common goal. The team must then define a "purpose" to guide stakeholder participation, establish principles to govern the actions of the team and create a project infrastructure that adheres to these principles. This infrastructure defines project roles, a process for managing group dynamics and a plan for ensuring that the team can function within the constraints of the sponsoring enterprise.
The second session establishes common objectives for the proposed system and articulates why existing systems may or may not meet these objectives. In this session the team will also determine which business units the system will support, who will use the system, which systems the new system will replace and the role of methodologies. This second session should also outline alternatives for delivering the new system, divide the team into working sub-units and schedule subsequent working sessions.
This initiation session can be completed within one to two weeks and applies to new projects and to projects already underway that may be faltering. Companies should not allow loosely coupled projects with competing agendas to become another Standish Group statistic. It is time to halt this historic pattern of failure and establish cohesive project teams as integrated components of the enterprise.