Plans to manage failure always mystify me. When I was told 80% of the data processing systems were never completed, I wondered where the numbers came from. The manufacturing shops were I’d worked were too small to tolerate that level of performance.
Shatterproof Glass could never afford trained programmers. When it needed computer systems, it tested some clerks and taught the ones with the most aptitude. They wrote the payroll and accounting systems from scratch, and people always got paid.
When I was there, it needed to modify most of its programs because the size of our part number had changed. It was the 1970s when car windows were introduced in new colors like gray and manufacturers were experimenting with thinner glass to reduce weight. The existing industry standard code no longer worked.
The only reason that project failed was the owner forced a strike by office workers, then moved the plant to North Carolina.
Mark Controls near Chicago had some of the best programmers I’ve ever worked with. When they needed to replace their computer systems, the project manager worked with key managers to develop a list of key reports and functions. They found the best answer was a commercial package used in another plant.
Once they started work, they had everything operating within six months. That was despite the company president who reacted to Wall Street downgrading its recommendations for the company stock by cutting costs. Where two programmers were supposed to do the work with a project manager, now it was only two working unpaid overtime. The other programmer wasn’t let go; my time was simply charged to existing projects so that new system costs were reduced.
Between Shatterproof and Mark Controls, I worked for a company that failed to implement IBM’s Copics manufacturing management system. Unlike the other companies, the central office was separated from the manufacturing plants. Any implementation planning meetings required travel, which limited them to upper managers who probably had other priorities when they visited the home office.
Our DP manager took to sleeping on a sofa in the lounge to develop an implementation plan, while the rest of us sat around for days doing nothing. The average programmer tenure in that period was 6 months. In the end, the company cancelled the project and outsourced the DP functions.
One other place I worked implemented new systems despite the owners. The project leader wanted his team to assess general requirements. The owners refused to wait, and asked another programmer to write on demand. Then, the owners fired the DP managers, and left the rest of us to rewrite the code they had ordered. At least we had some idea how it should function and could convert it into something more flexible. Turnover there was soon high.
In my last job, the IS department implemented major applications twice in ten years, once when I began and again for the magical year, 2000. Each was successful; most of the users were the same. Even though few were left from the original programing staff, continuity existed within the company.
The third new installation occurred after the contract changed hands and new managers distrusted the hardware they inherited, especially after the manufacturer stopped supporting some of it. Since there was no business justification, they couldn’t get funding for better applications, and so settled for continuing the same service with a different generation of computers.
The new managers didn’t trust the employees they’d inherited and so kept the implementation planning to themselves. Experienced users and programmers were deliberately kept out of the process, so the new company could do it its own way.
It wasn’t a failure, like the Copics experiment, but it satisfied no one. People were not willing to give their time to reimplement what they already had, and so reinforced the IS managers’ decision that his goal was to install everything then let users define what was missing later.
Looking back, failure has not been endemic and it has not been random and it has not been 80%. It correlated with the social structure of the company. Projects were more successful when managers, programmers and users were in the same area and could talk with one another. In those situations programmers developed a sense of how the business operated and could interpret the sometimes vague comments of the users. People at the same level learned one another’s weaknesses and needs.
In places where small group interactions could not exist projects were more likely to fail. The reasons varied: in one place, users were physically separated, in another owners didn’t want underlings to understand the business. More often, companies fear employees who socialize and do everything they can to discourage what they see as time wasting gossip that might be about them.
Companies who distrusted their employees were the ones who thought about managing failure because they continually experienced it and, unwittingly, perpetuated it.
No comments:
Post a Comment