× 
Training
Catalogue
Catalogue
Training
Courses
Courses
Advisory
Services
Services
In the first part of our two-part series looking at common project management challenges, we discussed the following three challenges and provided, what we hope were some helpful tips on how to overcome them:
If you would like to read our first post, visit Part 1: 5 common project management challenges and how to overcome them.
In this second part of this series we’ll explore the challenges:
A project’s scope can be defined as the description and boundaries of work that the project team has agreed to deliver and remain within. Often described in the form of what the project has to do and create, including any required changes to either people, processes, systems or assets and the project’s target areas (e.g. geography, demographic).
If we refer to the internationally recognized PRINCE2® project management method, in a PRINCE2 training program, project scope is described as:
“The sum of the product delivery, and management activities represented by an approved plan and its product descriptions and work package descriptions”. PRINCE2®
As a project proceeds there are many influences that place pressure on the agreed boundaries of a project, including, but not limited to:
A key aim of defining a project’s scope is to establish boundaries of control that increase the project’s chances of success. Project success is often measured by its performance against agreed targets, namely cost, quality, time and expected benefits. In most situations changes to scope will directly impact some or all of these project performance targets.
Poor scope control can impact product integrity, user preparation and acceptance, lead to strategic misalignment and a resulting product that does not match stakeholder expectations.
Further, without controlling and assessing the individual or aggregate impact of changes or discussing these changes and options with appropriate decision makers, the wrong decision may be made, increasing the probability of confused stakeholders, poor project and product performance.
Project scope creep can be defined as uncontrolled changes to the agreed work and/or boundaries of a project. Uncontrolled changes may be changes made by project team members, technical leads or technicians without following the correct change control procedures, including not involving the correct change authority level.
There are several reasons why scope creep may occur, here are some common reasons:
It is important to recognise there will be circumstances where the agreed scope needs to change. This may be needed to safeguard the product’s value and the project’s viability or maybe to win the support of an influential stakeholder. Project management is not focused on preventing changes, but ensuring proposed changes are appropriately captured, assessed, and where a change is necessary, the right decision makers are involved.
Changes to the project’s scope are likely and not necessarily an indicator of poor project management. Whereas, poor scope and change control is a key indicator that a project is not being appropriately managed.
Gaining agreement between the sponsoring team and project team on the reasons for the project, its objectives, desired outcomes, scope, expected products and the project’s acceptance criteria establishes a clear baseline for future decisions.
Together this information, which may be presented as a project brief according to the PRINCE2 method (or project definition document in other project management standards), also helps provide the necessary context for communications and enabling a consistent view amongst stakeholders.
Some questions to facilitate scope clarity whilst developing the project brief/definition document:
It can also be useful to consider the most effective means to document and communicate the project’s scope. Words may be the easiest way to record project scope, however it may not be the most effective means to communicate and engage time-poor stakeholders. A presentation, diagrams, mind map, ‘as is state’ and ‘to be state’ comparisons may be more effective to facilitate understanding, feedback and agreement.
In some situations, defining and reaching agreement on the ‘out-of-scope’ work may be as important as defining the ‘in-scope’ work.
Presenting both in-scope and out-of-scope descriptors to influential stakeholders can help draw out expectations that may have not been explicitly communicated. This may further reduce the chances of scope creep in the project, by minimising misunderstandings and divergence from what the project is delivering and what stakeholders are expecting.
Engagement with broader stakeholder groups prior to finalising the project’s definition helps ensure the project’s definition, including its scope, is accurate and complete. However, this may not always be possible, as time may not be available, or it may be too early to engage stakeholders.
In such situations it is important that the project’s sponsoring team has the experience and knowledge to represent and foresee stakeholder expectations. Alternatively, key influential stakeholders may be engaged early to test the completeness and accuracy of the evolving project definition and its scope. In such situations, controlled changes to scope may be required early in the project.
Once agreed, it is important that the project’s definition is communicated with stakeholders and importantly in environments where scope expectations are likely to drift. Project meetings, stakeholder presentations, 1:1 meetings, may be needed to maintain project and stakeholder expectation alignment.
Detailed requirements analysis is not always possible early in the project. Time pressures can make it difficult to accurately detail requirements and confirm the scope of work.
In environments that have adopted an agile project management approach, it is recognised that detailed requirements analysis is unlikely to be accurate early in the project, as agile project teams typically operate in dynamic environments. Instead key requirements are defined and baselined at the start of the project and detailed requirements are captured as the evolving product develops with stakeholder feedback and changes welcomed by the development team.
Iterative development – agile project management
For some, this approach may appear to increase the likelihood of scope creep. To address this, agile projects follow a set of practices to control potential scope creep. Here are some insights on how this is achieved:
Every project needs an approach for controlling changes to the project’s scope or product requirements. These procedures should be agreed to, communicated and understood. The formality of the procedure can vary, as influenced by the project’s complexity and risk level.
According to the PRINCE2® project management method, a procedure for change control should include the following steps:
Join a PRINCE2 training course to learn about PRINCE2’s technique for managing change requests.
It is also important that early in the project, team members and key stakeholders understand the importance of following these procedures. In larger more complex projects, independent assurance personnel may also be needed to check compliance to project procedures.
Product value can be assessed by measuring improvements to the operational baselines following the products implementation. The level of success is determined by comparing the ‘actual’ improvement against the baseline and ‘expected’ improvement. As per common project management methods, like PRINCE2, both the baseline and ‘expected’ improvement should be documented in relevant project documentation (benefits management approach and the business case). PRINCE2 defines expected benefit as:
A benefit: “The measurable improvement resulting from an outcome that is perceived as an advantage by the investing organisation”, PRINCE2®
Improvement types may be in financial or non-financial form. In most cases the value of a project product is typically realised post- project, whilst the product is in its operational phase.
For example, if an online bicycle retailer aims to increase its income by creating a new e-bike product range, actual sales are likely to be realised once these items have been developed and added to the company’s website. This typically coincides close to the end of the project. However, there are circumstances where benefits may be realised across the life of the project.
Similar scenario, but a different delivery approach, in this case the online bicycle retailer has decided to list each model as soon as they are ready for sale, and not wait for the entire product range to be complete. In this situation products ready for sale are promoted and hopefully sold, as the project continues to develop the remaining products within the range. A common practice adopted by projects following an agile project management approach.
Given benefits management is already a well-known and discussed topic:
Some reasons for this may include:
Ensure benefits management is appropriately integrated within your project, program and portfolio management frameworks. Some early and simple actions to achieve this:
The adoption of guidance documents is often highly dependent on the level of human support to help transition people to new ways of thinking or working. This is no different for benefit management or change management guidance. Without the appropriate level of support, benefits and change management training and induction, such guidelines may not be followed. For example, where an ‘output’ focused mindset prevails in an organisation, changing (or nudging) views and behaviours towards a more ‘outcome and benefits’ focused mindset may be more difficult without the appropriate change management skills and leadership support.
If wanting to learn more on the Foundations of good practice change management, visit our change management information page at: APMG Change Management Training
Ever considered a project management training course to enhance your team’s project skills and knowledge?
Ever considered a benefits management workshop to ensure ‘benefits’ management is well established within a project or the wider organisation?
Learn more on how agile project management training and practices can help deliver value faster?
Contact us for more information.
