Every project has a GPT – a Go-Live Prevention Team. Do you know yours? Do you know who is on that team, and what drives them? If you do not you may inadvertently let them succeed…
On every project, I have ever been a part of, and believe me with over 20+ years of project work experience there have been quite a few, there has been a group of people that seemed to put more effort into preventing a Go-Live than to make it successful.
Often these team members are part of the core team, sometimes even a sponsor or 2 is on the GPT, and it almost always includes a few very influential colleagues. On some projects, the GPT members are making themselves known early in the project. They may be opposing the need for a new system, or an upgrade. Or they may support a new system in general, just not the one that ends up getting selected.
If they do step out and voice their doubt and opposition you are in a good position because you can address that. It becomes a much more destructive force when you are not aware of “the GPT” and their activities.
Picture a department leader with substantial tenure in the company, due to years of service and the functional expertise people look to her or him for guidance. This person is selected to be on the core project team, and over lunch keeps sharing with non-team members things such as “the new system is terrible, I am telling you every task is at least 10 additional keystrokes”, “testing started and it is going terrible, we are finding bugs right and left”, “it is so hard to learn the new tool I am really worried for some of our coworkers”…. Etc. You get the picture.
The impact on morale, on employee support and buy-in, on keeping the momentum going, and getting support for critical activities such as data validation or smoke testing that involves end users not previously engaged in the project becomes much harder to facilitate.
And these are harmless examples. GPT members in extreme situations can go way beyond that, and ask direct reports not to do project work on time, or at all, set unachievable performance goals for the system, or project phases and vote “No” at every gate.
But how do you know if you have a GPT? Who is on it? What do you do about it? How can you actually embrace it and use it to your advantage to resounding project success?
Let’s first identify some very typical roles on the GPT:
The Skeptic was not sure the project should have started at all, the system should have been chosen, or you have chosen the right partner. They may have voted for a different solution or integrator, and try to prove their point.
If you had a skeptic and had voted against the chosen solution make an extra effort to get the skeptics on board. Ask them to verbalize their concerns and invite them to make issues known but in an actionable way. They can be an asset if they become the canary in the mine!
The chicken is not really against the project, or against the solution or partner, the chicken is just generally afraid of change, things going wrong, long hours, having to learn something new, transparency a new system might bring, etc.
The chickens are usually good to work with because they are willing to share all their worries when you ask them, and you take time to listen. And it is a good rule of thumb that for each outspoken chicken there is another 10 or so who share all the same concerns but are too chicken to say so. If you can address the concerns, and calm the nerves you may find an ally who ends up talking to other chickens and helps them get on board as well. You know the saying “birds of a feather flock together”.
I once read that perfectionism is a coping mechanism for people with a very low tolerance for vulnerability. So really the perfectionist may not be against the project and its intended benefits at all, the perfectionist just wants to get it absolutely right because they hate making mistakes, and are afraid how a less than perfect outcome reflects on them. Actually, they often say things like “testing is not 100% yet”, or “there is still 1 open priority and 4 bugs – we cannot go live with that”. They want to get it 110% right before day 1… An aspiration for high quality is not bad per se but overdoing it may not add value beyond a certain point.
Both Chicken and Perfectionist are actually meaning well. And they both suffer from cold feet close to Go-Live. Listen to them and make sure they know that Completions is better than Perfection; and that sometimes you need to operate with Clarity because you cannot wait for Certainty. They need to feel that it is OK to make a mistake and that the sponsors and leaders have their back in all of this.
Now the Saboteur is the one exception here, that player does NOT mean well. Regardless of what drives a saboteur, the outcome is not supposed to be a better Go-Live or a later Go-Live, the goal is to prevent it for good if possible. They are the rarest species of the GPT members – thank goodness.
If you truly have a saboteur someone who actively and purposefully works against project goals you will need to address that very swiftly. If there is a suspicion it is crucial to look into that right away before you find out that hardware was not ordered as needed, the design was not documented correctly, coding was not done in time, or is not working, etc. Saboteurs can cost a lot of money if they manage to delay the project and cause re-work. How do you prevent that? Take care of your skeptics, chickens, and perfectionists. The only saboteurs I ever encountered in my career started as one of the other 3 and were not heard despite all their raised concerns.
Since most of your GPT members are well intended, it is important to listen, but you need to try and not foster a project culture where the squeaky wheel gets all the grease, and the reliably working team members feel like only acting difficult will get them some ‘TLC’ as well.
Try to emphasize that it is OK to make a mistake, just not the same one over and over. That Completion rules over Perfection, and let Clarity drive instead of waiting for Certainty! You will be fine and so will be your GPT!