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?
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.
Amen to the communicate, communicate, communicate . . .
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.
@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?