}w!"#$%&'()+,-./012345<ya

Transcription

1 }w!"#$%&'()+,-./012345<ya MASARYK UNIVERSITY FACULTY OF INFORMATICS Design of Project Management Implementation as a Service DIPLOMA THESIS Bc. Marie Zachovalová Brno, 2009

2 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Advisor: Mgr. Michal Oškera i

3 Acknowledgement I would like to thank you to my adviser Mgr. Michal Oškera for his creative ideas, support and patience during our cooperation. ii

4 Abstract This work aims to design the service of project management implementation into IT companies. In many companies in the information technology field the work is organised into projects. But they are not always using project management (PM). In the first part of the work, the overview of both domains is provided, of project management and the service development. It starts with the introduction to project management and describing the main aspects of its implementation. Then, the description of service sector, of the new discipline service engineering and the chosen models and methods for service development are presented. In second part of the work, the PM implementation is described as a service by providing the value proposition. Following this description and by using the presented models PM implementation is designed. At the end, the used methods are evaluated. Keywords Service engineering, Service Science, Management and Engineering (SSME), Project Management, Project Management Implementation, Service System, Service Development, Conceptual Design, Three Dimensional Service View, Project planning iii

5 Contents 1 Introduction Goals Chapter Overview Project Management Implementation in IT Project Management Introduction PPPM basic concepts Process groups Project Management Standards Why to Implement PM into Organisation Capability Maturity Model Key Points in Project Management Implementation Process of Project Management Implementation Service Background Services and Service Systems Value Proposition Service Science and SSME Service Categorisations Services and PPPM Service Development Service Engineering Scope Organisation structure State of the art in service development Development Process Process models Development phases Service Development Concepts Conceptual design method Three dimensional view of services Conceptual model of service Similarities between PPPM and 3D service view Project Management Implementation as Service Value Proposition Deliverables Phases of Implementation Design of Service Conceptual Design Application

6 6.1.1 Metamodel System Design Three Dimension View Design Models Design of product model Design of process model Design of resource model Design as project planning Evaluation of Development Process Planning phase Conception phase Evaluation conclusion Conclusion Future Work Bibliography List Of Used Abbreviations A Conceptual Models A.1 Conceptual Model of Project, Programme and Portfolio A.2 Conceptual Model of PPPM A.3 Conceptual Model of Service B Conceptual Design Method B.1 Attribute Base For a Repair Facility B.2 Metamodel for PM Implementation C Three Dimensional View Method C.1 Use Cases C.2 Activity Diagrams C.3 Net Graph

7 Chapter 1 Introduction We know no more about services today than people knew about iron in the Iron Age. (Evert Gummesson) In last years or even decades the attention moves more and more to the services. And the attention to services is devoted also in the academic sphere. The novel discipline called Service science or SSME (Service science, management and engineering) emerged. One part of Service science deals with the systematic service development and aims to find suitable models, methodologies and tools which would provide means to design and develop services as we are able to develop products or software. In this work I tried to take some of existing methods and models and create design of service, concretely the design of project management implementation. Project management and project management implementation is a current issue. Many business activities in information technology (IT) companies are organised as projects. Accounting software development, adding new functionality to internal system, creating wireless network, information system implementation, launch of new website are examples of activities which are commonly marked as projects. Also the people from IT frequently talk about projects. However this project labelling and talking is often done without relation to the project management as set of standards and best practices and not following these standards and practices may result in unsure outcomes or delays of projects. Project management implementation can be done by the company itself when it has the resources (particularly human resources) capable to manage implementation. On the other hand, when the company does not have this capability they can implement project management in cooperation with consulting company which offers the implementation of project management as service. Joining the domains of the service science and project management gives the direct possibility to show their interconnections. As the authors of [18] say: We believe that SSME and project management disciplines are tightly interconnected on the conceptual level, i.e. they both are about the same even though each of them uses slightly different terminology and focuses on different aspects. 1.1 Goals This work aims to achieve these goals: 1. Describe the project management implementation in IT as a service 3

8 CHAPTER 1. INTRODUCTION 2. Study relevant methods of service design and development (in context of a new discipline service engineering) 3. Apply models and methods to develop service system of project management implementation in IT 4. Evaluate the used models and methods 1.2 Chapter Overview Chapter 1 - Introduction It mentions the goals and structure of work. Chapter 2 - Project Management Implementation in IT This chapter aims to describe the main aspects of the project management and project management implementation. Chapter 3 - Service Background This chapter provides the overview of the service related topics. It presents the definitions of services, novel discipline Service science, management and engineering and examples of service categorisations. It also includes the first comparison of the services and project management. Chapter 4 - Service Development First, the field of the service engineering is provided. Second, the service development process and its phases are discussed. Third, two service development concepts and one extra based on project planning are described. Chapter 5 - Project Management Implementation as Service Based on the general description of the project management implementation, this chapter describes it as service by providing the value proposition which defined the provider and client, the benefits of this service and the service deliverables. The implementation is described with emphasis on continuous improvement. Chapter 6 - Design of Service In this chapter the development concepts and the description of project management implementation as service are put together to design the service. It also includes the evaluation of the service development process and used methods. Chapter 7 - Conclusion This chapter summarises the results of the work and outlines the future enhancement and development. 4

9 Chapter 2 Project Management Implementation in IT This chapter aims to introduce the readers to the project management, especially in information technology (IT) companies, and let them realise the complexity of project management and its implementation. First, I present the introduction to the project management. Then, I discuss the reasons and benefits of having project management implemented into organisation. Last, the key points of implementation are described and the generic process of implementation is given. But first of all I start with the definitions of the project management and its today s wider understanding. Definition 1 Project management is the discipline of planning, organizing and managing resources to bring about the successful completion of specific project goals and objectives [37]. Definition 2 The application of knowledge, skills, tools, and techniques to project activities to meet project requirements [20]. Today the term project management implies not only to single project management as the mentioned definitions say, it represents the Project, Program and Portfolio Management (PPPM). Apart from single project management activities it also deals with coordination and managing set of projects. Any time in this work when the project management is mentioned the readers are asked to thought on its in this wider meaning. 2.1 Project Management Introduction There are several reasons why to start with the introduction to the project management and not going directly to the project management implementation description. First reason is obvious, to give the readers the background of the discussed issue and to make them familiar with the used terminology. Second, the project management implementation itself is a project or program and thus it should be managed in this manner (for detail see section 2.4). Third, the service development should be managed as a project (or program) too. Last, there can be noticed the duality between services and projects. The similarities are pointed out in the section

10 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT Project management in IT companies has several characteristics which distinguish it from project management in other sectors [20]: Wide variety of projects. There are small projects with one or two people working on it for a few weeks and there are also big projects with hundreds people lasting for years. Information technology supports many other possible activities (both in private and business life). This creates additional requirements of project manager s and team members knowledge. IT is still quite a new discipline. Many different IT positions (often specialists) complicates team creation and team leading, and causes the communication problems also within IT workers. Quick changes in technologies. New technologies shorten the delivery time and also create time pressure in business competition. To describe the main aspects of project management I follow two books - the Information Technology Project Management from Kathy Schwalbe [20] and the Successful Project Management from Milton D. Rosenau [19], and the standard IPMA Competence Baseline [5]. In this section the basic definitions of terms from PPPM, the role of project manager, the leadership and the tripleconstraint are explained. Then, the processes in projects are described PPPM basic concepts A project is a time and cost constrained unique process to achieve a set of defined goals up to quality standards and requirements [5]. A programme is a set of related projects and organisational changes put in place to achieve a strategic goal and to deliver the benefits that the organisation expects. A programme management is an instrument to implement strategic change [5]. Another important characteristic is the fact that the projects in the programme share goals and resources. A portfolio is a set of projects and/or programmes, which are not necessarily related, brought together for the sake of control, coordination and optimisation of the portfolio in its totality. The portfolio management is an instrument to manage continuity of projects and programmes in an organisation [5]. The projects and programmes in the portfolio share only resources. In other words, one can see the portfolio as a huge project which consists of task packages - projects, where the team members are the project managers of the projects. So any time the project properties are mentioned, they are also valid for a portfolio (and a programme). Figure 2.1 shows the relationship among the project, programme and portfolio. Project manager and leadership The job description of project manager is heterogeneous and dependent on the organisation and the project type. 6

11 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT Figure 2.1: Project, programme and portfolio relationships According [20] the project manager in IT should have the knowledge, skills and experience in several areas: project management information technology a domain in which the project is realized (e.g. the information system for health system require knowledge about the health system) general management skills and knowledge - financial management, accounting, marketing, strategic planning, supply chain, human resources, security, safety at work soft skills (e.g. effective communication, conflict coping, leadership) The project manager in IT should have knowledge in IT field but does not have to be the expert. This knowledge eases the communication with the team and suppliers. To finished project successfully the manager has to put more effort in being better project manager than in being better IT expert. The project manager has to develop himself in all five areas mentioned above. In some cases the leadership and management are taken as same though they are different. The leader concentrates on longterm goals and vision, and motivates others to achieve these goals. The manager manages everyday activities to fulfil objectives. It is said: Leaders identify the vision, managers realize it. The project manager has to take both roles. The good project managers are both good leaders and good managers. Tripleconstraint Every project has the following constraints: what, when and how much which are called a tripleconstraint. What dimension defines the specification of what has to be done. When dimension defines the time scope of project. How much dimension defines the cost of the project. These dimensions are related to each other. From two given dimensions the third can be computed. So any time one of dimension is changed, also the others have to be changed. [19] Figure 2.2 shows the conceptual model of PPPM domain. The central entity is the work breakdown structure (WBS) element, it is an activity, a product or a project. The WBS element leads to achieve the set of objectives, allocates resources 7

12 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT Figure 2.2: Conceptual model of PPPM domain and needs competences for its realisation. WBS elements can relate together in different relationships, e.g. the activity leads to the realisation of the product, the activity belongs to the project, the activity consists of several subactivities. The definitions of entities and relations are included in Appendix A Process groups Schwalbe [20] describes the project management divided into five process groups of each project - initiation, planning, realisation, controlling and managing, and finally finishing. These groups overlap in the course of project time and reach different level of activities. Figure 2.3 shows the typical situation during project. Initiating No project cannot start without an initiating process. It defines the project. The first estimation of the tripleconstraint is created. The project manager is assigned and main stakeholders are identified. 8

13 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT Figure 2.3: Relationship, overlap and level of activity of the process groups [20] Planning Planning process involves creating the plan which reflects the project requirements. Usually there is not the sole plan, there are a few plans - for scope, time, cost, quality, human resources and risk. Rosenau [19] says that the plans give the direction how and in which way to move from point we are now to the point we want to be. There are a few reasons why to plan project. The planning process and plans themselves help to ordinate project and better communicate in project team. They are necessary for managing the project, they provide information if or not the project is leaving given direction. They are simulation of project realisation, so they can give the warning if the project is unrealisable. Staníček and Hajkr [29] describe the five plans which answer the following questions: what should be done, how to reach the project goals, with who, when and how much it will cost. Three of them are already included in the tripleconstraint. They suggest the order in which the plans should be created. First start with what and create Work Breakdown Structure (WBS). WBS is decomposition of the project scope organized in tree structure. When the WBS is prepared, the how plan follows. It says how the what dimension is realized. It can take the form of a net graph which also show the dependencies and order in which the steps are realized. The WBS can be seen as the piece list and how plan is the manual how to create/realise this piece list. Then, based on these two plans one knows what competences and knowledge are needed, and it makes possible to create the with who plan in which the team members are identified. Last, we plan the when and how much dimensions. These two plans should be refined depending on the other one in several rounds. With these plans the scope, time, cost and human resources are planned. The two other aspects, quality and risk, are important factors in IT projects and could be even related to each other. For example, not finishing the prototype in time versus finishing in time with lower quality. For each identified risk the probability in which can occur and cost of the possible damage are given. The quality planning 9

14 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT means the setting of standards which will be followed and how. It also includes the quality metrics. Executing In this process the project outputs are created and therefore most resources is used. The executing process includes coordination of resources, team leading and managing or quality assurance. Monitoring and Controlling The controls are done to prevent the loss of given direction, from plans. It is done by following the done and not done tasks [19]. The outputs of this process are the status reports regularly prepared by the team members or project managers. They contain information what was done, where are problems, where could be problems, what needs to be changed. Changes and problems are natural part of IT projects. There can be uncertainty when planning project and during realisation the plans have to be updated. The origin of changes can be in the client but also external e.g. the inflation or the changes in law or standards. Closing The closing process is the formal acceptance of project results. It includes some administrative tasks (e.g. document archiving) and documenting learned lessons. There can be several reasons why to finish the project: the financial resources are spent much quicker than planned, the project lost its priority, there are no human or material resources available to finish it, the project cannot be finish in time and there is no reason to finish it after. But the best reason to finish project is achieving the given goals and objectives of project [19]. 2.2 Project Management Standards There are two important international standards in project management. The International Project Management Association (IPMA) standard is widely used in Europe and the Project Management Institute (PMI) bases in USA. These standards are not in opposition, they look at the project management from two different views. The PMI standard is written as a manual, how to behave and what to do, to get good chances that the project ends up well. It identifies the main activities which are taken in project management and its outputs, it looks mainly on the process side of project. On the other hand, the IPMA standard tries to describe all elements involved in the project manager profession. It defined three ranges containing the related competences - technical, behavioural and contextual competences. Preparation for the certification, both of the managers and organisations itself, increase the motivation of the employees to cope with questions concerning im- 10

15 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT proving the processes and methodologies, and therefore it leads to active participation on the progress, which results in increased success of the projects [33]. 2.3 Why to Implement PM into Organisation The [12, 20] gives the following reasons why to implement the project management into organisation to manage the information technology projects: More certainty in reaching the defined goals and objectives Lower financial cost Potency to work on European and international projects (due to fulfilled national and international standards) Flexibility Continual adoption Improve control over the financial, physical and human resources Improvement of customer relationships Shorter terms for software development Higher quality and reliability Higher profit Higher productivity Improved internal processes and coordination Positively influenced motivation The project management is a suitable tool to implement quality control and to reach high quality in company. The article [12] says: The Standard for management of project quality gives the instructions to use the project management to reach a higher quality. The following standard, describes how to cope with changes in project Capability Maturity Model The Capability Maturity Model (CMM) is a model of the maturity of the capability of certain business processes. A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization, and aids in the definition and understanding of an organization s processes. It identifies five levels of process maturity for an organization: initial, repeatable, defined, managed, optimising [34]. Follow the description of levels for the software development [22]: 11

16 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT Figure 2.4: Levels of Capability Maturity Model [22] 1. Initial level. In an organization at the initial level, conditions are not stable for the development of quality software. The results of any project depend totally on the manager s personal approach and the programmers experience, meaning the success of a particular project can be repeated only if the same managers and programmers are assigned to the next project. In addition, if managers or programmers leave the company, the quality of produced software will sharply decrease. In many cases, the development process comes down to writing code with minimal testing. 2. Repeatable level. At this level, project management technologies have been introduced in a company. That project planning and management is based on accumulated experience and there are standards for produced software (these standards are documented) and there is a special quality management group. At critical times, the process tends to roll back to the initial level. 3. Defined level. Here, standards for the processes of software development and maintenance are introduced and documented (including project management). During the introduction of standards, a transition to more effective technologies occurs. A program of constant, advanced training of staff is required for achievement of this level. The process does not tend to roll back to the previous level in critical situations. 4. Managed level. There are quantitative indices (for both software and process as a whole) established in the organization. Better project management is achieved due to the decrease of digression in different project indices. 12

17 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT 5. Optimizing level. Improvement procedures are carried out not only for existing processes, but also for evaluation of the efficiency of newly introduced innovative technologies. The main goal of an organization on this level is permanent improvement of existing processes. As seen in the description above, the project management is an essential means to get from the initial level up. The higher level the more quality and effective processes which are accompanies by the project management improvement. 2.4 Key Points in Project Management Implementation In this section the key points of PM implementation with respect to the IT companies are mentioned. Although, most of these points is valid for all PM implementations, in different sectors. They characterize the project management implementation and give the ground for the description of the project management implementation as a service. Continuous process and managed as project The continuous improvement is considered to be part of the PM implementation. The IPMA standard [5] in context of the competence Project, Program and Portfolio Implementation says: Continuous improvement is needed to improve capability in project, programme and portfolio management and increase the success of the organisation in carrying out its strategic plan. Since the continuous improvement should lasts forever, it does not have and evident end. To be able to manage the implementation and also the never ending improvement, one splits it into set of processes with the defined start and end. These processes have the main characteristics of project (uniqueness, time constrained and aiming to achieve defined goals), therefore they are projects and should be managed in this manner. Complex change The change of one aspect in the organisation influences the other aspects. Several ways of organisation improvement are given in [27]. They happen through the following aspects of organisation: organisation structure, assessing, competences, information and knowledge, people, and processes and activities. Since all these aspects are connected to each other (as shown in Figure 2.5), we cannot change one of them and hope that it is enough. One change evokes another change. The same avalanche effect happens during the project management implementation. Ignoring this fact can result in failure of implementation. Some of these aspects in the context of project management implementation are described in next sections. The complex changes as PM implementation in the organisation cannot be done without the support from top management. Without its involvement and interest they are not going to satisfied with the results. 13

18 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT Figure 2.5: Everything is connected to everything [27] Motivation and assessing There is no issue that motivation of team workers is the highly important factor in the successful project. Here I present one way of increasing the team motivation by keeping them informed and involved in the planning. The authors of [18] call it the team forming. They distinguish three kinds of forming: forming seminars which aim to communicate and elaborate the strategy of organisation for upcoming period; they happen approximately every half of year forming weeks provide time for project planning in team, discussions of objectives and goals, task assignment and also sharing the experience; they happen approximately every two months in forming days the team members share what was done recently and clarify next plans; they happen every 2 weeks Concerning assessing, the team members has to feel that the proportion of the given efforts and the gain assessing equals to the proportions of others. There are features which complicate the work: destructive competition (bringing attention to the success of individual can destroy the success of the project), aversion to new tasks (when the results are unsure), gap between popular (interesting and well valued) and non-popular tasks (boring and not valued) [30]. The assessing methods should reduce the negative effect of these features. Competences Earlier in this chapter the five areas in which project manager should have experience, skill and experience, in one word competences, were mentioned. During the 14

19 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT project implementation process the project managers and also the team workers especially need to broaden the knowledge in the project management field and soft skills. Project management methodology When describing the service of project management implementation I am not concern with the project management methodology. The concrete methodology and extent of its application depends on the organisation size, types of projects, experiences, priorities. Choosing the methodology suitable for the organisation is a part of implementation process. The points of project management (and also the standards) here mentioned say what should be done. The concrete methodology then specify how aspect. Software The project management is closely related to the project management software. Without appropriate software systems and supporting tools it is almost impossible to successfully managed bit more complex project [18]. Because of the diversity of existing systems and diversity in organisations needs, there is not a unique solution for all. Both, the selection and implementation of these software systems are important parts of the project management implementation process. Establishing regularity Some activities in project management (e.g. the planning, forming, strategic management) should perform on regular basis. Oškera and Staníček [18] use the metaphor of mills. To the flourmill be beneficial, it has to be in operation regularly or constantly. Further they say: Establishing mills and keeping them working is crucial to succeed and is one of hardest task within the PPPM process implementation service provision. We see the running mill as the key to the sustainability of the PPPM. There are several kinds of mills. Figure 2.6 shows three levels of them: the longest circle represents the strategic management and portfolio management, the middle one stands for planning and forming. The small one is the daily single project management. Implementer s skills The quality and success of implementation of PM is based on the experience and knowledge of the people working on it. Not all of this knowledge can be made explicit, therefore the people play important role. Having look at the description of the project manager certified according to the IPMA standard [5] at the highest level gives the hint who is the person which should be responsible for implementing the project management: 15

20 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT Figure 2.6: Regularity in project management shall have the ability to direct all projects of a company or branch or all projects of a programme has at least 5 years complex project and programme management experience, of which 3 years in responsible leadership functions in co-ordination and portfolio management of projects manages the co-ordination and controlling of all projects on the level of a company or branch proposes the portfolio priorities to general management develops the project management personnel and coaches the project managers is responsible for project management implementation, hand-books, guidelines, application of general methods and tools 2.5 Process of Project Management Implementation The competences in the IPMA standard [5] includes also Project, Program and Portfolio Implementation competence. It describes what should be included in the process of continuous improvement of PPPM. It also suggests the following possible process steps to master this competence (under a few steps I added some comments): 1. Decision made Decision made to adopt project, programme and portfolio management in the organisation as a continuous improvement/change management project. 16

21 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT As it was mentioned in section 2.4, the support of the top management is the critical point in the success of project management implementation. To made decision to start implementation of PPPM into organisation the management has to look at the project as continuous change which needs enough attention not only from managers. 2. Current State Analysis Determine the state of project, programme and portfolio management in the organisation versus industry benchmarks and best practice. The audit of current state done by the external organisation can explore the current situation more objectively. Also the external organisation could have more knowledge and experience with other companies, and therefore has more capability to make a quality comparison (benchmarking). At this point, the introductory training about project management can take place to unify the used terminology and approaches. 3. Develop Concept Develop concept for project, programme and portfolio management in the organisation. In this phase a lot of mental work has to be done. As mentioned several times before, the implementation touches many aspects of organisation. When developing concept, all these aspect has to taken into consideration. 4. Pilot PPP program Demonstrate feasibility by a pilot PPP programme. 5. Full Implementation Evaluate results of pilot programme and if successful set up a full-scale PPP implementation programme. 6. Improvement Steps Preparation Decide the speed of implementation and steps to take along the maturity path regarding competence development, organisational changes required and methods/techniques/tools to be adopted. 7. Improvement Steps Implementation Implement steps, select and train personnel in project, programme and portfolio management. 8. Repeat process and lessons learnt Continuously improve by repeating process steps and implementing lessons learnt. In this chapter the project management domain and the general process of project management implementation were introduced. Among other things the benefits of PM implementation, key points of PM implementation and the process of implementation were presented. The benefits and key points will be used in chapter 5 to describe PM implementation as service. Before creating this description next 17

22 CHAPTER 2. PROJECT MANAGEMENT IMPLEMENTATION IN IT chapter introduces the service system definition and the means how to describe the service system - value proposition. The generic process description of implementation provides ground for identifying the service deliverables and implementation phases. 18

23 Chapter 3 Service Background There is no doubt that the service economy and service employment is growing rapidly not only in developed countries but also in some of the developing countries, such as China and India. The term Service sector once mainly related to unskilled, low-payment, labor-intensive activities in industries are closely associated with technology/knowledge-intensive service jobs, which are performed by well educated, highly skilled, and ideally paid employees and are characterized by making advanced use of information and communication technologies [13]. This chapter aims to provide the readers the background in the service related issues. The definitions of service and a service system, the description of service science, two service categorisations, and, lastly, the relation of project, programme and portfolio management to services are provided. 3.1 Services and Service Systems We are meeting service on daily basis. To distinguish services from products seems to be easy, though before defining service the basic characteristics of services (compared to products) are summarised [21, 17, 38]: intangible - even thought the service itself can be realized through tangible products not storable variable, e.g. each taxi delivery differs - another point in time, maybe another route, probably another taxi driver and cab delivery and consumption happen at the same time difficult to measure and quantify difficult to provide complete specification client has to be present, e.g. the client has to sit in hair dresser s shop client is often co-creater not easily transportable I start with the simple definition from Kameoka and follow by the definition of Spohrer which leads to the service systems. 19

24 CHAPTER 3. SERVICE BACKGROUND Definition 1 Service is a supporting activity to help an individual or organization to achieve its objective [10]. Definition 2 Service is the application of competencies for the benefit of another, meaning that service is a kind of action, performance, or promise that s exchanged for value between provider and client [26]. This definition is illustrated in Figure 3.1. Figure 3.1: Service system triangle [16] Services can form more complex structures called service systems. Service systems are dynamic value-cocreation configurations of people, technology, organizations, and shared information (such as language, laws, measures, models, etc.), connected by value propositions into vast service networks [25]. Individuals, families, firms, nations, and economies all represent instances of service systems. 3.2 Value Proposition According [35] the value proposition (VP) consists of the total sum of benefits which a vendor promises that a client will receive in return for the client s associated payment (or other value-transfer). [28] says about it: Through all the process of service provision there must be at any time point valid statement of work declaring WHAT have to be done, HOW it will be done, WHERE it will be done, WHO will do what, WHEN WHAT will be 20

25 CHAPTER 3. SERVICE BACKGROUND done, and WHY it will be done. This statement is called a value proposition. Then he added the value proposition characteristics: Absolutely clear for all stakeholders. A benefit for the client must be obvious to this level that they buy in to the change. A clear axe edge 1 to cut up the problem has to be recognized and communicated. The axe edge is about usefulness for client or potential clients. Any particular usefulness claimed in VP has to be supportive to this axe edge. 3.3 Service Science and SSME Service Science, Management and Engineering (SSME) or Service Science is a new academic discipline designed to develop the skills required in the world s increasingly service-based economies. The SSME is also initiative established by the IBM company with the major goals to aim: to become more systematic about innovation in services to complement product and process innovation methods to develop science of services The proposal of a general theory of service systems should consist of three parts [3]: science what service systems are and how to understand their evolution; it is a way to create knowledge management how to invest to improve service systems; it also improves the process of creating and capturing value engineering how to invent new technologies that improve the scaling of service systems; it is a way to apply knowledge and create new value SSME combines knowledge from different discipline to improve the service sector. Example of this combination is shown in Figure 3.2. In any case, this new field brings together ongoing work in computer science, industrial engineering, business and management, social sciences and legal sciences. The SSME initiative also points out the need for people educated in more disciplines. They call them as T-shaped professionals, which are supposed to be both 1. The expression axe edge is the sharp edge of the axe. In context of value proposition it expresses the solution for client s problem and draws the attention of the service. 21

26 CHAPTER 3. SERVICE BACKGROUND Figure 3.2: Service science [25] deep and broad. Deep means that they should have deep knowledge in a selected discipline (the core field of study) and broad aims to multidisciplinary overlaps (communication skills across other fields). The wider scope of T-shaped people is necessary due to an ability to deal with multidisciplinary nature of service affairs [40]. Figure 3.3 shows an example of discipline structure as it is taught at the Faculty of Informatics, Masaryk University. One of the initiatives taken is the project DELLIISS of nine European universities and organisations, which aims to define the profession of the engineer in innovation of information services and develop the requirements for the lifelong learning [7]. 3.4 Service Categorisations The service sector is heterogeneous, to ease the references for different service, several categorisations were defined. In this section, I present two of them, one which shows the diversity of services and one which is related directly to the service development. The first categorisation of [25] starts with dividing resources into four categories based on the characteristics: physical or not-physical and if it can contract or cannot. It results in the matrix 2x2: People, Organisations, Technology and Shared Information (see Figure 3.4). Based on this matrix, he shows four kinds of services (Figure 3.5): Consumer services (non-market services), Business services, Industrial services, Information services. Regarding service development, F ahnrich et al. [4] evolved the typologisation 22

27 CHAPTER 3. SERVICE BACKGROUND Figure 3.3: T-shaped professional at FI, Masaryk University [31] Figure 3.4: Service resources [25] based on contact intensity and variety. Contact intensity means the intensity of interrelationships between clients and employees. Variety describes the total number of manifestations of the service product. There are four service types defined. See Figure 3.6 for overview and examples of each type. Process-focused services are standardised service systems. 23

28 CHAPTER 3. SERVICE BACKGROUND Figure 3.5: Service typology [25] Flexibility-focused services - suitable for systematic creation. Customer-focused services consist of a single, clearly defined standard service which may be influenced by client within certain limits. Knowledge-focused services - their performances require amount of customising. The project management implementation is a business service in the first categorisation and a representative of the knowledge-focused service in another. The contact with client is intensive and the variety is high. The number of manifestation of this service equals to the number of clients. 3.5 Services and PPPM This section shows the similarities between service and project domains from several points of view. First, I show the main similarities between the service (service provision, operation) and projects. Both, the service and projects, are [18] undertaken for benefit realisation, target/goal oriented unique processes time oriented processes with commitments and milestones specified involve people and technology as their crucial component 24

29 CHAPTER 3. SERVICE BACKGROUND Figure 3.6: Service typology [9] resource consuming based on cooperation and synergy In introduction of the chapter 2 there are briefly mentioned three relationships between service and project (or program or portfolio). Services and projects similarities were already mentioned. Before discussing the last two (PM implementation as project and service development as project), I mention the simple equations between services and PPP [31]: 1. Service creation = Project 2. Service System creation = Program 3. Service System operation = Portfolio or Program The project management implementation as project is more explained in the section 2.4 and also agrees with the equation number 3: the project management implementation is the service and because of its complexity also the service system. The last remains to explain the service development process as project: looking at the similarities mentioned at the beginning of section I demonstrate the closeness. The development is undertaken because of expecting results. It is also unique 25

30 CHAPTER 3. SERVICE BACKGROUND process, hardly any two development processes are going to be same. The involvement of people and technology is also crucial, without it the result does not appear. The example of consumed resources is the used software, developers, rooms. The cooperation with client on the service development is not necessary, but not including the cooperation with the potential client as essential the quality of design is lower and the success of service is unsure. Lastly, the competition in the business world requires offering the service as soon as possible, so usually the time for service developing is limited. This chapter provided the service background. It started with the service and service systems definitions. The service system with the roles of provider and client and the value proposition concepts will be used to describe service of project management implementation in chapter 5. At the end of this chapter, the similarities between projects and service were described from several points of view. 26

31 Chapter 4 Service Development There is no lack of ideas for new services in business. Rather, there is a lack of procedures describing how to translate these ideas directly into successful service products. (Rohit Ramaswamy) This chapter aims to introduce the service development domain. First, the new discipline service engineering (SE) which was already mentioned in the previous chapter as a part of SSME is presented. I deal with definitions and the scope of this discipline. Moreover, the aspect of organisation structure of development teams and the trend in service development are presented. After the service engineering introduction, I describe the development process of services, which models can be used for development and the phases of development process. Then, the two existing concepts for service development are discussed. Last, the design method based on similarities between projects and services is introduced. 4.1 Service Engineering The name of newly emerging discipline consists of the words: service and engineering. About services there was a lot of written in the chapter 3 and engineering is a traditionally technical discipline. [14] says: The term Service Engineering implies a basic of engineering knowledge and originates from the assumption that services can be designed and redeveloped in a similar way to physical products. Definition 1 Service Engineering is the specialist discipline, which focuses on the systematic development and design of service products with the aid of appropriate procedures, methods and tools [23]. Definition 2 Service Engineering can be understood as a technical discipline concerned with the systematic development and design services using suitable models, methods and tools [4]. Definition 3 Service Engineering is a systematic development and design of services using suitable models, methods and tools [9]. Definition 4 Service Engineering can be defined as the discipline addressing the technologies and engineering processes required to define, design, implement, test, 27

32 CHAPTER 4. SERVICE DEVELOPMENT verify, validate, deploy, maintain and manage services that meet user needs in current or future networks [1]. These definitions are in accordance with each other. All they contain these aspects: technical, systematic and models, methods, tools, procedures. These aspects are currently more known from classic engineering disciplines. This discipline is trying to put some orderliness in service development. Main objective is to ensure the introduction of new and enhanced services and their management in a fast and efficient manner. [1] Scope The service engineering mainly deals with the following aspects [15]: Improving the procedures for designing and developing services more professionally Establishing service design and development as a corporate function Adapting a service specific human resources management From the other view there are these three fields which concerns the service engineering: development of new services As it was said on the beginning of this chapter in the quotation, there is no lack of ideas for new services, but there is demand for translating these ideas into services. service innovation (innovation of existing services) There are plenty of existing service which cannot be omitted and replaced by the new services. The service engineering methods and tools could be use to transform these services into more efficient one. Service innovations can for instance be new solutions in the client interface, new distribution methods, novel application of technology in the service process, new forms of operation with the supply chain or new ways to organize and manage services [39]. design of service development system The systematic development needs the solid base and the metalevel which enables to talk about the service development. The existence of the development system eases the development by providing the methodologies, models and tools. The researchers and academics in SE devote to this field, compared to the previous two fields which are dominated mainly by the business organisation Organisation structure As it was mentioned earlier, the design of services was for long period based under the marketing. Looking at the usual organisation in the company hardly one can find a department which would be able to deal with service but the marketing. The 28

33 CHAPTER 4. SERVICE DEVELOPMENT marketing department is often responsible for coming up with new ideas and since there are no other departments which take over the development of the services (as in the case of the physical goods does the design department, for software the software developers) they have to deal with development on their own. There is nothing wrong on the marketing departments developing service. But often they do lack the systematic approach and sufficient knowledge and know-how. The service engineering adopts a more technical-methodological approach, attempting to efficiently utilise existing engineering know-how in the area of traditional product development to develop innovative services [4]. After discussing the service development under the marketing departments (since there is no other option), the question of interest could be what are the other options. [4] shows four alternatives, primarily distinguishes between service development as a permanent tasks or a temporary task. Figure 4.1 show these four alternatives. Figure 4.1: Organisational alternatives for service development [4] A separate organisational unit helps ensure that service development becomes anchored as a long-term feature. The organisational unit does not have be a department, it can take the shape of a position, a group or even a centre. The advantage of this organisational form is that the development activities distinct from daily operative activities, so that the know-how can be built-up and maintained systematically. Another alternative is service development under existing organisational units. In this case the service development is the additional task. The advantage of this form is that the capacity of the unit s members can be controlled more effectively, although the development-specific know-how is restricted. The third alternative is the service development by specific project teams. This solution requires minimum organisational changes and the members of the project teams can be appointed on case-to-case basis. The disadvantage is that the knowhow which is built up during the course of such project is often lost because the team members have to turn their attention to another task. The last alternative is external development of new services. The company can decide to outsource complete development or to purchase services that have al- 29

34 CHAPTER 4. SERVICE DEVELOPMENT ready been developed by others. This alternative brings most benefits if the company does not have the service development know-how or if it is missing the knowledge of the area State of the art in service development Service engineering is a new discipline under intense attention and expansion. Three main current trends in the service engineering according [14]: 1. utilisation of IT - the service development will be increasingly supported by systems for Computer Aided Service Engineering. This is alternative to sets of tools called Computer Aided Software Engineering which are widely spread in software development. The CASE tools (both in software and service development) tries to automate the development process. 2. combination of material goods and services - so called hybrid products. This involves two development process and different lifecycle of products and services. 3. organizational integration of the development process - examination of the process of service development and service innovation embedded into organisation. It should lead to standards and measurements, and more efficient development and innovation. Figure 4.2 shows the possible evolution in service development and its support by information technology. It starts with ad-hoc development, changing in methodical development in 90 s of the last century. The current situation should be under the Computer Aided Service Development tools. Unfortunately, these tools are still not common for the service development. 4.2 Development Process To express the importance of development process I start with the quotation from [8]: The sequence in which certain activities are to be undertaken during the development process is of special interest. Particularly those companies which regularly develop new services are seeking ways to eliminate redundant work, prevent past mistakes from being repeated and reuse existing know-how. This section starts with the description of process model and follows by the discussion about development phases Process models Process models document project activities. Until now, such models have been found mainly in traditional product development and software engineering, yet the basic principles behind them mean they can also be effectively applied to the field of service development [9]. 30

35 CHAPTER 4. SERVICE DEVELOPMENT Figure 4.2: Trends in service Development [14] Process models for service development should be able to [9]: 1. define activities that are necessary to develop services and the sequence in which these activities are undertaken 2. create the prerequisite for successful and efficient positioning of new services in marketplace by systematising service development 3. integrate clients into the development process at an early stage in order to satisfy the specific characteristics of service In short I mention two basic process models - waterfall and iterative, which origin in software development but also have their position in the service development. Waterfall model It is characterised by a linear progress. Each phase starts when the previous fully ended. The process is transparent and milestone oriented (clear end of phase). However, it lacks flexibility, the opportunities for the parallelism are largely neglected [4]. From previously mentioned requirements it goes well only with the first one - defining activities sequence. Iterative model The linear process steps of the waterfall model are each repeated several times. It enables to obtain initial outcome very quickly. It also enables learn- 31

36 CHAPTER 4. SERVICE DEVELOPMENT ing effect within single project [4]. From mentioned requirements: it defines the activities sequence and the iterating gives the space for the client cooperation and modification according the client s developing needs. The second requirement is partly supported by the attempt of systematic development Development phases There are several process models mentioned in papers dealing with the service design. They use different names for phases but, as it is shown in this section, they represent the same in more less details. Figure 4.3 shows the phases overview. Figure 4.3: Development phases According Luczack et al. [14] the process of service development consists of three major phases: service planning, service conception and service implementation. The first phase, the planning, starts with a systematic idea generation, followed by forming and evaluation of these ideas. The second phase, the conception, leads to the precise description of them. The third, the implementation, includes also the launch of the service. These phases were used as a scale to be able to compare the different processes together. Spath et al. [23] mentions these phases: project initiation (includes finding and 32

37 CHAPTER 4. SERVICE DEVELOPMENT selecting ideas), definition phase, analysis phase, conceptualisation phase, realisation phase, test, launch/rollout and project completion (includes continuing improvements). See the second column. Bullinger et al. [4] mentions these phases: Idea generation, Requirements analysis, Concept development, Implementation, Market launch and Post-launch review. See the third column. The last column brings out the common phases of the software development (SW). It is added to show the similarity between the SW and service process. 4.3 Service Development Concepts To demonstrate the development of the service, I chose two distinct concepts of service development. Both are taken from the papers [4, 11] concerning the service engineering (SE) and provide the recent progress in this discipline. There are not many ready to use concepts for service development in the context of the service engineering. SE is a new discipline and currently many works concentrate on finding its position between the marketing view of service development and software development and on creating the general development system. Also the chosen concepts are not offered as a complete methodology with the exact steps description. That is the reason why I call them concepts and not methodology. The first concept is based on the view of service system as set of attributes which are valued by the designer. The second one is based on the view of service as three dimensional space. One dimension expresses what, second how and last what with Conceptual design method The Conceptual design method for the service system development is described in [11] The core of the method is the metamodel which consists of the set of the attributes and the possible values for them. These attributes provide base for the characterisation of the service system. The designer selects the subset of these attributes and assigns a value to each of them according the service provider and designer. The service system is based on the general system architecture which consists of nine classes. A system is an organized set of objects which processes inputs into outputs that achieve an organizational purpose and meet the need of clients through the use of human, physical and informatic enablers in a sociological and physical environment: clients 1 - those benefing from the system or otherwise affected by it; goals - aims, purposes or central meaning; inputs - physical, human, financial, informational entities to be processed by the system; outputs - physical, informational or human entities as a result of processing by the system; processes - transformations for obtaining outputs from inputs; human enablers - human resources owning and/or 1. In [11] this class is called Customers. To be in compliance with the rest of the work I renamed it to Clients 33

38 CHAPTER 4. SERVICE DEVELOPMENT operating the system; physical enablers - physical resources which aid in operating the system; information enablers - information and knowledge resources supporting the system; environment - physical, economic, technological, social, ecological or legal factors influencing the system. The authors of this method identify the service system as the system in which the client may be actively involved in all nine previously mentioned classes. This service system definition differs from those provided in section 3.1 but it is not in conflict with them. None of them dispute the importance of the client in any service system. This one is based on specifying the included objects. Based on the analysis of 150 service design projects the author of [11] identified a group of objects for each class. They refer to it as the Capstone model, see Figure 4.4. Example of the objects: Business goal, Service goal, Customer goal and Culture goal are objects for class Goals. The object is a categorisation of the attributes. Figure 4.4: Service system - the Capstone model [11] The metamodel consists of the attribute sentences with possible values for these classes and objects. It is domain specific. During design process the library of metamodels is searched through for the relevant metamodel to the designed service system. The relevant metamodel can also be the generalised one (design of shoe repair facility using the product repair facility metamodel). There are two kinds of attributes: problem attributes - given by system provi- 34

39 CHAPTER 4. SERVICE DEVELOPMENT der, represent the objectives the system is intended to operate, voice of client; and solution attributes - provided by system designer, output, response of the engineer. Example of problem attribute: Economic sector of client group - private clients, military clients, government clients, business clients. The values are given by the client or provider. It is objective. Example of solution attribute: Primary method of communicating with the client - web page form, , phone, personal contact. The best value for this attribute is the result of the service design. Application The [11] presents metamodel for a repair facility service system (for reference see Appendix, the section B.1). Based on it I constructed the metamodel for the service systems of the project management implementation. Then I designed the project management implementation service system matching the description provided in chapter 5. Both the metamodel and the designed service system are described in detail the section Three dimensional view of services The typical service is characterised by the three dimensions and for each of them there is a model which describes it. The three characteristic dimensions are: [9] a structure dimension (the ability and willingness of provider to deliver the service) a process dimension (the provision of service is drawn as a process) a outcome dimension (material and immaterial results of provision of the service) There should be suitable models and concepts for each of these dimensions in the development process. The results of service development are resources models, process models and product models. The Figure 4.5 illustrates the relationships among dimensions and models. product model provides definition of the service content, it models what the service does and what is the result. process model specifies how the service is provided resource model plans to resource deployment for the provision of a service, what with Application The section 6.2 describes the usage of this dimensional view. First, the deeper explanations of each model type with the examples of the concrete models methodologies are presented. Then the usage of these models to develop the project management implementation service is described. 35

40 CHAPTER 4. SERVICE DEVELOPMENT Figure 4.5: Service concept [4] Product labelling Here I want to shortly point out the usage of the word product which is often used even the complete concept concerns the services. Namely there is usage of two types: In name of the model for the outcome dimension - Product model and in name of the entity in the conceptual model - Service product. The authors of [4] emphasise that the term product is used deliberately. They want to point out that the service can be developed and marketed in the same way as the physical goods and software. The other reason can be that the using of the product gives the tangible feeling of service. The Service product is defined as the service in the form which is offered at the market to the clients. For example the bank offers the drawing account as its product. Some years ago the accounts were accompanied by the bank book, but now the bank stores the money and enables comfortable manipulation with it; it is completely intangible service. 4.4 Conceptual model of service The figure 4.6 shows the conceptual (entity-relationship) model of a service. It is based on the service model provided in [4] and reflects the three dimensional view of services. The core component is the service activity. The relationship between activities assigns the precessors and succesors. This produces Process model. Service products bundle together in meaning: one product is part of other products. Service products are outputs of services and represent the Product model. Service activities join together to create the service product as it is offered at the market to the clients. To fulfil the service activity the certain amount of resources has to be spend - human resources, material and immaterial. The definitions for this model can be found in Appendix A.3. 36

41 CHAPTER 4. SERVICE DEVELOPMENT Figure 4.6: Conceptual model of service 4.5 Similarities between PPPM and 3D service view There can be found several similarities between the PPPM as presented in the chapter 2 and the three dimensional (3D) service view concept. First I show the similarities on the dimensions. One of dimensions easy to recognize in both is what. The closeness of how much from tripleconstraint and what with from 3D view is little less direct: what with says which resources are needed and in which amount. And the how much is dependent on the resources and their amount. It does not have to be express in money always. Let s take as example the project of developing website for the friend starting photography career. When it comes to specifying how much, the programmer talks in human and other resources - he spent 12 manhours and used his computer and software. 3D view and tripleconstraint differs in third dimensions: As the third dimension (the third element of tripleconstraint) the project management emphasizes the time aspect (when). I see that the time specification is not so important in the service development. The milestones and deadlines of the service provision depend on the intensity of service provision and client. When the time aspect is really important for the service it can be part of the what specification. The other distinct dimension is the how aspect. How is not included in the tripleconstraint but the [29] places it as one of the five plans needed for the project 37

42 CHAPTER 4. SERVICE DEVELOPMENT planning (section 2.1.2). Figure 4.7: Relationships among dimension of 3D view, tripleconstraint and 5 plans for PM planning Figure 4.7 shows the overview of relationships between different dimensions of the 3D service view, in tripleconstraint and of five plans for PM planning. The middle and last columns have the same colour because of their significant closeness. Who with plan says who is going to work on the project (what human resources are needed). Other similarities can be better seen from the conceptual models of both domains (Figure 2.2 and 4.6). - they both contain activity and product. These entities in both models can relate in different ways - e.g. being part of another or one follows other. Application The similarities in dimensions result in the third method of service design which is described in chapter 6. This chapter provided the comparison of the phases of the service development. The three identified main phases (planning, conception and implementation) are mentioned further in the work. The main purpose of this chapter was to describe two development concepts which will be used to design service in chapter 6. Based on the observed similarities between project, programme and portfolio management and the three dimensional service view the ground of the third design method was created. Also the application of this concept is a part of chapter 6. Moreover this chapter included the conceptual model of service. 38

43 Chapter 5 Project Management Implementation as Service In section 2.4 I described the generic process of project management implementation in the information technology company. To implement project management in the organisation only by the organisation itself requires very experienced managers inside the organisation, therefore in a lot of cases the implementation is done with the help of an external company. The consultants of this company provide the experience, knowledge and manage the process of implementation. From this point of view the project management implementation can be seen as a service. To describe the PM implementation as a service, I provide the value proposition - clear statement which describes the client and provider and the benefits of the service. At the end of this chapter, I devote the attention to the phases of implementation and the continuous improvement of PM implementation. 5.1 Value Proposition The structure and explanation of value proposition was described in section 3.2. Client, Provider and Target Based on the model of service system introduced in section 3.1, the client, the provider and the target are identified. The client is the information technology (IT) organisation which works on projects of software development. The consulting company which is capable to provide consultancy in project management and PM implementation is the provider. The target is the organisation implementing the PM itself. By the organisation are meant the people, processes, information and knowledge, organisation structure, assessing and motivation, and finally competences. These are the parts of reality which is changed during (by) the service (see section 2.4, paragraph Complex change). The Client - Provider - Target triangle is illustrated at Figure 5.1. Benefits for Client The client gets the project, program and portfolio management implemented. Through it the client can managed the higher control of quality, more certainty in reaching the defined goals and objectives and positively influenced motivation. These are generalised benefits. In concrete cases benefits might be the more specific. See section 2.3 for list of possible benefits. 39

44 CHAPTER 5. PROJECT MANAGEMENT IMPLEMENTATION AS SERVICE Figure 5.1: Client - Provider - Target triangle Deliverables The deliverables are described in detail in the next section. Axe edge -like formulation The consulting company provides its experience and knowledge to enable implementation of PPPM into the IT organisation (client). The implementation process will be managed by the consulting company. As a main deliverable the client gets the project, program and portfolio management implemented and the follow up service to support continuous improvement. 5.2 Deliverables This section gives overview of the deliverables with short descriptions. The deliverables of the project management implementation and the chronological order in which they are delivered are shown in the net graph at Figure 5.2. Analysis of current state is delivered In the first phase the consultancy organisation observe the current state of the organisation in the project management field. The result of observation is the written and delivered. Even the implementing organisation decides after receiving the analysis not to implement the PPPM, they can still value from the analysis. Requirements are identified The requirements are identified in cooperation with the client, therefore before identification, the introductory workshop to unify the terminology is recommended. It included the requirements for the organisation change, software, training and so on. Guidelines for PPPM are delivered Based on the analysis, the identified requirements and the current situation at the PM field the guidelines suitable for the imple- 40

45 CHAPTER 5. PROJECT MANAGEMENT IMPLEMENTATION AS SERVICE Figure 5.2: Deliverables dependencies menting organisation are prepared. This document is changed as the organisation learns and adopts new knowledge. The employees are trained in project management The employees, both the managers and non-managers have to be trained and educated in the project management. The higher managers should also receive the trainings and education in program and portfolio management. Organisation structure is adopted The project work is tightly connected to the team work. When these teams do not exist or are based only on functional structure, 41

46 the new teams need to be formed. CHAPTER 5. PROJECT MANAGEMENT IMPLEMENTATION AS SERVICE Soft skills seminars for employees organized The communication, negotiating, problem solving and some other are essential for project team work. Assessing and motivation system set The changed organisation structure, new tools, the bigger requirements of knowledge have to face themselves in changed assessing system. Software equipment selected and implemented The increasing power and availability of the information technologies make them essential part of the project work. The software (SW) needs to be selected according the organisation requirements. After the SW implementation the employees who are supposed to work with it, are trained. Testing program is prepared, run and finished Before running the first project or program, it is planned with the consultancy organisation. Then the project or program runs under their supervision. After the close-up of program or project, the results are analysed and the full project management implementation can be done. System for planning and managing projects is implemented The guidelines give the instructions and advices how to do project management but they have to be used in daily work to bring the results (and goals). To put the guidelines in practice and keep it followed on all levels in organisations requires responsible approach and control for several months before it becomes daily routine. The system is implemented when the mills (see section 2.4) are established and kept them working. Continuous improvement is prepared and provided After the PPPM was implemented the improvement steps are prepared and implemented. It is needed because the knowledge and needs of organisation emerge and change. And also the knowledge in PPPM domain emerges. This deliverable is delivered repeatedly. 5.3 Phases of Implementation The steps suggested in IPMA Competence baseline (see section 2.5) and the delivering of deliverables can be divided into the three phases - Preparation, Realisation and testing, and Continuous improvement. The similar phases can be found for the software implementation - Analysis and design, Realisation and testing, Maintenance. The deliverables delivered during first phase: Analysis delivered, Requirements identified, Guidelines are delivered, Employees trained, Organisation structure adopted, PM software selected and implemented, Motivation and assessing are set, 42

47 CHAPTER 5. PROJECT MANAGEMENT IMPLEMENTATION AS SERVICE Figure 5.3: Phases of implementation Soft skill seminars organised. The second phase includes: testing program is prepared, run and finished, and system for planning and managing projects is implemented. And when the implementation is finished (for that moment, after delivery of System for planning and managing projects is implemented ), the continuous improvement starts. This phase follows the principles of Mention/Use and PDCA to ensure improving. When using Mention/Use principle, first, we talk about the object which has our attention, we describe it and try to evolve it by our thoughts - we mention the object. Second, we apply the evolvement to the object which has our attention - we use it. Third, we evaluate and revise the application of evolvement - again we mention the object. And then again continue with use. The process can be seen as switching between Mention and Use: Mention use mention use... [32] Mention/Use principle can be found in many common processes, e.g. when learning from our own mistakes. PDCA principle is a four step process used in process improvements - plan, do, check, act [36]. Plan Establish the objectives and processes necessary to deliver results in accordance with the expected output. Do Implement the new processes. Check Measure the new processes and compare the results against the expected results to ascertain any differences. Act Analyse the differences to determine their cause. Determine where to apply changes that will include improvement. If possible implement the changes in daily routine or standards. The Mention/Use principle can be seen as generalisation of PDCA cycle, where Plan and Check corresponds to the Mention and Do and Act corresponds to the Use phase. Figure 5.4 show the PDCA cycle and corresponding double Mention/Use cycle. Mention/Use principle in the PM implementation continuous improvement: by using the project management the new impulses and needs are produced. Also the business environment generates new requirements and the knowledge in PM field increase. In the Mention phase these impulses, needs, requirements and knowledge 43

48 CHAPTER 5. PROJECT MANAGEMENT IMPLEMENTATION AS SERVICE Figure 5.4: PDCA and Mention/Use principles are evaluated and described. Consequently, in the Use phase they are implemented and used. And the usage again produces another new impulses and needs, the environment changes and the cycle goes another round. This chapter provided the example of the value proposition (VP) of PM implementation service. The VP is a part of the planning phase of service development process (for description of phases see section 4.2.2) and it is the base for the service design. Second part of this chapter deals with connection of the implementation phases and continuous improvement. Two models for continuous improvement (Mention/Use and PDCA) were presented. In next section the service development concepts from chapter 4 and the information from VP from this chapter and general description from chapter 2 are applied together to result in the design of service of PM implementation. 44

49 Chapter 6 Design of Service In this chapter, I describe the concrete steps taken to develop the service of project management implementation as it was described in the previous chapter. The section discussed the main phases of the development process of services. In this work I am concerned with first two phases - planning and conception phases. The first phase of development deals with generating and evaluating ideas and it is covered by the chapters 2 and 5 which describe the project management implementation first in general and then in clearer way as a service. In the second phase (conception) I took these collected ideas and described more deeply and precisely using methods for service development. Namely, I used the concepts - Conceptual design method, the Three dimensional service view and design as project planning - all are described closely in the chapter Conceptual Design Application The application of the Conceptual design method as described in the section was done in two steps - first, I created the metamodel and second, I applied this metamodel to get the required conceptual design of the service system. Note that it is also the application of Mention/Use principle (see section 5.3) Metamodel For creating metamodel upon which I would be able to design the desired service system, I generalised the project management implementation service, so the metamodel can applicable in more areas than only IT companies. When designing I took advantage of the Capstone model, see in Figure 4.4 and the metamodel example for the repair service (see Appendix B.1). The result is the set of attributes with possible values presented sorted out by the classes, but in the end this division is not important. During the design of the service (use of the metamodel) the classes do not play any role. Here the attributes for first two classes are shown. The complete attribute set is included in Appendix B.2. Clients The clients should play important role in the designing the service. The project management implementation service has to be made-to-measure. The provider should know its clients well. The class Client gives the overview of the client s features, attitudes and preferences. See table

50 CHAPTER 6. DESIGN OF SERVICE Client feature 1 client size small, medium, large 2 clients receiving service one, a few, dozens 3 clients requiring service one, a few, dozens 4 client s sector machinery, SW development, food industry 5 importance of client high, regular, marginal importance 6 economical level of client long established, new, merged Client attitudes 7 top managers experience with PM none, marginal, experience with PM in current company, experience with PM successfully working in another company Client preferences 8 novelty versus sustainability prefers novelty than sustainability, emphasis on sustainability Table 6.1: Conceptual design - Client Goal The goals are thought from several views. First one is the provider view (Business goals): why is it willing to provide the service. Second one shows the goals for the client. And last one includes goals neither directly for the provider nor for the client. They express how the provider influences or changes the culture, neighbourhood and surroundings by providing the service. See table 6.2. Business goals 9 service as competitive strategy no, some, real 10 cruciality of service existence no, some, yes (core service) Client goals 11 internal process quality improvement main, important, marginal 12 competitive factor main, important, marginal 13 profit increase main, important, marginal 14 internal process improvement main, important, marginal Cultural goals 15 increase knowledge of PM in business yes, partly, not directly Table 6.2: Conceptual design - Goal Inputs As inputs of the PM implementation are taken the factors which can influence the quality of service provision and reflects the current situation in client organisation. Namely it is the urgency, the level of client s PM knowledge, if the 46

51 CHAPTER 6. DESIGN OF SERVICE client has enough knowledge to do implementation on its own and impact of delay. See table B.3. Outputs The outputs partly overlap with the deliverables described in the section 5.2. The valuable output for the provider can be the gained experience, the feedback to the service provision and references. See table B.4. Processes For the Processes class I identified these aspects: form of client acquisition, range of required service (if complete or not) and way of contact between client and employees (channel, intensity, trust). See table B.5. Human enablers There are four kinds of human resources at provider s side seen in the project management implementation. Most needed are project management specialists. The soft skill lectures and technology specialists can either internal or external (e.g. provided as outsourcing). See table B.6. Physical enablers For the knowledge-focused service the physical enablers are less important. Anyway, among the physical enablers belong also some characteristics of the provider. In this case the level of experience with project management. The other physical enablers are the client location and the software. See table B.7. Information enablers The information enablers are which standards have to be followed and the billing principle. See table B.8. Environment The last class describes the external aspects: market, economic and social situation. See table B System Design The service system design process as described in [11] creates a specialised design space from the generalized design space. The generalized space is expressed by the metamodel. The designer selects a subset of attributes and assigns a best value to them. There are two interrelated searches. The first search explores the metamodel to generate a design domain representation space of attributes and possible values - steps (a) to (c). The second search analyses the resultant design space to determine the best set of values for the attributes - steps (d) and (e). The following steps were undertaken: (a) ascertain the requirements of the service provider First, I formulated the preliminary requirement: The requirement is to design the project management implementation service for consultancy company which is willing and capable to provide it. It will be offered to the IT companies. 47

52 CHAPTER 6. DESIGN OF SERVICE Second, the service system goal was specified by the attributes from the metamodel: - (4) client s sector - (9) service as competitive strategy (b) (c) (d) develop a design space of nominal attributes for the required system From the metamodel s attributes I chose the attributes relevant to the designed system: - (11) internal process quality improvement - (14) internal process improvement - (21) deliverables - (22) range of service required - (26) soft skills specialist - (32) billing principle - (35) current economic climate If the real client and provider would be present to the design, they both could participate on the design and the result set of the attributes would be consensus of the designer, the provider and the client. If necessary, another attribute not found in the metamodel can be added: - service provision condition (what has to client fulfil to get service provided) determine a set of potential values for each attribute If the set of values for any attribute in metamodel is not applicable, insufficient or non-existent they attribute values are added. In my case for example I added values to deliverables since the metamodel s values were not sufficient. - (4) client s sector: machinery, SW development, food industry - (9) service as competitive strategy: no, some, real - (11) internal process quality improvement: main, important, marginal - (14) internal process improvement: main, important, marginal - (21) deliverables: analysis report, PM guidelines, SW implemented, employees trained in PM, mill implemented - (22) range of service required: all, part of service on their own, part of service by another company - (26) soft skills specialist: internal, external, outsourcing, partner - (32) billing principle: fixed price, prices based on client s results after implementation, combination of both - (35) current economic climate: local recession, global recession, short local stability, long local stability - service provision condition: current client, own references, partners references, anyone create a problem partition (final design requirements) and solution partitions The chosen set of attributes was divided in the two parts. The problem partition contains those attributes which express goals and environmental aspects. 48

53 CHAPTER 6. DESIGN OF SERVICE They are also called design input as they come from the provider before the design starts. In our case they are (with the value): - (4) client s sector: SW development - (9) service as competitive strategy: some - (11) internal process quality improvement: important - (14) internal process improvement: main - (21) deliverables: analysis report, PM guidelines, SW implemented, employees trained in PM, mill implemented - (22) range of service required: part of service by another company - (26) soft skills specialist: external - (35) current economic climate: global recession, short local stability - service provision condition: own references, partners references The solution partition is the complementary subset of attributes. The value for them is provided by the designer at the end of design. (e) determine the best value for each solution attribute The best value can be chosen by any weight methodology. Also the interactions with the problem partition should be considered. E.g. the current global recession increase uncertainty of the business future and it can be unwise to base the billing on the future client s result. - (32) billing principle: fixed price The result design is the set of attributes and their values from point (d) a (e). 6.2 Three Dimension View Design This section shows how to use the three dimensional view of services to service design. First, the model types overview is given, followed by the design itself. Last, the design of project management implementation as the project planning is described and undertaken Models Product model: what the service does; it is the definition of service contents and structural plan of service products. The examples of the what models are an application scenarios, use cases, test scenarios [24]. Process model: how the service is provided. The aim of process model is creating transparency at an early stage and achieving the greatest possible process efficiency before the service is actually offered. The objective is to eliminate non-value-adding activities at the earliest possible stage. All steps has to be specified, above all, the processes must be represented transparently and lucidly, because they need to be understood by every single employee [4]. 49

54 CHAPTER 6. DESIGN OF SERVICE The examples of the how models are workflow, lines of interaction, lines of visibility, dialog control and activity diagram [24]. Resource model: what with focuses on planning those resources that are necessary to perform the service (included human resources especially with regard to the selection and qualification of staff), deployment of operating resources and designing the supporting information and communication technology. Plan of deployment of resources is an essential precondition for the efficient provision of service. The examples of the what with models: role concept, system borders, application framework, configuration [24]. All mentioned examples are taken from software development. These model examples provide good starting point for service development but sometimes they have to be adjusted as it can be seen later Design of product model To design what the use case diagrams are used. They can be used to describe the functionality of a system in a horizontal way, representing the details of individual features of the system. They do not make any attempt to represent the order or number of times that the systems actions should be executed. They display the relationship between the actors and the use cases. The syntax description is included in Appendix C.1. Figure 6.1 shows the overview use case diagram. In context of service design I encountered the problems with actor representation: the activity does not have just one responsible actor, usually the activity was realised by the group of people, from both provider and client, the consultants and the employees. In the overview use case there are two actors identified: consultants and employees works together on most main use cases and just consultants and top managers works on identify requirements use case. The actors in use case diagrams as they are used in software development represent external entities which interact with the system. But the service system includes both the client and provider. Therefore the syntax of the use case diagram has to be adapted to this fact. The actor can be an internal entity. Also, the actor can be also the group of actors. E.g. the actor can be the consultants and the project managers from the client side. The detailed use cases are included in Appendix C Design of process model To design how I used the activity diagram. It is the dynamic diagram used to model the flow of activities. The connection among activities represents the order in which the activities are taken. When using the swim lanes, the activity diagram also provides the information about the actor who performs the activity. The syntax description is included in Appendix C.2. 50

55 CHAPTER 6. DESIGN OF SERVICE Figure 6.1: Overview use case of project management implementation service When dividing activities into swim lanes another problem appears with the roles: there are activities which does not have just one responsible. The services are about cooperation between provider and client and really, there are some activities which are done equally by both, e.g. the form seminars. I generalised the actor roles and identified three actors - client, provider and both (client and provider). The more detailed allotment of roles as described later would lead to not well-arranged diagram, so I reduced number of actors only to these three. The activity diagram also included the points where client can finish the service provision. Figure 6.2 show the beginning of implementation process. The first points where the service provision can be finished is after delivering the analysis report and after evaluation of implementation process. The evaluation of the implementation process is the given point in which both, the client and provider agree (or not agree) on the further cooperation. They evaluate how the process (and cooperation) will continue and they can agree on not continuing. The rest of the activity diagram can be found in Appendix C.2. 51

56 CHAPTER 6. DESIGN OF SERVICE Figure 6.2: Activity diagram of PM implementation - beginning Design of resource model The project management implementation is a knowledge-focused service (see section 3.4). The resources needed for its provision are mainly the human resource. For the design purpose I considered only this type of resources. Other identified resources, e.g. the meeting rooms and equipment, are not so rare or costly, therefore they do not need to be necessarily included into development. 52

57 CHAPTER 6. DESIGN OF SERVICE Roles The identified roles from the use case diagram are top manager, project manager, manager, employee, consultant, project management trainer, information technology specialist, information technology trainer, soft skills trainer. Figure 6.3 shows the type hierarchy in client company and the table 6.3 gives role descriptions and divide the roles between provider and client. Client role employees managers project managers top managers Provider role consultants project management trainer information technology specialists information technology trainer soft skills trainer Description any employee of the client organisation, (including top manager) top managers and project (program) managers project or program managers managers responsible for strategic planning Description responsible for managing implementation and providing knowledge and experience about PM train employees in the project management responsible for PM software implementation train employees in using the PM software train employees in soft skills Table 6.3: Role descriptions Figure 6.3: Type hierarchy of client s employees roles Design as project planning The section 4.5 pointed out many similarities between service development and project planning which resulted in possibility to design service by the means of project planning. The last design was done by the method of five plans (described 53