A Comparison of Industrial Process Descriptions for Global Custom Software Development Werner Heijstek
[email protected]
Michel R.V. Chaudron
[email protected] 1
1
1
Libing Qiu
[email protected]
1
Christian C. Schouten
[email protected] 1,2
Leiden Institute of Advanced Computer Science, Leiden University Niels Bohrweg 1, 2333 CA, Leiden, the Netherlands 2
Duthler Associates Frankenslag 137, 2582 HH, The Hague, the Netherlands
Abstract—Global Software Development (GSD) is associated with many potential pitfalls. Some of these pitfalls, such as the lack of a structured and agreed upon process and unclear tasks, roles and responsibilities can be alleviated by using a process description. While GSD takes up a large percentage of industrial software development, it remains unclear whether organizations tailor their process descriptions for GSD-specific issues. This paper reports results of a comparative study of GSD process descriptions used for custom software development of three industrial organizations. The two methods applied in this research are in-depth analysis of process descriptions and interviews with process designers. We conclude that the level of detail of the process descriptions varies strongly and that the intended use of the prescribed process does not necessarily correspond with the provided level of detail. Also, the design of the process descriptions seems to be partly dependent on the expertise and professional background of the process designers. Other important factors in the design and intended use of the process descriptions are the size of an organization and organizational maturity. Keywords-Global Software Development; Process Description; Industrial Case Studies;
I. I NTRODUCTION Global Software Development (GSD) takes up a large percentage of industrial software development and is even referred to as the new standard software engineering mode [1]. GSD is motivated by a variety of reasons. According to Carmel [2], GSD is motivated by reasons such as (1) a limited pool of trained workforce, (2) the necessity to increase customer intimacy [3] and taking advantage of local expertise to localize products, (3) governmental clients demanding suppliers to locate R&D facility in their country as a condition of sale or a favorable tax treatment, (4) differences in development cost and (5) a promise of round-the-clock development that could lead to shorter intervals. Additional reasons are a focus on core organizational competencies, promise of quality improvements or improved development continuity, a better modularization of architecture, gaining access to new markets, strategic positioning for mergers or acquisitions and following the competition. However, the
inherent increase in risk and complexity of GSD projects aggravate the difficulty and failure rate of such development projects [4]. Some of these pitfalls, such as the lack of a structured process, unclear tasks, roles and responsibilities, knowledge sharing concerns and general communication issues can be alleviated by using a process description which explicitly addresses the issues associated with them [5]. It is generally agreed upon that working according to a welldefined development process is key to software engineering in general. Nevertheless, it is unclear whether organizations make use of process descriptions tailored for GSD and of what they are comprised. We report on a comparative study of the GSD process descriptions used for custom software development of three industrial organizations. Section two describes the objectives of the study, section three describes related work and section four outlines the method of the study. Section five reports on results which are then discussed in section six. Finally, sections seven and eight present the conclusions and elaborate on future work. II. O BJECTIVES Little is known about prescribed processes for GSD in industrial practice. What are they comprised of? How are they made? How are they used in practice? Are software process descriptions tailored for GSD-specific issues? What aspects of GSD are focused on? The motivation behind this study is to explore how software development process descriptions are tailored to accommodate GSD. This study signifies a first step by analyzing the content of, motivation for and use of three process descriptions currently used in GSD projects within three different organizations. The contribution to scientific GSD literature of this study is threefold and is divided up into three sub-questions which we will shortly motivate here. The first question deals with the content of the process descriptions. What is described in each of the process
descriptions for GSD? What common and distinct elements can be identified? We summarize these questions as follows. 1) The first sub-question relates to the extent to which process descriptions are tailored for GSD in different organizations: How do different process descriptions for GSD compare? 2) The second sub-question relates to the rationale behind the build-up of the process descriptions, why is a specific GSD process description made and what is the rationale for including or omitting certain elements? The second sub-question is: What is the organizational rationale for the design of a GSD-specific process description? 3) Lastly, we investigate how the prescriptions devised by the organizations are meant to be used in practice: How are these process descriptions meant to be used in actual development projects? III. R ELATED W ORK The lack of process structure is a commonly reported source of GSD process frustration [1]. This includes a lack of the definition of work units, such as design documentation [6], lacking prescriptions on methods of bundling work units [7] and lacking prescriptions on procedures for knowledge management [6]. No previous studies have focused specifically on industrial GSD process descriptions. The role of process descriptions in GSD has been discussed but not empirically validated in industrial practice. In their report on application of GSD in the large, Battin et al. [8] discuss various issues, one of which is ‘differing development process’. This issue poses the challenge of coordinating between various development sites that follow different processes. The authors prescribe three solutions for this problem. First, Battin et al. argue not to impose a common process to let each team produce results immediately. Second, to come up with a set of common work products and vocabulary and to make a mapping between the common work products and the specific deliverables of the individual development center. Third, to split a system up in tested subsystems that can be developed independently by each development center. This division by modularity or chunking of work items is one of the strategies that can be taken to global software development [9]. However, this strategy can only be applied if both the organization and the software system architecture allow modularization. If not, increased process commonality is imperative. Coordination in GSD becomes an issue because of process non-uniformities. An example of process non-uniformities is variation in definitions which may cause mismatched expectations. Also, a mismatch in common milestones at one location may affect other development sites, but is often not communicated early enough. In addition, different time zones may lead to more frequent work handovers [10].
Commonly regarded as the largest sources of risk in GSD are issues related to communication across development sites. The decreased amount of opportunity for informal team communication alleviates the inherent communicative difficulties posed by the distinctly different experience, training, professional backgrounds, cultures and native languages of various team members. This problem is further aggravated by the often rapid changes in team composition on each development site [11]. In their systematic review of 170 GSD studies [12], Jim´enez et al. list ten success factors. At least seven of these, such as ‘establishment of an effective communication mechanism’ and ‘application of maturity models’ are related to process descriptions. In addition, all seven best practices listed in a recent survey of empirical GSD studies literature [13] are facilitated by a process description. Process descriptions may include processes and activities related to knowledge management. In the context of GSD, knowledge management issues become exponentially pertinent as knowledge is spread over development sites and coordination of this knowledge can prove to be difficult [14]. And although the more central role of tools such as the use of distributed software configuration and change management systems (SCCMS) [2] [15] formalize, and thereby unify work methods, the use of these tools needs to be enforced by a common process. IV. M ETHOD A. Research Environment We obtained access to process descriptions of three different software development organizations that work with an offshore subsidiary to develop software. The organizations will be referred to as JKL, ABC and XYZ. The first two organizations are large and established information technology service providers that operate on a world-wide scale while the latter is a comparatively small, Dutch IT service supplier. Table I contains relevant data regarding organization age, size, offshore focus, process scope and organizational maturity. In the case of ABC, additional documentation was used to supplement the ‘non-onshore’ software development process description. The other two organizations tailored their common process descriptions to specifically address GSD-specific issues. All three process specifications are in use at the Dutch subsidiary of each organization. B. Approach The main unit of analysis was the GSD process description document. After obtaining the process description for each organization, we analyzed it. We looked for the target audience, the methods described, the way the process was outlined, the level of detail used and we distilled commonalities and distinctions in the descriptions. As part of
Table I O RGANIZATIONS U NDER S TUDY Organization
Operating
Employees
Offshore focus
Process scope
JKL
50 years
50,000
India
the Netherlands
CMMI level 3
ABC
50 years
100,000
India
world-wide
CMMI level 2
7 years
70
South Africa
the Netherlands1
CMMI level 2
XYZ
Organizational Maturity
1 only active in the Netherlands
the analysis, the work flow and activities of the process descriptions have been remodeled using a uniform third party modeling language. We used the Business Process Model and Notation language (BPMN) [16]. Using a common, visual-oriented, modeling language such as BPMN eases comparison of verbal descriptions and notational snippets. An example of one1 of these translations can be seen in Fig. 1. After this initial analysis, we interviewed the designers of the process descriptions. The main purpose of these semi-structured interviews was to clarify the findings of the analysis, to understand the process and organization of the ‘process development’ and to gauge the extent to which the descriptions are used in practice. To this end, the interviews were divided into six common sections 1) Document purpose Why was the document made? 2) Communication of the process How is the process communicated to its audience? 3) Process improvement How is the process made? How is it maintained? 4) Process management Who is responsible for the process? 5) Process in practice How is the process description intended to be used? 6) Document versioning What is the version history of the document we analyzed? Are future versions planned? In addition, we devoted a section to the specific process description of a particular organization. V. R ESULTS All processes are based on, or at least rely on, terminology from the Rational Unified Process (RUP) [17]. The RUP has enjoyed a widespread popularity and is often used in industrial practice. As a result, terminology used in the RUP is commonly understood and used. Of the three process descriptions, two were written, chiefly verbal-oriented documents and one a (detailed) set of slides. XYZ chose the slide format to be able to use the presentation as part of the on-boarding course for new project members or project leaders. XYZ shares the same documentation regarding their process description with all stakeholders, including all team members and clients. In 1 The
other diagrams are available upon request.
contrast, ABC reserves their process description for higher project management and JKL, while also aiming to only write for higher project management, keeps their process description confidential. Only XYZ uses detailed UML notation to decrease the chances of ambiguity due to the wider audience of their process description. At the time of writing, JKL’s process description was in the later stages of being completely reviewed and renewed. We analyzed a release candidate of version 1.0 which was at that time in use at several projects in the organization. ABC wrote their GSD process description in 2008 and did not intend on updating the GSD aspect of the process description but in 2009 embarked upon a multi-year, organization-wide campaign to further formalize development practices. XYZ’s process description was made over the course of several years and reviews or updates were not planned in the foreseeable future. A. Process Sections We identified 13 different, coherent groups of information in the process descriptions. These groups were identified by defining and naming a group based on a set of coherent topics, looking for the same set of coherent topics in the second and third process descriptions and redefining and renaming (often a subset of the initial set of coherent topics) until a set was consistent for as many process descriptions a possible. A summary of these groups can be found in Tab. II. Only three topics were common to all process descriptions, specifically (1) a description of work flow, (2) an overview of deliverables and (3) a classification of involved roles. In addition, two out of three process descriptions contained sections on (4) activities, (5) organizational objectives, (6) tools and (7) quality control. The other six identified topics were unique to the process description of ABC, namely (8) a description of change request processes, (9) risk analysis and management, (10) communication protocol, (11) recourse planning, (12) customer value and (13) knowledge management [18]. Only two out of three process descriptions describe a detailed process work flow and objectives. ABC approaches their GSD process description as an additive set of rules and practices to any process description and therefore, lacks a step by step work flow description. As both JKL and ABC are larger, multi-national organizations, there is a stronger focus on organizational objectives. XYZ is more flexible
Figure 1.
BPMN Diagram for GSD process description of case ‘XYZ’
and defines objectives per project. Remarkable observations include that while all three organizations find the change management (CM) process a key element of their process description, only ABC prescribes a CM process in their process description. JKL did not yet formalize their CM process and XYZ uses a CM tool set which enforces a specific process. Furthermore, JKL does not mention tooling because the organization does not make use of standardized tooling and XYZ describes itself as too small to need to
formalize knowledge management procedures. Also, only ABC prescribes a resource planning method. Resource planning for GSD is different from common resource planning because additional effort has to be calculated for communication, travel, increased quality of documentation and knowledge management [19]. GSD is known to add extra risk factors such as missing knowledge or know how and misunderstanding because of language deficiencies, different cultural backgrounds or employee turnover [19]. Only ABC
describes risk analysis in their process description. B. General Process The ABC process description mainly highlights the headlines of the process. Most of the description deals with project management issues and deliverable specifications. In the introduction of its process description, ABC defines a project manager which is ‘usually’ located off-site and an overall project manager which is ‘usually’ located onsite. Most of the sections containing project management activities include a reference as to which role is responsible for those activities, leading to an estimation of the distribution of activities on-site versus off-site. For the activities of the software development process, a table has been drafted of clear goals and guidelines regarding the distribution of activities on-site versus off-site. ABC’s process description is clear on which activities are performed by which actors on which shore. The process description submitted by organization XYZ, is less formal in structure, but not less formal in description. The software development process has been clearly defined and specified into activities. Roles and tasks are separated. And while project management activities have also been defined and specified into separate activities, they have not been integrated with the software development activities. This loose connection between project management and software development is illustrative of the informal structure of the process description. Another possible explanation for this lack of integration could be that XYZ is less experienced in GSD and generally less mature than the other two organizations. This process description makes no difference between which activities are performed onshore and, which are performed offshore as XYZ uses the same process description at both locations. C. Additional Documentation In addition to the documentation we analyzed, for at least one organization, XYZ, we found that the CM process was enforced by a tool. This tool obliges team members to follow certain steps while registering change requests. Moreover, all three organizations make use of an additional set of discipline-specific instructions which are placed on an internal wiki or other type of intranet site. For example, detailed methods for system design and modeling are described. Another example is a set of best practices for setting up a workshop to facilitate requirement elicitation. In all three organizations, these pages are continuously updated by experts. VI. D ISCUSSION A. Process Design and Rationale We observed various reasons for designing a GSD process. Various interviewed subjects within the same organization gave different answers to the question, ‘Why was a
process description made for GSD?’. Among the reasons were a desire for ‘repeatability of approach’ (prescriptive) to be able to better predict the development process, to use as course material for on-boarding of new project team members (descriptive) and organizational maturity, to eg. obtain a certain CMMI level. In addition, we found very different approaches of process description design for the three cases. The most visible are the description methods. ABC mainly uses lists and tables, JKL uses text supported by various types of diagrams including UML and free-form diagrams, and XYZ uses UML diagrams almost exclusively. Also, the level of detail of the process descriptions varies strongly. JKL provides a detailed process description in which process steps are clearly outlined. XYZ provides less detail and ABC provides almost no detail on process steps and focuses chiefly on the possible pitfalls of GSD. While these are three different organizations, these process descriptions are to be used for similar types of custom software development projects by software developers of similar education level and expertise. We did not find any particular reason for the choices for using models over text or viceversa. While answering questions such as, ‘Why did you use a UML activity chart to model this process?’, process designers generally presumed that their chosen method was the only logical method to convey a specific process step or best practice. While we did not yet study the use of process descriptions in practice, we suspect that, at least in the organizations we studied, the choice for inclusion of specific elements and the methods to describe these elements is at least in part dependent on the expertise and professional background of the process engineers. Another distinctive feature was the extent to which the steps of the development process are integrated with the project management activities. ABC separated both completely, providing for a strict separation of tasks and responsibilities. JKL, on the other hand, chose to fully integrate these processes. In the case of JKL, a separation of tasks and responsibilities was achieved by clearly describing the actors within the process description and by providing swim lane diagrams of the sub-processes. The information released by connecting the software development process and the surrounding project management activities can be seen as additional information regarding the process. A more mature organization, eg. in terms of obtained level of CMMI certification, links various types of activities to one another. The actual process maturity and the intended audience of a GSD process specification dictate the extent to which development process and project management activities are linked. Project and especially program management is less interested in development activities as it is in management activities but does need to understand how both relate to one another. XYZ’s level of integration of development and management processes can be placed in the middle between companies ABC and JKL. XYZ clearly defined a process view of the
project management activities and provided starting points to connect these elements, but a full integration is not achieved. We believe that part of the differences in descriptions, design and GSD approach in general can be explained by assessing the maturity of undertaking GSD. If we define a process description plainly as a description of a process, ABC provides a minimal amount of description. However, it provides the most elaborate description of GSD practices, only to merely recommend its use to project leaders. JKL provides a very detailed account of process steps, a more limited focus on GSD specific procedures but obliges project managers to use the description. XYZ provides a description of process steps, the level of detail of which can be placed between that of the process descriptions of JKL and ABC and focuses only sparsely on possible GSD issues while requiring all project members to know the documented process. As shown in Tab. I, the process scope of ABC is worldwide. ABC’s set of rules and best practices, while elaborate, is set up so it can be used with very tailored software development processes. By letting a project manager free to set up a customer development process but providing him with a detailed set of guidelines, ABC combines flexibility and the benefits of applying best practices. This is, however, as mentioned, not in line with ABC’s organizational objective of achieving operational excellence. ABC is in the process of defining a more rigorous process description in which its current GSD process description will be merged. B. Use and Management The intended use of the prescribed process does not necessarily correspond with the provided level of detail. For example, ABC provides a vast list of best practices but only intends these to be used as a reference, whereas JKL expects projects to follow the process as prescribed in the documentation. Both larger organizations, JKL and ABC, have set up departments, which are responsible for (re-)engineering, publishing and distribution of process descriptions. These departments periodically review the existing processes, not only for custom software development (generally Java and Microsoft .NET development) but also for software development for business intelligence and Enterprise Resource Planning systems such as SAP. Both larger organizations contain business consulting and process engineering department, which are actively involved in (re-)designing processes and process descriptions. The Dutch subsidiary of JKL uses a system where feedback is continuously asked of project management. Feedback on processes is also incorporated in the standard post-mortem analysis of a software development project. ABC uses a more top-down oriented approach, where an international team of specialists reviews and reengineers process descriptions. With regard to the overall goal of this study to understand how software development processes descriptions are altered to tailor for GSD, we note that the extent to which the
process descriptions have been particularly tailored for GSD differs. The larger organizations seem to take different strategies at GSD. JKL focuses on formal processes, whereas ABC intends to shift more responsibility to the individual project manager. This is remarkable as in their respective interviews, process management noted that JKL’s organizational strategy is to focus on customer intimacy, whereas ABC aspires to attain operational excellence. And while GSD is a central and an increasingly important activity for both organizations, their organizational strategies are not (yet) apparent from their GSD process descriptions. VII. VALIDITY The lack of related work investigating GSD process descriptions in industrial practice warrants an exploratory study. As no industrial, GSD-specific process descriptions are currently available in literature, the three process descriptions we obtained can only be compared to each other. In addition, two organizations in our analysis predominantly engage in intra-organizational GSD while one organization (JKL) also engages in inter-organizational GSD. This might influence the way the process description is designed. VIII. C ONCLUSION We report six main observations with regard to the process descriptions. First, all studied processes are based on, or at least rely on terminology from RUP. Second, motivations for GSD process description format, structure and content are said to be derived from organizational objectives. Our analysis did not confirm this. GSD process descriptions are made by a multi-disciplinary group of consultants, and it is not clear how the processes are used in practice. Design of the Process descriptions seems to be partly dependent on the expertise and professional background of the process engineers. Other important influences on the design and intended use of the process descriptions are the size of an organization and organizational maturity. Third, the level of detail of the process descriptions varies strongly. Fourth, the intended use of the prescribed process does not necessarily correspond with the provided level of detail. Fifth, the extent to which the process descriptions have been particularly tailored for GSD differs. Particularly the larger organizations seem to take strategies at GSD that are different from one another. Sixth, some parts of the processes are captured outside the process description documents we analyzed. (eg. the CM process of one organization is captured in a CM tool set) IX. F UTURE WORK In order to increase our understanding of GSD process descriptions, the use of the studied process descriptions in actual GSD projects must be studied. Are the specific alterations that organizations make to cope with GSDspecific issues followed by projects in practice? How does
this influence project success? Furthermore, the process of engineering a GSD process is not yet clear and the specific impact of GSD process descriptions on the development process is also to be investigated. ACKNOWLEDGMENTS The authors would like to thank all involved organizations and all interviewed process managers and project leaders for their time and openness. R EFERENCES [1] F. Salger, “On the use of handover checkpoints to manage the global software development process,” in OTM Workshops, ser. Lecture Notes in Computer Science, R. Meersman, P. Herrero, and T. S. Dillon, Eds., vol. 5872. Springer, 2009, pp. 267–276. [2] E. Carmel, Global Software Teams: Collaborating Across Borders and Time Zones. Upper Saddle River, NJ, USA: Prentice Hall PTR, 1999. [3] M. Treacy and F. Wiersema, “Customer intimacy and other value disciplines,” Harvard Business Review, vol. 71, pp. 84– 93, January/February 1993. [4] S. Sharma and G. Seshagiri, “Point/counterpoint,” IEEE Software, vol. 23, no. 5, pp. 62–65, 2006. [5] R. Prikladnicki, J. L. N. Audy, and R. Evaristo, “A reference model for global software development: Findings from a case study,” International Conference on Global Software Engineering, pp. 18–28, 2006. [6] J. M. Hussey and S. E. Hall, Managing Global Development Risk, 1st ed. Auerbach Publications, 11 2007. [7] M. A. Cusumano, “Managing software development in globally distributed teams,” Communications of the ACM, vol. 51, no. 2, pp. 15–17, 2008. [8] R. D. Battin, R. Crocker, J. Kreidler, and K. Subramanian, “Leveraging resources in global software development,” IEEE Software, vol. 18, no. 2, 2001. [9] A. Mockus and D. M. Weiss, “Globalization by chunking: A quantitative approach,” IEEE Software, vol. 18, no. 2, 2001.
[10] A. Mockus and J. D. Herbsleb, “Challenges of global software development,” in IEEE METRICS. IEEE Computer Society, 2001, pp. 182–184. [11] J. D. Herbsleb, A. Mockus, T. A. Finholt, and R. E. Grinter, “Distance, dependencies, and delay in a global collaboration,” in CSCW ’00: Proceedings of the 2000 ACM conference on Computer supported cooperative work. New York, NY, USA: ACM, 2000, pp. 319–328. [12] M. Jim´enez, M. Piattini, and A. Vizcano, “Challenges and improvements in distributed software development: A systematic review,” Advances in Software Engineering, no. 710971, pp. 1–15, 2009. ˇ [13] D. Smite, C. Wohlin, T. Gorschek, and R. Feldt, “Empirical evidence in global software engineering: a systematic review,” Empirical Software Engineering, vol. 15, no. 1, pp. 91–118, 2010. [14] K. C. Desouza and J. R. Evaristo, “Managing knowledge in distributed projects,” Communications of the ACM, vol. 47, no. 4, pp. 87–91, 2004. [15] R. E. Grinter, “Doing software development: occasions for automation and formalisation,” in ECSCW’97: Proceedings of the fifth conference on European Conference on ComputerSupported Cooperative Work. Norwell, MA, USA: Kluwer Academic Publishers, 1997, pp. 173–188. [16] OMG, “Business Process Model and Notation (BPMN) Version 1.2,” Object Management Group, 140 Kendrick Street, Building A, Suite 300, Needham, MA 02494 USA, Tech. Rep. formal/2009-01-03, January 2009. [Online]. Available: http://www.omg.org/spec/BPMN/1.2 [17] P. Kruchten, The Rational Unified Process: An Introduction. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003. [18] L. Qiu, “A comparison of process descriptions and specifications in the offshored software development industry,” Master’s thesis, Leiden University, August 2009. [19] S. Zopf, “Success factors for globally distributed projects,” Software Process: Improvement and Practice, vol. 14, no. 6, pp. 355–359, 2009.
Table II C OMPARISON OF GSD PROCESS DESCRIPTIONS C ASE JKL
C ASE XYZ
C ASE ABC
size content types language audience
44 pages text; UML & work flow diagrams; tables
54 slides text; UML diagrams; other diagrams
44 pages text; other diagrams, tables
English project management
English team members, client
English engagement management
Work Flow
step by step lev. of detail described
yes high level of detail (UML) roles; responsibilities; deliverables; requirements
yes high level of detail (UML) responsibilities per role; deliverables per phase
no low level of detail responsibilities per role; deliverables and requirements per step
Activities
description method described
step-by-step
absent
a list of important points
activity flows; acceptance criteria; activities per project type
nothing
activity lists for situations; acceptance criteria; on- and off site activities
objectives for steps; general objective of process description
absent (‘these differ per project’)
objectives for steps; objectives for steps
described with activities description
described as comment in UML diagrams
described in activities description
responsible staff; list acceptance criteria; references links in activities description; product hand-over process; update deliverables process
responsible staff as actors in UML diagrams; list acceptance criteria & show sample deliverables
responsible staff; list acceptance criteria; templates links in table; set deadline for hand-over
responsibilities per role
roles as actors in UML diagram
responsibilities per role
describe responsibilities in activities description; assign deliverables in table; assign tasks in table
responsibilities in UML diagrams; related deliverables in UML diagrams
list responsibilities ; related deliverables; tasks in activities description
description method
absent (‘not yet formalized’)
absent (‘process captured in a tool’)
change process outlined
described
nothing
nothing
description of change related activities; description of change related staffs; description of change related tools
description method described
requirement
none
list important risk management activities
‘require update risk log’
nothing
list requirements of doing RA&M; assign tools for certain RA&M activities
Communication description Protocol method described
none (‘promote informal communication’) nothing
none (‘organization size is too small’)
description of communication related activities responsible roles for communication activities; requirement for communication plan; requirement for communication document
Tools
description method described
none (‘does not use standard tooling’)
short tool descriptions
tools are linked to tasks
nothing
list of possible tools
recommended tools; Tasks
Quality Control
description method described
quality control per activity
none (‘differs per project’)
list acceptance criteria; tasks of responsible roles
nothing
separate quality control section (‘but just for reference’) list acceptance criteria in activities description; tasks of responsible roles
Overall
Objectives Deliverables
Role Classification
Change Request Process
Risk Assessment
Resource Planning
Customer value
Knowledge management
description method described
description method described
nothing
description method described
none (‘no standard method’)
none (‘differs per project’)
key activities of resourcing planning
nothing
nothing
list requirements of resource planning; assign tasks to responsible people
description method described
none (‘but we focus on customer intimacy’) nothing
enhancing customer text (‘shared view of enhancing the customer value’) nothing
description method described
none (‘separate organization-wide process specification’) nothing
none (‘organization size is too small’) nothing
organizational attitude towards customer value; activities for enhancing customer value important activities of knowledge management organizations attitude of knowledge sharing; list activities of knowledge management
