Eight to Late

Introduction

Most of the research and practice literature on project management tends to view projects as being isolated from their environment.  It is obvious to anyone who has worked on a project that this isn’t so. In view of this,  it is useful to look at the relationship between projects and the organisations that host them.  This post looks at this issue, drawing on a paper by Gernot Grabher entitled, Cool Projects, Boring Institutions: Temporary Collaboration in Social Context.

The emergence of projects

Grabher begins his discussion with a sketch of the how projects emerged as a distinct work form. Projects  – i.e. time bound, goal focused activities – have always been around. The modern notion of a project, however,   arose from a development philosophy that came out of the US Department of Defense in the 1950s.  He states,

…Instead of fragmenting and pre-specifying the development of military technologies along functional disciplines, these technologies were described in relation to their objectives, i.e. the military parameters of these weapons. The pacing of these concentrated efforts was crucial: parameters had to be met, goals had to be accomplished according to a grand scheme (program?) to win the armament race. Development processes that earlier were seen as separate activities were now conceptualized as an integrated entity called a program, system or project. The overwhelming scale of these projects in terms of financial and scientific resources as well as their ambitious timing created formidable problems of coordination and control. Experiments with various forms of organizational control ultimately lead to the professionalization of the role of the project manager…

From thereon the concepts of projects and project management were taken up (with much enthusiasm and optimism) by business and industry. The formalization of various project management methodologies, standards , qualifications and trade journals can be seen a culmination of this process.

Given the military-industrial origins of the profession, it is easy to see why a “command and control” philosophy dominates much of project management thought and practice. Many of the early projects that are paraded as textbook examples of successful projects operated outside normal organizational oversight. They were, to a large extent, deliberately shielded from external influences.  I believe this is why isolation from the environment is seen as a Good Thing by project managers –  problems of coordination and control become so  much simpler when one does not have to manage relationships and politics that are (perceived as being) external to a project. This practice may be necessary and workable for classified projects that run on billion dollar budgets, but it doesn’t work so well in   environments that most project managers work in. Projects don’t take place in a   vacuum; they are born, live and die in real-world organizations. To forget that is to see the “tree of the project” and miss the “forest of the organization.” This is particularly so because,  unlike those near-mythical mega-projects of the 1950s,  the efforts that you and I work on are deeply entwined with their hosting organizations.

Organisation-related characteristics of projects

Grabher then notes some characteristics of projects. I summarize these in the next few paragraphs.

First, it is interesting that the original meaning of the word “project” referred to a “proposal” or “idea”, rather than a “directed, time-bound effort.” Grabher points out that this  shift in meaning was  accompanied by a shift in focus: from project as idea (or goal) to project as process (or means to achieving a goal).   Projects are thus seen as vehicles for achieving organisational goals.

Second, Grabher notes that projects are often hard to decompose into constituent tasks, and that such a (commonly agreed) decomposition is only possible when stakeholders interrelate with each other continually.  This underscores the importance of communication in projects.

Third, Grabher highlights the importance of the project manager (he uses the term contractor) as the “lynchpin on whom trust is focused.” The role of the manager is particularly important in projects on which team members do not have the time to get to know each other well.

Fourth, the project manager / contractor is also the wielder of organizational authority as far as the project is concerned. He or she is, in this sense, a representative of the organization – a person whose presence underlines the fact that the project exists to achieve specified organizational goals.

Finally, deadlines are a defining aspect of projects. They serve several functions. For example, they ensure that a sense of urgency for action and progress remains through the duration of the project. They also might serve to legitimize execution of project work without external interference (this argument was frequently used in the military-industrial projects of the 1950s). But above all, the final deadline,  which culminates in the termination of the project, also serves as a connector to the rest of the organization. It is a time in which handoffs, documentation, team disbanding etc. occurs, thus enabling the results and  experiences from the project disperse into the wider organization.

Projects in organisations

The characteristics noted above highlight the dual nature of projects: on the one hand, as noted earlier, projects are seen as semi-autonomous temporary organisations, but on the other they are also firmly embedded within the hosting organisation. An effect of the latter is particularly evident  in consulting and software services firms (or even corporate IT shops), which tend to do similar projects over and over.  As Grabher notes,

[projects] apparently operate in a milieu of recurrent collaboration that, after several project cycles, fills a pool of resources and gels into latent networks. Project organising is mostly directed towards the actual realization of a potential that is generated and reproduced by the practice of drawing on core members of (successful) prior projects to serve on derivative successor projects. Such chains of repeated co-operation are held together (or cut off ) by the reputation members gain (or lose) in previous collaborations…

Another aspect of embedded-ness is the co-location of team members within a larger organizational milieu. The standard benefits of co-location are well known. These are:

1. Savings of transactional costs such as those incurred in communication, supervision of staff at remote locations etc. See my post on a transaction cost view of outsourcing for more on this.
2. Co-location improves the efficacy of communication by encouraging face-to-face interactions.
3. It enables “near real-time” monitoring of the health of the project and its environment.

There’s more though. Grabher notes that  in addition to the above “intentional” or “strategic” benefits, co-location also ensures that  team members are exposed to the same organizational noise – which consists of  a “concoction of rumours, impressions, recommendations, trade folklore and strategic misinformation (falsehoods!).”  Co-location enables project teams to make collective sense of organisational noise – this shared understanding of the environment can contribute significantly to the creation of a team spirit.

A related notionis that of enculturation: that is, the process of becoming an accepted member of the group, or an insider. This has less to do with expertise and knowledge than learning the unspoken rules and norms of a community.  Although becoming a member of  a community has much to do with social interactions within the workplace, there is more: a lot of essential know-how and know-what is transferred through informal interactions between senior members of the team (who are often senior members of the organisation) and others.

Projects generally need to draw upon a range of organizational resources: people and physical infrastructure being the most obvious ones.   Grabher notes that the increasing projectisation of organizations can be attributed to a perception that project-based management is an efficient way to allocate productive resources in a flexible manner   (…whether this perception is correct, is another matter altogether). However, there are other less obvious influences that organisations exert too.  For example,  Grabher points out that organizational norms and rules provide the basis for the emergence of swift trust, which is trust based on roles and professional ability rather than individuals and personalities.  Further, at a higher level,  organizational culture plays a role in determining how a project is governed, managed and run. These explicit and implicit norms have a stabilising influence on projects.

In addition to the stabilizing influence of the hosting organisation, projects also offer opportunities to build and enhance links between organisations – for instance, strategic partnerships.  This is, in effect, institution building aimed at leveraging the strengths of the participating organisations for a greater joint benefit. In such situations the participating organisations take on the role of “lynchpins” on whom trust is focused.

Grabher makes the point that firms (and institutions comprised of firms) not only provide resources that make projects possible, but also host a range of processes that are needed to organize and run projects. For one, projects are usually preceded by several organisational processes involving deliberation, selection and preparation. These activities have to occur for a project to happen, but they normally fall outside the purview of the project.

A somewhat paradoxical aspect of projects is although they offer the opportunity for enhancing organizational knowledge, this rarely happens in practice. The high pressure environment in projects leaves little time for formal training or informal learning, or even to capture knowledge in documents. To  a large extent the hosting organisations are to blame: Grabher suggests that this paradox is a consequence of the lack of organizational redundancy in project-based organizing.

I’ll end this section with the observation that the social dimension of projects is often neglected.  Projects are often hindered by organizational politics and inertia.  Further, a large number of  projects fail because of varying perceptions of project goals and the rationale behind them. Although it seems obvious that a project should not proceed unless all stakeholders have a shared understanding of objectives and the reasons for them, it is surprising how many projects drift along without it.   Many project planners neglect this issue, and it invariably comes back to bite them.

Conclusions

In the conclusion to the paper, Grabher states:

The formation and operation of projects essentially relies on a societal infrastructure which is built on and around networks, localities, institutions and firms. Relations between temporary and permanent systems are not a matter of straightforward substitution but have to be regarded in terms of interdependence. ‘Cool’ projects, indeed, rely on ‘boring’ institutions…

This is unarguable, but it should also be kept in mind that projects are often subject to negative organisational influences which can slow them down, or even kill them altogether (which is perhaps why those early defence projects were set up as near-autonomous initiatives). So  although  it is true that projects  are made possible and sustained by the organisations they’re embedded in,  they are sometimes  hindered by those very organisations .

To sum up in a line:    Projects depend on organisations not only for material and human resources, but also draw sustenance from (and are affected by)  the  social environment and culture that exists within those organisations.