7 Harms Done by Keeping Unrealistic Project Goals
Nearly a year ago, your organization decided to roll out a replacement for an aging legacy system over several years. Your project is to roll out production to the first ten field offices as a pilot. Your go-live date is January 1.
On November 1, you and the senior team leaders discuss and quickly agree that there is no way all ten offices will be ready in two months. You have a heart-to-heart with the project manager, but his response is discouraging: “The official position of the project is that we are implementing ten sites until we hear otherwise.”
This reaction is not rare, but it is indicative of poor leadership, bad business decisions, terrible project management, and absent or incompetent sponsorship.
Project management is about supporting informed decision-making. A good sponsor would want to know that the goals established months ago were colliding with facts on the ground and to discuss options for going forward. In this scenario, I blame the sponsor for not establishing a communication channel and expectation, and the project manager for not communicating a difficult but necessary message.
Let’s examine the business consequences of ignoring reality and sticking with an unrealistic goal.
- Wasted money: By pretending ten sites will go live, money will be spent on equipment, travel, training, conversion, and support for offices that don’t need it right now. Equipment doesn’t rot (although it becomes obsolete), but the other costs will be incurred twice.
- Squandered people time: Team members are going to shortchange other important work, change vacation plans, and put in long hours trying to do the impossible—a debt that overtime and comp time can’t repay.
- Inferior quality: Data conversion, training, and testing all require resources. If these resources are spread too thin, the same quality results cannot be obtained.
- Diminished organizational change efficacy: Rolling out a new system is not just a technical task; it requires preparation, modification, and adaptation of business processes. Rushed or done poorly, even a solid system may be rejected.
- Damaged credibility: In the eleventh hour when scope must be trimmed—or at rollout, when a mediocre system is poorly implemented—sponsors can legitimately ask project managers, “Why didn’t you tell me sooner?”
- Damaged reputations: The sloppy implementation will join the body of evidence, real and anecdotal, that suggests, “Those IT guys can’t do anything right.”
- Damaged morale: Most team members will suck it up and go the extra mile for the organization when it seems necessary, but when they realize their sacrifice was for nothing, that frustration damages loyalty and encourages turnover.
What if the project manager had reached out to the sponsor and had an honest conversation about status and expectations? What if the goal had been reduced to six or seven sites that could have been implemented more smoothly, with less stress, better coordination, and better quality?
Which project would you prefer to work on? Which would you be proud of? Which is in the best interests of the organization?
