Communications of the ACM
Home/Magazine Archive/August 2007 (Vol. 50, No. 8)/Involving Top Management in IT Projects/Full Text
Communications of the ACM
Involving Top Management in IT Projects
Involving top management in IT projects requires a vendor to be able to convince management that a proposed IT solution meets an organization's particular needs. Vendors must convince management they understand the customer's business and their solution fits management's overall requirements. A simple technique known as problem mapping has proved efficient in aligning vendors' and customers' interpretations of business needs and potential IT solutions. System consultants from a large international vendor learned to apply this technique of involving managers in the definition of their problems and in the causal relations between business needs and prospective IT solutions.
Top management involvement and the development of strong relationships with top management are consistently reported as the most important challenge within IT projects. In a May 2004 Communications article based on a survey of 541 IT projects, it was stated that when it comes to the complexity of IT projects, the technology aspects are more apparent but the organizational aspects have more significant effects on IT project performance and outcomes: to improve project performance, project managers must develop strong relationships with top management [8]. A similar conclusion was reached in a comprehensive and recent study resulting in an authoritative ranked list of IT projects' risk factors [5]. The list was based on a Delphi study, in which the participants were 45 experienced project managers from the U.S., Europe, and Asia, who have managed a total of more than 1,000 IT projects. They identified, analyzed, and ranked experienced project risks. This study confirmed that the lack of top management involvement is the primary challenge project managers felt was most deserving of their attention.
Top management involvement requires that management undertake sponsorship and ownership throughout the IT project, starting with the initial definition of the project's purpose and goal. It requires that management sincerely believes the IT project is business-relevant: management representatives must be convinced the proposed IT solution solves a relevant problem or supports a true business need.
This article describes how to establish initial top management involvement by using the problem-mapping technique, in which management and system consultants openly communicate their understanding of problems, needs, and IT solutions. We outline the participatory design approach, through which the problem-mapping technique is based, and demonstrate how professional system consultants experienced a problem-mapping session, which was used to obtain top management involvement in their suggested IT project.
Participatory Design
Recent research in participatory design has developed new ways to evaluate the fit between a vendor's proposals and the customer's requirements [2]. Participatory design approaches emphasize establishing mutual learning situations where system consultants and "users" share their views on the current situation and the need for IT, along with ideas and designs for future IT solutions [3]. This requires the system consultants to develop a thorough insight of the organization and the business they are to support with IT [7]. Management involvement is established through a process encompassing informing about and promoting understanding and backing for the relevance of the IT project and its goals and visions. The point is that top management and system consultants together develop the argument for how a specific IT-based proposal solves an experienced problem or supports an important business need [6].
The problem-mapping technique supports such an evaluation of the argument for an IT solution. This technique (originally developed by [4]) can help in visualizing and structuring the argument chain by relating identified problems or needs with proposed IT solutions. For example, this can take place during a meeting with the vendor's system consultants and the customer's management. The map is typically drawn on a flip chart or white- board and outlines the structure of arguments in four columns: specifying a problem or need, identifying its causes, the (undesirable) consequences it leads to, and the ideas for its solution.
Problem mapping is a simple yet very effective technique. The reason is it forces the vendor's system consultants to explicate and openly communicate their apprehension about the existing situation in the customer organization. By presenting problem maps, interpretations of what is needed are made apparent. This invites the customer's top management to review, challenge, and reformulate the system consultants' central suppositions, assumptions, and hypotheses concerning the causal relation between identified problems and suggested solutions.
When preparing for an effective problem-mapping session, system consultants must systematically discern among the information they have gathered and the assumptions and hypotheses they have made. Their view of the customer's existing situation builds on the gathered information, for example information registered in documents, observed events, quotes and statements from interviews, and other resources. Such information is indisputable in the sense that it "exists," for instance, in the form of quotes from past reports on business strategy, from statistics on the frequency of errors in a business procedure, from interview statements, and so forth. Using the collected information, the system consultants assemble a general image of the existing situation. This may give the impression an overview of the situation has been obtained, and the majority of relevant needs and problems have been revealed. System consultants having a great deal of experience within the work domain of the customer need only very little information (for instance, from a short series of interviews) in order to develop a convincing generalization of the situation, which identifies and characterizes relevant problem domains. Their image of the situation is tied together by a string of assumptions and hypotheses generalizing the information in a manner that covers the situation as a whole. Such assumptions and hypotheses are often implicit and typically take the shape of patterns of explanation and interpretations of the gathered information.
Problem mapping supports getting feedback from and comments on the information gathered by the system consultants as well as on their assumptions. Accordingly, this also means confirming or rejecting the assumptions and hypotheses on which the system consultants have built their representations of the existing or future situation.
Problem mapping supports getting feedback from and comments on the information gathered by the system consultants as well as on their assumptions.
Participatory design research suggests the system consultants must observe two basic rules in these situations [2]:
- Separate suppositions from the information gathered. Continually be aware of what can be traced back to various documents, audio or video recordings, notes from interviews and observations, and what the system consultant's suppositions (assumptions and hypotheses) are.
- Test considerations, assumptions, and hypotheses, not just conclusions. Be open to all such suppositions, while bearing in mind the importance of challenging and testing them. Visualize the considerations by forming a coherent argument from the identification of the problem to the solution proposals by using the problem-mapping technique.
A Detailed Example
The following example is based on a project in which system consultants from a large international vendor of a system supporting the compliance domain (tax assessment and auditing) were introduced to a participatory design method (described in [2]) as part of a method dissemination initiative [1]. Over the last decade the vendor had developed and offered a comprehensive and sophisticated system supporting all major processes within the work domain of compliance, such as tax assessment and auditing, including private assessable income (payee tax), company revenues, VAT, and so forth. The system is used by governmental tax audit authorities worldwide, where their customers are the tax authorities of an entire state or nation. The system may be compared to large enterprise resource planning systems, since it is comprehensive, expensive, and potentially entails large organizational restructuring and changes in work practices within the user organization. The system has proven to provide a sufficiently higher level of effective administration, and has given tax authorities substantially higher revenues.
When the vendor interfaces with a new potential customer, it is seldom initially obvious to the vendor or the customer how the customer's requirements relate to the functionality and the possibilities offered by the system. It must be clarified if the customer is in a situation in which he or she could benefit from implementing (major parts of) the system, that is, whether there is sufficient overlap between the customer's needs and the system's present as well as projected functionality. The vendor offers, as a free service, such an additional clarification in the form of an analysis project.
The analysis project lasted three months and involved three visits to the customer site. The vendor invested two man-months of resources plus travel expenses. The vendor's project team included three senior system consultants, all of whom had more than 10 years of experience with conducting numerous similar initial analysis projects within the compliance area. The focus of the analysis was on the customer's overall requirements and strategic needs, including clarifying business and IT strategies, identifying which parts of the compliance cycle and processes needed IT support, and the existing and projected IT architecture and their potential relationship to the vendor's system.
When the vendor interfaces with a new potential customer, it is seldom initially obvious to the vendor or the customer how the customer's requirements relate to the functionality and the possibilities offered by the system.
During the visits, the vendor's system consultants interviewed 13 selected employees representing different areas of the customer's organization and compliance processes. At each visit, they also had meetings with eight top management representatives, including the CEO, CFO, CIO, and five vice presidents representing the different tax regions. This management group had to decide if and how it would sign a contract with the vendor. Thus, strategic and economic aspects were a main consideration. Although the management group might have only a limited understanding of relevant work practices (such as performing a company audit), this was not considered problem. The initial decisions were focused on if and where to invest in IT (for example, based on political considerations, business strategies, overall organization of work, statistics of revenues, and so forth); more detailed considerations on how to support specific work practices with IT were postponed.
The outcome of the project was a report comprising the analysis of the customer's overall requirements as well as the recommendations for a subsequent implementation project. A strategy for a subsequent development and implementation project was described, where other managers and employees representing specific work practices in the chosen areas of compliance were to participate. The customer later signed a contract with the vendor for an IT project with a budget exceeding $10 million.
Problem Mapping
All interviews made at the customer site were recorded. After the first visit, the system consultants listened to all the recorded interviews and scrutinized the documents they had received (brochures, strategy plans, systems documentation, descriptions of production processes, and other documents). In the process, they made notes of their observations using keywords. All the keywords from the interviews and the document studies were reviewed, discussed, and written on color-coded Post-It notes. These were organized on problem maps with the headings: "problems" or "needs," "causes," "consequences," and "ideas for solutions."
The system consultants learned three lessons in the process of organizing their interview notes by using problem mapping.
- Their focus moved from reflecting on solutions to diagnosing the problems and needs the solutions should solve and fulfill. Typically their reflections on the interview data focused on how to solve observed needs by means of their system. Organizing their notes on the problem map led to a reflection on the problems and their causes and consequences that were to be solved.
- Suppositions related to interview observations were made explicit. Their interview notes only partially formed the arguments on the maps and they where thus supplemented with new notes. Most of the notes made for the maps did not originate from direct observations noted from the recorded interviews. When making a note as part of the map, the question "did you get that from your interview notes?" was often asked; usually the answer was, "no, not directly, but...". This revealed that a new note was actually a supposition based on impressions from the visit as well as from past experiences. Refining the line of argument on the problem maps made these suppositions explicit.
- A priority could be made with regard to the assumptions that were critical to the overall analyses. The resulting maps gave an overview of each problem/need at stake as well as how grounded a line of argument was in the interview observations. From this overview, the entries on the maps were prioritized, assuring the most critical diagnoses were reviewed and evaluated with the customer.
The system consultants presented the results of their problem mapping at a full-day workshop with the eight management representatives. The workshop acquainted the management group with each of the selected, prioritized problems and needs, as well as with the arguments for the possible IT-supported solutions presented in the diagnostic maps. Every participant at the workshop had a handout representing all the maps the system consultants had prepared. The table here presents one (out of 20) diagnostic map from this handout.
Each problem and need, as well as the argument for the possible IT-supported solution, was then discussed individually. As the managers discussed and commented on an entry on the map, the suggested revising and rephrasing were noted on Post-Its, which were then put on flip charts in the meeting room (see the figure here).
As an example of the results from this workshop, consider the map represented in the table here and then the changes to this map as shown in the figure on the previous page. The following changes can be highlighted:
- The problem "0-yield rate is too high (especially for VAT)" was moved to consequences, and "especially for VAT" was changed to "Payee and employee tax." Problem A was then rephrased to "Selection time-consuming and tedious."
- The cause "Random selection" as well as the consequence "Risk of taxpayer harassment" were rejected (crossed out on the chart shown in the figure). These assumptions were false according to the managers.
- Two causes were added ("Difficulties in identifying case-base" and "Inadequacy in expertise in making selection"), one consequence was added ("Reduced deterrent effect"), and two suggestions for solutions were added ("Resolve trade description problem" and "Establishing a structure for knowledge transfer").
The example demonstrates how management became acquainted with the system consultants' diagnosis of the current state of affairs and shows how management participated in a structured discussion of each line of argument related to an identified problem or need. In addition, the example demonstrates how the system consultants involved management in challenging central suppositions, assumptions, and hypotheses related to the causal relation between problem and solution.
Conclusion
The example demonstrates how a customer and a vendor collaborate in a mutual learning process, where the vendor openly disclosed his understanding of the customer's situation in order to align different interpretations of business needs and potential IT solutions. Usage of the problem-mapping technique led to:
- A focus on diagnosing the customer's problems and needs.
- Suppositions and assumptions being made explicit, especially with regard to the causal relation between a solution and the problem/needs it addresses.
- An assessment by top management of the system consultants' critical assumptions.
- The participation of top management in reviewing, commenting, and reformulating key arguments for needed IT solutions.
- Obtaining a shared overview of identified problems and business needs as a basis for prioritizing.
The technique clearly demonstrated why the customer might benefit from a specific solution offered by the vendor. It disclosed the system consultants' experience and knowledge within the compliance domain as well as the customer's specific context and situation. In this way, problem mapping gave top management confidence in the vendor's competence and in the relevance of the proposed IT solutions, and consequently established and solidified their involvement in the IT project.
References
1. Bodker, K., Kensing, F., and Simonsen, J. Changing work practices in design. In Y. Dittrich, C. Floyd, and R. Klischewski, Eds. Social ThinkingSoftware Practice. MIT Press, Cambridge, MA, 2002, 267285.
2. Bodker, K., Kensing, F. and Simonsen, J. Participatory IT Design. Designing for Business and Workplace Realities. MIT Press, Cambridge, MA, 2004.
3. Kensing, F. and MunkMadsen, A. Participatory design: Structure in the toolbox. Commun. ACM 36, 4 (Apr. 1993), 7885.
4. Lanzara, G.F. and Mathiassen, L. Mapping situations within a system development project. Information and Management 8, 1 (1985), 320.
5. Schmidt, R., Lyytinen, K., Keil, M. and Cule, P. Identifying software project risks: An international Delphi study. Journal of Management Information Systems 17, 4 (2001), 536.
6. Simonsen, J. Participative design with top management: Anchoring visions by the problem mapping technique. In Proceedings of the Eighth Participatory Design Conference 2004 (PDC 2004), (July 2004 Toronto, Canada, 2004), CPSR, Palo Alto, 2004, 109113.
7. Simonsen, J. and Kensing, F. Using ethnography in contextual design. Commun. ACM 40, 7 (July 1997), 8288.
8. Xia, W. and Lee, G. Grasping the complexity of IS development projects. Commun. ACM 47, 5 (May 2004), 6974.
Figures
Figure. The flip chart from the workshop representing the changes made to the map shown in the table.
©2007 ACM 0001-0782/07/0800 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.
No entries found