Blog: Fixing Problem and High-Risk Projects
I have never posted email marketing results, because... well, let's face it... it is kind of tacky. Now and then, however, there is a story to be told. In my opinion, this set of statistics is a little over-the-top in what it shows. I can only see one way to interpret it other than Information Technology "leaders" simply do not care about leadership.
To understand how I can make such a brash statement, you need a little background...
The lament echoes time and again, "The CIO should have a seat at the table." The claim continues that business cannot survive without the simplest of technologies. Then they provide evidence as if it would be the final nail in the coffin, "Just the other day, when email was down..." Raising my eyebrows in question, I ask, "So your email was down? For how long?" The question is like a scene from a horror film where the sudden realization is that the casket being completed is... your own. Gaining strategic respect is a long way away for those having trouble maintaining their tactical obligations. If your organization is having difficulty providing basic services, you will never have the privilege of being a partner with the business.
Again, I was chided for saying there are no Information Technology projects. This time, the excuse was that the company built software. I countered my antagonist by asking if the same group that built their software also maintained the account system, workstations, email, and network. "No, that is a separate group." He was missing that his company's production group was not IT. Information Technology is the support group... and yes, they should not be doing anything that fails to directly affect getting product out the door or reducing costs. Every project's goal must be to deliver to the operational needs of the company—selling product—not to the whims and desires of the IT group. If a project fails to address the needs of the customer (directly or indirectly), then it should never see a penny of funding. This seems such an elementary concept, but it is routinely violated by techno-bigots trying to implement the latest toy or tool.
I need your help. Why is it that as we get older, so many of us lose the desire to learn? Where is the fun in that? A few years ago, I was nearly sucked into it myself—at least for a few minutes. A half-dozen of us were sitting in a coffee shop talking about growing our businesses and conversation turned to Twitter—about its uselessness. As I drove back to my office, I thought, "The six of us ought to go tell the twenty million people using Twitter how foolish they are." With that utterance, I realized how I had been drug into the world of stasis. I spent the subsequent three days immersed in social media, studying Twitter, LinkedIn, Facebook, and numerous other social tools. Now I am perplexed on how to get others to see the value. Let me fill you in on what I have learned about teaching people, maybe you can point out my flaw.
I sent a note to professional organization's program director the other day asking if their group would be interested in hearing about methods to increase project success. The organization was for a technical group that worked with data transformation—a skill set used in every IT project I have ever been on. The reply came in a prompt, succinct, and sarcastic reply:
"We [sic] you please tell me just how this would ever relate to the members of our group. You obviously do not understand that we are not responsible for running the project."
Information Technology organizations continually struggle to build systems that meet their customer's needs. They work tirelessly developing solutions that are delivered late, difficult to use, or deficient in key features and functions. This is nothing specific to the last couple decades; it stretches back to the first systems developed. Fredrick Brookes eloquently underscores this in his recount of the 1960's software engineering project to develop the IBM 360 in his book The Mythical Man-Month (1975) and is required reading for all IT executives. For the Chief Information Officer to solve this problem takes a new approach, one, nearly opposite from today's direction.
A couple months ago I asked the question, "Who should the CIO report to?" on the LinkedIn's CIO Magazine Forum. Surprisingly, over 100 people responded, so many that the group's moderator moved the discussion to the jobs section. Maybe they were tired of the attention this old, beat-up subject was getting. I surely did not think responses would be quite as passionate as they were. However, my interest lay in another area, not in the answers to the direct question, rather the reasoning behind them.
CIOs have two major responsibilities—keeping IT's lights on (backups, networks, email, etc.) and providing support for business initiatives. Being mediocre at either will make for a short career. Although the respective budgets are normally a 70:30 split, a CIO will be fired in a minute for failing to properly support the 30%. That portion of their budget actually generates the company money. Keeping the lights on is a thankless job. People simply expect networks run, data served, and viruses inoculated. It is expected much as we expect water when turning on the tap. Supporting business initiatives is just as thankless since 60% of projects seem to always be in trouble.
Yes, I am on that soapbox. Ensuring that maintainability and adaptability are part of a system is a "best practice," extensibility is not. To the extent that a highly structured system is extensible, that is the end of any commitment to building for the future.
Adding hooks and stubs for something that may not happen, confuses and clutters the design of the resulting system. Building and running prototypes wastes time. Making a system extensible adds significant undefined scope. The reason is that no one knows what the future will bring. Furthermore, how can it be tested if the systems it is interfacing with are not defined?
Filling Execution Gaps
Rescue The Problem Project
- New PM Articles for the Week of November 9 – 15, The Practicing IT Project Manager, November 9, 2015
- The Argument for Disbanding Your PMO, Accellerated IT Success, Nov 13, 2015
- New PM Articles for the Week of September 28 – October 4, The Practicing IT Project Manager, October 4, 2015
- Episode 332: Project Sponsor Challenges and Solutions, PM Podcast, Cornelius Fichtner, September, 2015
- New PM Articles for the Week of December 1 – 7, The Practicing IT Project Manager, December 7, 2014
- How to buy Project Management Consulting Services: Service as a Product (SaaP), Guerrilla Project Management, Samad Aidane, December 2, 2014
- Episode 275: Your Project Statement of Work is Missing a Comma!, PM Podcast, Cornelius Fichtner, June 14, 2014
- State Invites 10 Firms To Shift Cover Oregon To The Federal Health Insurance Exchange, Oregonian, Portland, Nick Budnick, May 28, 2014
- Decision To Scrap Or Salvage Cover Oregon Health Insurance Exchange Poses Risks Either Way, Oregonian, Nick Budnick, Portland, April 9, 2014
- Cover Oregon Consultant: Fix For Health Insurance Exchange Could Take $40 Million, 21 Months, Oregonian, Nick Budnick, Portland, April 4, 2014
- Episode 205: Rescue The Problem Project, PM Podcast, Cornelius Fichtner, June, 2013
- Episode 206: How to Keep your Project out of Trouble, PM Podcast, Cornelius Fichtner, May, 2013
- How to identify, prevent, and recover from project failure, Accellerated IT Success,April 2, 2013
- Episode 260: The Seven Steps to Rescuing the Problem Project, PM Podcast, Cornelius Fichtner, January. 2014
- New PM Articles for the Week of August 6 – 12, The Practicing IT Project Manager, August 12, 2012
- New PM Articles for the Week of June 11 – 17, The Practicing IT Project Manager, June 17, 2012