We need to measure project performance to see if the project is on track.
The graphic below shares some ideas on the different ways you can measure work performance. None of these suggestions is better than any other – they are all appropriate for different projects, environments and levels of project management maturity.
Do you use any of these approaches to measure progress on your projects? Why (or why not)? Let us know in the comments section below!
For more on this idea, and a bit more background on the performance measures, check out this article:
It’s time to look at another project management Knowledge Area from the PMBOK Guide®-- Sixth Edition. This time, we’re diving into Project Scope Management. I’m going to be looking in detail at the major changes between the Fifth Edition and the current version. It feels like the Fifth Edition came out of circulation a while ago, but I know (anecdotally) that some people are still yet to update their internal processes to align to the Sixth Edition.
In practice, I don’t think that matters much. The changes aren’t radical – and while it’s good for new people being certified to work in an environment where the language and expectations align to what they studied as part of their PMP® prep, no one is going to find it difficult to work in a v5 environment.
So, onwards to this Knowledge Area. Let’s dive in!
Plan Scope Management Process
This is the first process in the Knowledge Area, and it makes sure you are setting yourself up for success. As with many Knowledge Areas, we start by planning out what we are going to do in this domain before getting on with the work.
The inputs haven’t changed from the Fifth Edition. They are still:
The objective of this process is to consider how you are going to get to an understanding of what the project scope is, so you need all of those things.
Tools & Techniques
There isn’t much change here either. Expert judgment and meetings remain as they were before, and there is the addition of data analysis.
You might recall that data analysis was added in as a tool and technique to schedule management too.
Data analysis is a lovely catch all for the kinds of things you might be looking at during your planning. For example, you will probably do some alternatives evaluation to decide which requirements and specific functionality or solutions you want to move forward with.
Nothing has changed here either.
At the end of working through this process, you’ll have the scope management plan and the requirements management plan.
I’d say that if you have a repeatable process in place with solid templates and expectations for managing scope, you should be able to complete the work required here quite quickly. You might not need to write a detailed document for requirements management and scope management, if you can include a paragraph in your main project management plan. There’s nothing in the PMBOK Guide®-- Sixth Edition that specifies you have to have separate documents, so go light on paperwork where you can!
Next time I’ll be looking at the second process in this Knowledge Area: Collect Requirements.
This is the end of my deep dive into the PMBOK Guide®-- Sixth Edition, and what it covers about Project Schedule Management. I’ve looked in detail at the major changes between the Fifth Edition and the current version.
One of the biggest changes in the Sixth Edition is the inclusion of information on trends and emerging practices, tailoring and Agile. This is long overdue and it’s helpful to have some specific guidance around how we can adapt the sometimes dizzying amount of information in the PMBOK® Guide to our own organisations.
To recap, here is the rest of the Project Schedule Management deep dive series:
OK? Let’s take a look at what you need to know about adapting this process for your environment.
Trends and Emerging Practices
Scheduling techniques have pretty much stayed the same for many years, but there are some new thought processes at work. We have to be able to manage in a competitive environment where everything seems to be needed much more quickly. There’s a business advantage to being able to compress schedules and deliver things in a shorter timeframe, so the emerging practices covered in the PMBOK® Guide relate to those.
First we have iterative scheduling with a backlog. This is a common way of managing work in an Agile environment and supports rolling wave planning. In other words, you have a big bucket of requirements (user stories) that are prioritised as you come to the end of a time box, for delivery in the next time box. This works really well when you can or need to be flexible about what features get released when.
The major benefit is that the customer gets to see real progress on an iterative basis. This is great for building loyalty, delivering benefits more quickly and ensuring user adoption over time.
However, when there are lots of dependencies between tasks or requirements, it can become difficult to manage.
On-demand scheduling is based on the theory of constraints. It limits the work in progress for a team so that you can balance demand against what the team is capable of doing. As someone who is not a fan of multitasking (although I do it every day), limiting WIP is a great idea.
Kanban is where you will see this approach in use most commonly. In practice it works because instead of building a schedule based on requirements, you plan around the team’s availability and they take work from the queue to work on it immediately.
This is a good approach in environments where you have people doing a mixture of BAU and project work, and their project work does not have hard deadlines. I have no project experience of on-demand scheduling, aside from using something similar for my own To Do lists, so share your experiences in the comments below – I’d love to hear more.
The PMBOK® Guide talks about the need to tailor the approach to scheduling because every project is different. For your project, think about:
The life cycle: what life cycle are you using for your project and is it the best approach for getting to a detailed schedule?
Resource availability: You might have to switch up how you manage the schedule because of difficulties securing the resources you need.
The project itself: Big, complex projects need a different approach to scheduling to a small, easy project. There might be constraints within the project environment that lead you down one scheduling path compared to another, for example being required to use earned value as a stipulation of a particular contract, or using a particular scheduling software tool because that is what the client uses. That leads us to:
Tech support: What tools are available to you? If you don’t have access to modelling tools, for example, it’s not appropriate to build your schedule on the basis that you can use them. If you don’t have virtual Kanban boards and yet your team is virtual, then perhaps a scheduling approach that relies on specific software isn’t the best way to go.
Considerations for Agile
Adaptive project methods are those that use short delivery cycles. You do the work, review the outputs and make changes as necessary before the next delivery cycle kicks off. We’re seeing more and more projects use agile approaches like this because they work.
However, in my experience, and that of the many project managers I mentor, a lot of companies have project teams doing agile and project teams who don’t use agile. Sometimes we use Agile and non-Agile techniques on the same project (for different aspects of the same project). There’s a recognition now that this is OK. If it works and you get results, then it’s OK.
The PMBOK® Guide talks about hybrid approaches and being able to combine scheduling techniques from different approaches to get where you need to get. As a project manager, you have to make or support decisions around the tools and approaches you are going to use, and it helps to have some experience of these. If you find yourself suddenly managing an Agile project with no prior experience, you’ll be fine, but get familiar with the approaches as quickly as you can!
Pin for later reading:
We’re almost at the end of the deep dive into the PMBOK Guide®-- Sixth Edition, and what it has to say about Project Schedule Management. Last time I looked at the Develop Schedule process.
Today we are moving out of the Planning process group and moving into Monitoring and Controlling for the sixth process: Control Schedule. This is the last process in the Knowledge Area.
Here are the previous instalments:
Control Schedule Process
The Control Schedule process happens on an ongoing basis throughout the execution part of a project. As you are doing the work, you are constantly going back to the schedule to track your progress, make changes and ensure the schedule still reflects reality.
As a result, the biggest output of the process is changes. You won’t put every schedule change through change control, but you’ll be using work performance information to make daily tweaks to the schedule to keep everything on track.
We see the common trend to simplify again in this process. Project schedule, project calendars and schedule data have been replaced by project documents in the Inputs list. You can still use all those documents for this process, but they aren’t called out individually any longer as specific Inputs.
You can also draw on:
And of course this isn’t a definitive list. Use whatever you need to in order to track, monitor and control progress against the schedule in a timely and efficient way.
Tools & Techniques
There are a few changes to Tools & Techniques, but they are all logical and make a lot of sense.
Performance reviews is out. These related to contract performance specifically, if I remember rightly, so the focus here is on being flexible enough to acknowledge some of the work (if not all of it) is performed by people who are employed by the organisation requesting the project. If I’m honest, my big issue with previous versions of the PMBOK® Guide was around the fact a lot of it was written as if you were outsourcing a lot of the work and buying in lots of services from contractors. Yes, I’ve worked on projects where that is the case, but not all my projects (or yours, I imagine) have been mainly supervising the work of contractors. We have internal staff who are also heavily involved in doing project work.
Project management software and scheduling tool have been replaced by project management information system, as we have seen elsewhere in other processes.
Resource optimisation techniques is now simply resource optimisation.
Modelling techniques is out.
The new T&T are:
The Outputs stay the same except organisational process assets updates has dropped off the list. If updating your schedule and controlling your project resulted in some business process having to change, then by all means report that to the PMO as a lesson learned. If updating an organisational process asset makes sense then do it anyway, even if it is no longer an output of this process. If you’ve got an example of when you doing schedule control has changed the way your business operates, then let us all know in the comments below, as I’m struggling to come up with a relevant example. Thanks!
That brings us to the end of the Project Schedule Management Knowledge Area. Next month, I’ll be looking at the trends and tailoring guidance for this topic. As you’ve probably noticed if you’ve followed the whole series, we’re seeing more specific guidance for Agile approaches through the different processes, so I’m expecting to see more information about that called out in the PMBOK® Guide. Watch this space!
Pin for later reading:
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: