Aligning Strategies: Organizational, Project, Individual Rick Hefner, Ph. D. TRW
[email protected] Abstract Current IT literature emphasizes the importance of adopting a governance strategy based on an organization’s customer market, and inherent technology and personnel capabilities. However, practical experience has shown that many organizations with sound strategies fail, often because the strategies are not aligned with IT project tactics or individual priorities. This paper explores the idea of aligning organizational, project, and individual strategies, using the Capability Maturity Model, an industry best-practices model, as a reference. Key points are illustrated with an industrial example.
1. Introduction Every organization, through it's philosophies, norms, shared values, and rituals establishes a culture that governs and dictates its business practices. The importance of organizational culture in meeting business goals has been stressed by many authors [1]-[11]. The culture of an organization derives from the basic principles by which that organization does business. Schein [10] suggests that influences on staff behavior can be broken down into four categories: organizational factors, supervisory style, reward systems, and job design. Scholz [6] identifies three dimensions: how cultures change over time; how the internal circumstances of an organization affect its culture; and how an organization’s environment affects its culture. Harrison [1] and Handy [5] suggest that four possible organizational cultures exist: power, role, task, and person. Authors such as Henderson and [12] have discussed the dynamic, twoway relationships of an organization's four “domains of strategic choice” when business and IT are in alignment: business strategy, information technology strategy, organizational infrastructure, and information technology infrastructure. Business success also requires success in project management. Today’s projects are larger and more complex, and must respond to shifting requirements, resources, and corporate priorities. Numerous texts and papers (e.g., [13]-[21]) have been written discussing the principles of project management, and the need for
insight into progress, product quality, and process characteristics. Senior managers must allocate corporate resources, anticipate project risks, and maintain customer satisfaction. The corporation must pursue long-term goals for process quality, maturity, and efficiency, which are based on project results. Additionally, the perspective of the individual must be considered. Individuals are interested not just in the success of the organization, or the project, but also in their own success. How they measure success depends on the characteristics of the job that are important to them increased pay, enjoyment of the work itself, group acceptance, recognition, empowerment, etc. This paper examines the interaction of these factors within the context of a commonly accepted industry standard, the Capability Maturity Model, and current industrial implementations of the model.
2. Capability Maturity Model Capability Maturity Models [22], [23] (CMMs) identify key best-practices used by industry for effective engineering and management processes. A CMM describes the principles and practices underlying process maturity and is intended to help organizations improve the maturity of their software processes, at both project and organizational levels. CMMs serve as the defacto standards for source selection and process improvement in the defense and commercial engineering community.
2.1 CMM Structure As commonly used in the software community, the CMM for Software is organized into five maturity levels: 1.
Initial. The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.
2.
Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
3.
Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.
4.
Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
5.
Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
To master a level, an organization and its projects must satisfy the key process areas associated with the level (Table 1). Key process areas are composed of commonly accepted industry best practices in that process. For example, the practices in Software Project Planning would reflect such practices as generating cost and schedule estimates based on historical data. Satisfying the key process area means the key practices are performed consistently throughout the organization. Level
Key Process Areas
Level 1
None
Level 2
Requirements Management Software Project Planning Software Project Tracking and Oversight Software Subcontract Management Software Quality Assurance Software Configuration Management
Level 3
Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews
Level 4
Quantitative Process Management Software Quality Management
Level 5
Defect Prevention Technology Change Management Process Change Management Table 1. Capability Maturity Model
Many companies use the model as a benchmark of
their practices, and a measure of the maturity of their processes. By complying with the model, they seek to implement strong software engineering and management practices, which lead to predictable project performance. Although the majority of software organizations are characterized as Level 1, savvy customers generally seek business with Level 3 or higher organizations, and leading-edge companies have achieved Levels 4 and 5.
2.2 Institutionalization The CMM addresses the alignment of corporate strategy with project tactics and individual priorities through the concept of “institutionalization”. Institutionalization refers to the building of an IT governance infrastructure and corporate culture, by establishing mechanisms for ensuring that proper practices will endure over time. For each key process area in the CMM, institutionalization is measured by four components, termed common features: • Commitment to Perform – actions the organization must take to ensure the process is established and will endure (e.g., policies, leadership); • Ability to Perform – preconditions that must exist in the project or organization to implement the software process competently (e.g., resources, organizational structures, training); • Measurement and Analysis – practices necessary to determine status related to the process, used to control and improve it (e.g., measurements and analysis); • Verifying Implementation – steps taken to ensure that the activities are performed in compliance with the established process (e.g., management reviews, audits). Satisfying each key process area in the CMM requires that these four common features be in place. For example, to institutionalize Software Project Planning, an organization would want to have documented policies, ensure adequate resources and training, provide organization support such as a Project Management Office, etc. Institutionalization is often the hardest part of complying with the CMM – any good project management text identifies the key planning activities, but ensure alignment throughout the organization and its projects is more difficult.
3. Governance Strategies Strategizing an effective IT governance program involves determining the right balance between
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
capitalizing on an organization's strengths and compensating for it's weaknesses [24]-[29]. Strengths can be used to more rapidly introduce new practices into a functioning project or organization. Weaknesses provide opportunities for more gradual changes, caused by a progressive shift in an organization’s values. By recognizing the relationship between culture and the CMM common features, an organization can properly address organization, project, and individual priorities.
Feature
Governance Strategies
Training
Provide training to all effected personnel in how to perform the new practices; publicize why these changes are needed.
Measurements
Publicize organizational expectations about the impact of individual and project practices on organizational goals. Revise organizational goals and standards as needed to reflect the likely performance of the process.
Management Reviews
Ensure management understands the goals, and is enforcing the needed practices on the projects.
Audits
Train auditors on the process and product standards appropriate for the practices.
3.1 Capitalizing on Cultural Strengths The proper IT governance strategy makes use of an organization's cultural strengths to support the strategic directions. For example, if an organization is strongly influenced by leadership, sponsorship will be a key factor in whether employees follow the proper IT practices. The employees will expect the leaders to endorse the practices through public and private statements of support. If the leaders do not communicate the IT strategy, or underline the value of these practices in implementing that strategy, the employees will sense that compliance is not critical and will abandon the needed practices. When organizational priorities are not clear, individuals are left to their own sense of priority. When implementing IT practices which support a organizational goal, specific governance strategies can be adopted based on those elements that are strongest in the culture. These are illustrated in terms of the CMM features as shown in Table 2. Feature
Governance Strategies
Policies
Change the policies to incorporate the needed practices; communicate the new policies to those effected.
Leadership
Assign specific software practices to responsible individuals or groups; identify responsible parties in plans and reviews.
Resources
Ensure resources are provided to perform the practices, possibly through corporate overhead. On newly beginning projects, ensure sufficient resources are allocated to cover the new practices.
Organizational Structures
Establish staff groups to assist projects in implementing the needed practices. Publicize the availability of these resources.
Table 2. Governance Strategies when Cultural Elements are Strong In general, relying on cultural strengths to facilitate compliance is more crucial when the need for the compliance is immediate, and the need for advance preparation and training is less critical. When more time is available, weaknesses should also be addressed – this will be discussed in the next section. Cultural strengths can be identified by examining those behaviors that are currently prevalent in the organization, e.g., use of power, speed with which things are done, leadership style, norms regarding involvement in decisions, etc. They govern which behaviors are rewarded and which are punished.
3.2 Compensating for Cultural Weaknesses Cultural weaknesses indicate a potential need for change, or paradigm shift. If an organization's culture is solely driven by one common feature or element, to the exclusion of all others, it may become overly dependent on that element. For example, if leadership is the sole important factor in an organization, institutionalization will be overly-dependent upon the leaders' understanding of the new improvements. Conflicts between leaders will lead to confusion. Leaders may undermine improvement by emphasizing conflicting priorities, such as budget and schedule. When key leaders are promoted or transferred, improvement efforts will falter, and activities will revert to business as usual. Organizations with unbalanced cultures must seek to
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
change the governance mechanisms by which mature practices are supported, by developing and building new common features into the culture. It is reasonable to attempt to counter cultural weaknesses when the need for compliance is less acute, or when there is a need to maximize preparation for new practices. In our experiences working with organizations implementing governance systems, strategic planning often neglects this effect. Organization leaders have set unrealistic timeline goals for achieving specific goals, ignoring the time needed for cultural change. Corporate staff may focus solely on implementation (e.g., developing huge guidebooks and complicated process models), but spend no energy on providing cultural support. These organizations have implemented new practices, only to watch them deteriorate when management attention is shifted to another crisis. The new practices can not be sustained because there is no cultural support – "that's not the way we do things around here." If long-lasting change is desired, the governance strategy must emphasizing short-term support for new practices using the existing cultural strengths, and long-term cultural change to achieve a more balanced set of common features. Specific governance strategies can be adopted to strengthen weaker elements (Table 3). Feature
Governance Strategies
Policies
Policies is perhaps the single most effective element in many cultures. An organization must adopt clear policies that apply to all projects equally, and must set up a visible and active review and enforcement mechanism.
Leadership
Senior management must stress accountability for actions, and reward and punish accordingly. The reward system must be visible to those effected
Resources
Without adequate resources, many organization will fall short when competing priorities arise. An organization must realistically estimate the cost of achieving the goals, and determine if they can afford it.
Organizational Structures
The organization may try to achieve goals solely by “grass-roots” actions. Experience has shown this is not effective; many IT initiatives call for new skills and knowledge. Plan and
Feature
budget for the needed support. Training
Implementing new practices effectively will almost surely require training. Budget for the cost of maintaining a permanent training office.
Measurements
Use measurements appropriately can be difficult; most organizations start too big and too detailed. Start instead with simple measures, and expand as the need arises. Ensure that measurements are being used in decision-making. If not, revise the measurements to make them useful.
Management Reviews
Management should implement periodic reviews to ensure the required practices are being performed. Start simple; weekly reviews with the software project manager, and quarterly review with senior management are useful for most organizations.
Audits
Management should implement independent audits of the software process and products at major project milestones, and incorporate these results into the management review process. Rewards and penalties for non-compliance must be visible.
Table 3. Governance Strategies when Cultural Elements are Weak
3.3 Project Goals Organizational goals and project goals are frequently in conflict with one another. Most project managers see corporate governance programs as counter-productive to project goals. Project objectives are short-term ("Get the product delivered by the end of the week."); organizational goals are long-term ("Achieve a broader market share within two years"). These timeframes often conflict in competing for an individual's day-to-day time, even though, in the long run, meeting organizational goals typically lead to higher productivity and shorter delivery schedules. In a worst case scenario, a project may drive its people long hours to meet a short term project goal, causing loss of employee morale and high turnover. One of the key difficulties arises from the adage "The
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Governance Strategies
customer is always right." In it's original context, it was meant to imply that the wishes of the customer must be understood and addressed. In practice, it is often used as a license to violate organizational dictums the customer does not agree with. A frequently cited example is the customer who refuses to pay for quality assurance activities on a costreimbursable contract. For an organization is implementing CMM-based improvements, quality assurance is essential, which creates a conflict. The root cause is the customer's lack of understanding on the value of QA. The customer may have worked with organizations that improperly implemented QA, hindering project progress rather than ensuring quality at the fastest possible speed. The customer may never have seen QA implemented at all, and may be wary of adding tasks and costs without demonstrated benefit. In some cases, the project or organizational may be able to change the customer's perception by presenting successful case studies or citing industry standards like the CMM, which reinforce the value of QA. In severe cases, the customer may refuse to change their mind regardless of the data presented. Projects must recognize that sometimes what a customer wants is not in the best interest of the organization or the project. It is up to the organization to decide whether they wish to work with such customers. Often, those customers who refuse to let the supplier implement industry best-practices are the first to complain when something goes wrong. The organization must decide if the risk to their reputation is worth the inherent advantages of the contract.
Feature
Governance Strategies
Leadership
The authority of project management should be preserved, but must be balanced against the authority of the organization. It is inappropriate for a project to make short-term choices that have long-term detrimental impacts to the organization's goals, culture or reputation.
Resources
The organization must establish clear guidelines regarding the availability of resources for specific project activities. In some cases, the organization may need to provide funds to assist the project in aligning it's goals with that of the organization, such as performing activities for which the project derives little short-term value. Projects must communicate to customers that essential activities are required by the organization, and must be considered a "cost of doing business", even if the customer does not see the value.
Organizational Structures
Organizational structures may help in providing resources, and balancing short-term and long-term goals.
Training
The organization is responsible for ensuring a skilled and knowledgeable work staff. The organization should establish minimum standards for each job function, and training to provide these skills to those who do not posses them. Projects must compensate for this training in their schedules, and should focus on project-specific training (e.g., domain, customer, user, product).
Measurements
The organization should establish common measures to be used on all projects; projects should add to these as needed. Common metrics should be kept historically from past projects to aid in project planning and resources estimation.
Management Reviews
Management reviews must emphasize the balance of authority between organizations and projects. The organization should periodically review project processes and progress to ensure that organizational goals are
Project goals can be aligned with the CMMrecommended organizational culture in several ways (Table 4). Feature
Governance Strategies
Policies
When policies are being developed, project manager feedback must be sought. Good policies are a compromise between consistency for the sake of organizational efficiency, and flexibility for the adaptability to different project environments and constraints. A waiver system must be in place to recognize when a policy is not appropriate to a specific project situation. Waivers should be used sparingly and require rigorous justification.
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Feature
Governance Strategies being met.
Audits
Audits are an effective way to ensure project compliance with organizational policies and goals. Care should be taken to establish strong organizational oversight of the projects' audit programs, to ensure the program is adequate.
Feature Policies Leadership
Resources
Table 4. Alignment of Project Goals
3.4 Individual Goals An individual's goals may not align with either the organization's or project's. Hackman and Oldham [29] cite five dimensions of individual motivation: • Skill Variety – The degree to which the work requires you to exercise a variety of skills; • Task Identity – The degree to which the work requires you to complete a whole, identifiable piece of work; • Task Significance – The degree to which the work affects others and contributes to social welfare; • Autonomy – The degree to which you have control over the means and methods you use to perform the work; • Job Feedback – The degree to which carrying out the work itself provides you with direct and clear information about how effective you are. Most individuals are motivated by a combination of these factors. The extent to which an individual aligns with a organizational or project goal depends on how much interaction the goal has with the motivational factor. For example, reviewing and auditing an individual's work would frustrate those motivated by Autonomy, but would be welcomed by those individuals motivated by Job Feedback. Not all individuals are motivated, positively or negatively, by the CMM features of culture. In Table 5, we summarize the major impacts by dimension. Note that for most employee motivational categories, there is little impact of the features. When an organization is establishing governance mechanisms, some will view them positively, some negatively. The organization must base their systems on the reactions of either the majority of the employees or on key employees. Similarly, when an employee seeks to join an organization, they would be wise to understand the corporate culture, and how it may impact their individual motivation preferences.
Organizational Structures
Training
Measurements
Management Reviews Audits
Same as above.
Table 5. Alignment of Individual Goals There is little in the CMM or current literature to suggest how to resolve the conflict between individual priorities and project or organizational objectives. The current philosophy is that an IT governance system must contain a broad set of mechanisms, so those not sensitive to one mechanism will be driven by other mechanisms. In practice, it is the alignment that is most difficult. When done properly, all governance features support the overall organizational goals. Often, this is not the case: leaders fail to communicate, conflicting priorities lead to inadequate resources, and the feedback system fail to identify the problems. Individuals are left with mixed messages and conflicting priorities and seek the path of least resistance or lowest pain. There is no easy way to achieve alignment. The most effective strategies involve constant assessment and realignment, seeking an appropriate balance between effectiveness, efficiency and control.
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Governance Strategies For those motivated by Autonomy, policies will be viewed as constricting. Those motivated by Task Identity tend to identify with their leaders, and will view their perception of change as important. Those motivated by Task Significance may view resources as one measure of significance ("If this was really important, they'd give us time and budget to work on it.") Those motivated by Task Identity tend to identify with their organization, and will want to know how their individual activities fit into the organization's charter and mission. Skill Variety-motivated people often view training as a perk. Task Identity and Autonomy individuals typically feel training takes them from current tasks. For those motivated by Autonomy, measurements are viewed as invasive. Job Feedback employees typically view measurements positively. Same as above.
4. Case Study
Feature
Governance Strategies
These concepts can be examined in the context of an organization in which the author has worked for 12 years. TRW Systems is a 10,000 person global technology, manufacturing, and service company, strategically focused on supplying advanced technology products and services to the automotive, space, and information systems markets. The organizations' core work is organized around 1-400 person project teams that develop software and software-intensive systems. Approximately 50 of these project have over 20 people.
Resources
Significant resources are provided to assist projects in implementation. Projects are expected to plan their work to comply with organizational goals.
Organizational Structures
The continued success of TRW Systems is dependent upon successful projects and successful project managers. Success is generally seen as meeting the cost and schedule estimates provided to the customer. There is considerable argument within the staff over what makes a good project manager.
Organizational groups coordinate improvements, conduct training, collect and analyze measurement data, and assist projects in planning and execution. Such groups exist at all levels of the organization and reflect higher-level goals in addition to those at their level.
Training
The staff is primarily engineers, most with 20+ years of experience and significant domain knowledge. Turnover is extremely low by industry standards, and it is common to find retirees that have spent their entire 40+ year career at TRW. Primary motivators among this staff are Task identity and Autonomy.
An organizational-level group establishes the required skills and knowledge for each job function, and provides classes for awareness, skills building, and refresher. Little projectspecific training is needed, and focuses around tools.
Measurements
A organization-wide metrics repository is maintained, and all projects contribute to it. A continuing challenge is the day-to-day use of measures at all levels of management. Project and organizational managers still perceive that good managers mange by intuition, not measurement.
Management Reviews
Projects conduct monthly reviews of schedule, budget and risk, supplemented by weekly reviews at the task level. A designated senior manager reviews each project quarterly to ensure consistency with organizational goals. Issues tend to be resolved quickly once they are identified.
Audits
Project-level audits of both processes and products happen frequently. Effectiveness could be improved by more consistent training of the auditors and by stressing the importance of their work to the staff.
TRW Systems has implemented the CMM for ten years in older parts of the organization, and two years in departments more recently acquired. The entire company is at Level 3 on the CMM maturity scale and has a strong set of CMM-driven cultural features (Table 6). Feature
Governance Strategies
Policies
Strong set of required practices driven by the CMM requirements. Few waivers, mostly for service oriented contracts, where ultimate authority rests with the customer. Policies are rigorously audited and enforced at both the project-level and through periodic organizational audits. Failing to meet policy is not punished, but viewed as an educational opportunity.
Leadership
Strong leadership is the organization's hallmark. Organizational goals are defined, communicated and passed down through executive bonuses and profit-sharing to all employees.
Table 6. TRW Governance Features Measurement continues to be a challenge for this organization. Recently, a Six Sigma program was launched by top management in order to encourage a more data-driven culture. The organization has also
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
implemented a balanced scorecard for measuring organizational progress against their goals.
5. Summary An IT governance strategy should be based on an organization’s customer market and inherent technology and personnel capabilities. The CMM provides guidance on the requisite features of a governance system. However, organizational strategies often conflict with IT project tactics and individual priorities and alignment is needed. Industry examples show such alignment is possible, but significant challenges remain.
Alignment: Leveraging Information Technology for Transforming Organizations,” IBM Systems Journal, Vol. 32, No. 1, 1993. [13] Tom DeMarco, Controlling Software Projects, Yourdon Press, New York, NY, 1982. [14] Henderson, J. C., and Venkatramon, N., “Strategic Alignment: Leveraging Information Technology for Transforming Organizations,” IBM Systems Journal, Vol. 32, No. 1, 1993.
6. References
[15] R. H. Thayer, "Software Engineering Project Management: A Top-Down View," Tutorial: Software Engineering Project Management, R. H. Thayer (ed.), IEEE Computer Society Press, IEEE Catalog No. EH0263-4, 1988, pp. 15-54.
[1] R. Harrison, “Understanding Your Organization's Character,” Harvard Business Review, 1972 pp. 119-128.
[16] George M. Doss, IS Project Management Handbook, Prentise Hall, 2000.
[2] Hersey and Blanchard, Management of Organizational Behaviour: Utilizing Human Resources, 3rd edition, Englewood Cliffs, N.J.: Prentice-Hall, Inc., 1977.
[17] Watts Humphrey, Managing the Software Process, Addison Wesley, 1989.
[3] T. E. Deal and A. A. Kennedy, Corporate Cultures: the Rites and Rituals of Corporate Life. Reading, Mass.: AddisonWesley, 1982. [4] R. E. Quinn and M. R. McGrath, “The Transformation of Organizational Cultures: A Competing Values Perspective,” Organizational Culture, P. J. Frost, L. F. Moore, M. R. Louis, C. C. Lundberg, and J. Martin, Eds. Newbury Park, Calif.: Sage, 1985, pp. 315-334. [5] C. Handy, Gods of Management, London: Souvenir Press, 1986. [6] C. Scholz, “Corporate Culture and Strategy - the Problem of Strategic Fit,” Long Range Planning, vol. 20, pp. 78-87, 1987. [7] M. Elmes and D. Wilemon, “Organizational Culture and Project Leadership Effectiveness,” Project Management Journal, vol. XIX, pp. 54-63, 1988. [8] D. I. Cleland, “The Cultural Ambience of Project Management - Another Look,” Project Management Journal, Vol. XIX, pp. 49-56, 1988. [9] G. Firth and R. Krut, “Introducing a Project Management Culture,” European Management Journal, vol. 9, pp. 437-443, 1991. [10] E. Schein, Organizational Culture and Leadership, San Francisco: Jossey-Bass, 1992. [11] A. Brown, Organizational Culture. London: Pitman Publishing, 1995. [12] Henderson, J. C., and Venkatramon, N., “Strategic
[18] Richard Bechtold, Essential of Software Management, Management Concepts, Inc., 1999.
[19] A Guide to the Project Management Body of Knowledge, Project Management Institute, 200. [20] Kathy Schwalbe, Information Technology Management, Thompson Learning, 2000.
Project
[21] Steve McConnell, Rapid Development, Microsoft Press, 1996. [22] Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles V. Weber, “Capability Maturity Model for Software, Version 1.1”, Software Engineering Institute, CMU/SEI-93-TR24, DTIC Number ADA263403, February 1993. [23] Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis, and Marilyn W. Bush, “Key Practices of the Capability Maturity Model, Version 1.1”, Software Engineering Institute, CMU/SEI-93-TR-25, DTIC Number ADA263432, February 1993. [24] C. Myers and J. Gremba, "Planning the Cultural Dimensions of Software Process Improvement", Tutorial, Software Engineering Process Group Conference, 1995.Controlling the Future: Managing Technology-Driven Change, S. Stokes, Jr., QED Information Sciences, Inc., Wellesley, Massachusetts, 1991. [25] J. Bayer and N. Melone, “Adoption of Software Engineering Innovations in Organizations,” Software Engineering Institute, CMU/SEI-89-TR-17, DTIC Number ADA211573, 1989. [26] M. Beer, R. A. Eisenstat, and B. Spector, “Why Change
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
Project
Programs Don't Produce Change,” Harvard Business Review, November/December 1990, pp. 158-166. [27] John P. Kotter, “Leading Change: Why Transformation Efforts Fail,” Harvard Business Review, March-April 1995, pp. 59-67. [28] R. H. Schaffer and H. A. Thomson, “Successful Change Programs Begin with Results,” Harvard Business Review, January/February 1992, pp. 80-89. [29] Richard Hackman and Greg Oldham, Work Redesign, Addison-Wesley, 1980
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
