By the end of 1991, drastic organizational changes were introduced in the IT department to try and overcome the existing problems. The main focus of these drastic changes was on the systems development and maintenance division, which was on the front line of giving service and support to end users. Other smaller divisions in the IT department, like Quality Assurance, Facilities, Office Automation and Training, were affected to a lesser extent, because they were not identified as the real problem areas.
A whole new management team was appointed in the systems development and maintenance division. The action was prompted by the need to solve as many of the critical problems described in the previous section as possible. Top management believed that the only way to solve the existing problems, and to regain end user trust and satisfaction with the service and support of the IT department, would be to restructure the systems development and maintenance division and to appoint new managers where necessary. All of the previously mentioned problems and frustrations could be summarized by the following three major concerns:
Low-quality software products and services
An unstable production systems environment
An unusually high maintenance frequency
The management team was challenged with analyzing the given situation and putting forward the necessary short- and long-term strategies that would be required to maintain and promote the bank's competitive position in the market. All this had to be done in the shortest possible time span.
This case study is based on a true situation. Some strategies were applied very successfully by the management team, while others failed.
The manager of the newly formed department believed in teamwork, and all projects/problems were analyzed and tackled by means of team efforts. Communication within the department was sound and took place regularly on an informal as well as a formal basis.
All systems development within the bank was the responsibility of the information systems development department. On establishment of the department, the main assignment from top management was threefold, namely to:
Stabilize the existing systems as soon as possible in terms of maintenance problems
Dispose of the magnitude of outstanding ad hoc requests for general management information
Deal with all new needs from users for the adaptation of existing products and the development of totally new products
Needless to say, the previously mentioned assignments were all rated equally critical by top management.
The systems environment had to be maintained and ad hoc requests for management information had to be possible and available to users on a daily basis. Furthermore, the backlog of new requests, with regard to systems amendments and new products that had to be developed, kept growing bigger and bigger.
The information technology management team was faced with the challenge to solve the given problems of the department as soon and as effectively as possible. They thoroughly released that a proper short-term and long-term strategy for dealing with the problem had to be formulated and "sold" to all personnel. Yes, they really had to deal with a change-management situation.
In short, the strategies of the management team were the following:
The first immediate objective was to follow a so-called breakthrough strategy. As Bob Schaffer puts it: "A strategy which consists of locating and starting at once with the gains that can be achieved quickly and then using these first successes as stepping stones to increasingly ambitious gains…Schaffer urges managers to… focus on accomplishing a short-term result, a success" (Peters, 1989).
A second important component of the strategy was that everything that had to be done, had to be subjected to strict quality control. As Tom Peters (1989) appropriately remarked: "Give quality all your attention."
The third important leg of the strategy was to demonstrate to all personnel in the department that the management team really had faith in their capabilities, but that there also had to exist mutual trust between colleagues, in order to help create a professional occupational environment in which high-quality products can be generated. This fact is strongly emphasized in the article of Tom Peters (1989) where he says: "…if you don't believe in the fulsome capabilities of people on the front line to get the job done and take responsibility for getting the job done, then you will make a million boo-boos."
It was decided to create an atmosphere of self-control, which would lead to self-discipline.
It was furthermore decided to create a work environment for each person in which he would be able, as a motivated person, to produce work of a high quality. This implied that each post within the information systems development department should have all the elements (dimensions) that would eventually ascertain that each member of staff:
Produces work of a high quality
Gets job satisfaction
The previously mentioned is based on the model of Hackman and Oldham (1991, p. 118), where job characteristics stimulating work motivation are identified. The complete model is shown in Appendix B.
In order to be able to carry through the total strategy to its full consequences, it was decided to create three sections within the department, namely: systems development, project management and business consulting. Each of these departments had to formulate its own objectives and policy.
A participating management style was followed, in which all personnel were constantly invited to give input with regard to the character and scope of the problems they encountered. Furthermore, suggestions and ideas towards the solving of problems were constantly elicited.
The first short-term objective of the management team was to determine exactly the nature of the current systems architecture. Several work sessions were held over a period of two months, in which all personnel had the opportunity to share their knowledge with regard to the existing systems architecture with the management team. It was decided initially to put up the whole architecture on a white board in a conference room, so that everybody could see it. It would afford anybody the opportunity immediately to point out any shortcomings he might incidentally notice.
After this process, the big challenge lay in determining how to go about simplifying the given architecture to such an extent that the variety of knowledge required for the maintenance thereof could be scaled down as soon as possible.
Regardless of the consequent suggestions and debates over how the complicated systems environment could be phased out, one thing stood out clearly—there were no affordable instant solutions for the existing problems.
However, it was thoroughly realized that they would have to be able to show short-term results to top management. As Winston Churchill aptly put it, "It is no use saying ‘we are doing our best.’ You have got to succeed in doing what is necessary."
The second immediate objective of the management team was to evaluate and categorize all outstanding as well as new user requests.
Although a computerized problem management system (help desk system) had already been available, it had many shortcomings and was not used by everybody. Some requests were therefore computerized and some were only available in letter format, which impeded the administration to a large extent.
Quality control with regard to the handling of all user requests (problems) was of course imperative, in order to be able to render a professional service to users. At that stage the information technology department was very unpopular with users, due to the fact that there were requests that were outstanding for more than a year. It was of the utmost importance to develop an effective problem management system.
It was immediately made policy that all users had to register their requests by means of the help desk system, before the development department would give attention to them. Information sessions were presented to users to supply the necessary training. The shortcomings in the system were immediately attended to, to provide for the categorization of user requests, as well as the furnishing of the necessary management information. The project management department was responsible for managing the system.
It was decided initially to apply strict control from management level with regard to all requests that had to be handled within the department, until a mental attitude of "only the best is good enough for our clients" had been established. It boiled down to "do it right the first time" and "deliver quality on time."
The management team believed that the root of quality work lay within the people themselves. Any person who is proud of and enjoying his job would deliver quality products. Practice proved this right.
The management team met every day (over a cup of coffee) to discuss and categorize the list of user requests immediately. It was the responsibility of the project management department for final quality evaluation.
The objectives of the evaluating and categorization process were the following:
To determine which requests were ordinary ad hoc information requests that could promptly be handled by the information center (which formed part of the development section)
To determine which requests had to be viewed as urgent maintenance and therefore had to be completed within 24 hours by the maintenance teams in the development section
To determine which requests were relevant to the amendment of existing systems and should therefore be viewed as maintenance projects
To determine which requests required further examination, because it is a new user need that could possibly lead to the development of a new bank system or subsystems.
In the latter two cases, the request was directly referred to the business consultation section for execution of the following basic functions, namely:
a proper examination of the real problem
a feasibility study
an impact study with regard to the existing systems environment
A graphic representation of the whole process is shown in Appendix B.
Thereafter the recommendations regarding such requests were put before the preliminary project team, who decided if the project should proceed. Such a project was then called a maintenance project, or a development project.
The project management section was put in control of the management function of all development projects. This section therefore had to manage the whole systems development lifecycle.
The responsibilities of this section can be summarized as follows:
To act as a metrics team for the planning and monitoring of all projects.
To put operation information as well as management information at the disposal of all levels within the organization. The approach was to keep everybody informed. It is aptly put by the manager of the Scandinavian Air Systems in the article of Tom Peters (1989): "An individual without information cannot take responsibility; an individual with information cannot help but take responsibility" (p. 9).
To ensure that all phases within the systems development lifecycle satisfy the prescribed standards and quality requirements of the department. Nobody was allowed to proceed with the next phase in the lifecycle before he had complied with the prescribed quality requirements.
To apply an after implementation audit to all software products, in order to determine whether the original objectives were reached and to take notice of (and to learn from) problem situations that were encountered during the development process.
To apply quality evaluation to all completed requests that were not handled as projects. This was just an interim measure, since they believed that it was the responsibility of each individual to ensure that he did quality work. The nature of this evaluation was primarily to determine the level of user satisfaction.
The project management model used was based upon the IEM method. An illustration of the model is shown in Appendix C.
For the purpose of this paper, only the components that supported the quality assurance process are discussed:
Project management—From the diagram it is clear that the total project lifecycle must be managed to ensure that deliverables of high quality be obtained. In fact, the term "project management" refers to the management of each individual project in order to ensure that high-quality results are delivered on time and within the budget. This is exactly what is obtained by means of this model.
Determining of the successful completion of a phase—The deliverables of the various phases are used as an aid to determine if a given phase was carried through successfully or not.
Timesheets and progress reports—Timesheets and progress reports are the two most important inputs to the whole project control process.
Timesheets: Since the management team exercised strict control over all tasks or actions which employers had to execute, such appointment of tasks were introduced into the project management system. All timesheets were automatically generated weekly (pre-printed) for each member of staff, with a list of all the tasks on which the relevant person may work (according to the management team). This immediately supplied a checkpoint against under the counter-requests from the user side, or even internal delegation among personnel.
On a timesheet three main categories of time could be indicated, namely:
time spent on projects
time spent on maintenance actions
time spent on unproductive activities, such as leave, training, idle, etc.
In the case of maintenance, a collection of codes was created for each product that was in operation, against which time could be accounted. By means of the correct management information, the unstable systems could be determined that would possibly not be cost effective for the bank any more.
Progress reports: Progress reports together with timesheets were handed in on a weekly basis. The purpose of these reports was to indicate "real" progress (as its name implies). By means of these reports, the necessary amendments to project schedules were done.
Time box management: In order to be able to restore user satisfaction as soon as possible, time box management was applied throughout all projects. The principle that was applied here is aptly described in the IEM documentation (1991): "…it is often better to obtain an acceptably complete, high-quality deliverable quickly than to wait for a long time for a more comprehensive deliverable" (p. 107).
Project planning and control: All user requests eventually reverted to projects were planned by the project management section in cooperation with the relevant project leader. To be able to apply project estimation in the most professional way, they had to establish and maintain a database of measuring instruments. This database was then used to measure the progress of each of the project teams as effectively as possible. As Tom Peters (1989) puts it in his article, "What gets measured, gets done" (p. 9).
The whole project management information system was developed on a microcomputer software package in order to be able to make management information of all development projects available.
Although not all of the imposed objectives were met, the management team in general achieved positive results with their approach. The main reason why some of the goals were not achieved was perhaps because of the fact that the management team was too optimistic about achieving their goals over the short term. One such goal was to stabilize the high level of maintenance over a short term. This was difficult because of the complexity of the environment.
On the positive side end user satisfaction was much higher over a relatively short period of time and one could even say that the culture gap was smaller. This could have been the result of end users having been invited to become involved in all decision making, which created confidence and understanding among them for the IT environment. This way of bridging the culture gap is also sanctioned by Du Plooy (1995). In terms of better service and support, requests submitted by end users on the help desk were addressed more efficiently, which also created confidence. That was the case for old and new requests on the help desk. The backlog was reduced to an acceptable level, and IT professionals were much more positive and committed, leading to higher quality products from most IT professionals.
Beer et al. (1990) discuss six steps for successful change management. They are used as guideline to evaluate whether the management team was successful:
Mobilize commitment to change through joint diagnosis of business problems
This step was vital to their strategy. Right from the beginning they realized that the only way to analyze the total business problem would have to be through a team effort that would require everybody's participation.
As had already been stated, all personnel were involved with the analyzing of the problem, and it was evident that most of them were very appreciative of the fact that they (down to junior level) were all asked to participate in the analysis process.
Foster consensus for the new vision, competence to enact it and cohesion to move it along
Participating management was the pivot on which all decisions hinged. Matters on which general consensus could not be reached on management level or within a project team were held over for further discussion until an acceptable solution had been reached. Sound motivation of standpoints were always encouraged, to enable us to find the best possible answer to a given problem. As a result it often happened that long, but thorough debates were conducted with regard to such matters.
The head of the department shared all information received from top management with the rest of the team. A staff meeting was held every week, during which personnel were fully informed about all decisions and visions that were communicated to him by top management.
Spread revitalization to all departments without pushing it from the top
The modus operandi of the whole department and the various responsibilities of the personnel were communicated to all the departments within the bank. Especially as far as the problem management action was concerned, several work sessions were held with users to explain the advantages of the new modus operandi to them and to train them in using the system.
All actions and efforts were appreciated in all respects, and they had the cooperation of everybody concerned.
Institutionalize revitalization through formal policies, systems and structures
As already mentioned, it was the duty of each department to supply the necessary policy documents and procedures, in order to structure and give order to the whole process. These policy documents and procedures were explained to all personnel at the staff meetings mentioned.
Even before such policy documents and procedures were introduced, it had already been clear that the personnel urgently needed these guidelines. Each person was supplied with his own set of copies that was updated from time to time. Many frustrations, obscurities and inquiries were immediately eliminated by the release of these documents.
Monitor and adjust strategies in response to problems in the revitalization process
Nothing is perfect—this they saw and experienced daily. Decisions that were made the previous day were often still-born the next morning, or withered and died soon afterwards. Then they were back at the drawing board.
It was always put clearly to all personnel that the management team was busy experimenting in many cases, and should they at all determine that a certain procedure or policy is not really efficient, or is not working, it would immediately have to be amended.
The management meeting that was held every day was used as a monitoring forum for feedback on all the activities of the previous day. In problem cases the necessary modifications were done to either policies or procedures.
It was imperative that the change process should not be monitored by the head of the department or division alone, but that it should be a shared responsibility. This is aptly put in the article by Beer et al. (1990): "Some might say that this is the general manager's responsibility. But monitoring the change process needs to be shared, just as analyzing the organization's key business problem does" (p. 164).