Project Planning as Key to Success in Project Management

Table of Contents

List of Abbreviations

List of Figures

A. Initiation

1. Introduction

2. Aim and Approach

3. Annotation

B. Fundamentals

4. History of Project Management

5. Common Definitions of Project Management Terms
5.1. Definition of Project
5.2. Definition of Project Management
5.3. Definition of Project Planning
5.4. Definition of Project Success

6. Standards in Project Management
6.1. Why Project Management Needs Standards
6.2. Project Management Body of Knowledge (PMBOK)
6.2.1. Origin of PMBOK
6.2.2. Concept of PMBOK
6.3. International Competency Baseline (ICB)
6.3.1. Origin of ICB
6.3.2. Concept of ICB
6.4. PRojects IN Controlled Environments 2 (PRINCE2)
6.4.1. Origin of PRINCE2
6.4.2. Concept of PRINCE2
6.5. Comparing the Standards
6.6. Standard Used for Further Investigation

C. Project Planning According to PMBOK

7. Definitions of Project Management Terms According to PMBOK
7.1. Definition of Project According to PMBOK
7.2. Definition of Project Management According to PMBOK
7.3. Definition of Project Planning According to PMBOK
7.4. Definition of Project Success According to PMBOK

8. PMBOK Knowledge Areas and Planning Processes
8.1. Project Integration Management: Project Plan Development
8.2. Project Scope Management
8.2.1. Scope Planning
8.2.2. Scope Definition
8.3. Project Time Management
8.3.1. Activity Definition
8.3.2. Activity Sequencing
8.3.3. Activity Duration Estimating
8.3.4. Schedule Development
8.4. Project Cost Management
8.4.1. Resource Planning
8.4.2. Cost Estimating
8.4.3. Cost Budgeting
8.5. Project Quality Management: Quality Planning
8.6. Project Human Resource Management
8.6.1. Organisational Planning
8.6.2. Staff Acquisition
8.7. Project Communications Management: Communications Planning
8.8. Project Risk Management
8.8.1. Risk Management Planning
8.8.2. Risk Identification
8.8.3. Qualitative Risk Analysis
8.8.4. Quantitative Risk Analysis
8.8.5. Risk Response Planning
8.9. Project Procurement Management
8.9.1. Procurement Planning
8.9.2. Solicitation Planning

9. Practice: Planning a Project
9.1. Setting of the Project
9.2. Project Plan:“Implementation of Uniform SAP (UniSap) in Europe”
9.2.1. UniSap Scope Management
9.2.2. UniSap Time Management
9.2.3. UniSap Cost Management
9.2.4. UniSap Quality Management
9.2.5. UniSap Human Resource Management
9.2.6. UniSap Communications Management
9.2.7. UniSap Risk Management
9.2.8. UniSap Procurement Management

10. Evaluation of Project Planning According to PMBOK
10.1. Chances and Benefits of Project Planning According to PMBOK
10.2. Risks and Constraints of Project Planning According to PMBOK

D. How Project Planning Facilitates Project Success

11. Accomplishing Element 1: Time Adherence

12. Accomplishing Element 2: Cost Adherence

13. Accomplishing Element 3: Specification Adherence

14. Accomplishing Element 4: Scope Adherence

15. Accomplishing Element 5: Stakeholder Appreciation

16. Accomplishing Element 6: Benefit

17. Accomplishing Element 7: No or Reasonable Trade-offs with Other Company Areas

18. Accomplishing Element 8: Alignment with Company Culture and Strategy

19. Accomplishing Element 9: Compliance with Laws and Regulations

E. Conclusion and Outlook

20. Conclusion

21. Outlook

Appendix

Bibliography

List of Abbreviations

illustration not visible in this excerpt

List of Figures

Figure 1: Example of Project Lifecycle

Figure 2: The Project Management Lifecycle

Figure 3: Project Planning Components

Figure 4: The Elements of Project Success

Figure 5: Usage of Project Management Standards

Figure 6: PMBOK Processes Mapped to Knowledge Areas and Process Groups

Figure 7: ICB Competences

Figure 8: PRINCE2 Structure

Figure 9: Differences between PMBOK, ICB and PRINCE2

Figure 10: PMBOK Planning Processes

A. Initiation

1. Introduction

A CEO is presenting the annual report in front of 20,000 employees when suddenly the projector breaks down. A key account manager cannot pay the restaurant bill for his top client as he has lost his wallet. A newly elected mayor misses his first public speech as he is being held up in a traffic jam. All these examples taken from daily business and their negative effects, such as the loss of time, a damaged reputation and higher costs, could have been avoided with an appropriate planning beforehand.

Projects are even more critical as they are by definition unique^[1]. As there is only one chance to satisfy the stakeholders, the pressure to bring a project to a successful end is much higher, and a failure has much more serious consequences than a faux pas in daily business.

Although this idea seems to be consistent and companies should therefore strive to complete their projects successfully, only 32 % of all projects succeed in terms of compliance with time, budget and specifications. 44 % are completed late, exceeding budget, showing a deficit in features or with a combination thereof. The remaining 24 % of all projects fail, i.e., they are cancelled before completion or are finished but never used. Going back to the year 2000, this failure rate has never been higher^[2].

A reason for this may be that the unique nature of projects also implies uncertainties^[3]. What has never been dealt with before is hard to predict and to control. And the more aspects of a project are unique, the higher are the entailed uncertainties and the higher is the risk to fail.

And projects are becoming more and more demanding with an increasing pressure on companies in terms of time, budget and quality. As globalisation is rising, the need for fast and comprehensive adjustments of processes, systems and products is increasing simultaneously. A fiercer competition forces companies to be flexible and creative to be able to keep pace with the rapid and innovative developments in their market^[4]. Legal and cultural constraints make projects more complex and can lead to significant delays or even to a failure of the projects.

To be able to bear the growing competitive pressure, companies need fast, innovative and interdisciplinary solutions^[5], which they achieve best by applying projects. But projects lacking clear targets, specifications, communication channels, schedules and budgets are likely to fail^[6]. Hence, an appropriate project planning is vital to avoid or at least minimise all uncertainties and risks that could lead to a full or partial failure of the project.

But project planning itself does not guarantee success. It must be executed in a way that is comprehensive and efficient at the same time. Wasting resources on planning processes that are not necessary is nowadays not an option for companies being faced with such a high competitive pressure. Finding out which planning processes are required and to which detail is crucial for performing a completely successful project.

2. Aim and Approach

The aim of this thesis is to demonstrate that project planning, as part of project management, is essential to finalise a project successfully. Additionally, this paper provides guidance as to which project planning processes are mandatory to accomplish the different components of project success and which are negligible.

The necessity of project success is described in part A. In addition to that, it is explained which difficulties in project management companies are currently faced with. Part B. includes background information on the relevant topics dealt with in this paper. It outlines the history of project management and comprises the general definitions of the project management terms mainly used in this work. Following this, common project management standards are described and compared with each other. This comparison results in a decision for one of these standards, which is then used for further investigation. Subsequently, the thesis focuses on project planning. In part C., the project management terms are defined more precisely according to the standard chosen in part B. After this, the different project planning processes and their purposes are explained, including descriptions of the inputs, tools and techniques and outputs commonly used for these processes. The theoretical content of this chapter is then put into practice, i.e., a project plan is developed applying the approach described before. This project plan shows how complex an appropriate project planning can be and illustrates which information is determined in this part of project management. It also visualises the theory described in the chapters before and hence contributes to a better understanding of the dimension of project planning work. An elaboration of the chances and risks of project planning according to the chosen standard completes part C. The following part D. explains how project planning contributes to project success. For each of the elements of project success, it is described which project planning processes support achieving this success element and in which way. The thesis is accomplished with part E. The main findings of this paper are summarised, and guidance is given for an efficient approach to project planning. Finally, it is explained how project planning and the project planning environment will develop and which adjustments to the project planning approach will be required in future to enable companies to cope with the rising challenges they will be faced with in the coming years.

3. Annotation

The main part of this thesis is based on the book “A Guide to the Project Management Body of Knowledge (PMBOK Guide)”, released by the Project Management Institute, Inc. Although the latest issue of this guideline for project management is the fourth edition published in 2008, this thesis references to the second edition issued in 2000. The 2000 edition is used in the FOM international project management lectures and is dictated to be used by the supervisor of this paper, mainly because it enjoys an excellent reputation and is applied by project managers worldwide. Furthermore, experience has shown that new publications take some time to be spread and acknowledged, so using an older version approaches far more readers.

B. Fundamentals

4. History of Project Management

Project management has been exercised since early civilisation. When building the Great Pyramid of Giza in 2570 BC or the Great Wall of China in 208 BC, people already used an early kind of project management^[7]. As the world became more and more civilised and industries grew, projects got more complex, resources ran short and the pressure to succeed rose. In the early 1900s, Frederick Taylor and Henry Gantt laid the foundations for a methodical project management by measuring and controlling labour by analysing separate tasks (Taylor) and by designing charts showing the chronological order and duration of project processes (Gantt)^[8].

The 1950s are generally considered the beginning of modern project management. Al-though different tools and techniques, such as the Gantt chart^[9], were used before, these attempts were mainly informal and hardly systematic. This changed with the setup of the US Navy project Polaris Missile in 1956 and the NASA Apollo project in 1960. These projects were of such a high importance to the US government that project failure had to be avoided by all means. To be able to cope with these unprecedented challenges, further formal project management tools and techniques, such as the programme evaluation review technique (PERT)^[10], the work breakdown structure (WBS)^[11] and the critical path method (CPM)^[12], had to be developed^[13].

Later, different project management associations and organisations were founded to enable project managers to share best practices, to build networks and to enhance project management as a science and a profession. The first association was the International Project Management Association (IPMA), founded in 1965 in Vienna. Only four years later, the Project Management Institute (PMI) was established in Pennsylvania^[14]. Both institutions enjoy an excellent reputation and set standards for project management that are applied worldwide.

Up to the present day, various other project management approaches have been developed, and tools and techniques are constantly being reviewed and revised. Project manager is considered a worthwhile profession, and lectures in project management are held in universities. With a rising number of projects, project management is increasingly important and is still on the move.

5. Common Definitions of Project Management Terms

Although nowadays most of the ways of doing project management closely resemble, the wording used differs significantly^[15]. That is why this chapter provides an overview on the common understanding of the terms that are relevant for project management. A more specific definition of these terms is given in part C.

5.1. Definition of Project

A project is an endeavour undertaken to reach defined targets, which needs to be performed within a given starting and ending date and with a limited contingent of resources^[16]. Projects require interdisciplinary work, which leads to a high complexity and calls for an own organisational structure^[17] and management approach^[18]. Companies perform projects with the clear purpose to create benefit by the means of change. But change combined with uncertainties in terms of budget, people and time also implies risk^[19]. But the most important attribute of projects is that they are unique^[20], i.e., they differ from other projects in at least one of the characteristics mentioned above^[21].

Each project has a project lifecycle, defining which tasks have to be completed from the start to the end of the project. This lifecycle is segmented into different project phases, whereas each phase needs to meet a defined target^[22]. Without this target met, the project cannot proceed to the following phase. Should the target not be met, it has to be discussed and decided if the phase has to be reworked, if previous phases need to be revised according to the new findings or if the project must be discontinued^[23]. Hence, the segmentation into phases and the review of the project status at the end of each phase enhance management control. As projects are unique, so are the project lifecycles. Al-though the prevailing phases of a project lifecycle are thinking, executing, reviewing and delivering^[24], these overall phases have to be adjusted and specified according to the project specific requirements. Therefore, each project has its own project lifecycle with unique phases and tasks^[25]. Figure 1 shows a generic project lifecycle for the development and implementation of an IT tool.

illustration not visible in this excerpt

Figure 1: Example of Project Lifecycle^[26]

In this lifecycle, thinking means building the conception or approach to the project as well as planning the framework of the project, such as schedule, budget and resources. This is followed by the development of the IT tool in the build phase. After the tool is finished, it needs to be reviewed and changed if necessary. Following the approval by the stakeholders, the tool is rolled out and the project is closed. This lifecycle is issued as a waterfall lifecycle as it pictures the perfect flow of a project, i.e., it assumes that each of the phases is finished meeting its target.

Projects can be classified on the basis of different aspects. Internal projects are initiated by a principal within the company, whereas external projects are performed for a principal outside the organisation. Other classification criteria are the size, duration, complexity and importance of the project to the performing company. The reach of the project is also one criterion, for example company-internal, national or international. Another category for projects is the project content or scope. Common categories based on the content are construction projects, IT projects, research and development projects, marketing projects and organisation projects^[27]. Depending on the class of the project, the project management may need to be adjusted to ensure an efficient and effective processing of the project^[28].

5.2. Definition of Project Management

Project management can be interpreted in two ways: First, project management is an institution within the company which performs project management activities. This includes an organisational structure, stipulating how the institution is integrated in the company^[29]. Second, project management is a leadership concept, designed and valid for one project^[30]. It determines what has to be done to complete the project and how^[31]. In detail, this means that project management includes all activities for planning, monitoring and controlling projects in a target-oriented, economical and strategy-related manner^[32]. Additional to that, project management comprises the initiation and closing of projects^[33]. Project execution is sometimes not considered a part of project management as it is no sheer leadership task^[34]. Figure 2 illustrates these project management process groups. Although the project management processes are unique for each project, the process groups are the same for all projects^[35]. All process groups can be found in each project and in each project phase^[36] of the project lifecycle and are performed continuously during the project or phase^[37]. This is why the project management process groups can be considered a cycle.

illustration not visible in this excerpt

Figure 2: The Project Management Lifecycle^[38]

Project management comprises four dimensions. The functional dimension addresses the tasks that have to be dealt with in each project phase. The institutional dimension covers all interdisciplinary aspects of project management, i.e., organising and aligning the project team members to each other and to the internal and external environment. This dimension is associated with the human dimension, which appeals to the project manager’s social skills as it involves all personnel and interpersonal aspects of project management, such as qualifying people or resolving conflicts. Tools and techniques that are to be applied in the project are part of the instrumental dimension of project management^[39].

How project management is performed is defined by the way the project organisation is embedded in the company organisation. The project organisation comprises all parties that are involved in the project and is valid only for the duration of one project. The temporary, interdisciplinary and unique nature of projects requires special organisational structures^[40]. There are mainly three kinds of project organisations: the functional or coordinating organisation, the projectised organisation and the matrix organisation. These three organisational structures differ from each other in the way how much decision-making power is assigned to the project manager^[41]. The functional organisation is characterised by a project manager being in a staff position between the executive board and the line management. The line managers remain the functional heads of their staff. The project manager has no decision-making power, but coordinates the project execution in terms of schedule, information flow and procedure. Hence, she/he is not solely responsible for project success, but rather supports the line management by meeting the project objectives^[42]. In contrast to that, the project team members are grouped to an almost autonomous department in a projectised organisation. All team members are exempted from their regular jobs to be able to perform the project. The project manager is authorised to lead this team^[43], which makes her/him also responsible for project success. The matrix organisation combines the project organisations described above. Responsibilities are shared between the project management and the functional management. The project manager needs to deliver the project management expertise and results, while the functional manager assigns and provides the required resources. The project team members may be assigned part-time or full-time and can work on one or more projects with different project managers^[44]. While the project manager holds the functional authority, the functional manager remains the disciplinary head of her/his staff^[45].

5.3. Definition of Project Planning

As shown above, project planning is the second step in the project management lifecycle. Anyway, this step can be found in each of the project phases again as each phase has its own project management lifecycle. Project Planning may also be a phase in the project lifecycle. The project planning period does not have a fix starting and ending point. In contrast to that, the planning needs to be reviewed and revised throughout the whole project as unforeseen incidents could make the latest project plans obsolete^[46].

After the project has been initiated and approved, the project planning work begins. The project planning provides a framework for the whole project, i.e., this phase determines what actions will be taken, how and when they will be taken and which resources will be needed and to which extent^[47]. Figure 3 shows the common components of project planning.

illustration not visible in this excerpt

Figure 3: Project Planning Components^[48]

The first step in project planning is setting up a project structure based on the information given in the initiation phase, such as the product description, the project scope and the strategy. This structure comprises the product structure, the project structure and the accounts structure. Based on this, activities are derived and grouped to work packages. Following this, the effort, comprising the amount of time, the costs and the resources, is estimated for each work package. Now a schedule is set up showing which activity is done when, considering the activity duration and the interdependencies with other activities. The resource planning defines the utilisation of the staff and the equipment for each activity and work package. The information gathered in the previous two steps enables an overall cost estimating. These three steps are interdependent and have to be balanced and aligned. Additional to that, risk management has to be executed, including a risk analysis and the deployment of measures to avoid and to minimise the identified risks. The findings of all these steps are summed up in project plans^[49].

5.4. Definition of Project Success

Traditionally, projects are perceived as being successful if they meet the defined targets for time, cost and quality or specification. These three factors form an iron triangle. Al-though this triangle is flexible in its prioritisation of the components, it is impossible to omit one of the factors or to adjust one of them without influencing the others as they are interdependent^[50]. If one of the factors is strengthened, this will only be possible at the expense of the other two. Nowadays, this definition is regarded as not being comprehensive. The iron triangle is extended to a square by adding the project scope to be adhered to. The project scope is also interrelated with the project time, cost and specification^[51], for example if the scope is further limited, time, cost and specification are most likely reduced too. These components of the iron square are particularly important to companies facing today’s challenges in an increasingly globalising and faster reacting world as outlined in the initiation of this paper. Delays or a waste of time are not granted as fast solutions are required to remain competitive and as increasingly demanding customers want their product in time. Costs need to be kept at a reasonable level to be able to operate more cost-efficient than the competitors. The specifications of the product need to be adhered to as otherwise it will be of no use to the customer. If the scope of the project is not complied with, resources will be wasted or work missed that is necessary to achieve the objectives set in terms of time, costs and specifications.

In addition to the hard factors described above, it is obligatory that the stakeholders of the project accept and appreciate the project and its product. The stakeholders are those people who are in some kind interested or involved in the project process and outcome. Each stakeholder may have her/his own expectations, viewpoints and requirements, which often stand in contrast with other stakeholders’ claims. Additionally, different stakeholders may have different levels of power in the project, so that their requirements have more weight than those of other stakeholders. Therefore, those different demands need to be prioritised and balanced with the aim to gain the highest possible conformity with most of these^[52]. Reaching stakeholder appreciation can be considered the most demanding component of success, as people are the key to accomplishing this objective. They may change their expectations and requirements during the process of the project, i.e., they are a highly insecure and volatile factor. Anyway, it is absolutely necessary for project success to get the stakeholders appreciate the project. Otherwise they could cancel it before completion or let it be finalised, but never use the product^[53].

But also if the project may seem to be successful as it meets all the criteria mentioned above, this is only a short-term view. It also has to be observed if the project creates the expected benefit to the company, which is often only shown after a longer period of time^[54]. If a company, for example, sets up a project for developing and implementing a new logistics concept, the benefit of it will not be obvious directly after the implementation of the new concept. If the project really pays off can only be assessed after a reasonable time went by after the application of the new concept.

Additionally, project success needs to be measured in terms of trade-offs made to other company areas in favour of the project^[55]. If the company has to assign all resources to the project to make it successful according to the aspects stated above, but the company’s daily business struggles due to a lack of resources, it is questionable if the project can be regarded as successful. The trade-offs have to be balanced to gain the highest benefit in all company areas.

A project also needs to be aligned with the company culture and strategy. The company culture comprises habits and merits that the employees follow and value. Performing a project contravening the culture is likely to cause people’s displeasure. If the project manager has to prescribe extra hours to be able to complete the project in time, the employees will refuse to accept or to work on the project. Working against the corporate strategy does also not contribute to corporate success. On the contrary, this project raises costs, but does not create benefit as the product is not applied as it does not fit to the corporate strategy. Using a product although it is not in line with the corporate strategy can impair the company’s reputation or confuse business processes and employees. Therefore, integrating the project in the company culture and strategy is obligatory for ensuring a smooth process of the project and a continuation of the business at the same time^[56].

Moreover, a project can only be considered successful if it is performed according to laws and regulations, irrespective whether they are governmental, institutional or company-made. A project manager trespassing against health or environmental regulations will at least have to pay a fine, but could also be confined to prison. Additionally, the company could be inflicted a punishment, which could cause extra costs and a loss of reputation.

illustration not visible in this excerpt

Figure 4: The Elements of Project Success^[57]

Figure 4 illustrates which components make a project successful, summarising the findings of the preceding paragraphs. A really successful project fits all of the criteria stated in figure 4. Anyway, sometimes projects are also regarded as successful although they accomplish only some of these objectives. This perspective depends on the project principle’s definition of project success, which may be less strict than what this paper stipulates. It can be concluded that project success comprises the short-term and long-term appreciation of all parties directly or indirectly impacted by the process and outcome of the project.

6. Standards in Project Management

6.1. Why Project Management Needs Standards

A standard serves as a guideline for a repeated course of action. This publication is compiled in collaboration of experts to ensure that common demands are met in a consistent quality and at a reasonable effort^[58]. Standards provide for a consistent terminology and for a common understanding of processes and procedures. That way, they ease communication and facilitate a higher quality of the product and processes. Additionally, projects and everything related, for example schedules, budgets and lessons learned, can be easily compared and reused. This enables saving time and costs. Moreover, standards give the project manager more backing as she/he can orient herself/himself by this guideline and can refer to it in case somebody questions her/his approach. Standards can also provide for a competitive advantage, because customers are likely to assign their project orders to companies that work according to a standard as this suggests that the project is conducted in a high quality and that the product meets the defined specification^[59].

On the other hand, the advantages stated above may take some time until they are perceived. This is mainly because newly implemented standards are often not accepted nor fully utilised by the people involved in project management. But also people accepting a project management standard from the beginning need some time to get used to it and to become an expert. Additionally, standards are constituted in a way to cover most of ever existing projects. To gain the full benefit of standards, the applying company needs to adjust the standard in a way to make it fit the company’s special requirements. On the other hand, the adjustment must not be that extensive that it removes the benefits a standard can provide^[60].

It can be concluded that the advantages of project management standards outweigh the disadvantages. Especially the larger a project is, i.e., the more people and processes are involved, the higher is the need for a standard in project management^[61].

Up to now, a variety of project management standards have been developed. Figure 5 shows which standards are mostly used according to 449 respondents worldwide, whereas multiple answers are allowed if more than one standard is used.

Abbildung in dieser Leseprobe nicht enthalten

Figure 5: Usage of Project Management Standards^[62]

The most important standards are the Project Management Body of Knowledge (PMBOK), the International Competency Baseline (ICB) and Projects IN Controlled Environments 2 (PRINCE2). All other standards are more or less based on these standards or are not yet in wide use, as they are specific to an industry or to a company^[63]. This is why only these three standards are examined in the next chapters.

6.2. Project Management Body of Knowledge (PMBOK)

6.2.1. Origin of PMBOK

The PMI was established in 1969 with the purpose to identify and document common methods for managing projects. PMI’s focus is on three areas: standards, accreditation and certification and ethics. Its work on the standards section was documented and published first time in 1987 as the PMBOK. Since then, the PMBOK has regularly been updated based on suggestions for improvement from PMI members and other professional organisations and individuals^[64]. PMI also executes accreditations for project management degree programmes^[65] and offers a certification programme with six credentials that can be achieved^[66]. Besides, all PMI members have to sign the PMI Code of Ethics and Professional Conduct, issued to assure that project management is considered a trustworthy profession^[67].

6.2.2. Concept of PMBOK

The PMBOK is a process-oriented compendium of project management knowledge. For each process, it defines inputs, tools and techniques and outputs. The processes are clustered into five process groups that can be found in each project and project phase: initiating, planning, executing, controlling and closing^[68]. Additional to that, the PMBOK defines nine knowledge areas in which the processes are grouped^[69]. Although the processes are interdependent and may overlap during a project or project phase, each process can be assigned to a process group and a knowledge area, as figure 6 demonstrates. Even though this mapping seems to be prescriptive, the PMBOK emphasises to serve as a guideline, i.e., the processes need to be adapted to the company and project specific context^[70]. The PMBOK also provides a short section on the project management environment, including the project lifecycle, key management skills and internal and external influences^[71].

illustration not visible in this excerpt

Figure 6: PMBOK Processes Mapped to Knowledge Areas and Process Groups^[72]

6.3. International Competency Baseline (ICB)

6.3.1. Origin of ICB

The ICB is issued by the IPMA. The IPMA was the first project management association established^[73]. It was founded in 1965 and is situated in the Netherlands. The IPMA works as an umbrella organisation for more than 50 national member associations^[74]. The first ICB was issued in 1999^[75]. The IPMA updates the ICB every few years based on their own expertise and recommendations of practitioners. The member associations adapt the ICB to National Competency Baselines to make them better suit the local requirements^[76]. The IPMA also offers a four level certification system that is based on the ICB^[77].

6.3.2. Concept of ICB

The ICB does not define processes for project management, but serves as a guideline for necessary project management competences^[78]. These competences and their components are displayed in figure 7. The ICB defines which contextual, behavioural and technical competences a project manager needs to have to perform project management in a satisfactory way. It also presents basic information on carrying out project management, such as terms, functions and methods, as well as expert knowledge^[79].

illustration not visible in this excerpt

Figure 7: ICB Competences^[80]

6.4. PRojects IN Controlled Environments 2 (PRINCE2)

6.4.1. Origin of PRINCE2

PRINCE was originally designed for the United Kingdom government’s IT projects. Since its launch in 1989, it has been used by both private and commercial companies and has been applied not only for IT projects^[81]. In 1996, PRINCE was renamed PRINCE2 after a revision supported by 150 organisations. Certification to a PRINCE2 Practitioner can be obtained by having passed the PRINCE2 Foundation and then the PRINCE2 Practitioner examination. PRINCE2 is non-proprietary, but copyright is owned by the Crown^[82].

6.4.2. Concept of PRINCE2

PRINCE2 provides a structured methodology for managing projects throughout the entire project lifecycle. Detailed descriptions of processes, methods and roles, combined with examples and templates allow for an easy application and adaptation to company and project specific requirements^[83]. Figure 8 illustrates the structure of PRINCE2.

illustration not visible in this excerpt

Figure 8: PRINCE2 Structure^[84]

The paper includes a set of principles, themes and processes, which need to be adapted to the project environment. The PRINCE2 principles describe an overall policy that is obligatory for executing projects. These principles include aspects like ensuring that the project has a continued business justification or like roles and responsibilities need to be clearly defined. The PRINCE2 themes explain how the processes shall be carried out and comprise items like plans, organisation and quality. They need to be considered and directed throughout the whole project. PRINCE2 also comprises a process model defining which activities need to be conducted in which stage of the project. The project environment provides a framework for the project and determines how principles, themes and processes need to be customised^[85].

6.5. Comparing the Standards

It can be concluded that the three approaches to project management have similarities. All standards rank among the most used standards and are applied worldwide. Besides, the three editors issue and publish guidelines to their standards and update those regularly based on the latest expert knowledge. Additionally, certifications are offered that are based on the three standards.

On the other hand, the three standards deviate from each other in important issues as summarised in figure 9.

illustration not visible in this excerpt

Figure 9: Differences between PMBOK, ICB and PRINCE2^[86]

The oldest of these project management standards is the PMBOK. It is also the standard most frequently used. While the PMBOK and the ICB provide a comprehensive collection of project management knowledge, PRINCE2 presents a precise instruction of how to perform project management. To facilitate this, it focusses on project management processes. The PMBOK follows the same approach, while the ICB emphasises the skills and knowledge a project manager needs to have. Both the PMBOK and the ICB are quite generic, i.e., the processes or competences named can be adapted or omitted to better suit the company and the project. In contrast to that, PRINCE2 prescribes which action has to be taken by whom and when. Only slight adaptations are allowed as per PRINCE2. Moreover, the ICB attaches great importance to social skills. The PMBOK dedicates only a small part of its scope to social skills, while they are not covered by PRINCE2.

6.6. Standard Used for Further Investigation

Chapter 6.1 explains why common terms and understanding are obligatory to perform project management appropriately. Anyway, as demonstrated in the chapters above, even the most applied standards vary significantly. For getting a closer look into project planning, it is therefore necessary to decide on one standard. The decision for or against a standard depends on its acceptance and spread among project managers, its adaptability, how well it meets present and future challenges in project management and to which extent it supports project success.

The PMBOK is the mostly applied standard. As it was the first published standard, it is well-known and could be revised by expert knowledge more often than the other two standards.

It is also ahead of the game in terms of adaptability. On the one hand, it is focused on processes, which makes it easy to follow and to apply. On the other hand, it is more descriptive than prescriptive, so that it can easily be adapted to the actual requirements of the company or project. PRINCE2 is also process-oriented, but is very inflexible as every step in this manual has to be taken. The ICB is more generic, but is oriented to competences instead of providing a manual on project management. Hence, it allows space for adaptation, but is also time-consuming. A standard that is too fixed is not applicable in an environment that needs flexible solutions to problems. Should the standard be too generic and does not give any guidance to how to do project management, people take far too long to become experts in this standard and waste too much time on learning, which is nowadays crucial as projects often do not allow for delays.

Social skills are mandatory in times of larger and increasingly international projects. Otherwise, coping with so many different characters and cultures is difficult. The ICB puts a strong emphasis on social skills, while the PMBOK only mentions their importance and PRINCE2 completely misses this part.

Project success is enhanced by clear instructions. That way, actions can be taken faster and decisions can be made with less pressure. So, time and cost can both be reduced, while quality can be increased. Same applies for the increasing size and internationality of projects. A common understanding of processes is necessary to reduce complexity. As the ICB does not provide a manual, it lags behind PRINCE2 and the PMBOK in that aspect. PRINCE2 comprises instructions, but only mentions techniques to follow them. The PMBOK provides a guideline and also explains the techniques necessary to practise the project management steps.

Taking into account all aspects illustrated above, the PMBOK serves this paper best for a further investigation of project planning and its impact on project success. It is therefore taken as a basis for all following sections of this paper.

C. Project Planning According to PMBOK

7. Definitions of Project Management Terms According to PMBOK

General definitions of the project management terms are given in chapter 5. The following chapters focus on the definitions that the PMBOK provides. In case of identical information with those stated in chapter 5., this information is only mentioned, but not specified. Only those aspects are elaborated herein that differ from the general definitions in chapter 5. All subsequent chapters are based on the definitions of chapter 7.

7.1. Definition of Project According to PMBOK

The PMBOK’s definition of a project is similar to the definition given in chapter 5.1., i.e., a project is temporary, unique, needs to achieve certain objectives with limited resources available and requires an own organisational structure. It involves and is performed by people. Its purpose is to implement the company’s business strategy by creating an appropriate product or service. Projects are also characterised by uncertainty, which is implied by the uniqueness of projects^[87]. The temporary and unique characteristic of a project entail that it is the more elaborated the more steps in the project lifecycle have been taken^[88].

Projects can be part of a programme. A programme includes several projects. Those are managed and coordinated by one institution when the benefit of managing them that way is higher than by managing them separately^[89]. This is usually the case when the projects have the same overall aim and need to share resources.

To make projects more manageable, they can be split into smaller segments. This can be done in two ways. First, these segments can be made own projects, called subprojects. The management of these subprojects is usually done like with projects, but by another internal or external project manager^[90]. Second, projects can be segmented into phases. All phases taken together form the project lifecycle. As stated in chapter 5.1., each lifecycle is unique. What they have in common is that each phase has a starting and ending point, defined deliverables and a phase-end review. The following phase can only be started after a positive acknowledgement of the previous one. Only if the risk of the previous phase is acceptable, the next phase may start before the previous one is approved. The initial phase of the lifecycle is marked by low costs, low staffing, a low probability of project success due to high uncertainties and risk and a high stakeholder impact. In the intermediate phases, cost, staffing and the probability of success increase, whereas risk and stakeholder impact decline. In the final phase of the project, the cost and staffing level plummet. The probability of a successful project is the highest in this phase. The stakeholders have almost no impact on the project in the final phase, as the costs of changes would be too high^[91].

7.2. Definition of Project Management According to PMBOK

In contrast to the definition of project management in chapter 5.2., the PMBOK omits the project management institutional character, i.e., the PMBOK considers project management solely as a leadership concept:“Project management is the application of knowledge, skills, tool, and techniques to project activities to meet project requirements”^[92]. This work comprises all processes for initiating, planning, executing, controlling and closing the project.

As illustrated in figure 6^[93], the PMBOK assigns these process groups to nine knowledge areas. Each knowledge area comprises the processes that are required for the management of the issue they cover and describes inputs, tools and techniques and outputs for each of these processes. There are in total 39 processes. Although these processes are assigned to separate process groups and knowledge areas, they may overlap. Besides, they are interrelated not only within one phase, but also between different phases. This is due to the fact that a project is progressively elaborated^[94]. As the project management processes are interdependent, the project management work has an iterative character. If the controlling processes, for example, reveal a constraint that hinders the phase from being closed, the planning has to be readjusted to fit the new situation. This in turn could make a redo of the executing processes necessary, which then are controlled again. This circle has to be run through until the phase can be closed. Moreover, the output of the closed phase usually is the input for the subsequent phase.

Just like the general definition of project management^[95], the PMBOK differentiates between three organisational structures: the functional, the matrix and the projectised organisation. Additionally to the general description of these organisational structures, the PMBOK subdivides the matrix organisation into weak, balanced and strong. With the weak matrix organisation, the project manager has only little decision-making power. A low percentage of staff is assigned full-time to the project. The project manager also works part-time on projects. These factors increase with a balanced matrix and are the highest in the strong matrix organisation. The project manager is a full-time job, and she/he has moderate to high authority over 50 – 95 % of the company’s staff. Still, the project manager has less decision-making power than in a projectised organisation. A combination of these three organisational structures throughout companies is also possible, which is called a composite organisation. This approach is usually used at different levels and for different kinds of projects^[96].

An appropriate project management demands a range of management skills. These comprise leading, communicating negotiating and problem solving skills as well as the ability to influence the organisation^[97].

7.3. Definition of Project Planning According to PMBOK

As shown in figure 6^[98], project planning is a major part of project management according to PMBOK. In contrast to the other process groups, planning processes can be found in each knowledge area. These 21 processes are described in more detail in chapter 8.

The planning processes can be divided into core and facilitating processes. The core processes need to be done in a logical order. For example, it is impossible to do an appropriate cost estimating without having performed an activity definition, an activity duration estimating and a resource planning. The core processes comprise all planning processes in the knowledge areas project integration management, project scope management, project time management and project cost management as well as the risk management planning process. The facilitating processes do not follow a specific sequence. When they can be performed is project specific. They can be executed with intermittence and whenever the project progress calls for them and allows space for them. The facilitating processes include all planning processes in project quality management, project human resource management, project communications management and project procurement management. Additionally, the risk identification process, the qualitative and quantitative risk analysis processes and the risk response planning process belong to the facilitating processes^[99]. The PMBOK emphasises that although some processes need to be performed in a certain order, planning itself is iterative. Due to the high interdependencies between the project management process groups, the planning processes need to be reviewed and revised in each project phase and throughout the entire project. And the more elaborate the project becomes, the higher is the need for more detailed project plans (rolling wave planning)^[100].

7.4. Definition of Project Success According to PMBOK

Stakeholders are considered to be an important factor for project success^[101]. Also the need for integrating the project activities with the operational business is mentioned. Besides, the PMBOK states that the integration of product and project scope is crucial for a successful project^[102]. Meeting quantifiable objectives is vital for project success. These are at least cost, schedule and quality objectives, but this list can also be extended by adding other objectives^[103]. Although the PMBOK offers an extensive glossary and mentions the words success and successful in several paragraphs, the compendium does not provide a definition of project success. Moreover, only mentioning but not specifying possible contributors to project success is not sufficient for a further analysis of this issue. Besides, the named factors for project success are not regarded as comprehensive. That is why the definition of project success in chapter 5.4. is taken for further reference.

8. PMBOK Knowledge Areas and Planning Processes

This chapter describes only the PMBOK planning processes. Figure 10 shows an overview about all PMBOK planning processes and illustrates which knowledge areas they are mapped to. The arrows between the sections define in which order they are dealt with in this paper.

illustration not visible in this excerpt

Figure 10: PMBOK Planning Processes^[104]

8.1. Project Integration Management: Project Plan Development

The purpose of project integration management is to coordinate all elements of the project. Project integration management plays a role each time decisions must be made or actions must be taken that depend on at least two different processes^[105]. This knowledge area can be considered an umbrella knowledge area.

The project plan development aims at creating a project plan that summarises the findings of all other planning processes, while not only documenting them, but also integrating them to make the whole project coherent. Additionally, this document adds assumptions and constraints to the project that need to be considered in project planning. It also considers historical information and organisational policies that affect project planning. As the different planning processes may be performed by different people, this document ensures that the planning information is available for everybody and that the decisions and actions are aligned with the other planning processes. The project plan needs to be revised several times throughout the project. As the project is progressively elaborated, the project plan has to be further detailed as well. And each time changes are made to other plans, these changes have to be included in the new version of the project plan. The project plan, as all subsidiary plans, needs to be approved to become valid. The project plan may be accompanied by supporting details, which are not part of the actual project plan^[106].

[...]

---

^[1] Cf. chapter 5.1.

^[2] Cf. The Standish Group (2009), p. 1.

^[3] Cf. Westland, J. (2006), p. 2.

^[4] Cf. Düsterwald, R. et al (2008), p. 2.

^[5] Cf. Lennertz, D. (2006), p. 973.

^[6] Cf. Düsterwald, R. et al. (2008), p. 2

^[7] Cf. Haughey, D. (2010): http://www.projectsmart.co.uk/brief-history-of-project-management.html, retrieval on 21/10/2011.

^[8] Cf. Meyer, C (n.d.): http://www.projectsmart.co.uk/how-project-management-developed.html, retrieval on 21/10/2011.

^[9] Cf. chapter 8.3.4.

^[10] Cf. chapter 8.3.2.

^[11] Cf. chapter 8.2.2.

^[12] Cf. chapter 8.3.4.

^[13] Cf. Azzopardi, S. (n.d.): http://www.projectsmart.co.uk/evolution-of-project-management.html, retriev- al on 21/10/2011.

^[14] Cf. Haughey, D. (2010): http://www.projectsmart.co.uk/brief-history-of-project-management.html, retrieval on 21/10/2011.

^[15] Cf. Project Management Institute (2000), p. 3.

^[16] Cf. Zimmermann, J. et al. (2010), p. 2.

^[17] Cf. Kuster, J. et al. (2011), p. 4.

^[18] Cf. Wegmann, C., Winklbauer, H. (2006), p. 31.

^[19] Cf. Westland, J. (2006), p. 2.

^[20] Cf. Burghardt, M. (2008), p. 22.

^[21] Cf. Zimmermann, J. et al. (2010), p. 2.

^[22] Cf. Melton, T. (2007), p. 7.

^[23] Cf. Heldman, K. (2005), p. 18.

^[24] Cf. Kendrick, T. (2010), p. 143.

^[25] Cf. Wytrzens, H. K. (2010), p. 34.

^[26] Own figure: Based on: Kendrick, T. (2010), p. 143.

^[27] Cf. Führer, A., Züger, R.-M. (2010), p. 10.

^[28] Cf. Rinza, P. (1998), p. 5.

^[29] Cf. Rinza, P. (1998), p.p. 3 - 5.

^[30] Cf. Wegmann, C., Winklbauer, H. (2006), p. 36.

^[31] Cf. Lewis, J. P. (2005), p.p. 7 – 9.

^[32] Cf. Schulte, K., Littkemann, J. (2006), p. 578.

^[33] Cf. Burghardt, M. (2008), p. 15.

^[34] Cf. Wegmann, C., Winkelbauer, H. (2006), p.35.

^[35] Cf. New York State (2003), p. 3.

^[36] Cf. Schwalbe, K. (2009), p.p. 79 – 80.

^[37] Cf. New York State (2003), p. 3.

^[38] Own figure: Based on findings of chapter 5.2.

^[39] Cf. Kuster, J. et al. (2011), p. 10.

^[40] Cf. Burghardt, M. (2008), p. 95.

^[41] Cf. Kuster, J. et al. (2011), p. 106.

^[42] Cf. Kuster, J. et al. (2011), p.p. 106 – 107.

^[43] Cf. Jenny, B. (2009), p.p. 64 – 65.

^[44] Cf. Gido, J., Clements, J. P. (2011), p. 437.

^[45] Cf. Burghardt, M. (2008), p.p. 99 – 100.

^[46] Cf. Haugan, G. T. (2002), p.p. 4 – 5.

^[47] Cf. Carmichael, D. G. (2006), p. 8.

^[48] Own figure: Adapted from: Burghardt, M. (2008), p.p. 17 – 18.

^[49] Cf. Burghardt, M. (2008), p.p. 17 – 18.

^[50] Cf. Morris, R. A., McWhorter Sember, B. (2008), p.p. 65 – 66.

^[51] Cf. Bittner, K., Spence, I. (2006), p.p. 79 – 81.

^[52] Cf. Tuman, J., Eng, P. (2011), p.p. 183 – 184.

^[53] Cf. Bittner, K., Spence, I. (2006), p. 81.

^[54] Cf. Haughey, D. (n.d.): http://www.projectsmart.co.uk/four-levels-of-project-success.html, retrieval on 20/11/2011.

^[55] Cf. Haughey, D. (n.d.): http://www.projectsmart.co.uk/four-levels-of-project-success.html, retrieval on 20/11/2011.

^[56] Cf. Harvey, A. L. (2002), p. 46.

^[57] Own figure: Based on findings of chapter 5.4.

^[58] Cf. British Standards Institution (n.d.): http://www.bsigroup.com/en/Standards-and-Publications/About- standards/What-is-a-standard/, retrieval on 24/10/2011.

^[59] Cf. Theiler, J. (2010): http://www.projektmagazin.de/artikel/wie-nuetzlich-sind-pm-standards- tatsaechlich, retrieval on 24/10/2011.

^[60] Cf. Theiler, J. (2010): http://www.projektmagazin.de/artikel/wie-nuetzlich-sind-pm-standards- tatsaechlich, retrieval on 24/10/2011.

^[61] Cf. Stadler, R. (2006): http://www.computerwoche.de/580645, retrieval on 24/10/2011.

^[62] Own figure: Adapted from: Strascheg Institute for Innovation and Entrepreneurship (2010), p. 47.

^[63] Cf. Strascheg Institute for Innovation and Entrepreneurship (2010), p. 47.

^[64] Cf. Project Management Institute (2000), p.p. 167 – 174.

^[65] Cf. Project Management Institute (2010), p. 1.

^[66] Cf. Project Management Institute (2011), p. 1.

^[67] Cf. Project Management Institute (n.d.): http://www.pmi.org/About-Us/Ethics/Code-of-Ethics.aspx, retrieval on 02/11/2011.

^[68] Cf. Project Management Institute (2000), p. 30.

^[69] Cf. Project Management Institute (2000), p. 7.

^[70] Cf. Project Management Institute (2000), p. 37.

^[71] Cf. Project Management Institute (2000), p.p. 11 – 27.

^[72] Own figure: Adapted from: Project Management Institute (2000), p. 38.

^[73] Cf. chapter 4.

^[74] Cf. GPM (n.d.): http://www.gpm-ipma.de/ueber_uns/ipma.html, retrieval on 26/10/2011.

^[75] Cf. IPMA (2006), p. VI.

^[76] Cf. IPMA (2006), p. 4.

^[77] Cf. IPMA (n.d.): http://www.ipma.ch/certification/standards/Pages/default.aspx, retrieval on 26/10/2011.

^[78] Cf. IPMA (n.d.): http://www.ipma.ch/about/faq/Pages/default.aspx, retrieval on 26/10/2011.

^[79] Cf. IPMA (n.d.): http://www.ipma.ch/certification/standards/Pages/default.aspx, retrieval on 26/10/2011.

^[80] Own figure: Adapted from: IPMA (2006), p. II.

^[81] Cf. Best Management Practice (n.d.): http://www.best-management-practice.com/Knowledge- Centre/Best-Practice-Guidance/PRINCE2/, retrieval on 28/10/2011.

^[82] Cf. ILX Group (n.d.): http://www.prince2.com/what-is-prince2.asp#prince2-history, retrieval on 28/10/2011.

^[83] Cf. Eilhardt, S. (2008): http://www.projektmagazin.de/artikel/das-neue-prince2-%E2%80%93-mit- sieben-prinzipien-projekte-managen, retrieval on 30/10/2011.

^[84] Own figure: Adapted from: Murray, A (2011): http://www.best-management-practice.com/gempdf/ PRINCE2_in_One_Thousand_Words.pdf, retrieval on 29/10/2011.

^[85] Cf. Murray, A (2011): http://www.best-management-practice.com/ gempdf/PRINCE2_in_One_ Thousand_Words.pdf, retrieval on 29/10/2011.

^[86] Own figure: Based on findings of chapters 6.1. – 6.4.2.

^[87] Cf. Project Management Institute (2000), p. 11.

^[88] Cf. Project Management Institute (2000), p. 4 – 6.

^[89] Cf. Project Management Institute (2000), p. 10.

^[90] Cf. Project Management Institute (2000), p. 10.

^[91] Cf. Project Management Institute (2000), p.p. 11 – 13.

^[92] Project Management Institute (2000), p. 6.

^[93] Cf. chapter 6.2.2.

^[94] Cf. Project Management Institute (2000), p.p. 29 – 38.

^[95] Cf. chapter 5.2.

^[96] Cf. Project Management Institute (2000), p.p. 18 – 23.

^[97] Cf. Project Management Institute (2000), p.p. 21 – 26.

^[98] Cf. chapter 6.2.2.

^[99] Cf. Project Management Institute (2000), p.p. 33 – 35.

^[100] Cf. Project Management Institute (2000), p.p. 32 – 33.

^[101] Cf. Project Management Institute (2000), p. 16; ibid., p. 32; ibid., p. 119.

^[102] Cf. Project Management Institute (2000), p. 41.

^[103] Cf. Project Management Institute (2000), p. 56.

^[104] Own figure: Based on: Project Management Institute (2000), p. 38.

^[105] Cf. Project Management Institute (2000), p.p. 41 – 42.

^[106] Cf. Project Management Institute (2000), p.p. 42 – 45.