How much does it cost to change?
From the The Money Files Blog
by Elizabeth Harrin
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts.
Written by Elizabeth Harrin from RebelsGuideToPM.com.
Recent Posts
Who really owns the project budget? Clarifying financial accountability
How to learn AI the sensible way
Making sense of project cost reports
How real PM mentoring actually works
The Accidental Product Manager: What project managers need to know
Categories
accounting,
agile,
ai,
appraisals,
Artificial Intelligence,
audit,
Backlog,
Benchmarking,
benefits,
Benefits Management,
Benefits Realization,
Bias,
books,
budget,
Business Case,
business case,
business case,
Career Development,
Career Development,
carnival,
case study,
Change Management,
checklist,
collaboration tools,
communication,
Communications Management,
competition,
complex projects,
Conferences,
config management,
consultancy,
contingency,
contracts,
corporate finance,
corporate finance,
cost,
Cost Management,
cost management,
credit crunch,
CRM,
data,
data security,
debate,
Decision Making,
delegating,
digite,
earned value,
Education,
Energy and Utilities,
Estimating,
events,
FAQ,
financial management,
financial management,
forecasting,
future,
GDPR,
general,
Goals,
Governance,
green,
Information Technology,
Innovation,
insurance,
interviews,
it,
Knowledge Management,
Leadership,
Lessons Learned,
measuring performance,
Mentoring,
merger,
methods,
metrics,
multiple projects,
negotiating,
Networking,
news,
Olympics,
organization,
Organizational Culture,
outsourcing,
personal finance,
Planning,
pmi,
PMO,
PMO,
Portfolio Management,
portfolio management,
presentations,
privacy policy,
process,
procurement,
product management,
productivity,
Program Management,
project closure,
project data,
project delivery,
Project Success,
project testing,
prototyping,
qualifications,
Quality,
quality,
Quarterly Review,
records,
recruitment,
reports,
requirements,
research,
resilience,
Resource Management,
resources,
risk,
Risk Management,
ROI,
salaries,
Schedule Management,
Scheduling,
scope,
Scope Management,
security,
small projects,
Social Impact,
social impact,
social media,
software,
software,
software,
Stakeholder Management,
stakeholders,
Strategy,
success factors,
supplier management,
team,
Teams,
testing,
testing,
timesheets,
tips,
training,
transparency,
trends,
value management,
vendors,
video,
virtual teams,
workflow
Date
We talk about the cost of change often on projects. If you’ve been in a delivery role for a while, you’ll no doubt be familiar with the idea that if you find something you want to change later on in the project, it costs more to make that change than if you identified it at the beginning.
That’s typically because there are fewer things to unpick and less rework required because you haven’t got as far yet. You can change the buttons on the widget if you haven’t manufactured any buttons yet. Just change the drawings or spec and you’re done. But if you have a factory stacked with boxes of buttons, then there’s a bigger cost involved – all the pre-made buttons need to be scrapped and you have to manufacturer a bunch of new ones.
Understanding how much wiggle room there is for change is important in understanding how easy it will be to make change later, and how agile (with a small A) you can be during the project when it comes to addressing defects or changing your mind.
Bridge building, button making, house construction: all these are hard to change later. But business process change, website design, or software writing probably have a different result. You can tweak a process later on, and while a group of different stakeholders will be affected, it is certainly possible (and cheaper) to do in a way that changing the foundations of a building once half the building is built is not – it’s a different kind of conversation, and a different kind of cost involved.
How easy it is to make the change, and the cost of change, play alongside each other throughout the project.
The PMBOK® Guide 7th Edition talks about Boehm’s cost of change curve. It sounds like common sense, but it is also important to challenge our assumptions and what we think we know. There is also a difference between bugs and changes that arise through active decision making. Is the cost of change the same for each on your project?
It might be possible to add a financial amount to each change and each defect so as to work out the potential cost of defects or changes addressed later in the lifecycle, but that’s probably overkill for most small and medium-sized companies, and organisations that are not software houses with plenty of data to analyse for this. Unless you’ve been through many product recalls or can model what it would look like to address a component failure, you might not have the data or time to create any meaningful cost models.
Instead, bear in mind the general principle: what is it going to mean to make a change on your project, for your decision makers, in your environment, for the development and delivery methodologies that you are using? Are there cutoff points? Points of no return?
Really?
Generally, as project managers we can make anything happen with enough money, time and resources – whether it’s the right decision to do ‘anything’ though is a completely different conversation.
It is sensible to think about the cost of change before you need to make any changes, and to consider how you’re going to avoid too many potentially costly changes. For example:
- Decent requirements
- Good quality stakeholder engagement so everyone is on board with the deliverables and no stakeholders are left out (as ignored stakeholders tend to want to insert their requirements on to the project later when they do find out about it.
- A good change control process
- Robust attitudes to quality deliverables, quality control and assurance.
How do you think about the cost of change in your projects? Is it a discussion you have with the team? I’d love to know how you work to minimise it – or if you embrace it and go with the changes! Let us know in the comments below.
Posted on: August 02, 2023 08:00 AM |
Permalink
Comments (3)
Please login or join to subscribe to this item
Thanks for this valuable post! I like your link to the PMBOK 7th ed. and the real life examples.
Regarding your list of considerations, I'd really like to emphasize Expert Judgment. It can be a gamechanger to “do it right” at the beginning or it can mislead the whole team or waste a chance to deliver a requirement.
Recently, I’ve seen a construction project (renovation actually), where incorrect expert judgment took away a chance to fulfill some of the customer’s requirements. Especially few exciters were simply wasted.
The key takeaway from Boehm's cost of change curve is that addressing changes or issues early in the project lifecycle is much more cost-effective and less risky than doing so later. Therefore, effective project management practices emphasize the importance of thorough requirements gathering and early stakeholder communication to minimize changes during the later, more expensive stages of a project.
To manage change effectively, project managers often use change control processes, which involve documenting and evaluating proposed changes, assessing their impact on the project's scope, schedule, and budget, and obtaining approval before implementing them. This helps to strike a balance between accommodating necessary changes and minimizing their cost and disruption to the project.
Yasin Ali Shah
PMP®, PMI-RMP® Certified Project Manager| SEPCO Electric Power Construction Corporation
Ras al khair, Eastern, Saudi Arabia
Thanks for Sharing, PMBOK 7th ed have a good book to understand more change management
Please Login/Register to leave a comment.
|
"All you need in this life is ignorance and confidence, and then success is sure."
- Mark Twain
|
