I tuned into the radio while driving home from the airport. A motherly voice pitching Disney's “Dinosaur” video crooned, “The story has such a good lesson for children: You can accomplish anything if you work together.” Sorry, Mom, but this lesson doesn't always hold true.
When Teamwork Doesn't Work
I recently returned from the GITA conference and trade show in San Diego, California, U.S., where several speakers explained why certain portions of their information technology (IT) projects had unraveled. Their reasons were familiar, as I had encountered many of the same situations at Arizona Public Service during my 25 years as an IT project leader.
To make sure we understand each other, let me define what I mean by the failure of an IT project. At the beginning of any project, as the result of the team's planning process, certain targets must be established:
- A schedule of when the project will be completed.
- A budget of how much the project will cost.
- Benefits explaining the actual return on investment.
So what is project failure? Failure occurs if the project is late, goes over budget or if the benefits are not fully realized. Some might argue I've set a harsh measure for success. Outside of the IT realm, however, few would argue with these measures in judging technical projects.
Historically, the rate of IT project failure has been high. About 10 to 15 years ago, the failure rate was around 90%. Things have improved with the advent of better software tools, automated testing and formal methodologies for projects, but the failure rate still runs around 50%.
Why Mom's Wrong
Why do IT projects miss their targets, even if the team works diligently together? Three situations can sink an IT initiative: certain decisions are made upfront, external to the team; certain information is withheld from the team; and/or incorrect information is provided to the team.
Executives, who should be the executive sponsors of the IT projects, often make upfront decisions before the project team even begins its planning process, with such unreasonable demands that the team can not conceivably deliver the expected outcomes.
An example might be an executive's directive to his new project manager: “I want a new work management system installed. I want it in six months. It must cost less than $750,000. Put together a team and make it happen. Don't bother me again until you're done.”
For a small utility, this may be achievable. For a large utility with 1000 users scattered across wide geographic areas, generating 10,000 work orders per year, there's not enough time or budget. The team will fail — period.
I'll bet you're thinking, “I know of a situation like that,” or worse, “I experienced a situation like that and it scarred my career.”
Now what about information being withheld from the team? Who would do that? For starters, it could be your friendly vendor sales representative. Is he or she worried about your implementation process or focused on receiving the sales commission? Too often, the rep does not reveal the true scope of work that the project team should take into consideration during the planning process. In all fairness, some reps don't even know the information themselves, but you can bet the vendor's technical support staff knows. For the project team, the result is the same. This team will fail. Their plan was fatally flawed before the first line of code was written.
Finally, sometimes the team receives incorrect information, be it from the utility side or the vendor side. I'd like to paraphrase several statements I heard while at GITA:
[For our new outage management system], we had to scrub data [needed for network connectivity] as old as 1996. Data that defines the link between the customer and his transformer was wrong or missing 20% of the time.
Our biggest technical issue was providing clean data for our Customer Information System (CIS) and for our Geographic Information System (GIS). We had to write special programs to help identify bad data. For example, one program identified all customers with CIS data that said they lived in one city, but the GIS data said their transformer was located in a different city.
We are still cleaning up from the effort to move primary and secondary maps to the new GIS. Many data problems [on the existing maps] were uncovered when we tried to use our network topology analysis software. Dealing with the data took much longer than we expected.
Beware of promises made by your vendor to provide a proprietary interface. In our case, it took a long time and affected our schedule.
Listen to these warnings about existing data. If existing data is not being actively used, bad data might not be noticed. It's not that someone deliberately set out to deceive the project team, it's just that when people collect data that no one seems to use, over time, they become careless.
My recommendation to help Mom be right more often is simple: Be honest.
Unless all parties are willing to work together without hidden agendas, the entire team is likely to suffer the consequences, resulting in late delivery, cost overruns and weak deliverables.