I had a meeting Tuesday (May 18) with several internal department leaders and a vendor, discussing a store technology conversion for one of our brands. About half way through the meeting, I asked my operations counterparts what the minimum number of stores participating in the program would be for us to launch. One of the department heads looked at me and said, "Why are you being so negative and talking about minimum participation? We will work hard and get this done. It's that simple."
The statement caught me a bit off guard. It made me realize exactly how negative we sounded about the entire project. In fact, we had spent a good part of the meeting talking about risks and planning for contingencies.
We asked: What are we going to do if a franchisee doesn't return the paperwork on time? What are we going to do if there are problems with a conversion? Who do we call if a lead person is not available? What do we do if they don't watch the training video or read the manual and call the help desk? Just writing down these questions now makes me realize how much of a negative tone the meeting had.
But we were asking these questions for good reasons. I happen to have personally done four of similar projects before, and none of them went what I would call "smoothly." Dealing with a large-scale technology rollout to several hundred (or thousand) stores is a complex, daunting task that has a lot of things that could go wrong.
Is managing risk the same thing as being negative? I work very hard not to repeat the same mistakes twice. This approach means I try and have a plan for the things that have bitten me in the past, to make sure they don't happen again. But when you've done this job for a long time like I have, the list of things to avoid gets pretty long. As a result, I can apparently come across as pretty negative. Maybe all my years of "learning opportunities" have turned me into a Negative Nancy. But I believe this knowledge all adds up to some sort of "technology wisdom" that allows me to be more successful than someone who hasn't suffered through those pains.
Over the years of doing these projects, I have seen firsthand many things go wrong. Fool me once, shame on you. With each project I try to take away key lessons learned about what worked and what didn't and use those messages to improve the projects I am involved with in the future.
But all that talk about avoiding problems makes you sound very, very negative, as I learned the other day. In this case, our business partners were a little worried about the "negative thinking." I think it was more of a worry about a self-fulfilling prophecy (if you think about all the bad things that could happen, it may influence the outcome so that bad things do happen).
As I mentioned in last week's column, good planning has the single biggest impact on a project's success. I believe that risk mitigation planning is the cornerstone of a good project plan. If you are "surprised" by something in a project, that is not good. If a project manager has done her job, in my opinion, she has anticipated the majority of the possible issues and pre-determined what actions should be taken. And the actual issues/problems that have been encountered by the team on a previous project of a similar nature should be automatically added to the list.
For example, "The last time we did a project like this, it was difficult to reach the franchisees on the phone. What are we going to do to make sure that is not an issue this time." In a project of this nature, such a question is perfect for a project kick-off meeting. As negative as it sounds, this is a risk that should be managed throughout the entire project.
The bad news is that even if you have a pre-determined strategy for managing such a risk (for example: If we are unable to reach the franchisee on the phone, we are going to use our field operations team to get a hold of them for critical information updates), it doesn't mean it's going to work. Just because you have an answer, doesn't mean it's the right one. But each project provides an opportunity to learn. What didn't work this time is added to our "technology wisdom" for the next project.
Obviously, as an IT leader responsible for project delivery, you can't spend all of your time worrying about what "might" happen. That's just doom and gloom. But I think that ignoring risks is done at your own risk, especially if those risks have actually happened in your past projects. Hint: If you have a risk that says, "If it turns out that Microsoft is a front for the mob and has hidden code within Windows to steal your identity, then..." you may have gone a bit too far.
So what is the right line to take? How do you balance good project management with the potential energy that such thoroughness can suck out of the project team? What are your thoughts? I'd love to gain some additional perspectives. Leave a comment, or E-mail me at [email protected]. You can also follow me on Twitter: @todd_michaud.
And don't forget to follow my Ironman training progress at www. IronGeek.me.