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:
I’m working my way through the Knowledge Areas and process of the PMBOK Guide®-- Sixth Edition, and at the moment we’re in Project Schedule Management. Last time I looked at the Estimate Activity Durations process. That means today is the turn of Develop Schedule.
Develop Schedule Process
This is the fifth process in the Knowledge Area. We’re still in the Planning process group – although this is the last Planning process for this Knowledge Area. Finally, after what seems like ages of gathering data, we are now in a position to actually create the schedule.
Unsurprisingly, the main output is your schedule. There are some other outputs too, and we’ll come on to those, but the schedule is the biggie.
There are quite a few changes to the Inputs between the PMBOK Guide® -- Fifth Edition and Sixth Editions, and as we saw with the last process, it’s mainly items being removed.
This time we’ve lost 11 specific documents. These have been replaced with the generic Project Management Plan, project documents and agreements.
Agreements refers to documents from third parties that talk about how they will do their tasks. You could use contract schedules for this, or a statement of work. I think agreements should also refer to the arrangements you have with line managers to use their staff on projects. Getting this firmed up will help massively with being able to build a schedule because you’ll be confident that the people you need are available to you.
As we’ve now got ‘project documents’ as a handy catchall, it might be useful to clarify exactly what they could mean. Here’s a (non-exhaustive) list of the documents you could refer to during this process:
Tools & Techniques
There are only a few tweaks to Tools and Techniques.
Critical chain method is out and data analysis is in. Data analysis covers things like ‘what if’ scenario planning and other simulation techniques. These are great if you have software that can do them, but the majority of non-multi-million dollar and major infrastructure projects will probably have to manage without.
Resource optimisation techniques has been renamed resource optimisation.
Scheduling tool has been replaced with project management information system.
And we’ve got a nod to Agile with Agile release planning.
The only change to Outputs is the addition of change requests.
Change requests pop up in other processes, so this could be a standardisation improvement. You can see why change requests are relevant here. If you are making changes to the schedule that might affect the scope baseline or other elements of the project management plan. It’s all part of being integrated with project management and using the processes as appropriate throughout the project. If you need to make changes, go through the change control process and document what is decided.
Next time I’ll be looking at Control Schedule.
Pin for later reading:
Today’s deep dive into the PMBOK Guide®-- Sixth Edition is into the third part of Project Schedule Management: the Sequence Activities process. I’m going to call out the differences between this process and what we used to have in the PMBOK Guide® -- Fifth Edition.
Sequence Activities Process
This is the third process in the Knowledge Area. We’re still in the Planning process group.
This process is about putting the activities you’ve already defined into a logical sequence. The main output is your network diagram, which shows how tasks link. However, I don’t think I’ve ever created a network diagram for a project. I’ve certainly sequenced activities, but I’ve never done it in such a formal way. A few sticky notes on some flip chart paper or just common sense as I’m putting the Gantt chart together tend to be the way I go about it. I’m sure there are projects that would benefit from a detailed network diagram, and I don’t doubt that it is a useful tool.
I’m from the school of thought that says don’t do things for the sake of them, just because the book says so, as long as you get the right result. I expect earlier in my career I spent more time checking the order of activities before defining my schedule, but now it all seems to happen as part of an integrated afternoon of planning.
Back to the detail of this process…
There are quite a few changes to the Inputs between the PMBOK Guide® -- Fifth Edition and Sixth Editions. Having said that, in essence the main change is that the detailed list of documents has been removed, and replaced with the generic Project Management Plan and Project Documents. These are nice catch all inputs that also allow a more broad interpretation of what needs to be considered for activity sequencing.
Tools & Techniques
The only change to the Tools and Techniques is the addition of your project management information system. In other words, PMI acknowledges that you probably won’t create a network diagram using paper and pens.
Your PMIS is most likely an integrated project scheduling tool. If it does Gantt charts, it probably does network diagrams too, so you can print one out to prove you have it if ever you need it. I have looked at network diagrams in Microsoft Project before, so despite not actively putting them together as a distinct step before scheduling, I have found them useful for a visual representation of the project overall, especially when some activities look out of sequence or I can’t work out how the dependencies should look.
Software is helpful for:
There are no new outputs. Nice and easy. It’s all as it was before.
You’d expect this process to be followed by Estimate Activity Resources, but that’s actually been moved to the Resource Management Knowledge Area.
That means next time I’ll be looking at Estimate Activity Durations.
Pin for later reading:
Today’s deep dive into the PMBOK Guide®-- Sixth Edition is into the second part of Project Schedule Management: the Define Activities process. I’m going to call out the differences between this process and what we used to have in the PMBOK Guide® -- Fifth Edition.
The project schedule is the main output of the Project Schedule Management Knowledge Area (unsurprisingly) and the action really starts with Define Activities.
Define Activities Process
This is the second process in the Knowledge Area. We’re still in the Planning process group.
Basically, this process is about making an activity list, covering all the different activities that need to be done to complete the work of the project. There are some other outputs too – we’ll come to them in a minute. But think of this process as the creation of your master To Do list.
There are some small changes to the Inputs between the PMBOK Guide® -- Fifth Edition and Sixth Edition. In the current edition, inputs are:
The schedule management plan and scope baseline have been ditched. That makes sense: the project management plan is such a broad, wide-ranging document that you don’t really have to specify the component parts.
Tools & Techniques
The Tools and Techniques for this process have changed slightly – meetings has been added (and if you want to get picky, it looks to me like the order of tools and techniques has been shifted around), which makes no practical difference day to day.
The addition of meetings makes sense in the context of the Knowledge Area. You can’t decide on what needs to be done unless you talk to people who are going to be doing the work, and you’ll do that through a meeting. That meeting could be informal, formal, a phone call, with lots of people or with one person.
Frankly, I think adding meetings in is a little bit pointless as it should go without saying that you have to talk to an expert in order to use expert judgment as a technique. But the PMBOK Guide® -- Sixth Edition is nothing if not diligent in setting out the detail.
There are two new outputs: Change requests and Project management plan updates.
The point of adding change requests in here is because you should already have a scope baseline in place. As you work through the activities, talk to the right people and so on, you may uncover extra work that needs to be done – or work that doesn’t need to be done. This would generate a change request to amend the baselined scope.
Project management plan updates is a generic catch-all type of output that is included as anything you might do to create a schedule may have some kind of impact on the plan. For example, you might need to update the schedule or cost baselines. Once a change is approved, you’ll have to make changes to those documents too.
Next time I’ll be looking at Sequence Activities.
Pin for later reading: