Cultural Complexity Squashes Methodology

In a previous post, I theorized that an organization’s culture is the largest obstacle to successfully completing a software development project. This topic really intrigues me for a few reasons. One is that it goes above the methodology argument. Where there are certain camps advocating one approach over another, there are more people sitting in between watching none of them work. In fact, the first “Extreme Programming” project (C3) “failed” due to communication failures between three stakeholder groups; developers, sponsor and users. So although they were able to revamp a failed development project and pare themselves down to an agile group, they still were unable to truly satisfy both the sponsor and the users. But, was it ever going to be possible to satisfy these people? Think about how much inertia must be overcome to make even a slight change in a huge organization such as Chrysler, much less replacing the entire paycheck system.

At the heart of this failure is the simple fact that an organization, much like people, do not always behave rationally (in a utility driven sense). In this case, after four years, C3 came in over budget and behind schedule. Also, after the Y2K scare (turns out that I didn’t need that bunker and canned food after all) Chrysler just went back to using their mainframe solution. The problem here is that at this point, C3 was more than likely in the home stretch and simply waiting for further adoption throughout Chrysler. But ignoring sunk costs, Chrysler cut the program.

Some cultural notes here: if you look at studies of new products, only about 15% of individuals are willing to put themselves on the cutting edge. Imagine how this would work throughout the HR groups of Chrysler. Is the HR director at the Twinsburg stamping plant going to eagerly replace the system that they have been using for years with a new one? Probably not willingly.

Also, knowing that Daimler was looking to purchase Chrysler, I’m sure it was a priority to trim down departmental budgets. In this case, it probably made sense to swallow the sunk costs in expectation of a better financial result.

Finally, apparently the C3 project is underway again, using SAP. Culturally, this probably makes sense. With SAP, your scope is already defined and your options are finite. With a custom-built system, stakeholders can dream up wonderful, contradictory and insane requirements and you can literally implement them all. With SAP, you cannot. Instead they have spent millions of hours accumulating requirements from your industry and have implemented the most commonly needed solutions. I am in no way saying custom development is a waste, but it is not always the best solution given the environment and context.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.