Context element

From apppm
Jump to: navigation, search

Contents

Abstract

The topic of this article is the context element of project management. The context element is a concept in project management, that provides an understanding of how the outside environment can impact a project. The environment of a project determines many the limitations, requirements and possibilities of the project. This article will provide a theoretical understanding of what the context element is and describe the different categories of contexts. Furthermore the article will present the relevant models that can be used to understand and manage the context element, and lastly it will present the limitations of the context element concept.

Background

The context element is a concept in project management that is related to the environment around a project and how it's influenced by it. The context of a project sets limitations and can create challenges. It is important to take the context into account, so the project can be planned and adjusted according to the limitations set by factors outside the project. The context element is a broad concept and covers a wide range of different factors of different importance that influence the limitations, the resources and many other aspects. In order to get a better overview of the concept, it can be organised into the different categories, the project context, the temporal context, the organisational context and the external context [1].

The project context

The project context covers the elements designed for projects within an organisation, but not the project specifically. This includes project governance and steering committees, the Project Management office, program and portfolio management. Many organisations have specific policies and procedures for projects that are expected to be followed. Projects also exist in organisational cultures consisting of the shared values, norms and expectations. In companies that are more innovative and entrepreneurial, high risk proposals are more likely to be accepted, and vice versa for conservative organisational cultures. Another example is the view of hierarchy within an organisation. In the Nordic countries there is a tendency towards a more flat hierarchy, which likely means a project management style of top-down leadership might cause conflicts [1],[2].


The project context can also be related the type of project. In general four different types of projects can be identified [6].

  1. Engineering projects
  2. New product development
  3. Systems development
  4. Organisational change projects

The competences required for projects in the different categories can vary widely. For example organisational change projects deals with human dynamics, which sets certain requirements to the people working in such projects. On the other hand, New product development may involve largely repeatable processes which requires different competences and procedures [5].

The temporal context

Figure 1: The different temporal factors that can influence a project [8].

Any project exists in the context of history. The interior of any project has to be understood in relation to it's past, concurrent and future context. The temporal factors that influence projects are shown in Figure 1. The lessons from past projects are important, as they have information about the weaknesses and strengths of certain processes, procedures, techniques and tools [3]. The pre-project politics are important, as it's often in this phase that the most important political basis for project success is decided.

Parallel courses of events, such as simultaneous projects in the same organisation also influences the interior of a project. Resources might become unavailable due to change of plans of the simultaneous projects. Also a projects role and function in it's hosting organisation influences the project. For example projects viewed as vital will have easier access to extra resources than projects viewed as less important [8].

The future plans and visions of the parent organisation also influences a project. Projects that are part of programs that seek to create certain benefits should be aware of what these benefits are, and how their project might influence them. Projects that are aligned with these long-term benefits might be considered as more vital, and as such have easier access to resources form the parent organisation.


There is also a broader temporal context, regarding the time in history. Projects undertaken in the 1960's existed in a different context than projects today. People had different skills, different motivation, etc. In todays world there is a large focus on sustainability and development of the third world. One example of this is the UN Sustainable Development Goals. Projects that can somehow align them self with these goals might inspire the team and gain the support of stakeholders [7].

Organisational context

Figure 2: Organisational structure of a functional organisation and a projectized organisation [2]

All projects, except rare cases, exists within a organisational environment and a corporate context. Classically organisations that undertake projects can be described as being functional or projectized organisations. It should be noted that the classification is a spectrum and many organisations lie somewhere between.

Functional organisations

In traditional functional organisations the staff is organised by their type of work and there are clear reporting lines to the respective management of each work function. When projects are undertaken in functional organisations they are often separated into phases corresponding to the responsibilities of the functional groups. For example in product development, the first phase is often the design phase and will be undertaken as a individual project by the design/engineering department. Subsequently the manufacturing department undertakes the next phase as an individual project. This means that questions and challenges related to their other phases of the project often are communicated to the department head, who consults the associated department head, who then contacts the relevant staffing. This process is cumbersome and delay decision making which can lead to delay of the projects [4]. Another issue that project managers in functional organisations should be aware of is, whether functional managers are rewarded for assigning staff time to projects. In these cases it is important for the project manager to control that assigned staff is being used effectively [2].

When cross-functional projects are undertaken in functional organisations some challenges might arise for the project manager if the overall leadership is not clearly defined. One solution is to define clear project controls at the start of the project, and agreeing these with the project board. This will help to "ensure that the project manager understands the level of interaction and support to expect during the project and is given appropriate exposure to other areas of the corporate organization" [3].

Figure 3: Balanced matrix organisation and composite organisation [2]

Projectized organisations

Project based organisations are typically companies that derive their primary revenue from projects (engineering firms, government contractors, consultants etc.). In projectized organisations the project members are typically co-located regardless of their functional group and reporting is typically done directly to the project manager. For projects undertaken in these organisations, the project management often have a greater deal of independence and authority over the allocated project staff. These organisations often have systems in place that support the project management such as financial systems for accounting and reporting of projects [2].

Matrix and composite organisations

Organisations that are both functional and projectized are called matrix organisations. The matrix organisation evolved during the late 1960 in order to push decision making to a lower level without loosing the inputs of all affected units [4]. In weak matrix organisations the role of the project manager resembles more that of a coordinator, while the strong matrix organisation resembles the projectized organisation where the project management have more authority, even though the organisation still maintain the traditional functional departments. The balanced matrix organisation, shown in Figure 3 is somewhere in between. Most modern organizations are composite organisations, that have a mix of all these traits at various levels in the organisation. Even highly functional organisations will create special project teams to handle crucial projects.

External context

The external context consist of institutions and factors outside the control of the organisation hosting the project. Even though these factors are outside the control of the project management it is crucial to be aware of the external context.

Standards and regulation

Standards are collections of rules, guidelines and practices published by a recognised body. Compliance with standards are typically not mandatory but only recommended. Standards are important because they facilitate business interactions, enable compliance with regulations, provide interoperability between new and existing products, etc.

Regulations are mandatory, with compliance regulated at different levels either governmental or organisational. In a danish context the Eurocodes in construction are an example of a collection of standards that are also regulations, as compliance is mandatory by danish law [2].

Internationalisation and cultural influence

In the modern world more and more projects consists of contributions across borders. In international projects it is important to be aware of the impacts of time-zones, national and religious holidays, travel requirements and so on. Likely it is important to be aware of the cultural context that a project operate within. The cultural context impacts the way that people and organisations interact [2].

Social-Economic-Environmental sustainability Essentially any project undertaken has an social, economic or environmental impact, both intended and unintended. As more and more organisations are held responsible for these impacts, it is important for project managers to have at least some awareness of the social, economic and environmental context that it is a part of [2].

Application and Tools

The context element is a concept, and can therefore not be applied as a tool itself, but is rather something that the project manager should be aware of. In the project managment literature there exist a range of models and tools that can help understand and manage the contextual element of a project. In this article a few tools will be presented in depth.

Utilising the temporal context

Figure 4: The PRINCE2 guide to lessons log [3]

The temporal context can be utilised in project management by learning from past experiences and capturing lessons for future project. In the PRINCE2 guide to project management [3], they recommend hosting a workshop where previous lessons can be presented during the start-up phase of a project. Attendees should be anyone interested in the project and people with experiences from similar projects. If the organisation have not undertaken similar projects, it might be beneficial to invite people from outside the organisation that have such experiences.

The recommendation is further to create a lessons log, where useful lessons are collected. These lessons might come from the workshop or documents such as project reviews, or results of audits. Also lessons from corporate, programme management, the customers or external organisations. This activity should be repeated throughout the start-up phase of the project to capture further relevant lessons.


Figure 5: The PRINCE2 guide to capturing lessons from projects [3]

When closing a project, PRINCE2 recommends evaluating the project and capturing lessons for future projects. When evaluating the project, the original intent and goals of the project should be reviewed, and also any changes made to these goals during the project. It's recommended to prepare an end report in consultation with the project management team, which includes

  • the project managers summary of the project performance
  • an assessment of the results of the project against the expected benefits in the business case
  • a review of how the project performed against its planned targets and tolerances
  • a review of team performance
  • a review of the project’s products (which should include a summary of any follow-on action recommendations)
  • if necessary, the documented reasons why a project was brought to a premature close


The lessons log should be reviewed in consultation with the project management team to identify lessons that could be applied to future projects and incorporate them into the end project report. The report should include:

  • a review of what went well, what went badly and any recommendations for corporate, programme management or customer consideration; in particular, the project management method, any delivery approach(es) used, project approaches and controls, and any abnormal events that caused deviation
  • a review of useful measurements such as: how much effort was required to create the products, how effective the quality management approach was in designing, developing and delivering fit-for-purpose products (e.g. how many errors were found after products had passed quality inspections), and statistics on issues and risks
  • any useful knowledge gained regarding the tailoring of PRINCE2 for the project.

Managing the organisational context

It is evident that there is a greater probability of success among projects with a high level of prestige and management procedures that are considered legitimate among the key players of the hosting organisation. Since both factors are social constructs, the project manager is advised to influence how his project is perceived in the organisation. This can be done be creating a sense of urgency around the project, and construct an image of the project as being strategically important to the organisation. As mentioned earlier, the project manager can also convey the image that his project is aligned with desirable goals in the temporal context, such as the UN Sustainable Development goals.

Another practical advice to the project manager is to chose his battles carefully, and not mindlessly pursue the implementation of textbook project management techniques that might conflict with the norms and standards of the organisation. The project manager should be aware of which measures and procedures that are considered legitimate in the eyes of key players in the organisation [8].

Limitations

It's difficult to talk about limitations of the context element as it is a concept. However the concept might be considered vague, as it is difficult to set the boundaries of the context. Any project exists in a huge number of contexts, and will be influenced in different degree from each of them. Trying to be aware of every context is impossible for a project manager. One solution to this could be to use the categories presented in this article, as inspiration.


Regarding the temporal context, a key characteristic of projects is that they are unique [1]. This means that there will always be limitations when using experiences between projects. For example when collecting lessons from past projects, one should be critical about what lessons are relevant to the current project.

Annotated Bibliography

  • Managing Successful Projects with PRINCE2 2017 Edition

This PRINCE2 guide gives the reader concrete and applicable tools that can be implemented in project management. With regards to the context element a few sections can be highlighted.

Chapter 14: Starting up a project - As described in the article, the temporal context of a project is something that should be utilised, for example via past experiences. This chapter describes a procedure of how to use gather experiences and using them effectively

Chapter 20: Closing a project - This chapter provides guidance to the end phase of a project, and describes a procedure of how to collect lessons that can be used in future projects.

  • No project is an island: linking projects to history and context, by Mark Engwall

This article published in 2003 analysis how the interior of a project is influenced by the historical and simultaneous context of the hosting organisation. The article is based on a two year case study of one of the principal power utilities in Scandinavia. The article have more relevance for researchers with an academic interest in the subject than for project managers looking for concrete tools.

  • Identifying the Contextual Elements of Project Management within Organizations and their Impact on Project Success, by Mark Ives

This article published in 2005 investigates the contextual aspects of project management in an organisational change setting. In the article, the author presents evidence for how a lack of contextual understanding has led poor project success for organisational change projects. As the previous article, it's mostly relevant for someone with an academic interest in the subject.


References

[1] Joana Geraldi. How to DO Projects. Danish Standards Foundation, 2017.

[2] A guide to the project management body of knowledge. Project Management Institute, Inc, 2000.

[3] Managing Successful Projects with PRINCE2. AXELOS, 2017.

[4] Jay R. Galbraith. Matrix Organization Designs - How to combine functional and project forms. Business Horizons 1971; Vol 14; pp 29-40

[5] Svetlana Cicmil. Quality in project environments: a non‐conventional agenda. International Journal of Quality & Reliability Management 2000; Vol. 17; Issue 4/5; pp.554-570.

[6] Mark Ives. Identifying the Contextual Elements of Project Management within Organizations and their Impact on Project Success. Project Management Journal; Vol 36; Issue; 1, pp.37–50.

[7] United Nations. About the Sustainable Development Goals. https://www.un.org/sustainabledevelopment/sustainable-development-goals/ (visited 27 February 2019).

[8] Mats Engwall. No project is an island: linking projects to history and context. Research policy 2003; Vol 32; Issue 5; pp.789-808.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox