{"id":2752,"date":"2002-12-28T11:22:53","date_gmt":"2002-12-28T11:22:53","guid":{"rendered":"http:\/\/staging.armedliberal.com\/?p=509"},"modified":"2002-12-28T11:22:53","modified_gmt":"2002-12-28T11:22:53","slug":"what-failing-technology-projects-can-teach-us-about-politics","status":"publish","type":"post","link":"https:\/\/marcdanziger.com\/?p=2752","title":{"rendered":"WHAT FAILING TECHNOLOGY PROJECTS CAN TEACH US ABOUT POLITICS"},"content":{"rendered":"

I got some smart comments from Henry over at The Modern Middle Manager<\/a>, and went over to take a look. He had a great post<\/a> on an almost-failed eCRM implementation, and it started me thinking.
\nAbout 70% of the billable work I\u0092ve done in the last five years has been work on failing technology projects. These are projects from simple websites to the project I\u0092m on a now, a multi-million dollar customer data warehouse for a major corporation. (The project is Really Far from my house, and while I\u0092m glad for the work, I\u0092m getting tired of commuting and anyone in Greater LA who has a troubled tech project ought to email me\u0085<\/I>)
\nAlmost all of these projects got into trouble for similar reasons. Lack of planning, lack of clear alignment among the stakeholders, a failure to follow rudimentary systems development processes, vendor deceit, and most of all, hubris.
\nHubris is the most important thing, because it is what allows the project sponsors and leaders to believe that what they\u0092re doing makes sense, even in the face of contradictory best practices and evidence.
\nHubris in the technology world typically looks like this:
\nA visionary engineer builds a tool or product. He partners with or hires, or is hired by an aggressive marketing visionary who takes the actual capabilities of the tool or product and ties them to a business need in the most visionary and optimistic way. They hire an energetic PR person, who gets them press in Wired (or the late lamented InfoWeek), where it gets read by an executive at an organization that has the business need targeted. The executive groks the vision, and calls the vendor, who sends a sales executive and sales engineer to meet with the organization, and sell a vision\u0085of a seamlessly integrated, real-time view of the company processes, or customers, or whatever.
\nNow the bigger the vision, the bigger the ROI, and the interests of all parties are well-served by revolution, rather than evolution. So the decision is made to junk the existing (badly architected, lashed-together, obsolete, barely-functional) systems, and build something new from scratch.
\nHere\u0092s where the problems really begin.
\nManagement, planning, analysis, and documentation rise in importance and as a necessary percentage of the project budget as the scale of the project increases.
\nExamples: I just designed and a friend built a small web-referral monitoring and reporting system; it\u0092s a database of about seven tables and four web pages. Meeting with the customer took about two hours, I wrote about ten pages of documents (including two pages of database ERD\u0092s, one page of flowcharts, and seven pages of functional description) in about a day, and the developer worked for a week to build it. So roughly 20% of the effort was in \u0091overhead\u0092.
\nI\u0092ve never worked in aerospace, but I\u0092m told that on major aerospace software projects that the \u0091overhead is approximately 60% of the total budget; this is required because a) the projects are extremely large; b) releasing buggy software and iteratively working it out \u0096 the Microsoft solution — is not an option; c) the management and reporting processes are extremely formal and structured, because that\u0092s what has worked on large scale engineering projects such as Apollo in the past. That system is brutally inefficient, and probably not a lot of fun for the people involved, but it works.
\nThe problems begin to arise when project sponsors try to take projects of near-aerospace levels of complexity and apply the kind of management techniques I used in designing a four-page, seven-table web tool.
\nMost non-aerospace organizations lack the expertise and discipline to manage huge projects. Many of them claim to, however.
\nThe best defense, I\u0092ve learned, is to manage the scale of the projects, rather than trying to change the management culture of the organization. This doesn\u0092t mean that you have to abandon far-reaching systems as a goal. It just means you have to break them up into littler systems that can be developed within a reasonable span of control. Personally, I tend to think that a project budget of $750,000 and a project term of four months is about right. You can do useful work and still have a small, agile team doing the work.
\nHenry came to the same conclusion:<\/p>\n

Don’t create one massive project, do mini-projects and stick to a rollout schedule. We changed too much too fast and tried for too many payoffs at once (in sales, client management, operations). That’s the number one reason the end-users got irritable and the reputation of the system was trashed almost immediately.<\/I><\/p><\/blockquote>\n

My personal project bible says much the same thing.
\nIf you\u0092re interested in this stuff at all, go read Rapid Development: Taming Wild Software Schedules<\/A>, by Steve McConnell. It\u0092s a terrific book; I\u0092ve given about a dozen copies away to clients and team members.
\nOK, for the non-geeks in the crowd, what\u0092s the relevance of this?
\nTraditional command-and-control government programs are like large software development projects; they are insanely complex, and to succeed, they require incredibly tight control over the participants. This both requires a huge \u0091overhead\u0092 of people doing the controlling, and a culture of tight control as well.
\nAnd like large software projects, they fail badly. The hysterisis\u0085the time lag between action and output\u0085is so large that it\u0092s almost impossible to change or adapt. Small projects fail well; they have low hysterisis, and so when problems arise, they can adapt in response to real conditions.
\nAs we\u0092ve talked about race, one of my issues is not that change needs to happen; it\u0092s that the breadth of change is so great that making it requires the kind of cumbersome, likely to fail or have unintended consequences programs that I\u0092m discussing here. I\u0092m trying to see a way through the problem that uses smaller more nimble, more effective programs.
\nNot only for dealing with issues of race, but for dealing with the array of issues that we confront as a society, and that, as a liberal, I\u0092d like to use the power of society and the government to improve.<\/p>\n","protected":false},"excerpt":{"rendered":"

I got some smart comments from Henry over at The Modern Middle Manager, and went over to take a look. He had a great post on an almost-failed eCRM implementation, and it started me thinking. About 70% of the billable work I\u0092ve done in the last five years has been work on failing technology projects. […]<\/p>\n","protected":false},"author":8,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/marcdanziger.com\/index.php?rest_route=\/wp\/v2\/posts\/2752"}],"collection":[{"href":"https:\/\/marcdanziger.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/marcdanziger.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/marcdanziger.com\/index.php?rest_route=\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/marcdanziger.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2752"}],"version-history":[{"count":0,"href":"https:\/\/marcdanziger.com\/index.php?rest_route=\/wp\/v2\/posts\/2752\/revisions"}],"wp:attachment":[{"href":"https:\/\/marcdanziger.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2752"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/marcdanziger.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2752"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/marcdanziger.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2752"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}