Derek H. T. Walker and Steve Rowlinson
Chapter introduction
Early project management texts tended to assume that projects were substantially tangible and flowed along a well-trodden path. The early texts such as that edited by David Cleland and William King (1988) have very structured and traditional content that stresses techniques, examples from solid tangible projects such as those found in construction, advanced manufacturing, aerospace, with some minor attention directed towards IT projects from a programming and development perspective. The promise of business-development-type projects and intangible projects such as change management and process re-engineering has been acknowledged, but there was little written about these. That situation has been more recently remedied and there is a rapidly growing interest in these less-tangible-projects, and new texts have been written to reflect this; for example, the one edited by Peter Morris and Jeffrey Pinto (2004). That book, which will probably remain a ‘must’ for most project managers in the future has, for example, sections devoted to strategic portfolio programme management and supply chain management. That particular text clearly demonstrates the flowering of PM attention to being not only a part of general management theory but also of leading the way. Most management theory, particularly strategy development, have stressed the need for better implementation (Mintzberg et al., 1998) but mainstream management texts generally fail to adequately grasp the PM nettle. We suspect and suggest that is because mainstream management literature has viewed implementation and ‘opera-tions’ as a lesser form of intellectual pursuit than strategy and planning and so has generally overlooked the PM literature. We do not wish to appear as complaining about this perceived shortcoming; we observe this as a theory gap worth filling. We also assert that this gap can only be effectively filled by absorbing and reframing mainstream management theory to a project, pro-gramme and portfolio context. By doing so, we attempt to expand the inter-est in PM theory and practice. One inevitable outcome of this changing focus is that we must recognise the range of types of project and the management approaches that necessarily flow from that realisation. This chapter adds to
that emerging perspective as well as providing a hindsight perspective on the forms of procurement options that have evolved over the decades to cope with a diverse range of project types and their realisation needs.
This chapter is thus presented in three broad sections and a vignette at the end of the chapter presents a scenario, and prompts relevant questions flowing from that scenario. The first section deals with a discussion on project types and their needs. The next section logically follows by outlining the various procurement options and how they may best fit the project type and need requirements. The third section focuses on writing and evaluating project proposals, and also contains a brief description of where contract administration fits into this picture. The chapter ends with a vignette and suggested activities and questions that readers can tackle to better frame their learning from this chapter.
Project types, forms and phases – influencing procurement choice
The PMBOK stresses the need for deciding what a project should deliver and how to plan to deliver that objective (PMI, 2004). There remains, however, a tension between taking a top-down and bottom-up approach to defining the scope of a project. The bottom-up approach essentially relies on a large number of well-understood and well-identified components that can be grouped into assemblies and these configured into subsystems, and thence into systems. A project becomes the summation of these systems that delivers a need. That need can have quite different systems that when brought together satisfy that need. Moreover, systems can include tangible parts such as a building or a weapon such as a ship/plane or missile delivery platform, as well as intangible systems such as training in the correct use of the weapon system, or commissioning a building including training in maintenance and facilities management, for example. Even these ‘hard’ or tangible projects have some ‘soft’ deliverables. Crawford and Pollack (2004) provide a useful discussion on this topic and link the concept of
‘hard’ projects or project objectives with objectivist scientific paradigms that believe that the truth lies ‘out there’ as a fixed reality. This approach led to a predominant systems view, while ‘soft’ projects relate more to subjective concerns, and is interpretive in nature, seeing sub-text and inexplicit needs as being highly important. This is a view that will be discussed further in this book, particularly in Chapter 3 relating to stakeholder management and in Chapter 6 relating to project performance measures.
The dichotomy is not complete as there has been an emerging use of a modified systems thinking approach (soft systems methodology or SSM) in project management, first developed by Checkland (1999) and used more recently to investigate project learning from experience and project learning histories (Maqsood et al., 2006). Further, Crawford and Pollack (2004)
identify a framework of seven dimensions that form the basis for a framework of understanding both hard and soft issues in analysing both hard and soft sides of the project. These are (Crawford and Pollack, 2004: 646) as follows:
1 the clarity of goals/objectives – how clearly these have been expressed;
2 the tangibility of goals/objectives – how well these can be defined, visualised or otherwise expressed;
3 success measures – the kinds of measures used to describe project success;
4 project permeability – the extent to which the project is subject to external risk and uncertainty influences;
5 number of solution options – the approach to exploring and refining goals;
6 degree of participation and practitioner role – the roles that team members adopt when managing a project and
7 stakeholder expectations – the view held of what is a valid expectation for the project that influential stakeholders believe to be reasonable.
They argue that this framework can be adopted by project managers when developing a strategy for delivering a project, and mapping issues against the seven dimensions so that they can avoid having a poorly balanced implementation and project definition strategy. If the expectation for the project is substantially ‘hard’ then there will be a clearly different PM approach to be appropriately adopted than for a ‘soft’ project. In their paper they illustrate their framework with three different case studies from public sector organisations, and conclude that the framework was useful in providing a structure to better analyse what went on in those projects to generate lessons learned. This kind of framework, based on experience and project histories gathered using the framework to provide a consistent way of making sense of project delivery performance, can be helpful at the project procurement design stage. For example, by improving understanding of hard and soft issues relevant to a particular project, a better fit for a delivery model, coordination of team members and communication media can be established.
During the beginning of the final decade of the twentieth century there was a vigorous debate about the value of and optimal form of developing a work breakdown structure (WBS) for a project in order that effective plans, monitoring, coordination and control could take place. Bachy and Hameri (1997), discuss the planning approach undertaken in a highly complex 10-year ‘ordeal’ as they call it, to develop a large expensive piece of scientific equipment – a Large Hydron Collider (LHC) – which allows scientists to look into the structure of matter. Their paper clearly favours the positivist paradigm. They advocated first developing a detailed and highly explicit product breakdown structure (PBS) or parts-list that defines
the minutiae in an intensely bottom-up fashion. They then detailed an assembly breakdown structure (ABS) that describes how the parts should be assembled, and incorporated logistics and material availability and other relevant production and manufacturing data and information. They used the ABS detail information to develop a top-down approach tree-like representation of the project as a series of connected sub-systems or work breakdown structures (WBS) organised by function and component. The head of the WBS was the ‘tangible project outcome’ and a series of high-level components cascaded down into a breakdown of the work to be done.
Detailed WBS work packages define suitable ‘chunks’ that they could provide a clear and simple description of what was to be done (objectives).
An organisation breakdown structure (OBS) followed the WBS to define responsibilities and accountabilities and this, linked with the WBS, informed the way that resources would be consumed to deliver the project.
The WBS and OBS formed the basis of the plan and in many ways is similar (but less detailed) to that used in the construction industry and other engineering applications often referred to as a global method statement and detailed method statement (Walker, Lingard and Shen, 1998). This approach is useful for integrating a range of plans, such as a risk manage-ment plan, an occupational health and safely plan, and an environmanage-mental plan (Shen and Walker, 2001) that can provide the basis for the project team to be sufficiently prepared for identified risks and have sufficiently modelled scenarios to be able to be in a position to cope with unexpected circumstances that distort the validity of planning assumptions (Walker and Shen, 2002). Lammers (2002) points out how complex the WBS on many projects can become and argues that the PBS also has a function of allowing tags or attributes to be linked to the WBS through the PBS so that a range of attributes can be stored in a data base that fully describes and defines the work packages. Turner (2000) recommends that work packages on a project of 1 year could have about 20 or so packages of work each delivering a project milestone with about 5–10 activities of work (each with resources and accountabilities clearly stated) within each work package that would take about 2 months to complete.
It is interesting to contrast the above with how PM and planning for con-trol is handled in other industries where different paradigms prevail. The arts provide such a contrast as the view that prevails amongst creative PM teams is one of emergence rather than complete and rigid specification. For example, in sculpting an outcome such as the famous statue of David, the view allegedly expressed by Michelangelo was that he knew that the statue was inside the block of stone, he just had to liberate it (Briner, Hastings and Geddes, 1996). The live entertainment industry also provides another useful example. Hartman, Ashrafi and Jergeas (1998) provide an account of 14 entertainment project events in Alberta ranging from sports to music projects. It is clear from their account that while each event demands that
they are completed on time, the mindset of the PM teams is quite different to the more traditional projects discussed in the preceding part of this discussion. They identify important major differences in PM practices that suggest different paradigm and value systems from construction of IT projects; for example: (Hartman et al., 1998: 270). Artistic creativity is highly valued so that ephemeral and intangible tacitly ‘understood’ performance expectations are real outputs as well as outcomes that are expected – failure to deliver on expectations results in shame and loss of face. The way that work is defined and undertaken is fluid and undefined, as may be seen by the common saying about such projects, ‘It will be OK on the night,’ mean-ing that the culture forces people involved in project delivery at a range of levels in a ‘hierarchy’ to ‘muck in’ when required to ensure delivery on time.
The authors (Hartman et al., 1998) and others (DeFillippi and Arthur, 1998) stress that we have much to learn from such projects. It is interest-ing, from a procurement point of view, that many of these projects use volunteer labour or those who expect to sacrifice their present immediate potential return to gain ‘experience’ for expected future benefit not only from knowledge gained but also social capital such as trust and respect from those involved in the projects.
This leads us to pondering if there is a useful typology of projects that helps us to (1) identify different types of projects that would need a different delivery approach and (2) provide some guidance on how to design a procurement choice that best fits the need for the type of project. From the above discussion it seems obvious that a micro-management approach, a procurement choice with its inherent contract requirement and behaviour expectation inherent in the scientific project example (Bachy and Hameri, 1997), would be unenthusiastically embraced and delivered for the projects described by Hartman et al. (1998). Two sets of authors provide us with some guidance: Turner and Cochrane (1993) developed a goals and methods matrix that is useful in understanding the needs of different project types that can lead us to develop appropriate procurement strategies to meet the needs of these projects. Another way of looking at project types was presented by Shenhar and Dvir (2004). Both of these views shed light on our understanding of the impact that project type can have on procurement choice that encompasses contractual requirements which in turn may impose obligations that affect PM behaviour and culture.
Turner (1999) in his text book identifies a number of project types and PM styles that relate to these. In Turner’s paper with Cochrane (1993) they identify four types of project based upon a 4-quadrant model of methods being well defined and goals being well defined (yes-no). Their typologies are as follows:
1 Engineering projects or ‘earth’ projects have both goals and methods solidly defined. Early published project case studies typically cite
construction, shipbuilding, aerospace and manufacturing projects as examples because they attract a ‘scientific’ view of operations management influence. The example presented by Bachy and Hameri (1997) typify this kind of project.
2 Project development projects or ‘water’ projects have poorly developed methods but well-developed goals. These are characterised as being somewhat fluid but structured in the way that a river, stream, lake or ocean naturally creates a boundary. The Bachy and Hameri (1997) case could have been looked at this way if the positivist paradigm of
‘certainty of solution’ (the research equipment design) was questioned as being merely ‘the option’. However, it can be useful to view this kind of project this way if the procurement aim is to specify a fixed outcome (or set of outcomes) while leaving delivery methods flexible – rather than demanding any particular process of micro-management.
3 Applications software development or ‘fire’ projects have a well-defined methodology but poorly defined goals. The procurement emphasis may be directed towards requiring a particular methodological approach that is known (or reasonably assumed) to be successful while holding the end goal more fluid. The ‘fire’ could be seen as air that is focused somewhat like a flame generated by concentrating the rays of the sun through a lens.
4 Research and organisational change projects or ‘air’ projects have poorly defined methods and poorly defined specific goals. These are characterised as being illusive and generally invisible though these projects can be redefined – by including intangible goal elements through a process of linking intangible to tangible outcomes – see Chapter 6 and recent research in this area (Nogeste, 2004; 2006; Nogeste and Walker, 2005). The key to making these projects less difficult to deal with, is to either separate the outcomes into several phased projects or to fully link the tangible and intangible outcomes.
The key to success in using this typology is to recognise the realities of the type of project and to intelligently design a project governance structure, and through the procurement strategy require that this governance structure acknowledges the project type and ensures that an appropriate procurement choice delivers the appropriate project controls and goals/objectives/vision to match the type. Where necessary, projects may be segregated into several linked projects, such as one to deliver the output and another to deliver the outcome if a radically different paradigm means that one PM group is ill equipped to deliver both outcomes and that radically different styles and types of PM team are required.
Aaron Shenhar has devoted a considerable amount of energy in thinking about types of project and appropriate management styles. His co-authored book chapter (Shenhar and Dvir, 2004) builds upon a number of previous
papers (Shenhar, Dvir and Shulman, 1995; Shenhar and Dvir, 1996;
Shenhar, 1998; 2001; Shenhar, Dvir, Levy and Maltz, 2001) in which he extends the ideas identified above by (Turner and Cochrane, 1993). One of the extending features that Shenhar and Dvir identify is how pace as part of pace, complexity and uncertainty intervenes between the project product, task and environment and appropriate project management style. They develop what they call the Uncertainty, Complexity, Pace (UCP) Model (Shenhar and Dvir, 2004: 1267) where the Uncertainty dimension can be seen as a combination of novelty and technology. Their Novelty, Complexity, Technology and Pace (NCTP) framework was developed to guide project management style. The PM style can of course be influenced by procurement choices that favour an appropriate PM style. The framework has four dimensions.
Novelty is measured as derivative, platform or breakthrough. These describe the extent to which methods are well-defined. Derivatives are extensions of existing products or methods. Platforms are new generations and refinements in existing families of products or methods. Breakthroughs are paradigm shifts going beyond innovation to invention or significant reframing that develops a totally new way of looking at a problem.
Complexity is measured as assembly, system and array. Complexity refers to moving from an assembly to a system and array. An assembly involves creating a collective of elements into a component. A system, by contrast, involves a complex collective of entities into a new form, a re-configuration or re-framing of parts into a new whole with different characteristics to the pre-existing system. An array-type project radically shifts the paradigm.
An array defence project may turn a set of physical network relationships into virtual ones where a radical new technology is introduced as the change agent.
Technology is classified as: low tech that relies on well-established technologies; medium tech that uses an existing technology base and incrementally extends it; high tech involves new technologies that may have been experimented with and tested in other contexts and so is ‘new’ in the applied context, but at least there is a reasonable body of knowledge of its impact and influences in other contexts; super high-tech projects are based upon new paradigms when the project was initiated.
Pace is perhaps the new concept in project types. Regular refers to an evolution as it happens with little sense of forced urgency. Fast/competitive projects are motivated by a sense of urgency so they do not follow a natural rhythm but are accelerated by force. Blitz/critical, as the tag implies, is driven by an acute sense of urgency and turbulence. The implication that these typologies present revolves, in procurement terms, around how to best encourage performance, accepting and trading risks, and developing a rewards and penalty structure that matches a project type to what can be otherwise developed by other PM teams. The image of flogging a dead
horse may be crude but it is relevant in this context. Project sponsors need to recognise the project context, and match a risk and reward strategy as well as recognising the value generated by intellectual input of teams in
horse may be crude but it is relevant in this context. Project sponsors need to recognise the project context, and match a risk and reward strategy as well as recognising the value generated by intellectual input of teams in