Benefits of recent Project Management Methods and Tools

Index

Abstract

Abbreviations and Definitions:

Table of Figures

1 Introduction
1.1 The Situation
1.2 Scope
1.3 Procedure of this Work

2 Relevant Issues in Project Management
2.1 Organization of Projects
2.1.1 Organization Structure and Size
2.1.2 Informal factors of an Organization and team building
2.1.3 Frustration
2.1.4 Optimal team size and communication
2.2 Project Planning: Methods of Scheduling Projects and Resources
2.2.1 Types of Project Planning
2.2.2 Project structure and schedule planning methods
2.2.3 Resource allocation methods
2.3 Project Execution / Steering Methods and Tools
2.3.1 Problem solving procedure / Customer Change Request Procedure
2.3.2 Project Team Coordination / Groupware tools
2.4 Methods of Project Controlling
2.4.1 Evaluating Project Progress (deadlines, costs and subject progress)
2.4.2 Project Risk Assessment (risk)
2.4.3 Productivity Measurement (time)
2.4.4 Performance Measurement (quality)

3 Implementation of Planning Processes into IT tools

4 Previous empirical research on the benefits of methods and tools
4.1 Project Portfolio Management
4.1.1 Findings of Cooper, R.G.; Edgett, S.J.;Kleinschmidt, E.J. (2001)
4.1.2 Findings of Cooke-Davies, Terry (2002)
4.2 Best Practices for Project Management
4.2.1 Findings of Elonen, Suvi; Artto, Karlos, A. (2003)
4.2.2 Findings of an analysis in Balderstone, S. J.; Mabin, V. J. (1998)
4.2.3 Findings of Diallo, Amadou; Thuillier, Denis (2004)
4.2.4 Findings of Matheson, D.; Matheson, J. (1998)
4.2.5 Findings of Sanchez, A. M.; Perez, M. P. (2004)
4.2.6 Findings of Shenhar et al. (2002)
4.2.7 Findings of Ojanen, Ville (2003)
4.3 Project Management IT tools
4.3.1 Findings of Kalthoff, C.; Kunz, S. (2004)
4.3.2 Findings of Projektron Ltd
4.3.3 Findings of Ahlborn, Jan (2003)

5 A Study on desired functionality in Project Management IT tools
5.1 Goal and Procedure of the Survey
5.1.1 Goal of the Survey
5.1.2 Design of the survey
5.1.3 Searching for and selecting suitable participants
5.2 Survey Research Implications
5.2.1 Qualitative Analysis
5.2.2 Quantitative Analysis

6 Summary and Conclusions

References

Appendix A: Management Feedback Survey

Appendix B: Cover letters of the survey

Appendix C: Survey Data Base Statistics

Appendix D: Survey Response Statistics
Response statistics general items
Response statistics IT tools importance/ realization items (excl. outliers)
Best Practices of IT tool based Project Management:
Correlations and Factor Analysis of Reasons for project’s failure:
Independent Sample t-Test on perceived Importance of IT tools by
respondents grouped by aggregated project success of projects
Independent Sample t-Test on Realization of IT tools by
respondents grouped by aggregated project success
Data reduction of realization perception of different IT tool features:

Appendix E: Criticisms of and hints for IT tools stated by participants

Appendix F: Zusammenfassung in deutscher Sprache

Eidesstattliche Erklärung

Abstract

A wide range of tools to support various aspects of project management are available and are being constantly improved. This research examines recently introduced methods and tools which are applied to Single and Multi-Project Management and reviews the benefits they can bring to project success and on-time performance.

The work goes on to analyse whether these methods are supported by or potentially implantable into IT tools and what further benefits can be gained from software support. A survey of international industrial companies was designed and carried out to determine the requirements, benefits and criticisms of IT-based project planning as reported by people in positions ranging from project engineers to top managers. The data collected were evaluated qualitatively and quantitatively to determine the benefits arising from the application of IT tools and the limitations of the currently available software. Finally, proposals are made for the future development of these tools.

Abbreviations and Definitions:

Abbildung in dieser Leseprobe nicht enthalten^{[1][2][3][4][5][6]}

Table of Figures

Figure 2.1: M-Model, Ahlemann, Frederik; Hoppe, Uwe [Ed.] (2003)

Figure 2.2: Overlap of Project Process Groups in a Phase

Figure 2.3: : metrics proposed in literature for the evaluation of R&D projects and portfolios

Figure 2.4: Optimal team size according to Brooks’ theoretic formula

Figure 2.5: Comparision of some resource allocation methods in a simulation

Figure 2.6: Projects’ planned/actual working hour conformity visualization over quarters

Figure 2.7: Project Buffer Graph

Figure 2.8: An outline structure of risk management methods

Figure 2.9: dynamics of typical projects: productivity over projects time (left)

Figure 2.10:estimated project progress in software projects at Siemens S.A. (right)

Figure 2.11: Performance Criteria in Product Development Project

Figure 2.12: Common and company specific problems in R&D performance measurement

Figure 3.1: Concept of Project Management Systems

Figure 3.2: Comparison of some PM Systems

Figure 4.1: How Managers see the Importance of Portfolio Management - Best vs. Worst

Figure 4.2: The Dominant Portfolio Method Employed - Best vs. Worst

Figure 4.3: Prioritised graph of preliminary problem areas

Figure 4.4: Top 10 best practices of R&D performance

Figure 4.5: Lowest 10 of R&D best practices (worst practices)

Figure 4.6: Best Practices of Project Management

Figure 4.7: Top 5 of core best practices

Figure 4.8: Importance of planning and control methods

Figure 4.9: Most important factors of internal effectiveness

Figure 4.10: Most important factors of external effectiveness

Figure 4.11: Project Management Software applied for Project Management

Figure 4.12: Intended extended application of Project Management Systems

Figure 4.13: Desired functionality in Project Management Software

Figure 4.14: Efficiency and cost benefits resulting from IT tool supported planning

Figure 5.1: TOP 10 IT tool realization (differences better vs. worse performing projects)

Figure 5.2: TOP 10 IT functionality importance (better vs. worse performing projects)

Figure 0.1: Ranking of best practices according to importance of related IT tool features Benefits of Project Planning Methods and Tools

1 Introduction

1.1 The Situation

All branches are facing rougher economic environments with increasing competition, increasing market concentration and fragility which is shortening product lifecycles while putting strong requirements to costs and quality. Coincidently less customer and supplier loyalty were forcing industry and science to increase productivity in all branches and business units^[7]. In order to increase productivity, theories were heading production costs; trying to optimize production flow, lower throughput time and product buffers.

Pressure to perform came also up for project management and the costs coming up from failing projects and lack of efficiency were embattled (every year 75 Billion US Dollar have been spent on failing projects only in the IT-Sector^[8]). New methods and tools were necessary to face inefficiency in projects caused by little pressure to perform, bad planning and unpredicted upcoming resource bottlenecks. As in production, these theories applied critical path, buffer and throughput time planning which guaranteed project schedule optimization.

Furthermore, in the early nineties^[9], new, department overlapping project organization structures were introduced and Project Managers were increasingly managing multiple projects at a time. This made project schedule planning very complex and prediction of resource bottlenecks without aids nearly impossible.

Therefore some scientists suggested application of IT tool supported detailed project planning and controlling, while others, managers in industry were still widely thinking like Dwight Eisenhower once said: "Plans are nothing, planning is everything”^[10].

1.2 Scope

This thesis summarizes and analyses, which principal methods and tools for Single and Multi-Project Management are applicable in IT tools for Project Management and which benefits can arise through application of those.

By performing an industry wide empirical survey on Project Managers, importance and actual realization of functionality in IT tools that can influence success factors of project management will be revealed; and the actual benefits of detailed, IT based project planning regarding industry's needs will be found. Finally, it will be tested whether the degree of application of IT tools has a positive influence on the given project success rate underneath the respondents of the survey.

1.3 Procedure of this Work

This work is basically divided into four parts:

In the first part (Chapter 2) key strategies, methods and tools of project management will be summarized and checked upon their potential use in IT tools.

In the second part (Chapter 3), the author will check how professional Planning Tool Provider implemented the Project Management methods into their systems, and what items still have to be improved.

In the third part (Chapter 4), relevant studies on key issues in project management will be summarized and their findings prepared for survey creation.

The final fourth part (Chapter 5) is related to the creation and execution of a primary empirical study that verifies project manager's tacit knowledge of project management and their perception of IT tool importance and realization. The survey’s outcome will be interpreted qualitatively and quantitatively.

2 Relevant Issues in Project Management

In order to be able to understand and to judge whether methods and tools are important for project management, it is important to define the principal terms and to know the levels and the structure of project management.

A Project can be defined (according to DIN 69901) as a one time event of certain duration, with a defined goal, having a complex structure with its own, specific and separate organization.

A framework describing all project related activities in companies is the M-Model introduced by Prof. Hoppe of the University of Osnabrück (compare Figure 2.1 below). Abbildung in dieser Leseprobe nicht enthalten

Figure 2.1: M-Model, Ahlemann, Frederik; Hoppe, Uwe [Ed.] (2003)

The M-Model consists of three levels of hierarchy: the Management Board, the Project office & Steering committee and Project Manager.

The upper third of the M-Model’s tasks are related to Portfolio Management. Portfolios include all projects and programs of strategic business units and are built up in order to reduce the complexity of the Management Board’s activities. The Management Board is supposed to drive a strategic portfolio planning and controlling by financial or resource constraints^[11].

Program Management’s primary planning object is coordination of the project program, a set of interrelated projects at the level of a department or a similar organizational unit at the middle level. Program management is done by Project Office and/or a Steering Committee

Project Management is related to the operational planning and execution activities of a project; primary goal is to ensure that the project meets the requirements during initiating, planning, executing, controlling, and closing phases (compare below Figure 2.2).

In the initiation phase, project ideas are generated, collected, captured, examined and their feasibility, profitability and strategic impact are analyzed for a go/no-go decision of the management. Planning, executing and controlling processes are described in chapters 2.2, 2.3, and 2.4. In the closing process a project, results are analysed, the enterprise closes the project and tries to learn from the experiences made. Initiation and closing processes can be supported by stand alone IT tools.

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.2: Overlap of Project Process Groups in a Phase^[12]

As project manger’s job is to ensure that the project meets the requirements; he has to have the following skills: knowledge, comprehension, application, analysis, synthesis, evaluation; and the following competencies^[13]: business achievement, problem-solving, influence abilities, people management and self management. Valle and Avella (2003) proved in an empirical study, that the quality of the project manager in the defined tasks correlates to internal efficiency as also to extern effectiveness of projects.

Multi-Project Management represents leverage of multiple, simultaneous projects at a comparable level to program management^[14][15]: solving conflicts of resources between projects, discovering redundancies and synergies, setting priorities, and using experience from past projects to apply to others. The differences between multi project management and program management are vague; a multi project manager’s tasks are more likely to be coordination and analysis – rather than leadership. He tends to have no responsibly over budget and personnel, in contrast to the program manager^[16].

Methods of Project Portfolio Planning and Controlling

The purpose of project portfolio planning is to evaluate the importance of each project within a company’s set of projects, with the goal of distributing financial and operational resources or to terminate projects with low importance or high risk. Industry experts estimate that project portfolio management efforts can provide businesses with a 30% return on investment within one year^[17]. The Gartner Group found the following benefits result from applied project portfolio management^[18]:

- Eliminating redundant projects and initiatives
- Improved resource allocation and utilization
- Improved financial visibility
- Better alignment of projects to corporate initiatives
- Improved project communication and documentation
- Establishing processes, methodologies and best practices
- A shared database for all project data
- Benefits are tied to costs through charge-backs.

A project’s importance (potential benefit) and performance evaluation can be realized by quantitative measures (“metrics”) of success as a guideline for financial and human resource distribution. The following metrics for external effectiveness and internal efficiency have been suggested by scientists within the last few decades (See below Figure 2.3 ).

IT-tools can greatly support financially based portfolio evaluation methods, but according to a study of Cooper and Kleinschmidt (2001), strategic methods appear to be the more successful ones (compare Figure 4.2: The Dominant Portfolio Method Employed - Best vs. Worst

on page 40).

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.3: metrics proposed in literature for the evaluation of R&D projects and portfolios^[19]

2.1 Organization of Projects

2.1.1 Organization Structure and Size

The “organization structure” of projects is dependant on the type of project and the organization. Different types of organizations require specific features, different complexity and different level of flexibility in IT-planning and controlling tools. The different kinds of organizational characteristics are briefly discussed below.

Most important rule in organization of projects is that collaborating people in dynamic environments of high uncertainty have to be able to act as peers to each other. This urges lateral organization structures. They enhance the collaboration, the intellectual challenge, the candid and transparent communication, and the willingness to take risks^[20].

This has to be taken into account in IT tools. They should offer a collaborative rather than a hierarchical environment and furthermore; some organizational structures as the influence and the matrix project organization demand functionality that solve the conflicts of competencies in the reporting lines. Change tracking & confirmation as also version control in IT tools can be counted on to be absolutely necessary for a correct plan update procedure considering both; interests of project managers and heads of departments.

2.1.2 Informal factors of an Organization and team building

Informal factors can be of very high importance concerning team performance and thus also for internal efficiency, especially in very innovative projects. Garber, Peter R. (1993) considers, that the most realistic measures for success of a team might be the “feeling of teamwork among each other”, “the pride they have in their team”, “the support of their ‘fans’/customers and their shared sense of accomplishment”, as these factors can significantly improve communication and motivation of the team (take note, that intensive application of IT tools can reduce these informal factors).

Motivation of the team and team building as a success factor of project management is a topic that has been frequently addressed especially in product development literature. Teams appear to create an environment that can enable and motivate individuals to engage in the creative process. Individual creativity can be enhanced through formal mechanisms like cross-functional teams , heavyweight product managers or established meetings. Tidd and Bodley (2002) coincidently found, that cross-functionality is of special importance in projects of high novelty, who desire more intense creativity than projects of low novelty. Clark and Takahiro (1991) state, that cross functional teams were especially important for product development in unstable markets having relatively short product life cycle times and intense competition. According to

Kellner (2002) the happiness of innovators can also improve creativity in projects, especially through its ability to enhance optimism and thus improve success of projects.

As mentioned, the performance increasing impact of cross functional teams arise from proximity of the team members of different qualification who enlighten each other and create a creative environment. Groupware tools and forums could probably have an enlightening effect in not project based organization forms like the matrix organization. However, lack of team spirit in groupware tools or other reductions of informal factors of organizations through Information Systems could harm the positive effects in other, project oriented organization types. IT tools could compensate the advantages of cross-functional teams or even diminish these positive effects.

2.1.3 Frustration

One further problem of Innovators / Engineers in R&D Projects is the frustration, not only in U.S.^[21] but also in German companies. “Engineers require more encouragement than other professionals because they work more often on virgin problems and must be given confidence that it is all right to work on some new approach and to make mistakes”. Mistakes are to be seen as a sign that an engineer is willing to take chances, be creative, and take innovative steps. This kind of motivation can only come through personal contact. Engineers can become frustrated because of 1 the role they play in the corporate culture, the lack of opportunity to advance, discouragement of networking and the lack of effective internal communication channels, lack of feedback from marketing and strategic manage­ment to engineers. As frustration is a cause of inefficiency and lack of productivity it has to be tackled.

Virtual collaboration in distributed teams and strong utilization of IT tools in project management could increase frustration because of lack of interpersonal exchange. Engineers could get isolated from important contacts to general management who are needed in order to advance. Thus, IT tools could enforce frustration and thus harm productivity. These are reasons for non-acceptance of IT tools and further ones are described by the interpersonal circumplex model (ICM)^[22] and the Technology Acceptance Model (TAM)^[23].

2.1.4 Optimal team size and communication

Another factor of productivity in innovative organizations is the team size. The optimal Team size is dependent on the task break down possibilities of a project and the ability to perform simultaneous engineering that can be improved through IT systems. In general, team size should be set to 3 or 4 up to a maximum of 7 or 8 people^[24]. "Adding manpower to a late software project makes it later"^[25], “there is a maximum number of additional team members that can be added to reduce the development time”2, meaning that an increased number of team members progressively increases the time needed for communication between the team members progressively and thus can reduce project completion time. Also Bob Norton, an experienced Project Manager, believes, that a small group of “3 to 6 really good programmers can beat a team of 100 programmers at some corporate giant every single time”^[26]. Also Simmons thinks that team size should normally not exceed 8 people^[27].

Contrarily, Swink (2003) finds that “adding part-time workers and a greater diversity of technical experts on accelerated projects surpasses the supposed negative effects of added complexity”. He posits that the reason for this is that additional resources are employed more strategically on intentionally accelerated projects.

In a theoretical approach, Brooks developed a formula in 1975 which describes the time effort needed for communication within teams depending on team size. According to Brooks’ formula, the highest outcome a team can have is that of 5.76 single working people at a team size of 8 (HC=head count). A team of 8 people looses, theoretically, the work of 2.24 people in communication (compare below ).

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.4: Optimal team size according to Brooks’ theoretic formula

Although Brooks’ theoretic formula is coincident with the practical experience of managers and scientists, there are also criticisms to this formula , for example that not every item has to be communicated with others, i.e. group meetings and discussions within subgroups can improve the efficiency of communication within the whole team. Kedzierski (1984) developed a communication system in order to reduce the pair-wise inter-communication with a structured, formal way of communication. Each essential communication can be classified by: question, request, inform, grip and plan and used to mark upcoming items by “Q,R,I,G,P”^[28]. Such a communication form could ideally be implemented into an IT System in order to also record each member’s participation and upcoming problems and to enhance general performance of communication. This would reduce the percentage of time needed for communication and thus increase the team’s productivity and also the maximum number of team members for maximal output. With application of such enhanced communication technologies efficient teams of more then 8 members should be imaginable. Furthermore it is evident that structured computerized communication could enhance inter-cultural communication and documentation. Multicultural communication barriers are a major problem in international teams^[29] and could be solved by IT-communities.

A further important issue of this section is that irrelevant communication, communication problems and activities which are not project related have to be minimized within the team. Perhaps, IT tools can help in pursuing the planning process and facilitate evaluation and supervision of project progress and costs, but on the other hand they also require frequent administration and updating by each team member. It thus has to be questioned, whether the benefits of utilization outweigh these administrative costs.

2.2 Project Planning: Methods of Scheduling Projects and Resources

In project planning, the requirements for successful project termination are being estimated and evaluated. Project Planning starts by estimation and enumeration of all work packages included in a project (work breakdown structure) and ends up in the creation of a project schedule including due dates and a cost plan.

2.2.1 Types of Project Planning

Three different types of Project Planning can be categorized^[30]: Rough Order-of-Magnitude, Top-Down and Bottom-Up. Top-Down and Bottom-Up methods are widely supported by IT tools.

The Rough Order-of-Magnitude (ROM) is the quickest method available and is based on experience and some historical data. Mostly based on intuition it gives a snapshot of the project’s cost and schedule (-25 to +75% of project budget). Subjective estimation of costs is risky because:

1. Tough competition can drive optimism in cost estimates in order to get the project
2. The managers can overestimate their own performance capabilities
3. Managers may not have enough experience and knowledge about costing
4. Nice-to-have features may find too high consideration
5. Risks may be underestimated

The quick Top-Down method is based on comparisons with similar historical projects and applies parametric models in order to extrapolate data from one project to another. It is the most appropriate technique for top level planning and decision making. Offering accuracy to within -10% and +25% it is good enough for planning, but not adequate for a final estimate.

The Bottom-Up method is the most accurate one and based on lowest level of Work Breakdown Structure planning. The effort of each Work package is determined with the person who performs its tasks. The technique is used to update the estimates of the final project budget. It is very time consuming but on the other hand very accurate (-5% to +10% of project budget).

According to Diesel Engineering Management of Bosch Automotive Systems, Japan Bottom-Up planning has certain risks which can lead to lower accuracy than a top-down planning:

1. Managers have a very good implicit/tacit knowledge for the duration of major steps in projects derived from experience. Contrarily, the effort for single small work packages is not known exactly. An unrealistic effort estimation of a repeated single work package can lead to very inaccurate effort estimation.
2. The sum of duration of all work packages is not the time needed for a project. Time needed for communication and administration is neglected in the bottom-up method.
3. Work package completion times are effected by learning curves. A once estimated effort for a work package can be much lower when same work package is repeated.

2.2.2 Project structure and schedule planning methods

Project schedules are commonly planned on a basis of graphical work package planning or on network diagrams such as MPM (Metra-point-method), CPM (Critical Path Method), and PERT (Program Evaluation and Review Technique)^[31]. Especially the more and more frequent use of Visual Scheduling and Management Systems (VSMS) like MS Project, Scitor or Artemis enforces the graphical bar diagram based planning first introduced by Henry Gantt for Hoover Dam and Interstate highway construction planning^[32].

The Gantt Charts implemented in MS Project and the above named tools principally pursue an estimation of a project’s total duration based on the critical path in work breakdown structure and project progress tracking based on milestone achievement control. These methods are well described in a wide range of common project management literature like Pollalis (1993), Litke and Kunow (1995) and Lock (1987).

To find the first optimal sequence of work packages, methods of operational research can be employed: branch and bound, dynamic programming, and newer methods like Lagrangian Relaxation, and neural networks^[33]. Besides a design specification, a work breakdown structure that allows the maximum number of tasks to be developed in parallel while requiring minimal communication is the most effective way to reduce development time and thus project total duration^[34]. In order to simulate the dynamics of critical paths during project execution, Monte Carlo scheduling and materials requirements planning software has been developed.

-A different approach for project scheduling and controlling is the CriticalChain (CC) for single project management and Theory of Constraints (TOC) methodology for multi project management published by E. Goldratt^[35].

Based on this theory, multiple software packages have already been improved (i.e. Scitor Project Scheduler 8, Speed to Market's Concerto 2002, or ProChain Solutions Inc. 1999).

The principal methodology behind CC is a new concept for milestone achievement. Milestones are not planned on a 100% probability basis (or 80% as commonly done), which leads the project manager to create security buffers prior to each milestone of a project’s schedule. Instead, milestones are planned on a probability basis of 50% and delays are put into a project buffer at the end of the project^[36]. In order to ensure bottleneck availability for multi-project-planning, a capacity buffer is to be created for each bottleneck.

The motivation of team’s productivity through a buffer's fill ratio controlling instead of easy-to-achieve Milestones is supposed to greatly improve productivity.

2.2.3 Resource allocation methods

Resource allocation algorithms implemented in IT tools so far do often not offer optimal results automatically (compare below findings of Pisz et al. (2003) on page 17). Furthermore, resource allocation method and buffer based controlling suggested by Goldratt is not optimal neither^[37]. The following heuristics of resource allocation and criticisms to them can be found in the literature, and they are almost all derived from production planning:

No Control –the simplest method available. Push System based first come first served (FCFS) priority rules are randomly followed^[38].
CC – basic principle of CC is to focus on few key constraints^[39] if projects are scheduled according to CC methodology, resource allocation is performed by buffer management and follows the following constraints: critical chain activities have higher priorities than non-critical chain activities; activities with highest level of buffer utilization have priority.
EDD – (Earliest Due Date)^[40] ; takes into account the earliest due date and the maximum lateness of a work task for resource allocation. The work package with the earliest due date or with maximum tardiness is served. Application of EDD rule prevents embarrassment of very large lateness, but is poor with respect to average tardiness.
MinSLK - (Minimum Slack heuristic, also called Least Slack heuristic)^[41] ; is based on constant recalculation of the critical path and slack times after completion of a work package (whereby slacktime is defined as the difference between late start time and early start time. It can turn negative if the start time of a work package is later than the late start time that is needed in order to complete the project on its due-date.) Employing MinSLK, resources are always allocated to work packages having the lowest slack time.
ConPIP - (Constant Number of Projects In Process)^[42]. ConPIP regulates the starting date of new projects based on a predetermined number of projects to be in process. An arriving project starts its processing immediately if the number of projects concurrently in process within the system is below the defined number.
QSC - (Queue Size Control)^[43] In QSC a predetermined maximum number is given for simultaneously processed work packaged, within the resource queue of a bottleneck. A new project is processed if the length of the bottleneck's resource queue is below this maximum number; otherwise the arriving project is discarded.

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.5: Comparision of some resource allocation methods in a simulation^[44]

Cohen and Mandelbaum performed a simulation-based comparison of “QSC”, “CC” and “no control” methods for projects in the aircraft industry. In the simulation, buffer based CC resource allocation leads into lower throughput rates than the chosen QSC method for resource allocation (compare above Figure 2.5). They are thus criticizing the CC method and demonstrate that buffer management may not be enough to meet the planned schedule. Other methods and especially QSC turned out to lead to equal or better results than the buffer control suggested by Critical Chain theory.

-In a comparative study Pisz et al. (2003) reviewed resource allocation quality of MS PROJECT 2002, PROJECT SCHEDULER 6.0, Proalpha 1.4d, and ILOG OPL Studio 3.6. From their tests it appeared that except ILOG OPL Studio 3.6 these tools did not meet the requirements to solve the considered problem of resource and budgeting constraints automatically. They proved furthermore, that simple application of branch and bound method could have solved the problem. Also in internet forums the author found issues concerning resource restricted schedule creation. At http://www.schwab-projektmanagement.de/forum there was to be found a case where somebody stated that the by MS Project 2002 automatically generated schedule was not the best at all and that he had to create his schedule on his own.

2.3 Project Execution / Steering Methods and Tools

During execution phase of a project, there are some tools available that are supported and others to be supported by IT tools in future. This makes especially sense for organizations that do not yet employ these methods unless they could get introduced in a cheap and easy manner. If execution and steering processes are directly implemented into IT tools, these could also ease up quality certification (i.e. ISO900X)^[45] for those companies who do not have it yet.

2.3.1 Problem solving procedure / Customer Change Request Procedure

In order to guarantee an effective and efficient problem solving or change implementation process, organizations should ideally have a defined procedure for problem solving and change requests. This procedure could be implantable into an IT tool and provide useful functionality for documentation, project procedure tracking and for decision support.^[46][47]

2.3.1.1 Open Point List

Problems and change requests can be put into an “open-point-list”, which could also be named as a “to-do-list” including not finished work tasks. Normally the “open-point-list” includes identified, but not yet solved problems, change requests, open requests and identified risks documented with identification who requested the point, due dates, responsibilities, and a status report^[48][49]. Open Point list supported by IT Tools could be supported by decision support systems who allow quantification and further documentation of the problems and an automatic selection of most important task to perform.

2.3.1.2 Decision support system

The items included in the open point list can be evaluated by a decision support system which can simplify evaluation of the importance, the effort to solve the item, available resources and time and the influence on other problems (i.e. QRA, FMEA etc.). On the basis of such an evaluation, the subsequent work tasks can be chosen and defined into an updated project plan. Of course also other decisions could be supported by an IT tool.^[50]

2.3.1.3 Actualization of Plan

As consequence of upcoming problems or change requests, updating the project plan is a part of project execution and supports project controlling. Actualization of the project plan is standard for project planning IT tools and does not need an individual solution.^[51]

2.3.2 Project Team Coordination / Groupware tools

Further benefits are expectable through collaborative support of IT Tools. This concerns especially documentation and communication.

2.3.2.1 Reporting / Document management

The Documentations related to testing and inspection of items causes the most problems in projects. Furthermore problem solving and customer changes have to be documented and reports have to be made. A document control centre can be instrumental for documentation of those procedures as also for “fitness-for-purpose” certification and has potential to improve access control and distribution of information.^[52]

2.3.2.2 Computer Conferencing / Forums for Discussions

Computer Conferencing allows people to exchange electronic messages about a given topic. The main advantage towards email systems are, that conferencing systems can be simultaneous and that messages are presented organized by topic and structure (contrarily to emails who are directly sent to recipient). Computer Conferencing and Forums can effectively support pre and post meeting discussion and overcome intercultural barriers if they support communicative aids^[53][54]. Also, they can support a structured way of communication and communication rules, which can also improve efficiency^[55].

2.4 Methods of Project Controlling

Project Controlling is a separate task to project planning and is defined by DIN69904 Ch. 5.17 as “Processes and Rules within Project Management which contribute to the assurance and achievement of project’s goals”.

Burghardt (2002) counts the following tasks on to be project controlling related tasks: “due date control”, ”cost development control”, ”progress control”, “quality assurance”.

As markets become more and more turbulent, also secondary project goals like productivity and costs in projects become more and more important esp. in R&D. Under those circumstances, the author considers project controlling relevant activities to be: observing the project’s state and progress in terms of deadlines and costs, risks, internal efficiency (productivity), external effectiveness and external/internal integration (quality).

2.4.1 Evaluating Project Progress (deadlines, costs and subject progress)

Detailed project progress tracking can be counted on to be a major part in anticipation of project delays or failures.

For project progress tracking, supervision and analysis the Government Department of Defense as a pioneer created formulas who allow quantitative evaluations of projects’ costs development and schedule performance.

The following indices for project progress analysis (or Cost and Schedule Performance Indices) were suggested^[56]. Most of them are supported by IT tools, although IT tools mostly use different captions within Cost Schedule Control Modules^[57]:

BCWP (budgeted cost of work performed, Also called "Earned Value")

is the amount of work accomplished against the amount planned. BCWP = BCWS x % of work completed

BCWS (budgeted cost of work scheduled)

is the planned or estimated cost estimate of the task/project, respectively the cumulative budget of a project.

ACWP (actual cost of work performed)

is the cumulative costs actually expended during the project's life cycle.

Taylor, Pinto and Suhanic suggest visualization of project progress indices in charts. Performance measurement S curves have relative scales on the axis and visualize percentage of project slippage and cost development. Earned Value curves visualize actual development using absolute scaled axes and are thus easier to construe. In all, following charts for progress control were suggested: S curves, trend curves^[58], productivity curves, bar charts, and planning networks^[59].

In the author’s opinion, a simple actual and planned working hour based visualization is not reliable enough to approximate and control the project progress. Wrong allocation of work effort to not yet important work packages could result in the project being delayed even though it conforms to the planned working hours. The author suggests artificial intelligence supported visualization of planned/actual working hour conformity for multiple but essential tasks. Using data from Bosch Automotive Systems Airbag Engineering Department in Japan, 10 major work tasks of projects were analyzed according to planned/actual working hours’ conformity. The applied formula was a 50% arithmetic average of “the fifth power of correlation of the planned/actual accumulated working hours over the quarters” with “the %difference between grand total over working hours in the specific task over the quarters”:

ConformityQuarterX = 0,5 * corrPA + 0,5 * diffPA

Whereas coorPA and diffPA are:

corrPA = Abbildung in dieser Leseprobe nicht enthalten

diffPA=Abbildung in dieser Leseprobe nicht enthalten

Of course, other formulas were conceivable but these were chosen after multiple experiments. Also, if the correlation was not calculable because of “division by zero” errors, just the %difference of working hours has been taken.

Figure 2.6 below shows two examples of projects: project1 was a successful project on schedule and project2 was a delayed project where specific tasks were neglected. With experience in interpretatiing multiple charts of multiple projects, it turns out that tasks which stay above 60% in planned/actual conformity can be counted on to be on schedule. Figure 2.6 below shows two tasks getting below 60% conformity in quarter 7 and 8: “Layout” and “Testing”. After clearance with the project manager it turned out that these tasks were neglected because the responsible team member was on holiday. After his return, “Testing” was compensated, but “Layout” still has been neglected.

Abbildung in dieser Leseprobe nicht enthalten Abbildung in dieser Leseprobe nicht enthalten

Figure 2.6: Projects’ planned/actual working hour conformity visualization over quarters^[60]

Obviously, detailed visualizations of project progress like these can help general managers and project controllers supervise their team members. The applied method resolved the responsible work tasks for project slippage. Simple planned/actual comparison would not have resolved this unless the accumulated work hours over all tasks had been relatively close to plan.

Although interpretation of plan/actual comparison has successfully resolved a misallocation of resources in these projects, other projects showed up other possible reasons for non-conformity to plan.

These further reasons were discovered for non-conformity to plan:

- Very high or low productivity in a specific work task.
- Problems concerning technical feasibility
- Schedule changes (i.e. because of technical changes) without actualization of plan.

Unless these reasons for non-conformity to plan are all in the interest of managers, a visualization of conformity to plan can still be counted on to be functional. Its usability is obvious, and such graphs provide a quick overview of project status and can ease monitoring problems and show exceptional performance in projects and teams. A simple bar-graph comparison of Plan/Actual values would be much too complex and not be possible to be interpreted. Thus, the author suggests improving the visualization of plan/actual working hour comparison furthermore by using artificial intelligence. Software houses offering IT tools for project management should work to improve the graphical evaluation of project performance. This has also been stated as an issue by a project manager in a survey (issue 17 in “Appendix E: Criticisms of and hints for IT tools stated by participants”): There are no warning functions of impending schedule slippage (traffic light circuit).

-In Goldratt’s Critical Chain, buffer filling ratio based project progress controlling is comparable to a plan/actual conformity analysis: The visualization of project buffer consumption (compare below Figure 2.7) provides a quick overview over a project’s progress and possible delay, and could also be applied to single work tasks. The buffer supervision is performed as shown in Figure 2.7 below and the main reason for buffer based planning without milestones in CC is that team members have lower knowledge about their end of week’s work ratio and goal and thus were expected to work more constantly.

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.7: Project Buffer Graph^[61]

Some IT tools like “Scitor Project Scheduler 8” support buffer based project controlling. What is not well implemented in every case is the colored segmentation between green, yellow and red zones within the buffer, which indicates whether a project is delayed or not.

The project’s subject progress control can be evaluated by updating the progress of each single quantified work package in the work breakdown structure^[62] or by quantifying the achieved defined project goals, the degree of external integration. This can be performed by graphs and also by table based calculation. However, for subject’s progress evaluation there are no IT tools needed because it can be performed by simple tools like MS Excel, too.

2.4.2 Project Risk Assessment (risk)

Every Project has its individual risks of failure and delay, which need to be considered in a detailed project plan. Risk can be defined as follows^[63]: “Exposure to the possibility of economic and financial loss or gain, physical damage or injury, or delay as a consequence of the uncertainty associated with pursuing a particular course of action”.

Different kinds of assessment methods are available which could be applied to IT tools:

Qualitative Identification or Activity list

analysis scope phase Risk lists

Response lists

Secondary risks and responses

Structure Risk and response links

Phase Minor and major risks

Specific and general responses

Simple and complex decisions

Ordering responses

Diagramming the risk/response structure

Quantitative Parameter Scoring Techniques

analysis phase Quantification of uncertainty

(based on questionnaires)

Computation Combination of risks in

Phase a nested manner

Risk Interpretation of results and development of

management alternative approaches as appropriate, for

initial planning and subsequent control/

planning revisions

Figure 2.8: An outline structure of risk management methods^[64]

Although risks cannot be avoided by the use of IT tools, but only anticipated and evaluated, IT tools should support risk management in order to allow adequate precautions.

Diagramming of risk/response can be counted on to be the most important qualitative method to be implemented into IT tools; the following methods are available:

Abbildung in dieser Leseprobe nicht enthalten^[65]

Most suitable method for quantitative risk assessment (QRA) in IT tools is the detailed analysis and simulation of project’s risks based on a precedent qualitative analysis.

IT-supported simulation requires little knowledge of mathematics; nevertheless IT models precise the perceptions of uncertainty surrounding all the input variables, and can i.e. anticipate the dynamics of Critical Chain behavior through Monte Carlo Analysis^[67].

Following further indicators can be counted on to be quantitative and are suitable to anticipate financial risks of a project portfolio^[68]:

EMV (Expected monetary value)
ENPV methods (expected net present value)

RADR (Risk-adjusted discount rate)

2.4.3 Productivity Measurement (time)

In most kind of projects, total project duration has to be minimized and delays have to be excluded wherefore productivity has become more and more important in all kind of projects. This could be achieved through empowerment of employees by extrinsic and intrinsic incentives to be performed by controllers. According to a study of Lock (1987), 40% of the European Managers were motivated by money and 60% by power.

The basis for extrinsic incentives are measurement systems who evaluate the productivity in projects and who can be used as an allocation base for compensations.

According to Shing (1988) a reward system can motivate individuals to higher performance under the following circumstances:

- The individual values highly such rewards as advancement, more money more scope, power, a good assignment and a good assessment.
- He believes that a high level of personal or team Performance will be recognized, produce results and will bring him these rewards.
- He has an opportunity to perform.

The productivity in projects is commonly not at a maximum and can still be improved. A typical development of productivity in projects is shown in Figure 2.9 below. Here we see that the productivity is reducing from the beginning of the project and is rising after about 30% of total project duration. This may be due to the fact that project progress is highly overestimated during project progress up to the halfway stage of the total project duration (compare Figure 2.10 below).

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.9: dynamics of typical projects: productivity over projects time^[69] (left)

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.10: estimated project progress in software projects at Siemens S.A.^[70] (right)

In consideration of the findings of Lock (1987), Shing (1988) above, productivity measurement and incentives should be suitable measures to increase productivity.

One approach for calculating productivity in projects is as follows^[71]:

ProductivityAbbildung in dieser Leseprobe nicht enthalten or

ProductivityAbbildung in dieser Leseprobe nicht enthalten^[72]

Effectively these formulas describe productivity as a planned input / actual input ratio based on planned effort estimation. The author considers this as very risky, unless planned effort is a subjective input value and should not be such an important factor in productivity measurement. Only in projects with low novelty and high repetition rate can these formulas deliver suitable indications of productivity.

Project Management Offices in Industry thus try to develop more suitable measures for project productivity estimation. The internal consultancy team at Robert Bosch GmbH responsible for this considers it to be very difficult and has been searching for more suitable measures for the last four years.

Known measures which can improve productivity measurement in projects as a more representative productivity indication for projects are:

DCT = Dynamic Cycle Time

The Dynamic Cycle Time measurement is derived from production planning and indicates the development of duration of single work tasks over time (comparable to throughput rate). DCT Calculation is individual.

FPY = First Pass Yield

First Pass Yield in projects declares the percentage of work packages which are completed within the first review loop without failures.

OTD = On Time Dates

On time dates is the percentage of work packages which has been completed on time / as scheduled

Take note that DCT / FPY / OTD calculation do not have to be relevant for every work package. Each work package should be equipped with a marker to show whether calculation will be performed or not because not for every work package DCT / FPY / OTD are suitable measures representing productivity.

A criticism to productivity measurement is pointed out by Szakonyi (1999) in section 22-5: “What you measure is what you get”, whereafter quantification of productivity leads to better measured results, but to no better productivity in reality.

If productivity measurement and incentives are applied, IT tools should support them. One possibility is the implementation of suitable measures directly in the work breakdown structure (Gantt Chart) of the VSMS. An evaluation of productivity should be easily realizable through working time record enhancement.

2.4.4 Performance Measurement (quality)

Like Productivity Measurement measures the internal efficiency in project’s execution, performance measurement measures the external effectiveness and external/internal integration in projects (utilization of term performance measurement is not unique and is also applied for productivity measurement^[73]). A performance measurement system should thus be able to measure all criteria of project success and to return them into discrete values. A suitable model for Project Performance Criteria can be found in below.

Abbildung in dieser Leseprobe nicht enthalten

Figure 2.11: Performance Criteria in Product Development Project^[74]

Although Performance Criteria are very obvious, they are very difficult to return into discrete values and thus difficult to implement into IT tools. In the scope of his doctoral thesis, Ville Ojanen pointed out the main problems of performance measurement and the creation of discrete indicators (see below Figure 2.12). Having a deep look at the highlighted problems below, only a minority of problems could be solved by IT tools (potentially by IT tools solvable problems are printed bold).

[...]

---

^[1] Barclay, I.; Dann, Z.; Holroyd, P. (2000), p. 5

^[2] Clark, Kim B.; Fujimoto Takahiro (1991), p. 34

^[3] Barclay, I.; Dann, Z.; Holroyd, P. (2000), p. 4

^[4] Clark, Kim B.; Fujimoto Takahiro (1991), p. 40

^[5] Charvat, Jason (2002), p. 285

^[6] Sapienza, Alice M. (1995), p. 87

^[7] Clark, Kim B.; Fujimoto Takahiro (1991), pp. 12-18

^[8] Microsoft Corp. (2003), p. 6

^[9] Nobeoka, Kentaro (1995), p. 3

^[10] Lechler, Thomas (2002), p. 1

^[11] Ahlemann, Frederik; Hoppe, Uwe [Ed.] (2003), p. 14

^[12] PMBOK guide (2000), p.31

^[13] Barber, Elizabeth (2004), p. 304

^[14] Lomnitz, Gero (2004), p.3

^[15] http://www.projektmagazin.de/glossar

^[16] Lomnitz, Gero (2004), p. 3

^[17] Microsoft Corp. (2003), p. 4

^[18] Gartner Group (2003), p. 15

^[19] based on Linton et al. (2002), p. 140; Suhanic, George (2001); further research

^[20] Sapienza, Alice M. (1995), p. 88

^[21] Frankel, Ernst G. (1993), pp.54ff

^[22] compare Brown, H. G.; Poole, M. S.; Rodgers, T. L. (2004) who improved the ICM

^[23] Davis, Fred D. (1989), p. 333; improvements of TAM by Gefen, David; Straub, Detmar (1997), p. 396

^[24] Sapienza, Alice M. (1995), p. 144

^[25] Brooks, F. P. Jr. (1995), p. 25

^[26] Norton, Bob (2004), p. 2

^[27] Simmons, Dick B.. (1998), p.206

^[28] Kedzierski , B. (1984), pp. 446ff

^[29] Storm, Jörg (2004), p. 3

^[30] Taylor, James (2000), pp. 141 – 143; Burghardt, Manfred (2002), p. 145; Charvat, Jason (2002), p. 151

^[31] Burghardt, Manfred (2002), S. 216ff

^[32] according to survey made, most managers do not know the meaning of Gantt or PERT diagrams but well use MS Project for project scheduling; compare also Kalthoff, C.; Kunz, S. (2004)

^[33] Morton, T. E.; Pentico, D. W. (1993), p.88, p.93, p. 120

^[34] Simmons, Dick B.. (1998), p. 210

^[35] Goldratt, Eliyahu M. (1997), pp. 26ff.

^[36] Leach, Larry P. (1999), p.43 suggests setting the project buffer length to 50% of the project’s total duration

^[37] see Figure 2.2on page 17

^[38] compare Barron, Y., & Mandelbaum, A. (2003) for a deeper analysis

^[39] Goldratt, Eliyahu M. (1998), p. 1

^[40] Morton, T. E.; Pentico, D. W. (1993), p. 64

^[41] Morton, T. E.; Pentico, D. W. (1993), p. 68

^[42] Anavi-Isakow, S.; & Golany, B. (2002), pp. 11ff

^[43] Cohen, Izack / Mandelbaum, Avishai / Shtub, Avraham (2003), p. 13

^[44] Cohen, Izack / Mandelbaum, Avishai / Shtub, Avraham (2003), p. 33

^[45] Simmons, Dick B.. (1998), p. 34

^[46] Burghardt, Manfred (2002), pp. 577ff; Bernecker, Michael (2003), p. 401

^[47] Burghardt, Manfred (2002), pp. 51ff; Bernecker, Michael (2003), p. 397

^[48] Bernecker, Michael (2003), p. 399; Madauss, B.J. (2000), p. 232

^[49] Bosch Automotive Systems JE/ERC; Bernecker, Michael (2003), p. 399

^[50] Bernecker, Michael (2003), p. 406; Szakonyi, Robert (1999), section 23-6, Lock, Dennis (1987), p. 453

^[51] Madauss, B.J. (2000), p. 224; Bernecker, Michael (2003), pp. 409ff

^[52] Madauss, B.J. (2000), p. 319; Szakonyi, Robert (1999), section 33-10; Lock, Dennis (1987), p. 589

^[53] Szakonyi, Robert (1999), section 23-5

^[54] a major problem in intercultural environments is the way of communication Storm, Jörg (2004), p. 3

^[55] compare chapter 2.1.4 and Kedzierski , B. (1984), pp. 446ff.; Charvat, Jason (2002), p. 166

^[56] Pinto, Jeffrey K. (2002), p. 52

^[57] Suhanic, George (2001), pp. 180ff

^[58] i.e. MTA (Milestone Trend Analysis); Cost trend analysis

^[59] Madauss, B.J. (2000), p. 231; Suhanic, George (2001), pp. 180ff; Burghardt, Manfred (2002), pp. 355ff

^[60] information for these graphs is gathered from Bosch Automotive Systems Airbag Engineer Department, Japan and is evaluated according to above mentioned formulas

^[61] based on Goldratt, Eliyahu M. (1984)

^[62] Burghardt, Manfred (2002), p. 367; Madauss, B.J. (2000), p. 231; Pollalis, Spiro N. (1993), p. 153

^[63] Cooper, D.; Chapman, C. (1987), p. 3

^[64] based on Lock, Dennis (1987), p. 439; Raftery, John (1994), pp. 5-16

^[65] Pollalis, Spiro N. (1993), p. 125

^[66] Lock, Dennis (1987) pp. 435ff.

^[67] Raftery, John (1994), p. 82

^[68] Raftery, John (1994), p. 76, p. 77, p. 80

^[69] based on Reichelt, Kimberley; Lyneis, James (1999) , p. 136

^[70] based on Siemens (2002), Abdel-Hamid, T. (1988), p. 324

^[71] Clark, F.D.; Lorenzoni, A. B. (1978), p. 17

^[72] Where QAB is quantity adjusted budget

^[73] Suhanic, George (2001), p. 175

^[74] Shenhar, A.;Tishler, A; Dvir, Dov; Lipovetsky, S.; Lechler, T (2002), p. 116