Key Concepts
The business environment does not stand still while a project runs. New regulations, technology shifts, geopolitical events, and market moves can change the value of what we are building, sometimes overnight. This task is about keeping one eye on the horizon, deciding which external changes matter, and adjusting scope or backlog when they do.
3.3.1 Survey Changes to External Business Environment
Look for changes to factors such as regulations, technology, geopolitical, market, etc.
Changes to our projects come from inside our organization (Internal Business Environment) and from outside the organization (External Business Environment.) We need to be alert and ready to consider all forms of change. This does not necessarily mean accept the change but evaluate its impacts, costs and merits.
Project managers are usually the custodians of approved changes, meaning we must accommodate them, but we are generally not the people to approve them. That is typically a change control board, steering committee, project sponsor or product owner.
Internal Changes
MORTAR is an acronym to help remember internal business factors that can affect the value and desired outcomes of a project, leading to changes.
M – Maturation of ideas. As we start to flesh out what is required, we realize there is a lot more needed than initially stated. This is especially true of digital products where we may not have built anything like it before.
O – Organization changes. Sponsors, product owners and business representatives come and go. People get promoted or reassigned, and the replacement people often have different goals that bring about project changes.
R – Reprioritization. Strategies and organizational priorities change. Sometimes the reprioritization of projects or goals within projects will cause us to make changes.
T – Taking away deliverables. Sometimes things are not required anymore, perhaps we missed an opportunity, or it turns out not to be worth the effort once we investigate it.
A – Adding scope. More often, things get added. ”While painting the exterior, can you fit new lights?” these changes all sound reasonable individually but can add up to large amounts of scope creep.
R – Rethink and pivot. Initiatives with high rates of uncertainty or complexity may not go as expected. Perhaps after investigating building a website to rent garden tools locally, we switch to creating a hub for exchanging them.
External Changes
PESTLE is an acronym to identify the external business environment factors that can affect the value and desired outcomes.
P – Political. Any way a government intervenes in the economy or a certain industry. This can include government policy, labor law, environmental law, trade restrictions, foreign trade policy, tax policy, etc. Also, governments may have an impact on the education system or infrastructure which may impact the viability of a project or create changes.
E – Economic. Events that affect the economic environment. It includes the financial models and accounting techniques used during the evaluation of the project. Factors include taxes, interest rates, inflation rate, exchange rate, wage rates, economic growth, recession, unemployment, credit availability, and financing availability.
S -Social. Social events that affect the project through market and community changes. These include shifts to remote work, cultural changes, population changes, health consciousness, global pandemics, career attitudes, global warming, etc.
T – Technical. Any and all technology related factors, including new tools, materials, platforms and environments. New technologies such as software as a service, platform as a service. New technology-based competition such as Airbnb disrupting hotel businesses. New advertising and distribution channels. New pricing structures such as eBay auctions, etc.
L – Legal. Legal factors including changes to laws impacting employment, imports/exports, quotas, taxation, access to materials and resources.
E – Environmental. Consideration of the ecological and environmental aspects of the project that could impact economic or social aspects. These include CO2 emissions, ground contamination, water contamination, endangered species and habitats, global temperature, natural calamities, access by rail, air, and road, ground conditions, proximity to water sources, and heritage sites, etc.
MORTAR and PESTLE can be helpful tools to identify common factors that could impact our project. They can also be helpful in a team workshop environment to prompt discussions and to brainstorm about potential threats and opportunities. However, they are at best simplifications and do not replace consulting with subject matter experts. Also, in many business domains (biotech, AI) technology is outpacing legislation and reminder acronyms, so it is best to not rely on these mnemonics alone.
3.3.2 Assess and Prioritize Impact on Project Scope/Backlog
Change Control Boards
A Change Control Board (CCB) is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project. The board represents key stakeholders for the project and is tasked with assessing changes in terms of cost, schedule, risk, and value impact. They are created to manage all project change requests fairly.
A Change Control Board (CCB) may meet on-demand for high-priority requests or on a regular schedule, such as once a week or once a month. In addition to deciding on project changes, they are also responsible for recording and communicating such decisions.
Once a decision has been made by the CCB, the scope of the change is compared to the established tolerance thresholds. Changes within thresholds can be approved and initiated by the project manager. Changes outside of tolerance thresholds usually require the project sponsor to approve the change.
Product Owner as a Change Control Board
Agile approaches are often used in high change environments where many scope and trade-off decisions need to be made daily. In these situations, getting the change control board together, bringing them up to speed about the issue or request and letting them discuss and debate the pros, cons and various options would just take too long.
Instead, the Product Owner is empowered by the business to make scope, priority and change decisions on behalf of the sponsor. They are trusted to do the right thing, act on behalf of the business and customers and manage the bulk of all change decisions themselves. Unless a change would materially impact the outcome of the project, the Product Owner approves, rejects and defers changes daily.
Product Owners often consult with the Scrum Master / team lead and members of the team to get information about estimates, dependencies and risks but otherwise have the autonomy to make project decisions.
Backlogs
Agile projects use a Product Backlog to store and collaborate on upcoming work items. The backlog is prioritized so the next items to be worked on are at the top of the backlog. In the simplified Scrum life cycle diagram below, the product backlog is highlighted in the red dotted square.
The Product Owner takes input from customers, the team and other stakeholders then makes their decision on the priority of items in the backlog, the highest priority at the top. During sprint planning, the team and product owner take the top priority backlog items and break them down into more detail to form the sprint backlog that gets worked on in the next sprint.
The product backlog contains the project’s high priority, medium, and low priority work items. Items near the top of the list will be more detailed and broken down into well-understood user stories. Items further down the backlog might be larger, placeholder epics or features that have been analyzed in less detail (but will be progressively elaborated as they move up the backlog.)
The column on the right in the image above shows how the team’s capacity is used to gauge progress and check completion targets. By estimating stories in points and tracking how many points get delivered per sprint, coarse-grained predictions are possible.
Update Baselines
With traditional life cycle projects, after the initial plan is created, it is saved as a baseline. This baseline plan acts as a reference point for comparison and tracking progress. As changes are approved, the baseline is updated to reflect any new requirements or deliverables so that progress is being tracked against the new updated baseline plan.
The project management plan includes scope, schedule and cost baselines. Together these baselines form an overall performance measurement baseline. When changes occur, potential impacts to the performance management baseline are examined to understand the likely impacts of the change.
Configuration Management System
A Configuration Management System (CMS) is a collection of procedures used to track project artifacts. These days, CMSs are usually computerized content management systems that allow monitoring and reporting on project artifacts. When a change occurs on the project, any associated configuration items should also be updated. The CMS maintains the change history of all components tracking what changed and who changed it to effectively control the versions of all the project components.
3.3.3 Recommend Options for Scope/Backlog Changes
Recommend options for scope or backlog changes such as updating schedule, budget.
A project manager’s life would be much simpler if changes did not occur, but like schoolteachers not having to deal with naughty children, that is not going to happen. We are much better served with learning how to deal with changes effectively. Also, sometimes change can bring a competitive advantage.
Being the first organization to respond to a market shift can bring huge economic returns, often referred to as “first-mover advantage”. So, what are our options for responding to change?
Integrated Change Management
Traditional projects have a comprehensive system for managing change. We have already discussed the Change Control Board, Baselined Plans and Configuration Management System. However, most projects also have a Change Management Plan that outlines who will be on the change control board, how it will operate and what to do with emergency changes.
There will also likely be a Change Control System to gather and track change requests in a standardized way. Plus, a Configuration Management Plan that explains the naming conventions, document management system and version control tools used.
When a potential change is identified it is sent to the change control board who evaluates it. They will assess the change to see if it is in scope as defined by the charter and evaluate the options available. The CCB will make a decision, update the status of the change request and communicate their decision to the relevant stakeholders.
If the change was approved, the project manager can start updating and re-baselining the plans. The change is then will be actioned through the execution of the updated plans. The main components of this process, sometimes called Integrated Change Management, are shown below.
Changes and the Backlog
Using agile approaches, the Product Owner is responsible for conducting similar steps as identified in the Integrated Change Management approach shown above, just by themselves and with less documentation. The Product Owner monitors the internal and external business environment, looking out for opportunities, threats and change requests that might impact the project.
When a potential change is identified, they evaluate it, consulting with other stakeholders such as customers and team members to gather the required information. Then decide whether to decline, defer or approve the change. If approved, they assign a priority and put it in the backlog displacing items of lower priority down the backlog. This process is depicted in the animation below.
The animation shows a “water-line” of agreed to work below the original backlog. If we accept a change the Product Owner and other stakeholders must accept that it displaces a similar sized piece of work with a lower priority.
We can accept changes, even late in the life cycle sometimes, but we cannot defy the laws of time and space. An important note about agile projects is that all work goes in the backlog. We do not maintain a separate list of change requests or defect fixes. Everything lives in the backlog, so priorities and remaining work is visible to everyone.
Backlog Reprioritization
In addition to new requests or changes being introduced into the product backlog, Product Owners also reprioritize items in the backlog as priorities change.
For a full explanation of how agile approaches manage changes, see the exclusive Agile Primer chapter (pages 16 – 38) in the PM Illustrated book.
Other Responsibilities of the Product Owner
As well as maintaining and prioritizing the product backlog, the Product Owner ensures that the product backlog is transparent, visible and understood, i.e., everyone on the project understands what it contains and represents. Product Owners also perform several other critical responsibilities:
- Creates and shares the product vision – Developing and explicitly communicating the product goal;
- Coordinates business and customer engagement – acts as the main contact with other stakeholders to gather and distribute product information.
- Provides story input – Creating and clearly communicating product backlog items. Ensuring the stories are “ready” for development and have acceptance criteria.
- Oversees product development – in collaboration with the team, they create release roadmaps, release plans.
- Collaborates with the development team – Answers team questions about the solution, engage in team work sessions, provides timely feedback on demos and reviews, etc.
Minimums
Some commonly used agile terms relating to releases include Minimum Marketable Feature (MMF), Minimum Viable Product (MVP) and Minimum Business Increment (MBI). While they share the first-word “Minimum” and all relate to the smallest increment of something, that something varies and so we should understand the definitions.
- MMF – Minimum Marketable Feature – A small, self-contained feature that can be developed quickly and that delivers significant value to the user.
- MVP – Minimum Viable Product – MVP is about learning more about the ultimate product. An MVP could range anywhere from not having any MMFs, to having a single MMF, to having several MMFs.
- MBI – Minimum Business Increment – A MBI is a description of the minimum amount of business value that can be realized from a business perspective. MBI is more related to MMF than MVP and was developed because some organizations objected to the term “marketable” since they did not sell products.
Updated Roadmaps
An output of evaluating project changes may include updated roadmaps. Roadmaps are high-level planning tools used to show chunks of functionality and their release targets. A Story Map is an example of a roadmap used to plan releases. In the image below, stories that represent functionality have been mapped out in functional areas by their Optionality – i.e. how critical they are.
In pic 1) above, stories are arranged vertically based on how critical they are. The four vertical columns could represent different functional areas. If this were a Netflix-type video website, these areas could represent creating a database of movies, membership logon, browsing movies, and payments.
Pic 2) shows the most critical stories that represent the walking skeleton of necessary functionality. These items are enablers for subsequent features to be built on. They represent a pre-MVP infrastructure.
3) Shows the stories select for the first release. They include all the necessary stories and others most critical for the first release. This might constitute a MVP if it contains enough functionality to be useful or might be for internal review to assess technical capabilities and gather initial feedback.
4) Shows the Second release and Third release planned stories. They add additional functionality in coherent groups of features that consider the span of business functionality and user activities. Each release adds more functionality until all the planned stories are delivered.
Release Planning
Traditional projects usually have a single release at the end of the project. Increasingly organizations are using hybrid approaches to deliver some functionality early for feedback then the remainder of functionality later.
Agile projects typically have multiple releases of different increments of the solution as they are available. Releasing early has a number of benefits, including:
- Validate approaches, technologies and materials to mitigate project risks
- Start to gain value from the solution early
- Generate real feedback from users allowing lower-cost adjustments if necessary
3.3.4 Continually be on the Lookout for Changes
Continually review external business environment for impacts on project scope/backlog.
Projects need to continually review the business environment for items or issues that could impact the project scope. This applies equally to whether that scope is managed in work packages and statements of work or in backlogs and user stories. Some tips include:
Governance Steering Committee
The overall governance or steering committee that coordinates the project might be called the Project Board or Steering Committee. These groups might include the project sponsor, a senior user, and PMO resources. They have responsibilities that include:
- Clarifying the project charter and objectives.
- Allocating the resources to the project.
- Providing direction when challenges or changes are encountered.
A clear governance structure becomes critical when project changes are caused by variations in the internal or external business environments.
When kicking off and chartering a project, it is a good idea to politely reiterate the steering committee’s role in providing direction in the event of business environment changes. That way it should come as no surprise that their timely guidance will be sought should major changes occur. Likewise priming and convening the change control board ahead of their first real need can be useful to dry-run to a hypothetical change.
We create fire escape plans ahead of fires, so we do not need to be creating them on the fly. Having clear expectations and practiced processes for handling major project changes can save confusion and valuable time.
Agile Tips
Get the best Product Owner you can. Ideally, they are well connected within the organization and fully aware of market changes and the competition. Educate and invite the team and other stakeholders to take part in risk management, demos and planning activities.
When identifying risks, it is good practice to assign a risk owner, someone responsible for monitoring the risk and alerting the project manager should it occur. Extend the concept to consider related business environment changes. Ask to be informed if they hear about anything that might impact the project.
At demos and retrospectives ask open ending questions such as: “Is anyone aware of any market changes that might impact our business case or planned work? Get people used to scanning for changes and sharing information. Create a culture of inquiry and information sharing, so we can hopefully be forewarned of events before we are forced to react to them.
Deliverables and Tools
- Updated baselines
- Reprioritized backlog
- Updated roadmaps
- Configuration management system
- Change control boards
- Backlog reprioritization
- Product owner responsibilities
- Release planning
- Governance
Related Topics
FAQ
Why track the external business environment?
Because regulations, technology, geopolitics, and markets can change the value of the project, sometimes overnight.
What should the project manager do when external changes occur?
Decide which ones matter to the project and adjust scope or backlog when they do.
How do external changes relate to internal ones?
Internal changes originate inside the organization and are covered under 3.3 Manage and Control Changes.
Further Reading
- Article: MMF and MVP Definitions
- Blog: MVP and MBI Definitions
- Book: PM Illustrated, Agile Primer, pages 16 – 38
Congratulations! You earned the Evaluate Changes badge.Explore these topics via an interactive mind map. (Click the nodes to expand/collapse, drag to pan, scroll/pinch to zoom.)
