“O Dad (what my oldest son calls me), the car’s dead again. Can you help me jump start it?”
Again! I thought to myself. I must have jump started that car five times in the last two weeks. If we don’t start the car at least every 24 hours, it won’t go. Since it wasn’t driven for a couple days, it rolled over twice and the starter clicked.
“Yeah, grab the starter and I’ll pop the hood. Good news is you’ll know how to jump a car if one of your friends needs it in the future!”
Up went the hood. We hooked up the charger, started the car, and away my son drove. The next day, we repeated the same exercise. This time, instead of my son driving to a friend’s house, we drove to the battery store and got it replaced! No issues since new battery has been installed.
Why did we keep restarting what wasn’t working? Why didn’t I fix the root problem sooner? That would’ve saved me time and frustration!
Now, put this in the context of the projects you are or have managed, and the processes in place to support them. Has a project stalled and needed to be jump-started, maybe multiple times? Maybe there’s a process step that constantly creates an issue or delay, but no one has looked at the root cause. Are we jump starting projects or processes that don’t work or add value?
I once started with a client where they asked I take over a project after the previous PM quit. The project was labeled “mission critical” and had to complete, and soon. I read the first charter. Then read the second charter after a “reboot.” Then the third charter after a “restart.” Now, I was being asked to create a yet another new charter. What do you call attempt number four? Insanity may be a good word!
But, instead of creating a new charter, I reviewed additional documentation and asked a simple, but difficult, question. Is this project still worth doing if it’s stopped three times already? That question brought anger and chaos! After multiple meetings, including with members of the executive team who had no idea this project even existed, it was officially terminated. No more rebooting or restarting. Instead, other projects were re-prioritized and processes put in place to showcase all projects in progress on a bi-weekly basis.
I, like many project professionals, have been tasked with picking up a project that has either stalled completely or in jeopardy of doing so. When that happens, dig into the root cause of why it happened in the first place. As more is learned, you’ll either restart the project as requested, or ask a very difficult question; is this project really worth doing? Sure, you may be yelled at (I know it’s happened to me more than once), but the more you ask to a broader audience, you may find the project isn’t worth jump starting. If it does get moving, hopefully this time will be viewed more closely to ensure it doesn’t sputter out again.
The same can be said about project processes. Sometimes processes are put in place with the best of intentions. But over time, they turn into time-sucking bureaucratic pains that should be allowed to die. If they’re not working, take them out!
If you ever find yourself saying “Well, it didn’t work the first time!”, ask if there needs to be a second. Don’t jumpstart what’s not working, or will continue to work. Ask questions, even if they’re uncomfortable. You could save yourself, your team, and possibly your company, a lot of wasted time and headaches!