The 18-month project was approved, funded, and project team members, users and user management attended the project kickoff meeting for the new system. Six months later the project is on schedule and on budget. Yet, unknown to the team, problems are brewing that cannot only sink the on-time and on-budget project, but these problems might have been stewing since before the kickoff meeting.
How could there be a problem with an on-time on-budget project? There are two major forces that can bring a healthy project to its knees: the mid-project blues and naysayers.
The project plan calls for the first user deliverable in 12 months. The users agreed to the schedule and signed off on the plan, yet just a few months into the project, the user is getting antsy, nervously asking at every meeting where things are. The project reviews do not satisfy user management. What is the problem?
The first problem is the mid-project blues, the unjustifiable yet very real feeling that things are not happening as they should. This queasy feeling is caused by the amount of time between project kickoff and the first user deliverable. The time between months 1 and 12, which seemed so short on the bar chart, now appears as a vast expanse with nothing to show for the dollars spent. A nervous user management begins questioning both progress reviews and IT’s veracity.
The second problem is even more insidious than the blues. It involves people out to “get” the project.
Some projects are embroiled in senior management disagreements and intrigue long before any project team is staffed. Senior managers might disagree with the scope, objectives, or size of the project. Others might think it should be outsourced. Still others might think it should never have been funded.
If the project successfully kicked off, then the dissidents lost the battle, but the war might not be over. Many one-time project objectors become current project naysayers, taking every opportunity to point out project flaws or mistakes—real or imagined.
Naysayers do not badmouth a project right away. The euphoria right after kickoff would drown out any negative comments and possibly even label the naysayer a…well, naysayer. However, after a few months, the naysayers now tell the project supporters that everything is not going as reported. You cannot hear bad news day after day with no impact. Doubt sets in. This is similar to the mid-project blues, only worse. Naysayers latch onto the mid-project blues and expand on them, elevating the once stone-in-the-shoe to a full-blown ulcer. At some point senior business management calls for a special progress review to understand “what’s really going on.” What went wrong?
Every project has a honeymoon period lasting from the start of the project and continuing for a few months. During this period the project is running on the goodwill created during its kickoff, with support high and criticism low. The honeymoon period keeps the naysayers at bay. However, when the honeymoon is over, the project becomes fair game for valid as well as undeserved criticism. This is particularly true as the project enters the deliverable desert—the period after the honeymoon and before any user functionality is delivered.
How long is the honeymoon? Difficult to say. Certainly it is no longer than 6 months. If you are managing an 18-month project, then you have no more than 6 months to produce work that will impress friendly senior managers, placate those on the fence, and thwart the project unfriendly.
What’s a project manager to do? Plenty.
1. Meet often with project stakeholders. One of the reasons once-faithful senior managers go apostate is that the naysayers have been whispering in their ears. No one chucks a perfectly good project out the window after hearing a single gossipy tale of doom. However, hearing relentless bad news can instill doubt in even the most ardent zealot.
The remedy? Hold a number of short meetings, weekly if possible, to keep stakeholders informed of progress. Demos are a great idea and more convincing than a PowerPoint pie chart. User staff assigned to the project can be a godsend. Getting a user supervisor to report on how well things are going carries far more weight than a Java programmer.
2. Speak English. Consider your audience. They are more comfortable talking about depreciation than IP6V. Have user-team members coach IT staff on the correct jargon or, better yet, have them present the progress report.
3. Tell the truth and the whole truth. Putting a positive spin on bad information sounds like a good idea, but it can come back to haunt you. It takes only one discovered evasion for business users to question the veracity of the project manager. The best way to weather bad or questionable news is to have a reputation for scrupulous honesty.
4, Provide user functionality before the end of the honeymoon period and every 6 months or so thereafter. Many teams must purchase, install, and test hardware and software early in the project—the infrastructure or housekeeping phase. Regardless of any infrastructure requirements, the project team must ensure that users see business functionality before the end of the honeymoon period.
The first three suggestions (frequent meetings, good communication, and tell the truth) are cheap and easy to implement; they just require the will to undertake them. The fourth, however, moving up user benefits to within the honeymoon period, is not. In fact, it is one of the most difficult and disruptive project planning tasks any manager will have to oversee. But it has to be done.
Will it cost more or take longer? It might very well. Moving functionality forward and postponing some infrastructure tasks can extend schedules and require additional funds. But the extra cost should be viewed as an insurance premium for increasing the odds of viable project results. In most every case, it is worth it. After all, there is nothing more expensive than a cancelled project.
Excerpted from Tillmann’s book Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019).