John Smyrk

Towards an outcome based project management theory

The importance of projects to improve operations management continues to gain wide acceptance. However, although all projects are approved in order to achieve outcomes (benefits) defined by the project funder, project management is often perceived by organisations as a process aimed at generating a unique output. While output delivery can still be accepted as an important milestone towards outcome achievement, a project should be considered complete only after the reason for its approval has been fulfilled. A model, based on such an approach has been developed. Practical implications of this model mean that although senior managers do not normally influence project results directly, they have an indirect effect on the eventual levels of success by clearly defining, analysing and validating the relationship between project outcomes and outputs. The added value of this includes the development of an outcome based project theory and the definition of the project owners new role.

An engineering approach for project scoping

Benefit realization is becoming a critical performance criterion measure for project success. However, the mechanism through which outputs eventually become outcomes has not yet been identified. This paper proposes that an output utilization mechanism is needed to explain the cause and effect relationship between a projects outputs and target outcomes. The paper describes such a utilization mechanism, and discusses its role in the generation of target outcomes. By expanding on the concept of output utilization, the paper suggests the utilization map as a new tool for project scoping.

The Input-Transform-Outcome (ITO) Model of a Project

The methodology proposed here not only highlights the central role of project benefits but also identifies processes that contribute directly to their successful achievement.

Starting a New Project

In the previous chapter, we proposed a sequence of global phases that span the life of a project. Here we discuss the first of these, initiation. Projects are triggered by the need to effect change, often associated with solving a problem or exploiting an opportunity. Regardless of a trigger, because they require the imprimatur of the funding organisation, proposals for all new projects should be presented for formal acceptance by whoever is recognised as the funder (defined here as the person or entity approving the budget and the project). A decision about funding is supported with some sort of formal document, conventionally identified as a business case. In this chapter, we discuss the processes surrounding development and approval of the business case.

An Interdisciplinary Approach to Scoping Service Delivery

When being considered for funding, all projects and service delivery initiatives should have a clearly defined scope. The scope for a project is formally declared in a statement of scope, which amongst other things, clearly identifies all of the outputs (deliverables) to be produced during the exercise. The scoping statement is the cornerstone of a project business case. Early in Initiation key players in a project face, what is called, “the scoping problem”: of all the alternative lists of outputs that might be proposed, which (if any) are “correct”? The scoping problem exists at two levels: one related to deciding on the list of outputs, the other related to deciding on the list of fitness-for-purpose characteristics that is to be applied to each adopted output. If not solved correctly, two situations can emerge: •A project is underscoped if its statement of scope is missing an output. If a project is underscoped it cannot generate its target outcomes (equivalent to benefits). If a project cannot generate its target outcomes, its business case cannot be realised – thus exposing it to failure. •A project is overscoped if its statement of scope includes superfluous outputs. If a project is overscoped its costs will be unnecessarily high and its timeframe will be unnecessarily long – thus making its business case less attractive. Furthermore, the eventual worth of the project will be lower than achievable – leading to underperformance of the organisation’s project investment portfolio. A reliable scoping statement is a precondition for estimation of a project’s costs and duration, which require in logical sequence: estimates of resources, a comprehensive model of the work involved and a scoping statement. Conventional approaches to projects assume that the issue of scope has been decided in other forums that lie outside the project proper and so the focus of their attention is on how to produce the outputs that have been decided elsewhere. PRINCE2 (OGS, 2007) acknowledges a necessary relationship between outputs and benefits, but fails to explain a mechanism linking the two. Aside from a general agreement that outputs need to somehow contribute to the project’s goals, little is provided in the existing literature by way of tools and techniques to solve the scoping problem. Organisations appear to address this issue by simply adopting arbitrary lists of outputs for initiatives – or by making intuitive judgements about whether particular outputs should be in or out of scope. When a project is eventually completed, the benefits that flow will be completely determined by the outputs that have been produced. If outputs were set arbitrarily in the scoping statement, then benefits will be equally arbitrary and so the resulting net worth of the exercise may or may not make for a sensible investment. Clearly such approaches expose projects to unreliable scoping. Following the high complexity of scoping service delivery, the objective of this research is to develop an interdisciplinary approach to project scoping: this approach will be based on effective models from the areas of Organisational Behaviour, Strategic Management, General Management and Operations Management.

Executing a Project: The Roles of the Key Players

The previous chapters have been concerned with the processes that precede work on the project proper. Because of its magnitude (in terms of duration and resources), execution is the most prominent phase in the life of a project. Execution is outputs-focused and, accordingly, it is dominated by the work required to produce, deliver and implement those outputs. That work is described and defined in the instruments discussed throughout Chap. 6 (in particular the WBS and Gantt chart). Although the plan defines what we want to happen, execution will inevitably unfold differently. Those same instruments can now be employed to monitor the project so that we are able to manage deviations from plan. Here we discuss the involvement of the key players in this activity.

Planning a Project: The Roles of the Key Players

The planning phase of a project provides a critical link between the business case (as a statement of intent), and the detailed guidance required for execution. This phase is mainly concerned with assembly of a project plan, a document that effectively serves as a comprehensive “script” for the work that is necessary to produce the project’s outputs. While a business case is intended to support a funding decision, the project plan is intended to support a decision about starting the work required to fulfil the business case. Project planning and the processes that underpin it are not only firmly-established in the literature, they are more than adequately supported by an extensive toolset and thoroughly understood by the profession. This chapter does not attempt to provide a detailed guide to such well-known territory, but instead approaches the topic by considering the implications of new concepts from earlier chapters for the role of each key player in planning.

Achieving Success in Projects

The discussion surrounding this framework suggests that the conventional IPO (input–process–output) view is incapable of supporting any meaningful decisions about a proposed project (decisions that should be based on a clear understanding of the target outcomes sought by a funder from the venture). This shortcoming in the conventional approach also means that it cannot be used to make judgements about the eventual overall success of the exercise. In general, judgements about success require that appropriate criteria be defined and applied as part of a formal evaluation methodology. Conventional wisdom suggests that a project is successful if its outputs are delivered fit-for-purpose, on time and within budget. If, however, as is implied by the input–transform–outcome (ITO) model, outcomes reflect a project’s purpose, then the conventional view breaks down (because it appears to ignore outcomes). In this chapter, we introduce an assessment framework for projects and explore some key issues surrounding its application. We do this by: assembling a general framework for gauging project performance, examining shortcomings in the conventional treatment of success and suggesting directions for resolution of those shortcomings. In the course of this discussion, we propose a new approach to judging success, based on the concept of project “worth”. We also review the results of some research into the way project success is treated in practice. From all this we conclude that there are three distinct sorts of judgement that can be made about a completed project. These relate, in turn, to: the investment made by the funder, the performance of the project owner and the performance of the project manager. We then go onto consider some important determinants of success by discussing the concept of critical success factors (CSF), examining some limitations of that concept and investigating an alternative approach, entitled critical success processes (CSP).

Projects: An Executive Context

Regardless of the area in which a business operates, its executives and senior managers are under continual pressure to bring about beneficial change. This pressure emerges as an unrelenting demand to undertake projects (as instruments of change) and undertake them well.

Realising Outcomes from a Project: The Roles of the Key Players

Outcome realisation is that portion of output utilisation that occurs up until the flow of target outcomes has been secured. Beyond that point, in many projects, utilisation continues as a regular business operation. Accordingly, the focus of this phase is not only with ensuring that outcomes are being generated as planned, but also that, in such cases, there is a handover of responsibility for future utilisation from the project to operations managers. This chapter deals with a significant extension to what has traditionally been defined “the project” in practice and literature. The discussion covers the roles of the key players from the point where outputs are delivered successfully, until project outcomes are secured.