Deploying Technology across the Enterprise

Seven General Principles for Successful IT Projects

Douglas Mitchell

Any company, which uses information technology, must eventually develop a methodology for acquiring and adapting available technology; computers, networking equipment and software to their business operations. I have served as an Information Technology/Information Systems/Systems Manager for several companies over the last twelve years, and have over that time developed some general principles for the deployment of technological solutions to business problems.

The first rule of deploying a new technology comes from the quotation above. The first deployment of a technology for a given problem – especially one not addressed before is the easiest. Something is always better than nothing.

This can be restated as our first Principle.

This seems a pretty obvious idea. What isn’t so obvious is its collorary.

The users of any system, be it technology based or just a collection of social conventions, get accustomed to the mechanics of that system. The users of the existing system will resist any new system that fails to be better, faster, more operator friendly (read this to mean does not ‘look and feel’ like the earlier system). In general, the users of the existing technological solution will prefer it to the new whether the new solution is better or not. The best way to ensure at least a modicum of their support for the deployment of the new solution is to include them in the development and especially the testing of the new solution. Therefore our next principle:

The operative words here are "always" and "help". Always enlist the help of the users; form a discussion group for example. Make sure the developers listen to the user concerns and problems of the old solution. Do not however, turn over the development of the new technology to this user group. The users are often too close to the problem of doing their own jobs to have the new ideas necessary for the development of the new solution. Getting the developers to talk to the users will allow the developers to understand their concerns and how these concerns get addressed in the new solution to be deployed. I’ve touched upon another point here when developing a new technology to replace an existing one. Our next principle then can be expressed as:

Having the developers perform the tasks the users perform will do more than any explanation or demonstration of the specific tasking, which make up the users work flow when using the existing solution to perform their jobs.

To Outsource or Not to Outsource

Every organization facing the deployment of a new technology has to determine whether to develop that technology in-house or to outsource the project to some outside contractor. In either case, it is extremely important that the Project Manager be held accountable for the ultimate deployment of the technology. It is equally important that the Project Manager be given all authority necessary to hire/dismiss contractors etc. This leads to our next principle:

When any organization tasks either an internal group or a subcontractor with a project, there is a belief that the organization has insulated itself from responsibility for that project. This is a particularly insidious belief, which consultants use to their benefit to convince organizations to outsource their development and deployment projects.

Tiger Teams

Many organizations use in-house 'tiger' teams to drive their development or deployment of new technological business solutions. In my experience, this is a natural development from the psychology of information professionals. Information professionals fall into two rough groupings; those who like routine maintenance of existing technological systems, and those who hate routine and like to work on new projects. The professionals who hate routine gravitate to tiger teams, because they can go from project to project and do not have to be faced with routine tasking. Because tiger team members hate routine tasks they tend to avoid tasks like writing documentation, and user training in the systems they configure. It is usually difficult even to get them to explain the new systems they've developed to the systems administrators who will be maintaining the newly installed system. In many cases the administrators must reverse engineer the solution just to figure out how to maintain it in production. This leads to the moral of this section.

The Prototype Pushed into Production Syndrome

There is generally a tendency to push any new technological system prototype once it is functional directly into production. This tendency must be guarded against and avoided, as it will delay the deployment of the final full-featured system.

This tendency to push the first working version of a system into production is reinforced by our first general principle when the system represents the first technological solution to a particular business problem. While it is probably true that the prototype system is better than no system - the effort in deploying the prototype combined with the effort in redeploying the 'real' final version of business solution makes the rush to deploy a net loss in the long run.

Conclusions

Following these seven general principles any organization can successfully implement and deploy technological systems, which truly address their business needs.

1This is a variation of a saying that I heard repeatedly from my father.

John Mitchell 1940 -