Preventing Your Project Launch From Being Scrubbed at the Last Minute
We had been working on a revolutionary new technology project for months. The impact it was going to have kept us incredibly motivated to succeed. Not only was it going to simplify an extremely complicated process, it would save time, reduce the potential for mistakes and uncover costly flaws in company record-keeping.
Needless to say, we were excited about the approaching implementation date. The company’s project manager and I met daily to make sure our t’s were crossed and i’s dotted. I took his feedback to our engineers. He fed our requests back to his team. We kept our momentum and buzz going strong.
The project deployment plan was to limit rollout to a handful of locations. Once proven successful, we would increase capacity in more locations. Eventually, over 3,000 offices would benefit by the rollout. Days away from moving into a production environment, the project was nearly stopped dead in its tracks, killing our buzz. What happened?
They Took a Closer Look
A little background: the project’s stakeholders had seen the application a number of times, and were continually kept apprised of its status. They knew what it could and couldn’t do, but never was there any disagreement about whether or not to continue. Their perfunctory nods of agreement that the project should keep moving forward belied the fact that trouble was brewing on the horizon.
Not until it was about to go live did they become unsure and say, ‘We need to dig into the details and make sure we’re really comfortable with where this is going.”
The irony is that it’s not like they didn’t have the time to review the application at a high level of detail earlier. They just didn’t. Perhaps they perceived phases of development as not important, or that it didn’t affect them. Maybe they were too busy to dig into the details.
For months, they kept bobbing their heads in agreement, signing off on the approvals to move forward — perhaps thinking they would give their ‘real feedback’ later.
That’s actually what they did. Days before the application was to go live, feedback started coming out of the woodwork, setting the delivery date back by weeks. Some of their comments:
- Design Feedback: The color schemes, logos, icons, and other graphical elements that had been agreed upon much earlier in the process needed tweaking. Included were fundamental changes to the design itself that had far-reaching implications.
- “Drive-By” Feedback: Here’s what happens in a drive-by: a team member is reviewing the application on a machine somewhere. A person with a Big Title walks by.
“Hey, check this out,” says the team member.
“What’s this?” asks Big Title.
“It’s our newest application, and it will save tons of money,” says the team member. “What do you think?” he says, not hearing the death knell toll.
“Well, it’s nice. But, I would do this, move that, get rid of this, and change that,” says Big Title. His title carries weight so you’re not sure if you can just ignore what he said.
The company’s project manager confirms his influence; the feedback needs to be incorporated. Just great! Say goodbye to the launch date just three days away.
- “Justify My Existence” Feedback: It is painful to get feedback from someone that needs to justify their existence. You know what I’m talking about. The application is just fine; nothing is functionally or cosmetically wrong.However, one person in the approval process feels it is their duty and obligation to bring an extremely minor nit to everyone’s attention.
- “Hey, I Just Learned Something New” Feedback: Someone is reading a book or taking a course that is ostensibly related to the application’s development. They learned something new, and now must look over your shoulder and point out something — or many things — they feel should be done differently.
Don’t get me wrong, there is nothing wrong with feedback, improvements or revisions. Feedback should always be welcomed, appreciated and implemented. Change control processes are put in place to absorb and accommodate change. The problem is when feedback is given SO late in the development cycle.
It’s like the Space Shuttle is about to take off and it’s T minus 10 seconds. The countdown begins and someone pipes up to say, “Scratch the mission,” because they noticed a fingerprint smudge on one of the windows.
What Can You Do to Prevent Late Feedback?
To prevent feedback from coming in so late in the process:
- Get Everyone Involved Early On: Yes, this sounds obvious, but the emphasis is not so much on the early timing as it is on ‘everyone.’ Make sure you have identified everyone on the approval path. You may find a handful of people that show up later in the process to have a tendency to slow things down. Verify that these are the ONLY people that have the final say about the application going live. Otherwise, you’ll be chasing approvals for the rest of your career.
- Set Expectations: Once you’ve identified everyone on the approval path, make sure to set the expectation that they need to give this project the attention it deserves. Recount experiences that demonstrate how last-minute feedback almost always throws the delivery date out the window. Correlate cost with substantial delays in the project.
Make a Big Deal Out of Not Getting Feedback Early — Don’t assume silence is consent. If you have not received feedback from someone you know must provide feedback, go get it. It means that they have not taken the time to form an opinion in order to give feedback. All systems are NOT GO until you have heard what they have to say.
- Define What Is Considered a Show-Stopper: It’s almost impossible not to receive last-minute feedback on a project. However, part of setting expectations should be to define what a showstopper is — a legitimate concern about functionality that would prevent the application from going live.
