Before we look at IT as a whole, let’s take a look at a more obvious example. It’s pretty easy to define the job of a programmer. They take a set of requirements and write code that meets the requirements. It’s also easy to make that case that programmers can be used to generate value… and they run for days on twinkies alone. Yet, no matter the skills of the programmers, the value of programming is in what it automates for those using the software. It’s not enough to simply give a user a number of tools, the tools must be logically presented for the task at hand, and they have to have the *appropriate* level of automation.
The “appropriate level of automation” is key. Allow me to oversimplify. It requires a certain number of actions to make text bold in a typical word processor. We could reduce the amount of work programmatically by making an assumption – such as automatically bolding a whole paragraph with a click. That’s quicker, but I no longer have the capability to bold individual words, which is too limiting. On the other hand, if we had to bold each letter individually, it would be a cumbersome process… one that used to be a reality, not too many years ago.
Intentionally or not, this specific scenario is played for every feature that goes into an application… and for every feature that seems obvious, there are 10 that require a deep understanding of how the end user works, what they are trying to accomplish, what they expect to see, how they’ll screw it up… and you can go on and on. As far as the programmers are concerned, doing it right or wrong usually takes the same amount of work… but the value of the application literally hinges on knowing what the application is supposed to do, up front. All users who open an application have a certain task they want to perform, and they will gravitate towards applications that do the “right” job in the “right” way.
“The corporate mindset is that if a computer can boot, run Office and access the internet… well… that’s all they do, right?”
Programming is treated as a commodity in organizations that view the task of automation as a means to an end, as opposed to an integral portion of the business model. “We are now required to keep records of transactions for X years, we think it would be better to do this with an online database… hey programmers, build on online database to do that.” These projects are usually successful in their scope, but organizations eventually wind up with a hundred different systems that were all built with the same narrow focus, none of which talk to each other and ultimately create unnecessary inefficiencies or duplication. These same organizations realize at some point that their business is out of control, so naturally, they come to the conclusion that they need to literally rebuild their whole way of doing business from scratch and take a massive technological leap with an aggressive “ERP” project. Millions of dollar and several years later, they scratch their heads when they wind up with a solution that is far more reminiscent of the old process, than the process the technology should have allowed. Large scale ($Millions plus) ERP projects have a massive failure rate. Failure doesn’t mean the ERP was scrapped, failure may be indicated by being overbudget, overtime, underutilized, ROIs much smaller than anticipated, etc… anything that diverges significantly negatively from the original project goals.
Small programming projects tend to be successful because it’s easy to define the processes the programmers are going to automate, the goal usually being to evolve a process with a more efficient mechanism rather than replace a process with something unknown. Large ERP projects fail for dozens of reasons… it’s almost impossible for any large organization to fully document all of their existing processes, much less envision how all of those processes can be improved with automation on the whole, and how those changes will impact everything else. These are seen as capital projects, requiring every employee, every executive, every business office representative to come together as a collective whole to rebuild the business rules from the ground up with technology no one has any experience with. These projects fail because they expect the organization to function in an unnatural state, rather than using the organizations strengths to drive the development. In fact, there’s no better way to show how little an organization knows about its own business than to mention the letters “ERP”.
Having to undergo a *large* ($Millions plus) ERP project means, quite literally, that the company has seriously missed the boat on technology – probably for decades. However, ERP implementations are both inexpensive and successful when it is simply next logical step of an existing, successful, cohesive business development platform. Surprise surprise, companies that have a successful history of using IT to automate their business processes are more successful in large scale process automation projects. Duh!
The ERP debacle, and the fact that so many organizations expect a different result from the same plan, is a symptom of a much larger dysfunction. If we fail to get value from a cash cow like programming resources, how in the world do we get value out of less-easy to define IT roles in the enterprise, like the help desk, or the systems group, or the software group… etc? Simple answer is, we don’t. The corporate mindset is that if a computer can boot, run Office and access the internet… well… that’s all they do, right? How do you know your large organization has failed to leverage the most basic benefits an IT department can offer? They use the word “outsource”… a lot.
We’ll talk about that next time….
— By the way, if you’re enjoying these articles… please let others know about them! Digg this article, mail it, quote it, del.icio.us it, whatever… just spread the word! Feel free to drop me a line as well!