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 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.
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. “Miguel,” shared a fellow director in a large urban district, “don’t fall on your sword yet.”
I recently found that I fumbled on a project. Here are some tips I came up with to avoid having it occur again. 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 mis-steps 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.
Here are the 7 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.
|Measure twice, cut once.|
Make Donations via PayPal below: