Eight to Late

Sensemaking and Analytics for Organizations

The myth of the lonely project

with 4 comments

Introduction

Much of project management theory and practice is based on the premise that projects that are lonely – that is, they are unique undertakings,  largely independent of their organizational environment and history.  In an important paper published in 2003 entitled, No project is an island:  linking projects to history and context, Mats Engwalls argues that such a view is limited and misleading. This post presents a summary and some reflections on  the paper.

Background

It is easy to understand why the lonely project perspective dominates much of project management practice and research. A project manager’s focus is on his or her current project; history,  environment and context are therefore seen as irrelevancies.   Perhaps as a consequence, this view also permeates much of mainstream research in the field. There are exceptions, of course, such as the paper I  have reviewed in my post on the relationship between projects and organisations.

As Engwall states:

With few exceptions, research has been dominated by a perspective based on “the lonely project”. The primary interest has been in the structures and dynamics of individual projects, typically discussed from the individual project manager’s (PM’s) perspective. As an outcome, the project has been conceptualized as a lonely phenomenon, independent of history, contemporary context and future. Earlier experience, simultaneous events, and future intentions are seldom included in the analysis. In this dominating ontology, procedures employed in one project are considered to be unique and factors determining project success are considered to be due to the individual project in question

In contrast, organizational theory has long recognised that (permanent) organisations are influenced by their environment and history. As he states:

In organizational theory, the environmental impact on organizations is a classical issue. There are probably few organizational theorists today who would challenge the idea that external factors strongly influence the inner life of an organization.

Engwall’s contention is that projects, like permanent organisations, are best viewed as open systems whose structures and processes are influenced by their environment and the history/culture of the organisations in which they are embedded. He builds his argument through a detailed analysis of  two major engineering projects undertaken within one  organisation. We’ll take a brief look at the two projects first and then discuss his analysis in some detail .

The case studies and the approach

The two projects were carried out within a major Scandinavian utility company. Both projects were multidisciplinary, involving teams with expertise in construction, process and electrical engineering. The first project – referred to as the Hydropower project– was a major upgrade of a hydroelectric plant and the second – called the Transmission project – involved the design and construction of a high voltage direct current (HVDC) power link across the Baltic Sea.

The two projects had several features in common. These include:

  1. Both were internal projects – i.e. the deliverables were intended for use by the power company.
  2. The projects were carried out in roughly the same period (between 1985 and 1992).
  3. They were the two biggest projects carried out by the company during the period.
  4. Both projects were organized on a matrix principle. Work carried out in individual departments was coordinated by the project manager.
  5. The project managers on both projects were of a similar age. Both were seasoned engineers with plenty of experience of working on major projects.

As we’ll see, the two projects took very different trajectories despite these similarities.

Engwall gathered data on the two projects through a variety of sources – from archives, through interviews and even by direct observations in project meetings. He  then analysed the data from two perspectives: first, from the view of a near-autonomous project (the “lonely project” view) and  then from a viewpoint that takes into account historical and contextual linkages with the parent organisation.

The lonely project view

The hydropower project

This project was implemented by the hydropower division, one of seven engineering and business divisions within the utility. The project was run by a project manager who coordinated the engineering work done by the different divisions. Most of the work was done by internal staff, supplemented by externals where necessary.  Most important, though, is the fact that the project was run as a traditional “textbook” project. As Engwall puts it:

The PM was well aware of the message in project management literature and had the explicit intention of employing its concepts and techniques in his project. He put a strong emphasis on structuring, planning, scheduling, and cost control. He produced a project management handbook, defining guidelines and checklists for the project. He formally defined the roles and procedures of the project organization. He initiated start-up meetings, workshops, and seminars for key engineers, and assembled his project team for coordination meetings once a month. He felt responsible for all kinds of issues concerning the design and engineering of the hydropower plant…In many ways, his management approach resembled the role model of the project management textbooks.

The project manager felt that he was ultimately responsible for delivery of the design and engineering work, and his approach reflected this. In short: the project was run pretty much as recommended by project management orthodoxy.

The transmission project

This project was run by the transmission division of the utility. The project was managed by a team leader from one of the engineering departments within the division. The core HVDC system was procured from external vendor, but most of the other engineering work was done by different divisions within the company. The project manager’s main job was to coordinate the work done by the different divisions and the external party. He did not have as much positional or expert authority as his counterpart on the hydropower project. Further, he kept a much lower profile, often deferring to experts to make decisions. Significantly, neither the manager nor his deputy had any formal knowledge of project management principles. As Engwall puts it:

In relation to the Hydropower Project, this PM had a lower formal rank within the company’s hierarchy. In his position as PM, he had no formal authority at all. He held a degree in electrical engineering from a junior college. He was very humble, had a very low personal profile and was often silent during meetings. He, and his deputy, coordinated the project without an explicit management approach. Neither of them had any formalized training in project management and they had limited theoretical knowledge of project management methods and techniques. During the interviews, they often excused themselves for their lack of knowledge in project management theory.

Moreover, the project had no formal organizational structure. Project meetings were optional – it was up to the departments to decide whether or not send a representative. Most of the coordination work was done through direct (but informal) contact between the project manager and the engineers doing the work. The responsibility for scheduling and timely delivery of different modules was delegated to the engineering department doing the work. In short: the project was run without formal project management processes and controls.

Analysis

Surprisingly, the manager of the hydropower project had many more problems than his counterpart who ran the transmission project. As Engwall states:

The PM of the Hydropower Project encountered several difficulties when he tried to coordinate the activities of his project. Many of the participating engineers did not follow his instructions and decisions. The project was constantly delayed because the engineering departments were not paying enough attention to it. Furthermore, many of the engineering departments tried to perform their parts of the project independently of the other departments, and without the involvement of the PM. On many occasions, the PM found it impossible to gain control of the project, which he was formally in charge of. Time schedules and milestones were not taken seriously, costs were recorded without consideration to budget, and different departments were planning and engineering their technical power plant subsystems without sufficient coordination with the other players…

The project manager’s response to the above was pure traditional PM: he attempted to assert control by pushing the formal processes even further on an already mutinous team. Yet, despite his efforts, the project was judged a failure because of delays and budget blowouts.

In contrast, the transmission project ran smoothly, and was deemed a great success. The specifications were met within the stipulated budget. Further, the transmission link was operational several days ahead of schedule.

From the lonely project perspective, the difference between the two projects is paradoxical. As Engwall writes:

The PM with his formal authority, explicit management approach, and who deliberately applied state-of-the-art methods of project management was having significant problems, while the PM who lacked both formal authority and an explicit management approach, and who deviated substantially from the textbooks, was being significantly successful. How come?

As an answer to the question posed above, Engwall suggests that classical project management theory (as described in books and BOKs) is incomplete – i.e. there are factors that the theory does not take into account. To illustrate this point, he takes a broader perspective of the projects, one which includes the organisational environment (context) and history.  We’ll look at this organisational view next.

The organisational view – linking projects to environment and history

The hydropower project

On the technical side, one of the key requirements of the hydropower project was that many features and aspects of the existing plant had to be preserved for their historical value. It was also stipulated that the plant had to continue operating uninterrupted whilst the upgrade was in progress. These requirements greatly increased the technical complexity of the project.  Finally, the project was truly unique because it was the first time the organisation was carrying out a major upgrade within a single project; all prior upgrades had been carried out as a series of minor, ongoing extensions.

On the management side, the project was used as a testing ground for a new project management approach within the organisation. The new approach conflicted with the existing one in many ways.   For one, the project manager took on responsibility for coordinating work between different engineering divisions – something that, in the old approach, was done through direct contact between those responsible for the work. Consequently, many project personnel saw the new approach as a deliberate move by management to micro-manage their work and reduce autonomy.

As Engwall puts it:

For the first time, engineers and department heads, who were used to working almost autonomously, encountered a PM who was deliberately trying to control the project process by actively getting involved in their day-to-day work. The management problems of the project were, in this sense, the result of a collision between two philosophies: … traditional procedures…and [a] “modern” management style…The hidden agenda behind the client’s appointment of this specific PM for this specific project was as follows: to force the Hydropower Division to change its management procedures from within.

In short: there was a clear lack of trust and open communication between the project manager and the team.

The transmission project

The transmission project, because of its strategic importance, was strongly supported by top management. The project was therefore given high priority. Further, the project was considered interesting by engineers because of its technical novelty and complexity. Yet, despite the perceived novelty, the organisation had carried out many similar projects involving HVDC technology. Further, the company already had a longstanding relationship with the external contractor who was responsible for the core HVDC component: the players involved in the project were known to each other and, more importantly, trusted each other. The key team members – many of whom had worked on the earlier HVDC projects – had the same responsibilities as they had on those prior endeavours. The project was therefore not so unique.

Another important point is that the low-key management style of the project manager fit perfectly with the ethos and existing procedures of the organisation. Quoting from the paper:

The PM had been working at the division in over 30 years; he was a well-respected engineer and had an in-depth understanding of the inner life of the division. He manifested trust in his engineering colleagues and had no interest in challenging the traditions of his division. He did not fight for any formal power or official recognition as a PM. Once the HVDC contract was signed, he left most of the responsibility for its execution to the informal team of key engineers….the PM did not challenge the permanent engineering departments by fighting for more formalized procedures or methods in accordance with project management textbooks. On the contrary, his humble and informal way of coordination harmonized the existing norms and structures perfectly.

In short: the PM did his job in a way that was sensitive to the expectations of those who worked with him. He did not violate the (explicit or implicit) rules and norms of the organisation.

Analysis

When viewed through the lens of context and history, the following differences between the projects become apparent:

  1. The transmission project, because of its strategic importance, had greater visibility and prestige in the organisation. The fact that it was well supported by management and had interesting technical challenges made the project attractive to engineers within the organisation. In contrast, the hydropower project was low key and had little support from top management. Consequently, there was little incentive for engineers to devote time to it.
  2. The projects differed in degree of uniqueness: the organisation had more experience in HVDC transmission projects than it had in performing upgrades on functioning hydropower plants. The fact that the organisation had successfully carried out projects similar to the former reduced uncertainty associated with that project.
  3. The projects were managed using very different approaches. The manager of the hydropower project used an approach that did not fit with the existing culture and ethos of the organisation whereas the transmission project was managed in a way that was sensitive to institutional norms and practices. It isn’t surprising, therefore, that the manager of the hydropower project had more difficulty in getting the job done.

The paradox is thus resolved: a full understanding of a project must take into account the context of the project, and  the culture/environment of the host organisation(s).

Discussion

The author’s analysis suggests that project success factors are context dependent: a methodology or approach that works in your organisation may not work in mine.   An implication of this is that prescriptive project management methodologies are unlikely to work when they are applied without due regard to organisational quirks and circumstances. Several other studies support this conclusion – see my posts on going beyond best practices and project management in post-bureaucratic organisations for examples.

Another important implication of this work is that intrinsic properties of projects (such as size, scope, technology etc.) are perhaps less significant than extrinsic ones (such as organisational culture). As Engwall puts it:

… these [latter] factors have little to do with the technical content of a project per se, but rather with how different stakeholders interpret a project in relation to the procedures and traditions of its surrounding context. The findings suggest, for instance, that important aspects of a project’s inner life are dependent on the level of deviation between the practices applied within the project and the knowledge base and institutional structure of its organizational context.

The research also calls into question the notion of a project as a unique undertaking. Engwall’s contention, supported by the case studies, is that projects typically consist of a mix of unique and repetitive processes. We never begin with a completely blank slate, nor do we ever repeat exactly the same project.

Endnote

The obvious takeaway from the paper is that project managers need to be aware of the history, culture, strategic imperatives and social dynamics of the organisations within which their projects are embedded. They should then tailor their  approach based on their knowledge of these factors. As the case studies illustrate, project management best practices may count for little if historical and contextual factors are ignored.

At a more philosophical level, the paper illustrates that project success is contingent on a host of factors that at first sight have nothing to do with projects.  Often these factors will become evident only in hindsight,  after the project has run its course.   Managers can therefore never be absolutely certain that they have considered all the key variables on their projects. Consequently they should view any actions they take as being provisional,  subject to change as their knowledge  of the project evolves.

Written by K

October 21, 2010 at 5:04 am

4 Responses

Subscribe to comments with RSS.

  1. […] The myth of the lonely project: Discusses why project managers need to be aware of the history, culture, strategic imperatives and social dynamics of the organisations within which they work. Based on: Engwall, M., No project is an island: linking projects to history and context, Research Policy,Volume 32, pages 789-808 (2003). […]

    Like

  2. […] that failure is a consequence of over-zealous adherence to methodology (see my post entitled The myth of the lonely project for a detailed example).  In such cases the failure is often attributed to causes other than the […]

    Like

  3. […] major shortcoming of project management, as it is taught, is that it overlooks the fact that every project is invariably part of a larger system: namely, the hosting organisation and its environment. Understanding this is critical to the […]

    Like

  4. I think, Kailash, that trying to look for the causes in a causal manner is risky: IF you come with one cause or a bunch of them, they are only valid for the examples. I find it extremely difficult to build a sample space out of projects and, most of all, risky and most likely useless (we cannot draw conclusions about “ultimate” causes: that’s dangerous if you jump to the next project not in the sample).
    BUT we are allowed to say the group of causes as coming from the project context or even from its environment (for we don’t always map contexts too finely). We can say that the results had to do with the classical general item: governance, executive support and ownership, alignment (the engineers doing the hydro project were at odds with the execs!) and communications.
    I wouldn’t blame the Hydro’s PM for the failure: he was screwed well before he even began planning! The very charter [hidden] directives were impossible to match, like those HAL-9000 had! Yes, you can say that the guy hadn’t the clarity of mind as to say “well, you need to decide if you want to impose a management style or to complete the work”, but the guy, well, most likely hadn’t a saying in it.

    I think this is one of those great articles one has to save for the years, for it’s time-independent.
    Kudos!

    Like

    Ricardo Guido Lavalle

    October 10, 2016 at 2:24 pm


Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.