Everyone fails. Nobody’s perfect. The trick with failure is to do it right.
“The fastest way to succeed is to double your failure rate.” –IBM’s Thomas Watson, Sr.
“Forget about the consequences of failure. Failure is only a temporary change in direction to set you straight for your next success.” – Denis Waitley
But is it possible to fail wrong? Absolutely! Consider these two (real life) IT project examples. One fails right and the other fails wrong.
Example #1: Provide electronic ordering for a tradeshow
In this example, the project leader implemented a custom web site and rolled it out to 100+ tradeshow vendors the day of the show. Unfortunately, the venue’s wireless network couldn’t handle the volume of vendors connecting to it. The project was a failure and orders were eventually taken on paper (after a rather hectic and VERY visible time of troubleshooting).
Example #2: Provide mobile ordering through VPN
For this project, IT identified a low-cost solution that used existing iPads with a VPN connection into the back-end ERP. A demo menu was created to test connectivity. The data plan was enabled on 2 iPads as a test. They were able to connect into the VPN, but when they attempted to use the ERP, the connection became problematic and ERP functionality stopped. This project was a failure and IT began looking for a new solution.
Both projects ended as failures, but example #2 failed right. Why?
- Limited user impact. The second example only affected two users, and the affect was only for an hour while testing was taking place.
- Limited investment. In the first example, the entire custom web site was completed before the failure was realized. In contrast, with the second example a demo app was created with only about two hours of effort.
- Failure identified early. In example #1, the failure wasn’t realized until “show day” (the very tail end of the project), while in example #2 failure was realized up front, before any real development was performed or deadline was reached.
To fail right, project leaders need to look for risks and move them to the front of the project. By identifying and testing for risks early, we can eliminate possibilities that will cause failure quickly, before time and money is spent on the wrong solution.
Beyond risks, it’s also helpful to identify the end-goal of the project and do a proof-of-concept up front — to ensure the project can succeed before investing too much effort into it. This is exactly how example #2 was handled.
For large IT projects, identify the primary reason for the project up front. I’m a big fan of project vision statements for their ability to help us focus on the ultimate goal of the project (typically something we want but do not currently have). For an ordering solution, the primary goal may be getting orders out of something (web, mobile, tradeshows, paper, whatever) and into your corporate ERP. A new phone system project may have the end-goal of unified communications or streamlined corporate mobility. A mobile app development project’s primary objective may be customer engagement. Every tech project has an ultimate objective that is The. Most. Important. Thing. Identifying this early on and testing up front can help ensure the project’s success — before you invest months (or years) of effort.