I happen to be a fan of science fiction. Truthfully, I hate to say how many times I have watched the Star Wars movies. Yes, all of them. In one, Darth Vader visits a Death Star that is under construction. Unhappy with the timetable for the launch date of the Death Star, he states, if the project manager cannot complete the project on time, he will send a garrison of troops there to oversee construction and take personal charge of the situation himself. Needless to say, the movie implied that the launch date was met. Obviously, the threat of punishment from the Dark Side must have motivated the workers.
There are, however, some projects where the launch date may not be completed on time… even if the “force is with you.” As an example, let’s consider Obamacare and the issues going on with their website. It is not my intention to imply that I support or do not support Obamacare, nor should you infer that it was poorly managed—though the project is now plastered all across the television and newspapers. Still, it may take years before all of the facts are disclosed, regardless of what appears in the media.
IT projects generally suffer from the events described below. The larger the IT project, the greater the chance it will appear in print and committees will be formed to look for someone to blame. But in any event, here are some typical scenarios that may occur throughout IT projects.
- The launch date for the project is determined by someone in the senior most levels of the organization or government with virtually no understanding of the technology or the risks. The date is picked based upon personal or political reasons, often with little regard for what is realistically possible.
- If information is needed to support the decision for the launch date, it is not obtained from consultants or experts in the field. Rather, it is provided by companies that expect to be contractors on the project and receive large contracts. The cost and schedule are grossly underestimated to guarantee winning part of the contract, and knowing that problems will appear in the future.
- When problems arise, the solution is almost always resolved through scope changes that result in mega profits for the contractors. The work is documented in such a way that it is cheaper for the client to agree to scope changes to the existing contractors than to go out for competitive bidding and find replacement contractors where the same problems will occur again… and again… and again.
- The senior management who picked the original launch date immediately distance themselves from the project and make sure there are several layers of management between them. Therefore, they cannot be blamed for any of the issues or problems that may arise.
- Senior management immediately state that they were never informed of the risks or the technical issues. These comments are often well-supported by the two or three layers of management beneath the executives because they prefer to remain employed.
Once the problems begin to surface, and we know that newspapers sell more copies reporting bad news rather than good news, the witch hunt begins for someone to blame. Even though we teach that the buck stops at the top of the organization, there are still several layers of management beginning at the bottom where blame can be assigned.
At the bottom of the chain are the contractors. They will claim that they either told certain people about the risks and it fell upon deaf ears, or they failed to disclose the risks and potential issues. In exchange for taking the heat, the contractors will be given lucrative contracts for scope changes to correct the problems. Does this sound like a punishment or a reward? When the problems are finally resolved, and after the schedule has slipped and the damage was done, the contractors look like white knights appearing as if the force was with them all along. They overcame Darth Vader and the Dark Side.
Once the issues are resolved, the problems may be forgotten. Look at the software issues with the opening day of Terminal 5 at London Heathrow Airport as an example. More than 40,000 pieces of luggage travelled without their owners and more than 500 flights were cancelled—all because of software. Similarly, look at the baggage handling system at Denver International Airport. This was also an IT project.
I will leave it up to each of you to determine if Obamacare deserves to be compared to Star Wars or the launch of Terminal 5 at London Heathrow or Denver International Airport. But if history has taught us anything we can expect those very close to the Obamacare Project to discuss the intimate details of the project when they retire and write books. Unfortunately, we may have to wait years until this happens.
Perhaps the managers of this project should take part in my free online keynote speech: “Lessons Learned Can Create New Opportunities,” on November 7 for the free virtual summit on the future of business—International Project Management Day.