The OCM Challenge of IT Projects

by Luis F Pacheco LL, 2010

At the beginning of the 80’s, in Mexico, I lived an unexpected and nameless phenomena: the delivering of software systems for business operations support. Software engineering was underdeveloped and project’s mismanagement in budget, schedule, quality, staffing and performance were things that we, systems builders, had to learn to live with.   

This was a common professional programming environment:   

• There was nothing like a “business package” to buy in the software market, but companies had to develop all of it.
• The standard tools for writing systems were 3rd. generation languages (i.e., COBOL).
• System analysts did not know any single word about business management processes.
• We were conscious about writing programs in a skinny fashion because computer storage were expensive.
• One “good” programming practice was trying to produce only 10 lines of code, daily, but guaranteed to be “free of bugs”.
• The concept of “man-month” -a popular pragmatic key performance measure unit for IT productivity- had started to be disfavored as a “myth” by F.P. Brooks, Jr.

From those years comes this all-time favorite joke (very enriched now) about the indubitable fiasco of IT Projects to perform as an efficient device.

Found at http://www.adamsdesk.com

I must say this:   

• Business processes re-engineering had not been invented yet.
• We did not talk in terms of “benefits realization” and “business cases”.
• ERP did not existed (neither the Wikipedia nor the Google’s searcher).
• Only the Object Oriented Programming (OOP) and the early ideas of M. Porter about strategy and competitiveness brought us some hope in our lives.

By the end of the 80′s IT project’s out-of-control situations were a very common issue.

Programs’ coding started to be a minimal part of the whole task.

Figure 1. The Origin of Giants: Relative distribution of programming tasks.

New activities demanded professional management.

Figure 2. Baby Monsters: System’s size changed task’s distribution.

Only 2% of finished business systems were usable.

Figure 3. The Golgotha: Bad results of IT apprentices in the 80′s.

IT disasters when PM was still underdeveloped.

Figure 4. Budget Wrecks: Software development as nightmares journeys.

Then I was interested in two problems:

1. How could we encourage a cooperation impetus among the IT project members and their users (assuming they understood each other).
2. How could we assure the customer’s satisfaction once a system was installed (assuming it worked).

I believed that “people variables” and “linear methodologies” were imputable for this poor performance, but I did not realize how exactly the thing worked. Inspired to clean this mess -pursuing an “integral solution”, I started a master in Organization Development and met a bit after the chemical engineer’s community to learn how they transferred technology.   

As the IT puzzle were being more complex, I had to repoint my theoretical assumptions toward better mental models that accounted for a wider picture: the causes of failures appeared to be more socio-cultural biased than I had considered.   

The following drama (Business Week,  Apr 26, 1993; Jack Robertson, Mar 8, 1993) suggests that -if you like to read between lines.   

In those early days, I rarely saw a fully accomplished project. Even when IT people intended to follow a plan, to close a project systems had usually to be installed with errors and unfinished. Anyway, the end of the affair (God bless) was the most beautiful and enjoyable episode of the whole tale.

At the begining of the 90′s after a decade of software projects crashes and millions of dollars in looses, we were caught by surprise by a new business happening: Michael Hammer wrote its memorable “Reengineering work: Don’t Automate, obliterate” in Harvard Business Review. He argued that work could not be improved at the task level because activities were tied at a higher stage by the business processes they belonged to. This boom unleashed a lot of expectations among the fame hunters. (Every boss should want to reengineer his processes to make them “horizontals”.) But the honeymoon was very short: in 1994 Hammer & Stanton accepted that the failure rate of this innovation was greater than 75% (Financial Times, Oct 5 1994, p. 20). The reengineering movement exposed also how insensitive its apostles were about the issues they intended to solve.

Hall, Rosenthal & Wade published to the end of that very short period “How to make reengineering really work” (Harvard Business Review, Nov-Dec 1993). This was a sound article: it scanned a sample of 20 american and european business, was supported with hard data, built over an excellent knowledge integration, and sparkled with a bit of systems thinking. The authors found that narrow-process improvement don’t yield bottom-line results. A couple of factors were used to achieve this conclusion: the Breadth of Process Redesigned (values: from “single functions” to “business units”) and the Depth of Business Change (values: from “unidimensional” to “multidimensional”). Best results were found at the intersection of highest values.

Figure 1. An early opportunity to get into the systems thinking avenue.

It had actually to be the ERP generic software technology what commenced a new “IT Era”. The construction of huge systems were facilitated by “pre-built-ready-to-use” modules. IT technicians were reassigned to “configure” real business situations instead of writing abstract code. Software solutions started to be driven directly by customer’s needs, not by analyst’s skills. Programmers had to learn all that stuff of “business processes” to save their jobs. New professional roles were created at workplace. And more. But it still lasted several years before firms got some convincing benefit from this innovation. By the middle of the 90′s management of ERP projects in Mexico were still poor and customers didn’t realize all over what they had installed into their servers.

Recently, Panorama Consulting Group conducted an online survey among 1,600 global organizations that had completed an ERP implementation within the last four years. Information was collected from December 2005 to December 2009 and the results were published in its 2010 ERP Report. The Panorama’s major finding is not promising: both budgets and overall satisfaction are decreasing ince 2008, or to say in its words As Belts Tighten, ERP Implementation Benefits Decrease. We will see its figures in the next section.

The BPR practice was resurrected -fortunately- by ERP systems. The capacity for delivering complex systems in a reasonable time frame created the illusion of having a new powerful industrial standard for business transformation. The novitiate and tortuous days had apparently gone forever. Even more, the nightmare of business software development challenged initially by ERP started to face the intimidation of a new terrible enemy: the lasser sword of PM that claimed to have enough strength -at last!- to make it disappear.

But nothing of that hasn’t happened yet.

Instead, the reengineering’s ideal to redesign horizontally business processes was partially delayed by the project management’s linear thinking. At the end of last century big software project’s breakdowns were commonplace all around the world. The abstract of the K.R. Linberg’s article “Software developer perceptions about software project failure: a case study” (J. of Systems and Software, Dec 1999) captures well the tension between what businesses demanded to programmers in those days and what it was delivered by them.

“Software development project failures have become commonplace. With almost daily frequency these failures are reported in newspapers, journal articles, or popular books. These failures are defined in terms of cost and schedule over-runs, project cancellations, and lost opportunities for the organizations that embark on the difficult journey of software development. Rarely do these accounts include perspectives from the software developers that worked on these projects. This case study provides an in-depth look at software development project failure through the eyes of the software developers. [...] The results of the study identify a large gap between how a team of software developers defined project success and the popular definition of project success. This study also revealed that a team of software developers maintained a high-level of job satisfaction despite their failure to meet schedule and cost goals of the organization.”

The sites below contain references of most known software project’s failures in the last thirty years (enjoy the Software Hall of Shame in the IEEE Spectrum’s article “Why Software Fails“).

• Coding Horror.
• CRM failure rates.
• High failure rate hits IT.
• High Project Failure Rates.
• History’s Worst Software Bugs.
• Interview: Jim Johnson of the Standish Group.
• ERP failure: New research and statistics.
• Project and Programme Failure Rates.
• Statistics over IT projects.
• Understanding Project Failure Rates.
• Why Software Fails.

The ERP 2010 Report (Panorama Consulting Group) shows five major findings on ERP failures rates at present times.  

1. ERP Implementations Take Longer Than Expected.

Figure 5. Companies have unrealistic expectations about an installation.

2. ERP Implementations Cost More Than Expected.

Figure 6. ERP implementation 2010 vs. 2008 (Budget/Cost).

3. ERP Implementations Fail to Deliver Measurable Business Benefits.

Figure 7. Despite the investment ERP’s benefits are no guaranteed.

4. SaaS Implementations Take Less Time Than On-Premise, but Deliver Less Tangible Business Benefits.

Figure 8. Average Implementation Time of ERP systems (Months).

Figure 9. SaaS vs. On Premise ERP Results.

5. Companies Do Not Effectively Manage the Organizational Changes of ERP.

Figure 10. The lack of OCM is a critical obstacle in the implementation of ERP.

Figure 11. Companies still expect their ERP to deliver real business value.

If you go deeper inside literature you will see clearly that IT has today the same kind of problems than thirty years ago: time and budget’s overruns, lack of clear benefits, adversity, a complicated project management, failing skills and others. Anyway, no one would have imagined at 80′s -it was inconceivable- that IT people would be able to implement the huge systems that are been installed nowadays in eighteen months.  IT has astonishingly overthrew its engineering issues to design better solutions and deliver them… quickly! (comparatively speaking, of course).

Things are certainly better now than thirty years ago. The software packages that customers demanded in the 80′s decade are easy cake for today’s technology. So if IT failures persist the causes must be hidden in some neighbor’s land, not in his own. I would rather think that error is still there because nowadays change projects are more ambitious and complex than before. I mean, failure can be explained by the big challenges that we impose ourselves. Each time we overcome a problem we urge to face the next confrontation. But usually the right tools for fighting are not ready yet.

We are living in these days another edition of that ancient play. Impelled by the success of “Agile” methodologies for software development, IT is knocking today at the door of a new impredictable challenge: spreads its focus and goes beyond the coding task to get into the swamp of organizational culture for assuring business benefit realization. Its last city to conquer.

But organizational change management (OCM) -that one coming from OD, by the way- deals with social change a lot of time before IT realized its importance. Until now it has no magic answers or systematic procedures to guarantee the success (despite the “new” OCM methodologies around there claiming infallible results) of any change project.

Will IT make the dream real?

References

Send article as PDF to

Bookmark It

Hide Sites