Lessons Learned from IT Scars

Last night, I attended a Women in Technology event titled The CIO/CTO Agenda 2012. Moderated by Christopher Dorobek, the six panelists’ candid and often humorous discussion covered many topics that included paths to success, current priorities, mobile communications, and vendor/contract relationships. My question to the panel wrapped-up the discussion:

“Since all of you have been in your field long enough to have IT scars (misaligned or failed projects, unmet IT expectations, etc.), what do you now do differently based on those scars?”

The answers were illuminating; they are paraphrased below:

I ask better questions and am willing to ask tough questions at all levels.
– Lisa Davis, CIO, U.S. Marshals

Define the requirements.
– Taylor Rickard, CTO, G&B Solutions

Yes, define requirements early, fund and staff projects at the correct levels, and involve the customer.
– Peggy McKelly, CSC Corporate Vice President, Application Portfolio Management, CIO Office

Communicate, communicate, communicate. Miscommunications from both sides, the IT provider and the customer, in regard to expectations has resulted in too may IT scars.
– Rear Admiral Janice Hamby, Military Deputy and Chief of Staff, Office of the DoD CIO

Strong partnerships and honesty are essential. Be out of my comfort zone.
– Pradeep Mannakkara, CIO, Rosetta Stone

Listen. If it sounds too good to be true, it probably is.
– Sondra Barbour, CIO, Lockheed Martin

Great advice that goes beyond technology and can be applied at many levels. In addition to the above, all panel members clearly had a passion for what they do and find a way to have fun while doing it. The lesson I took away is that the panelists chose to use the lessons from those IT scars to their advantage and refused to let setbacks deter them.

What about you – what do you now do differently based on any IT scars you have from your career in the technology field?

Leave a Comment


Leave a Reply

Andy Gravatt

That was a great question and those are fantastic insights. Everytime I’ve ever gotten in trouble on an IT project it’s been caused by the requirements. Either we didn’t have them all, the customer didn’t know them all, or the customer kept changing their minds. I’ve always been able to work through other risks, but an undefined project will fail each and every time.

Justin Kerr-Stevens

Agree with Rear Admiral Hamby’s comments.

I’ve had to manage a project that had a track record in previous failure. Working through former project plans showed that the issue wasn’t in deployment, it was in communicating the requirements to all involved.

Veronica Wendt

@Bill @Justin – Very true on how important communicating is. And I would add: are all parties talking the same language, or at least in a language where the requirements mean the same thing to all involved?