Have you spent good money developing a technology initiative only have it fail? Maybe it was a cloud computing initiative, new website, a redesign of an existing website, business application, mobile application, date center expansion or one of dozens of other projects that might be on your list. For whatever the reason, the initiative wasn’t successful.
There’s a lot you can do to help ensure the success of your projects and just as many things to guarantee they die a painful death. Here are a few things to avoid if you want your technology initiatives to succeed.
Hire someone without the required experience to run the project and/or lead your team. This approach will ensure the failure of your project, especially if the team surrounding this faux leader is in need of, well…leadership. If you’ve brought someone on to “get ‘er done”, you’ll know in a week or so whether or not you made the right decision. If you’ve made a mistake, fix it right away by showing this person the door and finding someone else.
Start building with no real plan. It’s like building a house; you can’t raise the roof without a solid foundation and the walls to support it. Your technology initiative is the same. You need a solid plan in place before you write a line of code or buy any technology or service. Your master plan should include both a functional and technical specification and a formal project plan.
Hire consultants and don’t manage them. I can tell you from experience that the decision to leave the kids home alone for any length of time sometimes brings with it a certain “you should have known better” hind-site. In most instances, even if the person, people, or company you’ve engaged are top-flight, there will be potential issues. If you want to avoid the “but that’s not what I wanted” scenario upon project delivery, make sure you spend the time necessary to manage your consultants/vendors/partners or whatever you call them. Failure to do so brings risk and exposure you’re sure to regret.
Take delivery without testing. I’m sure some of you are smiling right now, as I am. How many times have you taken delivery of a product or service and not tested to be sure it’s to spec? I’ve done it once or twice in the span of a 20+ year career and it can get ugly later on, I promise. Acceptance testing the final deliverable is critical. If it’s not exactly to spec, send it back with explicit instructions, like you would an undercooked piece of fish in a fine restaurant. And be sure to determine why the disconnect happened, so you can avoid it happening again.
The list is far from a complete, but if you combine the above with some common sense and feedback from your team, you’ll be ahead of the game and better assured of a successful outcome.
