Team leaders, I’m told, take responsibility for their team’s failures. You know, when the Titanic hit the iceberg, and it sank, the Captain went down with the ship. When anti-cybersecurity efforts fail and phishing/ransomware succeed, the ship sinks and the Captain with it. The ship may sail again, but never with the same captain. Failure is a tar brush and it stains you in an organization.
When the football coach watches his team have a losing season despite his best efforts, he finds himself looking for another team to apply. When the invading army loses the battle, the commander is among the fallen.
Note: This is a repost from an oldy but goody blog entry. I’ve updated it a bit for fun.
When honor is lost, the honorable warrior falls on his sword.
 |
| Image Source: http://goo.gl/woXr2j |
Ouch, that’s pretty gruesome. Well, thank goodness we’re past that, right? I mean, right? Ok, maybe not.
Fumbled A Project?
“Miguel,” shared a fellow director in a large urban district, “don’t fall on your sword yet.”
At the time, I thought I’d fumbled on a project. A colleague analyzed it from an objective perspective, then reminded me that things might look bad from my point of view, but they weren’t as bad as I thought. You have to ask yourself a simple question, he suggested. “Given what you knew then, is there anything you could have done differently?” A follow-up is, “If there anything you should have known but didn’t because you missed it or failed to prepare for it?”
At the time, I thought I’d fumbled on a project. A colleague analyzed it from an objective perspective, then reminded me that things might look bad from my point of view, but they weren’t as bad as I thought. You have to ask yourself a simple question, he suggested. “Given what you knew then, is there anything you could have done differently?” A follow-up is, “If there anything you should have known but didn’t because you missed it or failed to prepare for it?”
As you might guess, if you can answer both those questions in a way that shows you did all your research and took appropriate actions, then your goose isn’t cooked. Of course, history is littered with the corpses of people who did the right thing and died anyways. Same thing goes for CTOs. If public opinion is against you, or a scapegoat is needed, you are still just as dead as if you’d screwed up yourself.
A Few Suggestions
Here are some tips I came up with to avoid having fumbles from happening. As I read these, I realize that they are obvious. I can’t help but ask, Why didn’t I do this in the first place? The reality is that everyone missteps and other factors can force your hand. For example, consider what might make you set aside these tips for avoiding technology implementation failure:
- Perceived need for speed – in my situation, I felt we were under an imperative to fix a technical issue and, as such, taking shortcut in implementing a solution that has worked in the past seemed “OK.” Be on guard for the “need for speed.”
- The boss says, “Do it.” – Trust me, even when the boss says to get it done, the intensity will be increased when what gets done fails. And, who wants to document to cover their rears.
- Foolproof solution that will work! – We’ve all encountered foolproof solutions that are going to be “slam-dunk” and then…you get slammed.
In spite of these suggestions above, you will still want to make yourself a checklist. Here are some items that might appear on your checklist.
Seven Tips
-
Contact other districts and find out what’s been done previously. If I’d done that in this particular situation, I would have found that the mistake we made in implementing had already been explored and done by others. “Learn from other’s experiences,” a piece of advice I forgot.
-
Do a mock walkthrough of the technology implementation and detail the steps. This is important because in one situation, I realized that while several team members individually knew something needed to be done, that wasn’t articulated as a team and failed to become part of the group knowledge that we could tap into. If we had walked through the process we were trying out, we would have realized we needed to take more steps.
-
Consult with stakeholders prior to scheduling when possible. One of the challenges I encountered included a failure to appreciate how serious a temporary lack of access to the technology implementation would be for stakeholders. What seemed pretty short time to be without something was of incalculable concern to stakeholders. When we went over schedule on the implementation by a few hours, stakeholders were concerned.
-
Notify stakeholders using different methods (e.g. email AND phone calls). Although I always notify folks when I’m moving their cheese, I failed to pick up the phone.
-
Develop a fall back plan if it all goes poorly. Having a fall back plan in mind is important. The reason for a delay came about because the primary plan failed to work as well as expected. We had to come up with a fall back plan at the last minute, which meant stepping back and relying on equipment that was less than desirable.
-
Make the changes then evaluate success with stakeholder feedback. This seems pretty obvious, but I would probably point out that one needs to make it easy to collect the feedback. So, maybe I need to revise this tip to read, Make it easy to receive stakeholder feedback on the technology implementation.
-
Shut down the old technology. Switching from one technology to another? Then make sure that you shut down the “old technology” so that users won’t keep using it when the new one is put in place. That way, you’re not caught trailing data from one system to another.
I’m sure there are many other tips one could consider. . .Keep this one in mind, too:
 |
| Measure twice, cut once. |
Everything posted on Miguel Guhlin’s blogs/wikis are his personal opinion and do not necessarily represent the views of his employer(s) or its clients. Read Full Disclosure
Discover more from Another Think Coming
Subscribe to get the latest posts sent to your email.
Another Think Coming 