Here’s the usual progression:
Business case: It’s thin. So whoever’s brainchild this budding disaster is does what managers have done since before spreadsheets were invented: They fiddle and twiddle until the ROI exceeds the hurdle rate, convincing themselves their revised assumptions are still, if not entirely reasonable, at least doable with some luck and a strong tailwind.
Requirements and specifications: Estimating the requirements and specifications phase is a bugger. The bigger the project, the more unknowns lie lurking; each and every one of them complicates things further. The requirements and specifications phase always goes long, but that’s okay. Everyone knows the more thorough your design, the less time you’ll need for coding and testing. We’ll make it up then.
Planning: IT being aligned with the business and all, planning goes right-to-left, starting with the delivery date and working backward to whatever schedule will achieve it. This time it’s the project manager who, in desperation, fiddles and twiddles until the schedule looks plausible, so long as nobody looks at it too closely. Which they won’t because it tells them what they want to hear.
Yellow: That’s the project status, also known as behind schedule with no path to salvation, but enough time before the deadline that denial still supersedes reality. Adroit project managers take two actions when a project reaches this stage. First they squeeze testing. This puts both the project and the team’s complexions in the green. Second, they start a job search before the project tanks their reputation.
CIO self-deception #3: The big mission-critical project that's fallen behind schedule? We'll catch up in the next phase and deliver it on time.
Level one testing: This consists of redefining the exalted state of good-enough down. With lax enough standards and enough political clout, even the worst code can get rammed into production.
Level two testing: Also known as PROD. You always test, and test thoroughly. The only question is whether thorough testing happened before or after the software went into production.
Off the rails: The new CIO stops the train wreck. His predecessor blames the project manager. The project manager attends PMI meetings the way those with drinking problems go to AA.
LEADERSHIP BRIEF
CIO self-deception #4: We're doing ITIL.
This might seem like semantic nitpicking, but there’s no such thing as “doing” ITIL.
ITIL is a framework, as its proponents patiently explain to whomever is willing to listen (generally a small and apathetic audience that doesn’t include our self-deceptive CIO).
ITIL lists the things IT has to be good at. It doesn’t prescribe how to go about being good at them, which is just as well, as there is no one way to do anything on ITIL’s list that works in all situations. (Don’t believe me? Think about how you’d run IT if you worked in a small ad agency. Now think about how you’d run it in a large government contractor specializing in cybersecurity.)
On top of this, there are a lot of CIOs who equate “doing ITIL” with having a decently run service desk (or at least renaming their help desk so it reads “service desk”) and maybe instituting a change advisory board (CAB) to sit between app dev and IT operations so they both glare at the CAB instead of each other.
78