If a project succeeds and meets expectations, you probably don't spend much time thinking about it. You move on to the next one. On the other hand, if a project fails or misses expectations, you're wise to spend some time trying to understand what happened and why. Recently I had the chance to think about a project that missed my expectations. From that review, I formalized seven key steps for managing technical risk and one golden rule.

Learning from my own mistakes

A sister company of ours wanted to set up secure Web access to its HTTP server using SSL. Knowing that I had done it at our shop, they asked me if I could do the work at their shop. They told me their environment and needs were similar to mine. I gave them an estimate of three to four days of work. It actually took more than 10. Yes, the secure Web access works fine now, BUT the project certainly failed to meet my expectations on the workload. What went wrong?

Mistake #1: No input to the project planning or management
I was the technical expert but DIDN'T have any real input into how the project was managed. I should have made that a clear condition to accept the work. I will next time. I could not change HOW they operated in IT, and it had a major impact on my project.

Mistake #2: I assumed their environment was the same as mine
Since I was going to be setting up a technical environment I knew how to do, I made the mistake of assuming I would