Idea Transcript
High performance projects – A speculative model for measuring and predicting project succes Peter M. Storm Rob E. Janssen gr 04-04
OUN
HIGH PERFORMANCE PROJECTS A speculative model for measuring and predicting project success
Peter M. Storm Professor of management Open university of the Netherlands PO Box 2960 6401 DL Heerlen the Netherlands Rob E. Jansen Programme manager DSM Industrial Services
Conference paper submitted to IRNOP VI Project Research Conference Track D: Project Theory
1
HIGH PERFORMANCE PROJECTS A speculative model for measuring and predicting project success
1 Introduction Over the years numerous attempts have been made to develop Project Theory from a formal, descriptive framework into an empirical, predictive model. A model which can be used to systematically increase performance of projects over time. In Business Theory such models do exist (see for instance Johnson and Soenen, 2003). So why not in Project Theory? Obviously, the interests of those who invest in projects are at stake here. If we can’t improve our ability to predict the performance of a project the business of projects will remain a trial-and-error business. Which is bad for the reputation of that business as well as its economic health. This paper describes and compares different approaches that have been taken to develop a predictive model of project performance. Limitations and drawbacks of these approaches are mentioned. On the basis of this review a set of requirements for a generic model is specified. Subsequently a speculative (or prototype) model is developed to satisfy these requirements. In this model projects are viewed as behavioural systems, rather than as technical systems or formal systems, which transform themselves during the project life cycle. The behavioural patterns of the project are used as predictors of success. The model can be used as a framework for comparative empirical research. 2 Business models for predicting success A pragmatic starting point for developing a generic model of project performance would be to borrow the concepts used by business performance analysts. Unfortunately, the correspondence between a business model and a project model is very limited. As an example, in the model developed by Johnson and Soenen (2003) none of their indicators of success and only two of their predictors of success are applicable in the context of a project. These two are: size (measured as total assets) and efficient working capital management (measured through the cash conversion cycle). However, the predictive value of at least one of these two in the context of projects is rather questionable. Size is of interest to business because it provides a source of power and, in some cases, a source for economies of scale. Neither of these two advantages seem to hold for most projects. Predictive models for business are based on the fact that (a) businesses compete with each other and (b) business performance can measured repeatedly over a long period of time. These two conditions do not hold for most projects. Perhaps business performance models can be applied when we focus on project portfolios. However, the focus in this article is on predicting the performance of a single project. 3 Indicators of project success The question of how project performance (or success) should be measured in single projects has been approached from three different perspectives. The most dominant perspective, it appears, is the TBS perspective: a project is successful if it delivers on Time, within Budget and according to agreed Specifications. At second place, we would guess, is the CIA or Capital Investment Appraisal perspective: a project is successful if it realizes the expected financial target. Variations within this perspective are: • BO or Business Opportunities: a project is successful if it realizes the expected business opportunities ( Remenyi and Sherwood-Smith, 1998) • PFC or PortFolio Contribution: a project is successful if it provides the expected contribution to the portfolio of projects to which it belongs (Foti, 2002) The third perspective could be called the Stakeholder Satisfaction Assessment (SSA): a project is successful if it satisfies the relevant needs of the stakeholders and if it receives praise from press and public (De Wit, 1988). Baccarini (1999) has attempted to combine the first two perspectives in his Logical Framework: “it is proposed that project success consists of two components: product success and project management success”, each measured at two levels. Pillai et.al. (2002) have extended this combined approach to develop an analytical and quantifiable measure of overall project performance: project performance is a function of normalized variables representing (a) the merit, (b) the risk, (c) the category bias, (d) the progress deviation, (e) the cost deviation, (f) the decision effectiveness, (g) the customer commitment, (h) the cost effectiveness and (i) the production preparedness of the project.
2
Shenhar et. al. (1997) have performed a comparative investigation, involving 80 projects, to derive four criteria of project success, using factor analysis. The criteria they arrive at are: (a) customer satisfaction, (b) budget & schedule control, (c) business success and (d) future potential. In our view, at least for the purpose of developing a generic predictive model, project success should be defined as the weighted combination of owner satisfaction and user satisfaction on the criteria agreed within or concomitant with the contract between contractor(s) and owner and measured at the moment of full acceptance of the project results. This is a somewhat formal view which leaves room for a variety of industry specific, technology specific and strategy specific criteria. For instance, this view is applicable to both soft projects (such as projects which are aimed at behavioural change or learning) and hard projects (aimed at the development and implementation of objects, industrial processes or systems). It also accommodates variations in the timing of success measurement. In this view it is assumed that such classical criteria as on time, within budget and according to specification are included in the agreed criteria of success if these are really of strategic importance to the owner and or of operational importance to the user. The question of how the two criteria should be weighted relative to each other is left aside within the context of this paper. We acknowledge that this question may turn out to be of empirical importance. 4 Predictors of project success Turner (2002) has stated that project success factors should satisfy the following requirements: • They should represent elements of the project and its management. • The project manager and the project team must be able to influence them • The factors, when present, should increase the chance of success. Many attempts have been undertaken to identify the most important factors that determine project success. Turner (2002) reviews some of the most widely known of these, namely those developed by Grude, Morris, Baker et. al., Pinto and Slevin. In total these models present more than 25 different factors contributing to project success. In his attempt to summarize these, Turner arrives at six factors: (1) agree clear goals and objectives, (2) agree the success criteria with the stakeholders at the start, (3) acquire top management support, (4) have good, clear plans, (5) agree the success criteria with the client at the start, (6) consult the sponsor, the client and the consumers (users), (7) gather a competent, motivated team to undertake the project. Of these factors Turner believes that the most significant contributor to project success is to agree the success criteria at the start of the project. According to Belout and Gauvreau (2004), who also reviewed these models, the most important empirical studies on the critical success factors have been conducted by Pinto (and several co-authors) over a number of years. A majority of these models can be characterized as prescriptive. By contrast some models have been developed which are of a more descriptive nature. A recent and representative example, we believe, is the model developed by Pillai et. al (2002). A major strength of this model is that it describes the logic behind the various causal relationships, which is something that cannot be said of many prescriptive models. A limitation is that it focuses on the specific nature of R&D projects. Although differences can be noted between these models, they also share certain common characteristics: • Most models are prescriptive rather than predictive. In general, predictions are not necessarily identical to prescriptions. For instance, body temperature can be used as a predictor of illness. However, reading one’s body temperature is generally not recognized as a prescription for preventing or curing illness. Certainly, there is a relationship between the predictive action and the prescriptive action, but that does not mean they are identical. • Most models do not specify the nature of the mutual relationships among the variables. In most cases they seem to suggest linear, additive relationships. In other words they suggest that combini ng as many success factors as possible increases the chance of success. In general, this assumption is questionable. For instance, to increase the chance of being healthy in the future one should eat and exercise regularly. However, it is the optimum combination (in time and space) of these two which promotes health the most. But, the optimum is not to eat and to exercise to the maximum. Also, eating and exercising at the same time is usually not beneficial for one’s future health. Hence, there is a trade-off between eating en exercising. Current predictive models of business success are rarely, if at all, based on the assumption that success factors should be linearly combined to
3
•
•
•
improve the chance of success. Quite to the contrary, these models recognize that there are trade-offs between the various predictors of success. There is a lack of empirical data available on project success indicators and their predictors (Belout and Gauvreau, 2004). A problem with the data that are available is that they are usually gathered through surveys in which the same source (respondent) is used to gather data on the independent and the dependent variables. Most models are still of a speculative nature, as is the model presented here. Many models are, it seems, intended to be exhaustive. With these models it is attempted to include any logically relevant factor in all dimensions. Whatever the reason for this apparent desire to include so many factors, the resulting model may become so complex that it cannot be validated. This is especially the case when we assume that the relationships between the variables in the model represent trade-offs. Some models are based on the concept that projects represent phase systems, others are not. Phase systems develop over time. Their behavioural characteristics are different in different phases. If the system is considered to be an organism one can say that the system transforms itself. We believe this to be an essential characteristic of any project. A logical consequence of this axiom is that different predictors are needed in different phases (Belout and Gauvreau, 2004)
Given this brief review of current models of project success, we propose the following requirements for our model: • The variables should be (as) predictive (as possible). Thus leaving room for different theories to transform predictions into prescriptions. • The model should acknowledge trade-offs which are considered essential in the management of a project. • The model should be robust, containing as few variables as is conceptually feasible. • The model should acknowledge the phase system nature of projects. 5 Trade-offs in the management of a project In our opinion, handling trade-offs is an essential part of managing any business, and so also of managing projects. It is i mportant because trade-offs mean balancing a number of factors that each have a large impact on a project. The difficult part is that increasing one factor means reducing the other(s). An added difficulty is that generally it is hard to determine what the impact of the factors involved will be. In broad terms one can distinguish two types of trade-offs: performance and strategy tradeoffs. Performance trade-offs deal directly with the objectives of the project, while strategy trade-offs refer to the approac h for project execution. Traditionally, performance trade-offs have received most attention in literature. The simplest variety are the two-aspect trade-off of which “time-cost” is probably the best known. It is still a popular subject, looking at the many papers regarding optimization algorithms. The attractiveness is that one deals with two relatively straightforward aspects. Still, in practice the situation quickly becomes very complex. New techniques are employed to overcome this, see Leu e.a. (2001) who combine fuzzy set theory and Genetic Algorithms. A second variety of the two-aspect trade-off is “life cycle costing” where one balances investment cost vs. operational cost. See for instance Woodward (1997). The next step is to extend these to the three-aspect trade-off time-cost-quality. Quality generally refers to the result, or product, of the project. It can include many aspects: flexibility, safety, operability, maintainability, operational efficiency etc. Consequently, cost now includes also all kinds of quality related costs – especially those incurred because of additional design features and purchased component quality – in addition to the strict execution related costs. One can understand that the system is now much more complex, making it e ven harder to address the trade-off quantitatively. One attempt is made by Khang and Myint (1999), for the construction of a cement factory. In recent years risk has been added to “cost-time-quality “, resulting in a mixed performance and strategy trade -off. The addition improves the conceptual framework but increases the complexity even further. In the context of this paper, we would like to discuss this trade-off further because it pertains to the model we will introduce later. We translate it towards the trade-off between using
4
proven work processes giving known results and new work processes promising better results. In short: certainty vs. results. Before we discuss it further, we need to introduce a model for project activities. In this model, the total work done in a project is subdivided in two categories: 1. “routine” activities, where proven and established work processes are being used. This pertains to both the production work (contributing directly to the result) and the project managerial work. These are more or less routine activities requiring, and this is important, little or no cooperation between the parties involved; also, since the processes are well established, it takes little time to get these into operation and to keep progress up; 2. “problem handling” activities. This area can be further subdivided in: 2.1. “preventive” activities, dealing with potential future problems and where planning, organizing and risk management are the prime tools; 2.2. “corrective” activities, where problem solving and crisis management are dominant. This is the realm of co-operation. This is where the existing systems don’t work or have failed and where the project team must find new and creative solutions. Such efforts require time and energy which cannot be spent on production work. Schematically the subdivision can be presented as follows, where the outer rectangle represents the total project work load:
REACTIVE PROBLEM HANDLING ACTIVITIES
ROUTINE ACTIVITIES
PREVENTIVE PROBLEM HANDLING ACTIVITIES
FIGURE 1
Trade-offs in project management
The rectangle as shown represents a project as it is and for a given context. Between industry, organizations and over time, the relative and absolute sizes vary: • When standard production work processes are further developed, the central dividing line moves towards the left, reducing the need for problem handling action; • Increased project management maturity has several effects: − As project management work processes improve, again the central dividing line moves to the left; − As risk management improves the horizontal dividing line moves upwards, thereby reducing the need for corrective action; − As the general understanding of project principles within an organization or an industry improves, the left hand boundary moves towards the right, thereby reducing the need for both preventive and corrective action. The balance between routine and problem handling also varies from phase to phase. As a project progresses and all goes well, the routine part increases and the problem handling part decreases. If it doesn’t, the project will get into deep trouble: the number of people and parties involved goes up and flexibility goes down since the work processes used are more geared towards efficiency. Crisis management thus becomes much harder.
5
Within a given context, however, one can trade -off certainty against results by adjusting the balance between routine and problem handling activities. It is important to realize that this also affects the need for co-operation and time and efforts required for problem handling activities. It is clear that in a real project, there are many trade-offs, hard and soft, who together create a very complex optimization problem. As we mentioned earlier, many efforts are reported in literature to determine optimum solutions using mathematical algorithms. However, these approaches (still, and probably always will) require gross simplifications of the problem situation. In real life, therefore, handling trade-off situations is a human process, requiring a wide range of soft skills, in which perception and politics may have greater influence than facts and hard skills. This makes handling trade-offs definitely more an art than a science. As we said, in our opinion, handling trade-offs is the essence of managing any business, including projects. That is why we feel that a project suc cess model must cover the effectiveness with which trade-offs are handled in a project.
6 The phase system nature of a project All projects have a life cycle (Turner, 1999). Organizations also have a life cycle. However, there is a major difference, which is crucial to a proper understanding of the nature of project management versus the nature of organization management. To put it in black and white: the task of project management is to actively plan the end of a project, while it is the task of organization management to plan for the survival of an organization. Project theory describes how a project can be finished as soon as feasible and sensible. Organization theory describes how an organization can be continued, if necessary at the cost of other organizations. On the other hand, it is also the task of project management to bring a project to life, which is not the case for most organization managers. To bring something to life in order to end that life in a purposeful way distinguishes the nature of project management from the nature of organization management. In order to accomplish this a project manager must transform himself from an entrepreneur at the start to a liquidation manager in the end. Different forms are required in between. A project manager is a systems designer, a community builder, a marketeer and more. And all of that must be accomplished in a relatively short period of time. Many books and articles on project management treat projects as distinctive subsystems of a larger system (the organization of which they are part). These project subsystems require distinctive structural arrangements (such as, in some cases, a matrix structure). We agree with this view, but we do not believe that characterizing projects as a separate set of subsystems acknowledges their unique nature sufficiently. The uniqueness of projects, we believe, comes out more clearly when we view them as phase systems. The essence of a phase system is that it transforms itself. In each phase of its life cycle the system presents a different view of itself. It behaves differently. It is organized differently. To illustrate this phenomenon we present and discuss the following experiment. A small team (4-8 persons) is assembled. This team is given the following assignment: “As a team you are to arrange a thirty feet long, endless rope into a perfect square. While you are doing this each of you is blindfolded and each of you should actively participate in the task. You may determine the precision of your square and you should perform the task of rearranging the rope within ten minutes; that is to say from the moment you first touch the rope to the moment you signal to me that your task is accomplished. You have 30 minutes to prepare yourself for this job; 15 minutes of these should be devoted to searching and selecting a solution and 15 minutes should be devoted to design a procedure”. However simple this task may appear, it contains all the essential challenges of a project: • It is time restricted. • It is a true team effort; there is only one significant performance and that is the joint result of the team. • It is non routine; there is no one best way to perform this assignment; very few people have performed this task before; transforming the definition of a square into a set of rules which can be applied by blindfolded people is not easy; coordinating the movements of people whom you cannot see requires a carefully designed system of messages • It cannot be successfully accomplished by means of spontaneous improvisation; in other words, it requires meticulous planning. • It is risky; there is the danger of the rope getting entangled with itself and there are physical dangers involved also.
6
One of the authors has executed this experiment many times in the past ten years in different settings and involving different types of participants. Different settings were: in-company training sessions, open registration training sessions, formal policy development meetings and even parties. Participants ranged from unexperienced to very experienced in project management, from complete strangers to cohesive teams, from young to old, from blue collar to white collar. The aim was to find out what determines high performance in such a project. In this exercise, high performance can be described as: • The required product is delivered on time and according to specification • All limitations set by the principal (the experimenter) are respected visibly • The project team is satisfied with its accomplishment • The project team can explain why it succeeded (and all members agree on this explanation). Low performance can be described as: • The required product is not delivered at all (the team gives up) • The team has attempted visibly to violate the limitations set by the principal • The project team is dissatisfied with its accomplishment • The project team disagrees on the reasons why it failed. The experiments have shown that these characteristics almost always go together. In other words: the teams either are high or low performing. Something in between rarely happens. Why? What makes the difference? Our observations have led us to believe that the following factors have no or very little influence: • Age, education, sex • Experience in project management • Size (within a range from four to eight members). On the other hand one factor which clearly distinguishes high performance teams from low performance teams is the ability of a team to transform itself during the life cycle of the project. This transformation follows what we would call a natural sequence. Three distinctive phases can be recognized in this natural sequence: 1. Search. In this phase the team explores the nature of the assignment, identifies the major challenges, tests the level of its own ambition and cohesion, searches for a feasible solution and selects a preferred solution. 2. Design. In this phase the team transforms the chosen solution into a procedure (or script), designs an organization fit to execute the procedure, identifies specific risks that may occur during execution, develops contingency measures to be taken if and when risks actually occur, memorizes each step in the procedure and performs a dry-run (without the rope, which is not available at that point) of the procedure. 3. Execution. In this phase the team assembles at the location indicated by the principal, arranges itself according to the design it developed during the second phase, puts on the blindfolds, executes its procedure and gives a signal to the principal when it is finished. These three phases are similar to the three first project life cycle phases mentioned by Turner (1999) and others: initiation (germination), design (growth) and execution (maturity). All teams were closely observed during the experiments. The results of these observations show that High performance (HP) teams behave quite differently from low performance (LP) teams. • During the search phase HP team members are standing closely together in a loose constellation (there is much moving about), while LP team members are sitting (far) apart in a fixed constellation. • During the search phase the conversation between HP team members is rapid (very few, if any, silences), it involves all members and it is not visibly managed. In LP teams the conversation involves mostly a few members of the team, it is not fluent and it usually leads either to a situation where one or two members take on the role of discussion leader or to a situation of overt or covert conflict between two fractions in the team. • HP teams seem to find a common “level of ambition” rather rapidly. In LP teams discussion about “how precise should our square be?” seem to have no ending. • HP teams do select one preferred solution and stick to it during the design phase. This enables them to proceed on a different level: detailed design. LP teams keep coming back on the issue of what the best general solution is. This prevents them from proceeding on the level of detailed design.
7
•
In HP teams, who did not have a specific leader during the search phase, a leader emerges rapidly during the design phase. In LP teams the order is often reversed: they have an active leader during the search phase, but no active or dominant leader during the design phase. • During most of the design phase, HP teams do not have a fixed task distribution even though they are working towards a detailed and fixed task distribution during the execution phase. This is possibly a result of the fact that they are still looking for flaws (risks) in their design. LP teams tend to start with a fixed task distribution at the beginning of the design phase. Although possible flaws are as frequently mentioned in LP teams, it seems that they lose their ability to immediately adapt themselves to new views. There is a much stronger “let’s get this over and done with” attitude in LP teams. • HP teams always finish the design phase with a dry run. The signs of self confidence resulting from this dry run are very visible. LP teams rarely finish the design phase with a dry run. The possibility of a dry run is often suggested in LP teams by one of the members but is usually ignored or waved with arguments like “that is not necessary, everyone knows what he has to do” or “there is no time for that” or “that doesn’t make sense because we don’t have the real rope to do the tryout with”. • During the execution phase HP teams execute the task exactly according to their own procedure. There is rarely any hesitation or improvisation. In LP teams there is almost always a moment at which one of the team members starts making suggestions for alterations of the procedure or even deviates from the procedure without mentioning it to the others. • During the execution phase HP team members use speak loudly when requested to do so (thus giving clear signals to each other and informing those who do not have very active tasks what the current situation is). LP team members do not give loud signals to each other; they seem to operate on the assumption that “no news is good news”. These observations seem to indicate that there is a clear connection between the three phases and the way in which a high performing team behaves (see table 1). HP teams transform themselves according to the phase which they are in. TABLE 1 PHASE SEARCH
DESIGN
High versus Low Performing teams in subsequent phases HIGH PERFORMING TEAM • Rapid (randomlike) interaction • Informal, unstructured • Involvement of all • Common level of ambition • Creative thinking dominates • • • • • • •
EXECUTION
•
• • • • •
Acceptance of previous decision Switch from randomlike to systematic interaction Switch from non-structured to semi-structured Switch from shared leadership to supportive leadership Switch from creative to pragmatic thinking Detailed planning of execution Risk analysis leads to visible improvement of plans
•
Loyal execution of agreed procedure
•
• • • • •
LOW PERFORMING TEAM Slow interaction Tendency to formalize; desire to control Involvement of some Different levels of ambition Pragmatic thinking dominates Quasi-acceptance of previous decision Increased formalization and structure Strong difference between formal and informal structure Switch from pragmatic thinking to opportunistic thinking Rough planning of execution Risk analysis is not taken seriously / does not lead to visible improvement of plans
Improvisation by some team members
8
• • •
procedure Switch from team of equals to hierarchy Switch from spontaneous communication to controlled communication Switch from supportive to directive leadership
• • •
members Unclear hierarchy Haphazard communication Partial acceptance of directive leader
Are these characteristics more or less representative of high versus low performing teams in real world projects? We believe they are. We see a strong correspondence with the many project teams we have witnessed or led during our professional career. Even though the differences between high and low performing teams are less pronounced in real life projects. The comparison is difficult (and hence speculative) because in real projects: • Phases cover much longer periods of time; • Teams are not operating in such isolated environments; • Resources are much more scarce; • Project goals are much more complex; • Project environments are more complex and less stable. We conclude that some predictors have more predictive power in the early phases of a project, while others become more important at a later stage. This conclusion is in line with results of empirical research reported by Pinto and Slevin (1988) and Belout and Gauvreau (2004).
7 The model The investigation reported above pertains to very simple projects. What will happen when a project is complex? Belout and Gauvreau (2004) note that “ with respect to project success, historically, projects have been managed as technical systems instead of behavioural systems”(p. 2). We adhere to this latter view. Projects are behavioural systems which transform themselves in a dynamic way. We postulate that in complex projects the transformation from start to finish is rarely stable. In other words, success factors (or predictors) may improve and deteriorate in an alternating fashion during the project life cycle. For instance, (top) management support, which is included in many project success models (Belout and Gauvreau, 2004) is rarely a stable variable in our view. Management support is not a technical factor, it is a behavioural factor which is dependent on a complex array of factors such as agreement on policy goals, stability of the power structure, economic conditions, budget constraints etc. Hence, managing a project towards success is not just a matter of creating a number of conditions, such as the ten conditions mentioned in the Pinto and Prescott (1988) model and assuming that once these conditions are realized the project will automatically become a success. Managing a project towards success, in our view, is much more a continuous struggle to transform the project, as a behavioural system, through the subsequent phases (or stages) of the project life cycle. In the first phase the first behavioural predictors of success have to do with focus. Focus means a clear vision on the reason for being, the scope and the strategy (and its incumbent risks) of the project. It is generally acknowledged, for instance through the wide spread acceptance of the PMBOK, that focus is essential in project management. The concept of focus relates directly to Turner’s view that the most significant contributor to project success is to agree the success criteria at the start. Focus can be attained by applying a single reason for being, a narrow scope and a straightforward or proven strategy. However, this is not the only way. It is equally feasible, in the early stages of a project to apply a multi focus approach. Applying a single, narrow focus may seem preferable from an administrative point of view. Almost every control issue becomes easier to handle that way. However, it is possible (in some cases even likely) that a project which starts off with a single or narrow focus gets stuck in its own single sightedness. An interesting example of that phenomenon is presented by Baker (2002) in his description of the Firefly project. The purpose of the Firefly project was to find and acquire a replacement for the T-41 Air Force plane. This plane was to be used for selecting candidates for undergraduate pilot training. The
9
project had a single, narrow focus right from the start. There was only reason for being (the T-41 was considered outdated), the scope was narrow (the project should be restricted to finding a replacement) and the strategy was straightforward and proven (a COTS, or commercial off-theshelf, strategy was chosen). Nevertheless, the project turned into a total failure (Baker, 2002, p. 53). Some of the lessons learned: (a) a narrow sighted approach was used which led to blindness for the risks inherent in the project, (b) the COTS strategy proved inappropriate, but no one dared to challenge this strategy because that woul d lead to severe delays. Narrowing down the focus of a project too soon may inhibit the search process that leads to (a) identification and understanding of risks, (b) more in-depth understanding of the core problems and (c) discovery of more effective or efficient solutions. On the other hand, narrowing down the focus of a project too late may lead to fragmentation, needless wandering about and waste of scarce resources. Next to establishing focus, the essence of project management is about creating an alliance between people and parties (organizations). This alliance is both new and temporary, at least to a majority of those involved. Alliance can be described as the degree to which all of those who are expected to contribute directly to the project (a) share a common goal, (b) acknowledge the necessity of the contributions by the others and (c) accept the risks posed by the project. In this view, the client and the user also belong to those who are expected to contribute to the project. Lack of alliance inhibits (a) coordination, (b) decision making by the customer or principal and (c) learning (Berggren et.al, 2001). Lack of alliance may lead to a dominance of either central management or sectional (subproject) management within the project while finding a balance between these two is crucial to the success of many complex projects (de Ridder, 1994; Al-jibouri, 2000). Alliance is needed to create, what Graham (2000) calls, the “right team architecture”. “Having the right team architecture can substantially reduce both the amount of work that must be redone, the time delay before before the need for rework is detected, and thus the time before the work is corrected” (Graham, 200, p. 9). Creating a project alliance and avoiding subsequent fragmentation is difficult in several respects. To begin with a project alliance is temporary. Temporary business alliances are based more on instrumental or rational motives than on expressive or emotional motives. However, to create strong bonds among people, expressive and emotional motives are crucial. These motives relate to the project as an adventure. An adventure is something which is worthwhile because of the journey and the experiences themselves, not necessarily because of the results. An adventure is usually not just a pleasant experience, it also contains one or more extreme challenges. To overcome these challenges the allies involved in the adventure must have a desire and willingness to share their fate with each other. In general they will not do so just for pragmatic or instrumental purposes. Second, a project may run into a crisis. As Loosemore has noted, it is not unusual that “at a time when mutual sensitivity between project members is important it is less likely (to be present); at a time when collective responsibility and teamwork are important, they are less likely (to be present)” (Loosemore, 1998, p. 139). There seems to be a paradox involved here: sound project management aims at preventing any crisis to emerge, but some sort of a crisis is needed to create the kind of alliance which is strong enough to survive a disaster. Vos (1985) describes two attempts, in which he participated, to climb the Mount Everest. During the first attempt the dominant leadership style and team culture constrained a free exploration of issues relating to conflict of interest. His diary shows nevertheless that these conflicts really did exist. Hence the first Mount Everest team consistently avoided any type of crisis in the alliance. Until this was no longer possible due to an avalanche of problems. When the real crisis came the team had no experience on how to deal with it and it collapsed. The second team tried to learn from this experience and brought many potential conflicts of interest out in the open long before the real trial began. This team too encountered conflicts when conditions became difficult and when disaster loomed. But it survived them all and reached the top. Third, the alliance created in a project is almost always at odds with other alliances to which the participants are bound. Often, these other alliances are stronger and older than the project alliance. In many cases there is some sort of an upper limit to the strength of the project alliance. When the project alliance becomes too strong, members of other alliances will feel threatened. The abundance of literature dealing with the matrix structure witnesses to that phenomenon. Following focus and alliance, project management is about creating momentum. Momentum means a positive increase in the speed with which a project is progressing. Progress refers to all the essential processes within the project. These are, for instance, the process of mobilisation of
10
resources, the process of defining core problems to be solved, the search process for potential solutions, the decision process that leads to selection of a preferred solution, the process of negotiating support and permission from parties in the transactional environment of the project. “A project that is progressing rapidly tends to overcome difficulties that would stop a project that lacked that momentum” (Davis, 1986, p. 26). The increase in speed may be high or low, but the essence is that it is positive. Momentum brings with it both positive and negative pressure. Positive is the shared feeling of progress, of solving problems which seemed unsolvable. Negative is the stress that goes with doing things more rapidly than usual and with the raised expectations of success. According to Davis “The natural bias of a project team is not toward the high-momentum but, rather, the low-momentum project. One of the obvious reasons for this is that in most phases of a project, it will take the combined efforts of several, if not all, of the project team members to maintain momentum. However, a single project member can cause the project to come to a halt..”(Davis, 1986, p. 26). In addition, a high positive increase in speed, like the launching of a rocket, requires a multitude of advanced techniques. Such as continuous approval systems (Bhuyian, 1999), concurrent engineering (Denker, 2001), fast tracking (Ibbs, 1998) and reliable progress monitoring (Al-jibouri, 2003). In general, it can be stated that the project management maturity level of an organization determines what techniques are available or can be introduced in a project without disproportionate risks or efforts. Still, as we discussed under Trade-offs, there are choices to be made in every project. However, implementing such advanced techniques in a project requires time and resources thereby reducing the perceived momentum of the project. Hence, project management is confronted with a dilemma. “Are we going for high or low momentum?”. Each has its advantages and disadvantages. Creating high momentum from the start is both more risky and more costly i n the early phases of the project. However, if one does succeed in creating high momentum the reward is a project which has transformed itself into a system which is unstoppable. Going for high momentum at a much later stage defers the costs and risks to a later moment. But then it might be too late. The fourth and final predictor in our model is performance. Performance represents the combined result of budget performance, schedule performance and quality performance. In our view a project performs well if and when project management succeeds in finding optimal solutions to the trade-offs between these three performance criteria. The problem with performance is that it becomes truly visible late in the project. In early stages a project may be on time, within budget and documents quality may appear good, but during execution errors in both project design and execution planning may come to light. One of the authors works in the chemical industry where it is common wisdom that high performance can only be achieved after proper Front End Loading. Once the execution is underway the train is rolling and it is impossible to adjust the track without incurring major penalties. While it is not feasible to save a project at that stage, it is still possible to wreck it. Scope changes, for instance, can greatly disrupt the flow of largely routine activities, by stopping work in progress, causing fundamental rework and introducing all kinds of errors. To reach a high degree of performance is more difficult in later stages of the project. During execution, when most resources are deployed, and during implementation, when progress of the project becomes very dependent on external conditions and on actions to be taken by people outside the project. There is not one universal strategy to reach high levels of performance. It is common wisdom that limitation of scope changes and tight monitoring and control have a positive influence on performance. Scope changes disrupt the learning curve of repetitive work in the project (Eden et. al, 1998). Loose monitoring and control systems lead to late recognition and imprecise understanding of delays and other problems. On the other hand, repetitive work is not the only work in a project. Search and design work is, at least, equally important. In some cases scope changes are inevitable. And scope changes lead to learning at a different level. Particularly in search and design work. Combining these predictors and relating them to the major phases of a project our model can be represented as follows (see figure 1) ALLIANCE FOCUS
PERFORMANCE MOMENTUM
SUCCESS INITIATION
SEARCH-DESIGN
EXECUTION- IMPLEMENTATION
11
FIGURE 2 horizon)
Predictive model of project success (arrow indicates length of prediction
At the start of a project we expect Focus to have the most predictive value. During the search and design phases Alliance and Momentum are added. Finally, during execution and implementation Performance becomes a fourth source of predictive value. A project is a behavioural system in our view. Hence, we do not expect these predictors to be perfectly stable during the course of a project. As a consequence each of the four predictors must be measured repeatedly. This model, we believe, satisfies the requirements specified in paragraph 4: • The variables are of a predictive nature. The model does not suggest or imply any causality. For example, more focus does not automatically lead to more alliance. • The model acknowledges essential trade-offs in the management of a project. Both within the realm of each of the predictive variables and between the predictive variables. For example, in attempting to create momentum project management is confronted with a dilemma: early freezing with the potential benefit of early momentum and the risk of late (and possibly big) delays; or late freezing with the potential benefit of high momentum during realization and the risk of very low momentum during the early phases. And, as an example of a trade-off between variables, building a strong alliance is often at odds with creating early momentum. (de Ridder, 1994). • The model is robust, meaning that it focuses on the essentials of project management. Not in a formal sense, but in the sense that essential demands or challenges of project management (where projects are viewed as behavioural systems) are represented. Yet it contains only four predictive variables. Each of these variables can be conceptually related to most of the variables included in the prescriptive models developed earlier. For instance, using the Pinto and Prescott (1988) model, project mission can be conceptually related to focus, management support, personnel and client acceptance can be related to alliance. One can conceive alternative ways of specifying these relationships, thereby leaving room for different causal models of project performance. • The model acknowledges the phase system nature of a project. 8 Concluding remarks Our model is speculative. It is vulnerable to many sorts of critique. For instance, it can be argued, with good sense, that it is a lack in our model that we do not separately consider the interaction between the project and its environment (in our view this interaction is included in each of the predictive variables). We welcome this critique. We hope this critique will be aimed primarily at the essential characteristics of our approach, which are: • We expect that making a distinction between predictive and prescriptive models of project management will add to our knowledge and insight. Just like it has been (and still is) helpful to the natural sciences and to economics as a science that some research is focused on trying to predict outcomes without bothering to much about the precise nature of the underlying models, while other research is aimed at unraveling, part by part, the threads of truly causal relationships within theoretically sound models. This two-sided approach will hopefully lead to the discovery of “black holes” in our knowledge about project management. • A project is a behavioural system and not just a technical or formal system. In that sense it is mysterious in its behaviour. It is the nature of the multitude of behavioural patterns under different conditions that we must better understand, more than the man made logic of technical or formal systems. • Generic models of project success should be robust and leave room for the development of industry specific, technology specific and strategy specific models, while maintaining general consistency over all these differences.
12
References Al-jibouri, S., 2002, “ Effects of resource management regimes on project schedule”, International Journal of Project Management, vol. 20, no. 4, p. 271-277 Al-jibouri, S., 2003, “Monitoring systems and their effectiveness for project cost control in construction”, International Journal of Project Management, vol. 21, no. 4, p. 145-154 Baccarini, D., 1999, “The logical framework method for defining project success”, International Journal of Project Management, vol. 17, no. 4, p. 25-32 Baker, B., 2002, “The Fall of the Firefly: an assessment of a failed project strategy”, Project Management Journal, vol. 33, no. 3, p. 53-57 Belassie, W. and O. Tukel, 1996, “A new framework for determining critical success/failure factors in projects", International Journal of Project Management, vol. 14, no. 3, p. 141-151 Belout, A. and C. Gauvreau, 2004, “Factors influencing project success: the impact of human resource management”, International Journal of Project Management, vol. 22, no. 1, p. 1-11 Berggren, C., J. Soderlund and C. Anderson, 2001, “Clients, contractors and consultants: the consequences of organizational fragmentation in contemporary project environments”, Project Management Journal, vol. 32, no. 3, p. 39-48 Bhuiyan, N. and V. Thomson, 1999, “The use of continuous approval methods in defence acquisition projects”,International Journal of Project Management, vol. 17, no. 2, p. 121-129 Cooke-Davis, T., 2002, “The real success factors on projects”, International Journal of Project Management, vol. 20, no. 3, p. 185-190 Cooper, K., J. Lyneis and B. Bryant, 2002, “Learning to learn, from past to future”, International Journal of Project Management, vol. 20, no. 3, p. 213-219 Davis, J.G., 1986, “Pilot programme in construction project management”, International Journal of Project Management, vol. 4., no. 1, p. 25-33 Denker, S., D. Steward and T. Browning, 2001, “Planning concurrency and managing iteration in projects”, Project Management Journal, vol. 32, no. 3, p. 31-38 De Wit, A., 1988, “Measurement of project success”, International Journal of Project Management, vol. 6, no. 3, p.164-170 De Ridder, H.A., 1994, Design &Construct of complex civil engineering systems , Delft: Delft University Press Eden, C., T. Williams and F. Ackermann, 1998, “Dismantling the learning curve: the role of disruptions on the planning of development projects”, International Journal of Project Management, vol. 16, no. 3, p. 131-138 Foti, R., 2002, “Priority decisions: portfolio management enables strategic value judgments”, PM Network, April, p.25-29 Graham, A.K., 2000, “Beyond PM 101: lessons for managing large development programs”, Project Management Journal, vol. 31, no. 4, p. 7-18 Ibbs, C., S. Lee and M. Li, 1998, “Fast-Tracking’s impact on project change”, Project Management Journal, vol. 29, no. 4, p. 35-42 Johnson, R. and L. Soenen, 2003, “Indicators of successful companies”, European Management Journal, vol. 21, no. 3, p. 364-369 Khang, D-B and Y-M Myint, 1999, “Time, cost and quality trade-off in project management: a case study”, International Journal of Project Management, vol. 17, no. 4,p. 249-256 Leu, S-S., A-T Chen and C-H Yang, 2001, ”A GA-based fuzzy optimal model for construction time– cost trade-off”, International Journal of Project Management, vol. 19, no. 1, p. 47-58 Loosemore, M., 1998, “The three ironies of crisis management in construction projects”, International Journal of Project Management, vol. 16, no. 3, p. 139-144 Morgan, I. and J. Rao, 2002, “Aligning service strategy through super-measure management”, Academy of Management Review, vol. 16, no. 4, p. 121-131 Pillai, A.S. , A. Joshi and K.S. Rao, “Performance measurement of R&D projects in a multi-project, concurrent engineering environment”, 2002, International Journal of Project Management, vol. 20, no. 2, p. 165-177 Pinto, J.K. and D.P. Slevin, 1988, “Project success: definitions and measurement techniques”, Project Management Journal, vol. 19, no. 3, p. 67-73 Pinto, J.K. and J.E. Prescott, 1988, “Variations in critical success factors over the stages in the project life cycle, Journal of Management, vol. 14, no. 1, p. 5-18 Remenyi, D. and M. Sherwood-Smith, 1998, “Business benefits from information systems through an active benefits realisation programme”, International Journal of Project Management, vol. 16, no. 2, p 81-98 Shenhar, A., O. Levy and D. Dvir, 1997, “Mapping the dimensions of project success”, International Journal of Project Management, vol. 28, no. 2, p. 5-13
13
Turner, J.R., 1999, The Handbook of Project -Based Management, London: McGraw-Hill Turner, J.R., 2002, Success, strategy, excellence, Lecture presented to the European Construction Institute Benelux Region. Vos, B., 1985, Himalaya Dagboek, Utrecht : het Spectrum Woodward, D.G., 1997, “Life cycle costing––Theory, information acquisition and application”, International Journal of Project Management, vol. 15, no 6, p. 335-344 Yeo, K., 2002, “Critical failure factors in information system projects”, International Journal of Project Management, vol. 20, no. 4, p. 241-246
14
Managementwetenschappen working papers 2003 - 2004: Green series gr03-01
A.C.C. Herst, R.J.R. Hommelberg The Risks and Returns of Management Buy-Outs. Evidence from the Netherlands
gr03-02
Marjolein C.J. Caniëls, Henny A. Romijn Firm-level knowledge accumulation and regional dynamics
gr03-03
Cees J. Gelderman Handling measurement and strategic issues in Kraljic's portfolio model - results of explorative case studies
gr03-04
David Davis, Ivo De Loo Black Swan Records - 1921-1924: From a Swanky Swan to a Dead Duck
gr03-05
Allard C.R. van Riel, JanJaap Semeijn Online Travel Service Quality: Towards Delighted and Loyal Customers
gr03-06
Henk van den Brink, Kees Kokke, Ivo De Loo, Peter Nederlof, Bernard Verstegen Teaching Management Accounting in a Competencies-Based Fashion
gr04-01
Marjolein Caniëls , Anke Smeets How to integrate didactic principles in an e-learning environment
gr04-02
Ivo de Loo, Peter Nederlof, Bernard Verstegen Behavioral Patterns of Controllers in the Formation of Control
gr04-03
Marjolein Caniëls, Kees Gelderman Buyer-supplier relationship development - Emperical Identification and Quantification
gr04-04
Peter Storm, Rob Janssen High performance projects- A speculative model for measuring and predicting project succes
Yellow series ge03-01
Bernard Verstegen Critical Accounting in the Academy
ge03-02
Huibert de Man De afstudeer-begeleider als coach: reflecties op ervaringen in een bedrijfskundige opleiding
ge04-01
Bé Albronda, Kees Gelderman Managing the Global supply Base through Purchasing Portfolio Management
ge04-02
Iwan Sewandono Vox populie vox dei? Versterken van burgerinitiatieven
ge04-03
Huibert de Man Bewust organiseren? De betekenis van onbewuste processen in organisaties en de consequenties daarvan voor strategievorming en organisatieverandering
ge04-04
John Gerrichhauzen, Albert Kampermann HRM en ICT onderweg naar morgen
15