managing information technology projects: chart(ii) development in a large hong kong company

~ntefnationai Journal of t~jof~atio~ Management (1992), 12 (142-l 57)

Carlson Chu is currently an engineer with Hong Kong Telephone Company Limited and specializes in the field of telecommunication signalling and integrated services digital network (ISDN). His interest in IT project management developed from his work in managing software projects. Barry Bannister has worked on a number of information management projects in Asia and currently is head of the Manage- ment Department at Hong Kong Polytechnic.

Managing Information Technology Projects: CHART( II) Development in a Large Hong Kong Company

C. CHU AND B.J. BARRISTER

The computer-based system has become an important corporate asset, for the success of information technology (IT) projects can have direct impact on the profitability of a company. Although there has been significant progress in software engineering techniques, problems like delay, budget overruns, sub- standard performance or even complete failure still occur frequently in IT projects. Technical excellence is important but high quality management is also indispens- able in dealing with the immense complexity and scale of today’s IT projects. Project managers must be able to identify problems in all aspects of the project and act promptly to solve them. The study on which this article is based employed a systematic model - the project implementation profile (PIP) - as a framework for the investigation of the vagaries of CHART project development in a large Hong Kong company. The authors trust that the experience of CHART(ll) will assist readers contemplating similar projects to avoid some of the difficulties encoun- tered in the Hong Kong context.

Background of the CHART(II) system

HKComNet is a Hong Kong company that operates a local communication network. In parallel with technology development and network evolution, the quantity of network data has increased exponentially. A large volume of record updates such as additions, amendments and deletions are produced everyday. A large work force is employed to maintain the record files, but it is still unable to attain timely and accurate record management. In view of the growing trend, top management decided to computerize the engineering work in 1989. This marked the birth of the CHART project. The CHART system will replace the manual filing system by a common database and it is able to transform the user inputs into engineering charts, perform job schedul- ing and issue the corresponding work orders. The system is further subdivided into CHART(I) and CHART(I1) targeted at different equipment manufactured by different overseas suppliers. Figure 1 provides an overview of the CHART system.

A project team was formed with team members coming from end-user departments reponsible for the issue and maintenance of engineering records. They were high-calibre telecommunication en- gineers and technical officers but had no previous experience in software system design and analysis. A specification for the CHART system was compiled and the contract awarded to a software consultancy firm. Afterwards, the project team was dissolved and only two staff members remained to liaise full-time with the developer.

Because the CHART system was highly engineering-specific in nature, it was completely different from usual commercial applications. The developer required a significant amount of information and de- tailed clarification in order to comprehend the intended CHART

142 0268-4012/92/02 0142-l 6 @ 1992 Butte~o~h-Heinemann Ltd

c. CHU AND fk!. 5ANNlSTER

r CHART (1) users

CHART (I& I I) system

DEC platform

interface to other systamr @w

y-”

Data generation centre

Figure 1. An overview of the total integrated CHART (II) system

operations and facilitate the design prrrcess. Inadequate communication fed to many probfems and the progress of the project was affected. The dew&per reflected this sitrtatiun to the top rn~~~~~rn~n~ of HKComNet and in response the CHAR”r Project Department was ~~~~~~js~~~ in April 1990 (see Figure 2). Despite the formation of a dedicated Project Department, the CHART project continues to suffer from ever increasing problems and disputes. Nat only is the progress unsatisfactory, but the client-developer relationship is deteriorating.

The objective of this article is to investigate the CHART(I1) IT project of HKComNet Company Limited from a managerial perspective and recommend possible improvements. The project is divided into phases that can be contracted to different software consultatlcy firms. It is desirable from HKComNet’s point of view that the development strategy and policy be i~de~~~d~n~ of any gwticufar develaper.

A project is a set of activities, linked together over a finite period of time, which are carried out tcr produce a specific goal or goals. Most projects are one-off involvements, which have a warking organization structure with well defined responsibilities.

‘Cln.rbzg rhe gzrps in project managemctzt The traditional form of organization creates management gaps and

syx@ms (1984). Systems Gap Working Far- functional gaps which divide the company into operational islands’ as

ly ~e~~~~.~~~u~~~~~~~ of Project P&m+ illustrated in Figure 3. Project management emerges as an o~~~~~i~a~ion- grs. GuiI&r& Brrttcr~~~h~. al structuring concept designed to obtain more effective and efficient

~aRa~~R~ IT projacts --

Overseas equipment supplier

-- 7

~-----_~.___-__

Senior ~a~a~e~~n~

1

n Contract

.~.l.~~“~___.~~l._.-___-.-.-._._._._._

Hang Kong office

HKComNet

i Secondary i end users

Senior rn~~~gerne~t

Development team

Figure 2. The relationship between the CHART department and various ~t~ke~o~de~

~tiljzatjQn of the company’s resources of manpower, capital, materials, technology, information and facilities. As project management is well suited to accomplish certain goals, it receives increasing popularity in our society and its organizations. The prime objective of project management is to accomplish the target with the given resources and balance the trade-offs among time, cost and performance. Figure 4 is a pictorial representation of the main factors in project management.

Like product life q&e, the concept of project cycle provides a useful framework for rooking at project dynamics over time. Most projects go through simifar stages on the path from origin to compfetion and each stage c&s for different tasks to bc performed. Basically four distinct phases of activity are identified.

0 Conceptualization; 0 Planning; 0 Execution; and 0 Termination.

$44

‘PINTO, J.K. AND SLEVIN. D.P. (1987). Balancing strategy and tactics in project implementation. Slnnn ~u~ugeme~~ Re- view, Fall, pp. 33-41.

Management gaps Functional gaps: departmentization

CHU AND B.J. BANNISTER

AA

1713DL

DUB?

E7!!2i\il

~perotjonai blonds

Figure 3. The generation of ‘operational islands’

Project critical success factors

Many recent studies on IT projects have developed lists of critical success factors that are crucial to successful project implementation. Based on a comparative analysis of the conceptual models developed by these researchers, Pinto and Slevin2 consolidated them into a generic ten-factor model:

Project mission; Management support; Project schedule/plans; Client consultation; Personnel; Technical tasks; Client acceptance; Monitoring and feedback; Communication; and Trouble shooting.

Based on these ten factors, the Project Implementation Profile (PIP) framework, as illustrated in Figure 5, is developed. The model is intended to demonstrate that these ten factors are both time sequenced

Performonce

Environment

Figure 4. Pictorial representation of the main factors in project manage-

ment

145

Managing IT projects

Project mission

1 *

Top management support

Project schedule/ plans

Client connotation

Personnel recruitment, selection, and training

Technical tasks

Client acceptance

Trouble shooting

Figure 5. Ten key factors of the project implementation profile (source: Schultz, Slevin and Pinto, 1987)

and interdependent. For example, it is important to set goals or define the mission and benefits of the programme before seeking top management support. In actual practice considerable overlap can occur among the various factors, and their sequencing is not absolute. The arrows in the model represent information flows and the sequences, not causal, directional, or correctional relationships. In addition to the seven factors that can be laid out on a sequential critical path, the remaining three factors are hypothesized as playing a more synoptic role in project implementation. These factors, monitoring and feedback, communication, and trouble shooting, must all necessarily be present at each point in the implementation process.

An in-house survey’ conducted by Philips NV (Holland) in the late 19’70s provides potentially significant insights in the relative importance among competitive factors. The survey covered 150 IT projects and Table 1 lists the factors which were perceived by respondents as being the keys to success, along with the frequency with which the in~iividual factors were mentioned in connection with each project. Table 2 lists perceived causes of failure based on data from the same survey; however, it should be noticed that the priority of critical success factors is dynamic rather than absolute or immutable in nature during the project life cycle.

3~~~~~~, M. (1990). Project leadership and Strategy and tactics the involvement of users in IT projects. Project Management, 8 (No. 4), pp. 214- As one moves through the ten-factor model, it becomes clear that the

216. factors’ general characteristics change. The first three (mission, top

146

Table 1. Key to success

C. CHU AND B.J. BANNISTER

Factor Frequency of mention (%)

Clearly defined objectives High user involvement Executive quality of project manager Well-defined project management structure High user commitment Quality of project team Choice of project Planning and control methods in project Limited objectives Well-defined responsibilities Good estimating methods Technical quality of project manager

96 80 73 69 69 57 57 57 30 26 23

7

40p. cit., Ref. 2.

management support, and schedule) are related to the early ‘planning’ phase of project implementation. The other seven are concerned with the actual implementation or the ‘action’ of the project. These planning and action elements can be considered strategic - the process of establishing overall goals and of planning how to achieve those goals - and tactical - using human, technical, and financial resources to achieve the strategic ends. While both strategy and tactics are essential for successful project implementation, their importance shifts as the project moves through its life cycle. Strategic issues are most important at the beginning, while tactical issues gain in importance toward the end.

The strategy/tactics effectiveness matrix,4 as shown in Figure 6, is constructed from the four possible combinations of strategic and tactical performance. The values ‘high’ and ‘low’ represent strategic and tactical quality, i.e., effectiveness of operations performed. Also, as far as possible, the kinds of errors likely to occur in each scenario are predicted. The combinations are:

0 Cell I: High s~ra~~gy/~ig~ raetics. Cell 1 is the setting for projects rated effective in carrying out both strategy and tactics. Not surprisingly, most projects in this situation are successful.

Table 2. Causes of failure

Factor Frequency of mention (%)

Poorly-defined objectives User not involved Poor planning and control methods User not commi~ed Changes in requirements Political problems in user organization Project manager a poor executive Ill-defined responsibilities Bad estimating methods Poor project management structure Too ambitious Project manager a poor techician Poor quality project team Software failure

50 46 46 42 42 42 34 34 34 34 23 19 15

7

147

managing /T projects

Potential for

Type II 8.111 errors

High acceptance : misuse

High potential

for implementation success

2 I

High potential Potential for

for implementation Type I 8 IV

failure errors

I _ Low

Low acceptance : low use

3 4

Effectiveness of strategy Hlgtl

Type I error : Not taking an action when one should be taken

Type II error : Taking an action when none should be taken

Type III error : Taking the wrong action ( solving the wrong problem)

Type IV error : Addressing the right problem, but solution is not used

Figure 6. Strategy/tactics effectiveness matrix (source: Schultz, Slevin and Pinto, 19873

* Cell 2: Low strategy/high tactics. Project strategy is poorly conceived or planning is inadequate, but tactical implementation is well managed. Projects in this cell often suffer from ‘errors in action’. Type ZZ error happens if an action is taken when it should not have been, i.e., waste of efforts. Type ZZZ error can be defined as solving the wrong problem, i.e., the wrong problem is isolated. Because of poor strategy, a project may be pushed into implementation by top management even though its purpose has not been clearly defined. This results in high acceptance but misuse.

0 Cell 3: Low strategyl~o~ tactics. Projects in this cell have a high likelihood of failure.

e Cell 4: High strategy/low tactics. Project strategy is effectively developed but subsequent tactics are ineffective. There is a strong tendency toward ‘errors of inaction’. Type Z error occurs when an action that should have been taken was not. Type IV error occurs when the action taken does solve the right problem but the solution is not used by the client. The end product is of poor quality or cannot fulfil client specifications, resulting in low acceptance and low use.

148


Findings from questionnaires

A questionnaire was designed to measure CHART(I1) project scores on each of the ten factors in the Project Implementation Profile model. The questionnaire consisted of a total of 50 five-point scale questions (five questions for each factor), and respondents were requested to provide their ratings on each question ranging from 1 (Disagree) to 5 (Agree). The questionnaire was used as a pragmatic instrument to highlight likely problem areas rather than for statistical purposes. The questionnaires were distributed to the HART project team members and contact persons in end-user departments. However, the staff of the software consultancy firm considered it was too sensitive to participate in this survey and declined to comment.

The overall results are summarized in Figure 7 where it can be seen that none of the factors was valued as exceptionally high or low, with scores being concentrated within the 50 to 70 percentile range. This type of result is not unexpected in a bureaucratic organization characterized by generally mediocre performance and in which there is a reasonable likelihood of CHART(I1) project staff having to spend time in ‘firefight- ing’ exercises to eliminate or prevent the errors mentioned in Figure 6.

The ratings for project mission, top ~nanagem~nt support and client acceptance were the lowest among the factors and therefore subsequent research effort, including observations and interviews, was concentrated on these three areas in order to diagnose the possible causes of poor performance.

Problem investigation

Problems in project mission

Poor irzitial project strategy. Top management were too optimistic about the project and expected to avoid the difficult task of system development by contracting it to a software consultancy firm. The initial project team was dismissed soon after the system specification of CJIART(I1) was completed. it was unrealistic to expect the developer, who barely knew anything about the specific technical details, to design a functional system merely on the basis of some general documentation without active client interaction.

The dissolution of the project team projected a false impression of mission accomplishment to other organizational members. Naturally they assumed their duties were discharged. This seriously hindered subsequent activities because no one would ever care about and support a supposedly completed project (Type I error - not taking an action when one should be taken). The two members who remained behind to liaise with the developer were only engineer grade staff who lacked sufficient authority and could not work efficiently by themselves with the development consultants. This in turn affected the performance of the developer who naturally felt that they were not solely responsible for delays, errors and the generally inadequate level of IT management evident in the project so far, thus sowing the seeds of future conflicts.

Lack of genuine company-wide support. The advantages of the project as presented by top management consisted of some vague indications of better work quality, which certainly was not effective in motivating

149

As evaluatecf by CHART (II) project team

Project mission


Project schedule/plan

Client consultation

Personnel

Technical tasks

Client acceptance

Monitoring and feedback

Communication

Trouble shooting

0 20 40 60 80 Percentile rankings (%)

Project mission


Project schedule /plan

Client consultation

Personnel

Technical tasks

Client acceptance

Monitoring and feedback

Communication

Trouble shooting

As evaluated by end users

0 20 40 60 80 Percentile rankings (%)

Figure 7. Project implementation profile for CHART (II)

100

Hong Kong workers who in general consider financial rewards as most important. Most of HKComNet staff felt the project had not really involved them and therefore they had little interest in it and did not take any real initiatives to support it. Even when they noticed something

150


went wrong, they just *let it be’ (Type I error - not taking an action when one should be taken), with these problems eventually showing up at a very late stage causing considerable damage to the project’s overall implementation.

In a recent staff attitude survey, 41 per cent of the employees commented that management ignored the negative impacts on staff in effecting changes, with those of low rank or advanced age suffering particularly from rapid technological changes. These staff exhibit a high degree of inertia to changes and produce only sufficient half-hearted work effort in order to satisfy their supervisors. After the company-~vide retrenchment in March 1991, it was even more difficult to gain genuine support from the employees because they perceived automation as a major threat to their job security.

Middle managers, in addition to their own functional duties, acquired CHART(I1) as part of their supervisory responsibilities - with the project being regarded as an additional workload not tied to any extra financial or other types of rewards - and so they tended to avoid whole-hearted commitment without provoking negative reactions from top management.

Unclear ~erfo~~~~lc~~r~war~ criteria. An objective can be thought of as a quantified statement of what is to be accomplished within a particular time frame. On the other hand, a goal is a non-specific open-ended statement. Although the project schedule and mission were clearly enough defined, team members felt uncertain as they had no concrete idea of exactly what each individual was supposed to achieve at each milestone. There was no formal objective setting for team members, while some waited for the project leader to provide directives which, when issued, were neither specific nor coordinated, resulting in indi- viduals using their own initiative to work on whatever seemed to be appropriate (Type III error - solve the wrong problem). Without a clear sense of vision from the top, therefore, the priority order of activities was decided on the basis of subjective judgement.

Problems in top management support

Difference in orientation between top management. Contracts for IT projects are usually defined in broad and flexible terms. The actual details are worked out during system analysis and design, thus becoming a potential main source of conflict for many IT projects. For HKCom- Net the objective was to tnaximize benefits obtained from the contract, while in contrast, the objective of the software consuitancy firm was to maximize profit. Whether the contractual parties can resolve these differences in purpose and orientation very much depends on the influences of one party on the other.

Faced with various external and internal constraints - such as frequent changes in user requirements and insufficient technical know- ledge of CHART operations - the developer was unable and unwilling to deliver everything requested by HKComNet. Disputes over the interpretation of contract terms escalated as the project deadline approached and since the relationship between top management of the two companies was not as good as it might have been, it was not easy for them to compromise. Unfortunately HKComNet did not have a strong influence on the software consuitancy firm because they had no close

151

nonaging IT projects

business relationship and under the present circumstances the project was unlikely to bring further contracts to the developer. Agreements were usually reached after difficult negotiations involving both parties and resulted in bitterness on both sides.

To support top management in their negotiations, the project team undertook many irrelevant tasks such as gathering evidence to back up their side in negotiations (Type II error - action taken when it should not have been). On the other hand, certain development work had to be suspended until there was a clear decision from top management. This inevitably introduced further delays and hence the situation continued to deteriorate and seriously constrain the progress of the project team.

Bureaucratic culture. Meilir P. Jones’ has pointed out the primary causes of mediocracy are fivefold:

e e l

e

e

Absence of well-defined objectives for the organization; Weakness of the formal organization; Employees’ drive for self-advancement through competition with other employees; Departmental problems that limit employees’ ability to perform well; and The tendency of mediocracy to self-perpetuate.

In many respects, HKComNet resembles a mediocracy. Even though the company has defined and announced its corporate mission, it has not strictly followed this up by formal objective setting in divisions and departments. Without clear objectives, individual staff members may opt to pursue personal goals. Therefore, the intense political culture cultivates risk aversion behaviours in which employees generally tend to avoid decision making in order to reduce the possibility of committing errors. To play safe, colleagues request each other to record all decisions in black and white with the conduct of business relying heavily on formal communication channels leading to an approach in which information has to flow through a hierarchy that is prone to delays, filtration and distortion.

This bureaucratic culture is in contrast to the dynamic and flexible culture of the DP business. In addition, cultural barriers further hinder effective cooperation between the client and the developer. As a result differences in perspective sometimes induce the client to reject effective solutions from the developer (Type IV error - action taken does solve the right problem but the solution is not used by the client).

Problems in client acceptance

Frequent s~e~ifi~at~~n changes. Since the technological environment changes at a very fast pace, lots of new services have to be implemented to cope with the demands of customers; hence, there is at least one major software and hardware upgrade for HKComNet’s equipment each year. As a result, new work practices are introduced and old ones are amended or abandoned, and for the lastest revision of CHART(H) specifications, the document itself is over one inch thick and contains hundreds of modifications.

Inaccuracy in specification was also caused by the poor documenta-

‘JONES, M.P. (198.5). Practical project man- tion problem of the equipment supplier to HKComNet, so that the

agement: Restoring quality to DP projects supplier was unable to provide a complete set of operational manuals and systems. Dorset House Publishing. and documents to HKComNet. Even when some of the manuals were

152


available, they were usually incomplete, lacking in adequate explana- tions and full of errors. As the specification of the CHART(I1) system was compiled from these inaccurate documents, it inherited all the mistakes embedded in the original manuals.

The fact that end users were not accountable for the quality of the specifications, induced them to treat the matter casually and informally. Without thorough consideration, there was not enough assurance of the accuracy of the specifications and eventually missing requirements were discovered and changes were requested.

From the viewpoint of software development, it was extremely undesirable to change the design once the programming stage began. Frequent changes in specifications also squandered the time and other resources invested in design efforts, while continuing disagreements and the developer’s refusal to provide certain functions resulted in low client acceptance, as the finished components only partially complied with the original or revised requirements (Type IV error - action taken does solve the right problem but the solution is not used by the client).

C~~~~~~c~~~~~z problem. The CHART(I1) project team believed they had regularly provided sufficient information to end users who claimed that they had inadequate information with which to monitor progress. The root of the problem lay in the different definition of information as what had been provided by the project team was not what the end users actually wanted. Even though abundant materials, such as technical design documents, were delivered to end users, not much useful information was communicated. Since this had no immediate impact on end users, they just tolerated the situation and rarely reflected the situation to the project team. As a result the feeling of being ‘left out’ created a psychological barrier to the acceptance of the project.

Perception probletn. The project team admitted that they had di~iculty in documenting the descriptions of work practices accurately from end users because they were not standardized by formal procedures and also different job holders or end-user departments employed different methods. The CHART@) project team had to discuss the project with every user department and combine their description into one generic procedure and seek their endorsement.

Due to differences in perception, it was very unreliable for the developer to perform software design merely based on specification documents without direct communication with end users. Deviations were introduced by the project teams in interpreting end-users’ descriptions and then by the developer in interpreting the specifications.

I~z~uf~cie~t t~~i~~~g for end users. The CHART system inevitably introduces changes in existing work practices. Under the present circumstance, the project team is already fully occupied in catching up with the project schedule, barely any efforts have been devoted to training end users. As end users receive little assistance to cope with the changes, they do not understand the need to alter their present work practices and tend to resist any changes imposed on them. This is a typical problem associated with the line and staff function dilemma, but which is exacerbated by the types of problems and errors discussed in this article in relation to IT project management.

153

Managing IT projects

Impucts of retrenchment programme

As mentioned earlier, HKComNet carried out a retrenchment programme at the end of March 1991 in which about 10 per cent of the employees were laid off. This was followed by a major reorganization of the corporate structure as a result of which employees generally felt that top management lacked the sincerity to communicate and consult with them throughout the process. They felt that they were forced to accept management’s decisions without a viable alternative, thus creating an atmosphere of distrust. Rumour and speculation circulated around the company, staff morale was greatly affected as employees were confused by the sudden chaos in the hierarchy and also frustrated by indefinite career prospects. Although nobody in the project team was laid off, members were influenced by the sense of apprehension felt by their colleagues throughout the company and in addition, the nature of the CHART project placed the team in an embarrassing situation in that they had to carry out their work in an appropriate manner in order not to provoke further resistance to automation which was already perceived by staff as a factor in the retrenchment programme.

Alternative courses of action

Chnnge to another developer. To a large extent, the CHART(I1) project suffered from difficulties created by the gradual breakdown in consen- sus between top management of HKComNet and the software consultancy firm concerning the scope and operational functioning of the project. Lacking a sense of rapport, it is difficult for the development team to carry out their work effectively under the current circumstances. As it seems that there is little hope of reversing the present situation, changing to another developer is recommended. In order not to make the same mistake again, the choice of a new developer is crucial. HKComNet can either select a suitable candidate from among those companies with which it already has a satisfactory working relationship. or contract the project to its sister company Computpower Co. Limited. Computpower is the most favoured choice as it and HKComNet are members of the same group of companies and therefore there should be less potential for management conflicts. Under this arrangement, the project team should be able to work effectively and in an harmonious environment. However it is important that an official business relationship should be enacted even though they are group companies, so as to maintain professionalism in all aspects of the project management process.

Once it is decided to change to another developer, the present development strategy also needs to be revised and in this situation HKComNet may consider - instead of insisting on having a fulIy functional CHART system - that it is worthwhile to drop part of the optional requirements so that the developer can concentrate efforts on completing the main function modules. This ‘at least something good’ policy saves the new developer from the redesigning the whole system again and it can be brought into service earlier by simply adding the unfinished function modules.

Qua&y assurance scheme. The fact that end users are not accountable for inaccurate descriptions of their work practices induces them to treat

154


the project casually and lower their awareness of mistakes. If the quality of the specification can be improved the number of subsequent changes will be reduced and better client acceptance can be achieved. Therefore, responsibility should be restored to end users and the project team set up guidelines to be followed by end users in preparing the specifications by themselves. The completed specifications are then submitted to the project team which acts as a counter-checker to detect further mistakes and combine the various pieces of information in a single system specification. This forms a double-tier quality assurance scheme in relation to which additional resources and assistance from the CHART project team should be provided to end users in order to compensate for the increased workload.

Defining baselines. The project leader should discuss the project with the various stakeholders so as to agree on the baselines for accepting changes in specifications. All requests for changes are evaluated accord- ing to the agreed criteria through formal procedures and in as objective a manner as possible. Non-priority modifications are screened out until the next development phase and, in this way, the project environment is more stable so that the devetoper can estimate design efforts with greater certainty.

7’uctic of pru~ugu~~un. Top management should convey to all staff the importance of the CHART(U) project to the company’s prosperity and profitability. This can be done by regular reiteration - by top execu- tives at various company events - of the increased efficiency and staff benefits resulting from the project. Articles disclosing the latest status of the project or other useful information should be published in the company magazine and newsletter with the main theme being to keep every employee in regular contact with the project and to help promote the status of the CHART project from their point of view. When the project is perceived to be important, middle managers and their subordinates will be more ready to support and work for the project in the hope of obtaining top management’s recognition. In addition, it is imperative that top management give open appraisals and suitable rewards to those who have made distinctive contributions to the project. Hopefully, such desirable behaviour will be reinforced and ultimately integrated into the culture of the company.

1L;ligh profile image. The project team needs to maintain a high profile image and work to maintain a high professional standard with the aim of fostering respect in all stakeholders and creating a desire in the team to manage the project as effectively as possible. Basically the project team has to work on the policy of ‘never say NO to customers’ while exercising expertise power and information power as important sources of influence. The role of the project leader is to employ effective diplomacy in order to develop mutually beneficial relationships with stakeholders.

Window polishing techniques. As mentioned earlier, after the retrenchment programme in March 1991, the morale of employees was greatly affected and hence management should advance the project with great caution as it may arouse suspicion of further lay-offs. At present, what employees most desire is job security and so top management should

155

If the present situation is left unchanged, there is a high likelihood that an incomplete and sub-standard system will result. It is likely that many aspects of the system will not comply with end-user’s expectations and therefore a great deal of redesign work will be necessary in the future. The following recommendations are therefore made:

e HKComNet should be prepared to change to another developer. Part of the optional requirements may be dropped in order to let the developer concentrate effort on completing the main function modules. A double-tier quality assurance scheme should be set up in order to restore responsibility to end users. Baselines for specification changes should be defined in advance with the agreement of stakeholders. Top management should employ proper tactics of propagation to generate support from company staff. Changes in the organizational culture are also necessary but the specific details of such changes are beyond the scope of this article. HKComNet needs to review its corporate mission, objectives and strategy and devise a plan to accomplish the necessary changes in culture.

0

*

e ‘MINTZRERG, H. (1983). StiWYUrt? itI fiVe,Y:

Designing effective organizations. Engle- e

wood Cliffs, NJ: Prentice-Hall. 7~~~~~~~~~~, C.E. (19%). New conceptions of coordination (unpublished paper). Chinese University of Hong Kong, September.

promote the CHART system as one of the company’s core operations that offers stable employment opportunities well into the future. This approach at least restores some incentive to employees and may reduce their resistance; however, there is a possible side effect of further demotivating staff who cannot participate in the project, which high- lights the need for the project to be managed carefully and tactfully.

Reveal the training plan. As the system is still under development, many aspects are unknown or subject to change and therefore it is difficult for the project team to provide training to end users at the present stage although this does not mean nothing can be done. One positive and proactive step the project team can take is to reveal its training plan so that end users can be sure of what kinds of training they will receive, as this will assist in reducing their fear and anxiety in relation to proposed changes resulting from the implementation of CHART(I1).

Work closely with end users and developer. Mintzber$ and Lindblom’ have identified different kinds of coordination mechanisms. Direct mutual adjustment is the most effective communication method in handling the most simple or most complex tasks. In this respect and to improve communication, the project leader should consider setting up two offices which are physically close to the developer and end users, respectively, as this will encourage frequent face to face encounters and help to overcome the difficulties experienced during the initial implementation exercise. In addition, representatives from end users should also be invited to attend the working meetings with the developer so that they are able to obtain first-hand information on plans and progress in relation to the project.

156


Conclusions

The Project Implementation Profile model provides a systematic framework for designing research instruments, such as questionnaires, to evaluate project status in terms of critical success factors. Potential problem areas are predicted by low scored factors so that in performing periodic projects, a project manager is able to correct ‘exceptional’ issues as soon as they emerge.

The fact that the PIP model failed to provide a strong indication of the troublesome contractual relationship existing during the initial implementation phase of CHART(I1) reveals that there is a need to include an additional significant factor, ‘Client and developer relationship’, in contract-based projects. Finally, in applying the model used in this article, readers should, if necessary, make appropriate modifications to the basic model in order for it to suit the characteristics of their particular projects.

357

managing information technology projects: chart(ii) development in a large hong kong company

Documents