After reading the first three posts, someone asked me (thanks
dear) why the themes listed focus on negative aspects, rather than on
positive ideas about how things should be done.
For me, the answer is that I have neither interest in regurgitating what
is already documented in texts, nor interest in creating a new one. There are libraries of excellent texts; many
professional disciplines and certifications; an ample number of proven
life-cycle methodologies; industry-wide standards and practices; and educated, seasoned professionals ‘out there’. Perhaps, there are too many
sources and methods from which to choose.
What sparked me to write about systems projects gone awry was
watching the healthcare.gov project crash. As more information about its
problems became public, I expected, more accurately, HOPED to see some new category of problem, some unforeseeable root cause, some hidden threat that emerged late in the
project. I reasoned confidently: that
the system at the center of the 100-years-in-the-making legacy achievement for
the Administration would get the ‘best and brightest’, and would get high level
detailed, perhaps even brutal scrutiny. This was not to be. Instead of repeating the successes of the high-flying new
generation of IT gurus made legendary by their historically brilliant application of IT during the political campaigns, America got the same-old, same-old IT project failure
scenario.
Why? How? Who?
In this blog space I want to explore both the nature and behavior of organizations
and the people inside of them when building automated
systems. Why do (we) IT and management
professionals fall into the same 40 year-old traps? How and why does management miss or ignore
warning signs? Who makes up the typical
team – and does that contribute to this apparent blindness?
Since 1963 I’ve worked in what I’ll call Information Technology.
Back then it was called Automated Data Processing (ADP) and was punch card
based (a term so old that spell check doesn’t want me to use it). The
processing and logic was split across different machines (one for each
function) each having a unique hand-wired control panel for each step. All of
the technology has changed drastically. What it took eight of us to do on a
dozen machines back then, can be done by one person on an iPad today What hasn’t changed enough is the ability of organizations and the people in them to consistently apply proven methods in building systems.
This blog is dedicated to
exposing these issues more fully in the hopes that someone will learn something
that will help avoid the mistakes that continue to plague IT projects in
particular.
The "WHY" is a societal behavior issue that applies to human group endevors. It happens when the management team's dedication and loyality to leadership overwhelms their own judgement. It is "Group Think" on steriods. The workers see the problems, get fustrated that nothing is done, and eventually abandon the program figuratively or literally. And without the dedication of the workers the program is doomed to failure.
ReplyDeleteI've observed this on many programs, perhaps the most similar was the Marine Corps AAAV. During my "Deep Dive Review" of the program the Program Manager (a Marine) status reports read like ... "Sir, my entire platoon is dead, but I expect to take this hill within the next hour." and the reply from leadership ... "Good job, report when you've taken the hill." Every report from outside the chain was ignored, until testing proved the program was technically infeasible.
I can list many more (TASC, SBInet, etc.) but here is the bottom line. Every program that got into this behavior had significant political backing. None of them recovered and none survived, but it took many years and millions of dollars spent before they were stopped. The key enablers of this behavior are a nobel intent/objective, the "WHAT" (i.e. people easily align with the vision), but the proposed solution, the "HOW", is not feasible (i.e. leadership and management don't understand how the realities of physics and/or marketplace inhibit success).
Case in point; read the 2010 memo from David Cutler (the principle architect of ObamaCare) in this Washington Post article. http://www.washingtonpost.com/blogs/wonkblog/wp/2013/11/04/the-memo-that-could-have-saved-obamacare/
DeleteThe President choose loyality over competance.
This article names names of the WhiteHouse staffers and others who were involved: http://www.washingtonpost.com/politics/challenges-have-dogged-obamas-health-plan-since-2010/2013/11/02/453fba42-426b-11e3-a624-41d661b0bb78_print.html
Delete