So, let’s put that illuminating question to the team here at CM Crossroads.

If one accepts Petroski’s premise that people can learn from their mistakes (which I do), then one most probably would not subscribe to the notion of doing the same things over and over again.  This idea segues nicely to a common definition of insanity- that is, expecting different results by repetition of the same actions.

And with regard to these lessons learned. Are they really internalized?

It's been my experience that lessons learned, even when formalized in a classic framework, do not guarantee learning. Learning happens more frequently when it is culturally possible and fostered by management  throughout the ranks.

Learning really is the opportunity part of 'worst mistakes'- hence the reference to Petroski.

To keep this light, though on point, here are the tracks to my 'Worst Mistakes' blues CD:

1. Forgetting the Reason which prompted your action:
I think you could apply this principle to every corner of life. It is very bad to loose sight of the reason you started something,  launched a project, or even why you maintain certain relationships.

This is what allows madness to have its own life. I look at software development in very much the same way. At some juncture, and usually at great cost,  the ego must be checked and remembering the reason you started a project should  take the foreground.

Though, I can't say I've actually witnessed this acknowledgment too often, you know the usual suspects:  Technologies seemingly selected as resume boosters or for some idiosyncratic bias, good money thrown after bad because 'we've invested so much already' or just simple disconnects from the folks whose input is so critical to the reason.

The end game should never fall into obfuscation. If you set out to build something, its purpose shouldn't be so opaque as to remind others of cable guy Roy Neary's mountain project in 'Close Encounters of the 3rd Kind'.

2. Ego over Reason
Yep, this is a crippler. We've seen multi-million dollar technology projects roll past all projections of time and  expediture. Changed requirements provided by the business, but wait, none of them are with the firm anymore. Gee, so now you're building out infrastructure, coding applications, hyping expectations and when you finally get to the dance your date says "why did you wear THAT? and oh, I didn't know you drove an '87 Escort...".

Ego hurts. Well, sometimes it kills. And sometimes wasted money is just that. Wasted money. Point is, while it takes a lot to admit a mistake and put a  stop to the bleeding, your CFO will likely thank you.

In the end, knowing when to kill a project is as important as knowing when to start one.

3. Pedal to the Metal
Momentum. Like ego, can kill.

We always hear about 'ramping up'. We never hear about proceeding with caution; heck, let's just throw that to the wind. Momentum without tangible proof of concept is the equivalent of riding solely on emotion. And while emotion is both powerful and useful, engineering is based on objective facts and proven results. This leads back to reason. So, I would suggest that too much vision and too little proof is another worst mistake.

4. Your Candor makes me Cringe
Jack Welch, in his best selling book Winning, devotes a segment solely to candor and its importance. What he's really referring to is the inability of many companies  to allow the truth to surface. Too often, those who speak the truth are regarded as dissenters and are met with reprisal or dismissal. Kudos to Jack for chasticing this practice and instead fostering a culture that values honesty at GE. Too bad for those elsewhere whose reluctance to embrace valid employee candor was their worst mistake.

5. The Breakup Song
It's true that people who are incompetent should go. But is it possible for everyone to be incompetent? I mean, really?

Ok, let's add 'changing players so often that your learning curve never improves' to the list of mistakes.

Somewhere,  you have a core team that needs a voice and forum. They need a leader and mentor. Give them a voice and be a good coach to get real answers.

6. I Only Needed a Chevy (Mercedes Benz Blues)
So, we know all about ailing Detroit and their bail-outs; this item isn't anything about them. It's simply a commentary on the purpose of technology, or at least one of them - especially as it concerns business, technology's role and the very timely debate of needs versus wants.

Technology should sit at the table and play the role of enabler. Our primary mission should be to solve business problems, maximize operational effort and provide competitive edge in our respective industries. If your technology's 'slick factor' is a differentiator, then perhaps it makes sense to build the Mercedes of applications or infrastructure. There are, however, too many times when all that is needed is a Chevy!

By paying attention to your customers’ needs AND wants, you can choose features wisely and avoid spending  on costly ‘bells and whisltes’ that are not important. In today’s tough economy executives will appreciate the IT professional who knows how to save money, by making sensible technology choices.

7. Investing with Bernie Madoff
In legal terms, Res ipsa loquitur.

Yep, you heard it here.
Now where's my hanky?....
..mistakes!

---

Andrew T. Madejczyk is Vice President of Global Technology Operations for Sterling Infosystems Inc.. Based in New York City, Sterling is a leading provider of employment and background screening services for many Fortune 500 companies. Andrew is a 20-plus-year technology and engineering veteran whose prior engagements have traversed various industry sectors including Financial Services, Aerospace/Government and Healthcare. His experience includes Sig Sigma quality practices that result from years spent as an industrial/systems engineer in the aerospace community as well as studies with Villanova University. Andrew has been a longtime member of ISACA, IEEE, ISSA and most recently, the New York CTO Club. You can reach Mr. Madejczyk through linkedin http://www.linkedin.com/in/madejczyk