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?
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:
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.
You hear it all the time: “We want our project managers to add value.” “How are you adding value to the organisation?” “I want to spend more time on valued-added activities.”
But what does adding value actually mean?
I’m not a great fan of buzzwords that I can’t explain and turn into practical actions, so I’ve given this topic quite a lot of thought over the years. Here are 5 things I think you can do to add value (in a meaningful way) as a project manager.
1. Team building
Projects are done by people. People make up teams. Groups of people don’t have the same impact as a well-functioning team. Therefore, spending time on team building is worthwhile and will create value for the organisation because you’ll be better at delivering whatever it is you are delivering.
Focus on creating a positive work environment. Think about what people need to get their tasks done. Look for roadblocks you can remove, processes you can streamline. Talk about the blockers and why they are a problem.
And get some fun in there too.
Being committed to the team and the job, and the project, is a sure way to add value because it increases the chance the project will actually get done. How many projects do you know of that started but didn’t have the momentum to get across the line? That’s what tenacity will help you avoid.
Assuming you are working on the right projects, the ability to follow through and get the work done is important for making sure your time pays off for the company.
This is such a large topic, which includes resolving conflict, smoothing over awkwardness, being diplomatic while speaking truth to power, respectful challenge and knowing who to connect and when. There’s a whole bunch of soft skills (or power skills, as it is trendy to call them now) that fall into this bucket.
They are important because this is what helps you get work done even when the environment is tricky. The more you listen, the more you understand and the easier it is to get your projects done. You’ll understand more of the business context that lets you make the right decisions that – you guessed it – lead to delivering a higher-value result.
4. Control the process
Governance might not seem like a particularly value-added thing to do, but when you understand and use the processes of project management, you can structure, standardise, save time, automate, compare and improve so much more easily.
If you have a standard approach, however informal, everyone knows what to do and what to expect and that takes some of the uncertainty out of what is normally a pretty uncertain time for people – projects deliver change and that comes with an overhead of having to live with not knowing exactly what the future will look like. That can be an added source of anxiety and stress for the team and wider stakeholder community.
5. Change management
Projects start to feel out of control when change is not managed appropriately, and that’s when stakeholders start to get nervous. You can help your projects be more successful and ‘land’ better with the receiving organisation, if you manage change properly.
That goes for both the process-led effort of receiving and handling change requests as part of your project management work, and also integrating what you are delivering into the business in a way that makes it possible for the benefits to be received as soon as possible, with the least disruption. Benefits = value.
How do you interpret ‘adding value’ as a project manager? I think it could go much further than what I’ve written here. I’m sure there are many other ways of looking at our role and how we can serve our stakeholder communities in the most value-adding way. Let me know by leaving a comment below!
Thinking about the cost of quality revolves around two things: how much it costs to comply with quality requirements and how much it costs to put problems right.
The infographic below shows the four considerations for working out the cost of quality for your project: prevention and appraisal before things go wrong, and dealing with internal and external failures in case they do.
Which of these do you use on your projects? Tell us more about how you manage the cost of quality in the comments below!
When you’re planning how to deliver quality results, and what needs to go into your project schedule, it’s worth looking at what regulations and standards you need to adhere to.
In this article we’ll look at the difference between regulations and standards and what that means to you managing a project.
What is a regulation?
A regulation is a requirement for your project. You have to follow regulations.
Regulations include applicable laws.
For example, there are a range of regulations that can influence the way you approach your project and what you can and cannot do. Here are some areas affected by regulation:
Laws vary between countries, so check what is applicable to where you are based. Also note that in multinational projects, the laws and regulations might differ for people on your teams in different locations.
What is a standard?
A standard is a guideline. Your project should follow guidelines because they are there for a reason, but if you can justify why you need to approach something in a different way, then you don’t have to follow the standard.
For example, it might be the standard that no one in your office works on a bank (public) holiday. Let’s say it is normal for the office to close over the end of year period when many colleagues are celebrating Christmas. However, your project is to upgrade the telephony switches. Knowing that the call volumes will be low and no one will be around to answer calls anyway, you might decide that the Christmas period is the perfect time to do that project work. It’s not standard, but it’s the most appropriate solution for your project and least disruptive for the business.
Not all standards or regulations are going to affect every project. It’s important to have a view as to what is important for this project. It is something I would consider and resolve as part of project initiation, so that I can go into project planning with all the information needed.
How do standards and regulations affect projects?
Standards and regulations affect projects in a number of ways.
1. By affecting project scheduling
Any time legal compliance is required, you can bet you need to add extra time to the schedule to have the legal team check out what you are doing and ensure the project is ticking all the boxes. Build in enough time for regulation-related checks and work.
Equally, with resource-related regulations, you may have to constrain working time which will have an implication for the schedule. For example, you may not be able to use overtime hours, or you might have to factor in travel time to your schedule if your resources aren’t permitted to go over a certain amount of travel before taking a break.
Some of these constraints could be legislation affecting workers, others might be the way your company operates (or as PMI would define them, enterprise environmental factors). An example would be dictating that the standard working week is 40 hours. You would take that data and ensure your schedule reflects a 40-hour standard working week.
2. By affecting project quality
If you have to follow regulations or stick to standards, this could have an implication for project quality. You might have to do additional quality checks, or use particular materials. An example would be building control. In the UK, you need building control to sign off on construction work. You can’t simply carry on building or assume everything will be OK without having someone come round and inspect the site. That’s an external quality check you have to consider and plan for.
3. By affecting project budgets
If your project needs a building control check, you have to pay for that. The building controller will charge you for his or her time. That cost needs to go into your project budget forecast. Depending on what regulations and standards you have to abide by, your project costs will need to accommodate the related charges.
Once you understand the standards and regulations that affect your project, and how they are likely to affect the project, you are able to plan for them. Some might need mitigating factors and adding to the risk register. Others will be easy to manage, perhaps by adding a little extra time or an additional task to the schedule.
Do a bit of research at the start of your project and then incorporate what you need to so that your project, and your organisation, stay compliant with the relevant regulations and standards.
Pin for later reading:
3 Levels of Project Quality [Infographic]
How do you define the right level of quality on your project? Your project sponsor probably has expectations you need to meet. Your team has a level to which they can deliver. You have to find a way to balance the competing needs and hit a quality level that suits as many people as you can.
At least, that’s a good approach if you want to avoid too many grumpy faces round the table at your project lessons learned meeting.
This infographic, inspired by a fantastic short little book on project management called Project-Driven Creation by Jo Bos, Ernst Harting and Marlet Hesslelink, sets out the three levels of project quality that you can reach for your deliverables.
Which one do you hit most often?
Read more about this topic in the article here.