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:
Regular readers will know that I’ve been doing a series called What’s New In the PMBOK Guide®-- Sixth Edition. Recently we’ve been looking at Project Resource Management. However, it’s been so long since the Sixth Edition came out that it doesn’t feel right to call these articles ‘What’s New’ any longer. So today we are carrying on the overview of the project management processes with Project Schedule Management but as a ‘deep dive’ instead.
Don’t worry, I’m still taking the same approach and calling out the differences between the current and previous versions.
The main difference, at Knowledge Area level, is that this section used to be called Project Time Management. Personally, I’m grateful that the name has been changed. Time management also makes me think of personal productivity, Pomodoro, timesheets and things like that. Schedule management is a title that speaks more specifically to the management of time as relates to project tasks.
Overall, this topic is all about getting a detailed plan that talks about how and when the project will achieve the outputs (whatever was set in the project scope). The schedule is the main output of the whole Knowledge Area and it’s helpful for managing expectations, communication and tracking and reporting progress.
So… let’s get started with a deep dive into the processes.
Plan Schedule Management Process
This is the first process in the Knowledge Area. We’re in the Planning process group.
This process is all about planning how you are going to make your plan. Yes, even creating a project schedule needs some effort in planning!
It feels like much of this process will be things you do automatically or don’t have much to plan for because the boundaries are set by your corporate processes and governance.
There’s actually no change in the inputs between the PMBOK Guide® -- Fifth Edition and Sixth Edition. The inputs are:
No surprises, no real explanation needed.
Tools & Techniques
There is a small change here for this process. Analytical techniques has been removed and replaced with Data analysis.
It’s semantics really. Data analysis does give the impression of being broader, and more in line with the trend towards big data and data science. So what does ‘data analysis’ actually mean?
It can include a range of tools or techniques that allow you to dig into and analyse the data in a number of ways as they relate to producing a project schedule. For example:
The output hasn’t changed either. The output is a schedule management plan i.e. something that defines what form your schedule takes. How long waves (or sprints) will be, what methodology to use where you have a choice, what level is detail is required to manage the plan.
I don’t think I have ever worked on a project where I have produced a plan about how to manage my schedule. Generally, there might be a paragraph in the Project Initiation Document that says I’ll follow the corporate standards and that’s that. I expect there are some types of mega project where this type of planning for the plan is required, but if you have some experience managing projects and a low complexity project, you will probably be able to make those decisions intuitively and not need to justify yourself by writing a whole document about them. What do you think?
Next time I’ll be looking at Define Activities.
Pin this article for later:
In this video I share a few more ways to track project schedule performance. Sometimes it helps to look at the schedule in different ways, or to use different approaches to get updates from the team. Ultimately, the more tools you have available to you, the easier it is to flex your style to manage performance.
How do you track schedule performance? Let us know in the comments below.
There are a couple more ideas for tracking project schedule performance in this video.
I also mention this book, Healthcare Project Management, in the video.
In this quick video I share three different ways to track schedule performance. Do you use these methods already? Let me know in the comments below.
If you’d like to read more about this, or you just can’t watch the videos where you are, then you can read more about schedule tracking in this article.
Pin for later reading:
How do you track the performance of your project? Here are 5 ways that you can do it.
1. Fixed Formula
This is pretty easy. Assign a fixed percentage when the work starts. Then make it up to 100% by allocating the rest when the task finishes.
The Pareto principle is a good one to use if you don’t know how to split your task percentages. Assign 20% complete to the job when it starts, and the remaining 80% when your team member reports the work complete (because at that point it’s 100% complete).
It’s simple to work out but it’s not terribly accurate. It’s only good for small pieces of work and short tasks where it would be too difficult or not worth it to work out percent complete across a couple of days. It can also be used where the task is no longer than a week long. If you are updating your project plan once a week, and the task is no longer than a week long, the task is either started or finished so the 20/80 split (or 50/50 or whatever you think is appropriate) works out pretty well.
2. Weighted Milestones
When you’ve got plenty of milestones along the way, you can work out project performance by tracking how many you’ve hit.
In other words, you can pre-assign progress (percent complete) to certain milestones or parts of tasks. When you hit Milestone 1 you can say the project is 15% complete, at Milestone 2 it goes up to 20%, at Milestone 3 you’re 65% complete and so on. Until your final milestone at project completion where your project (or task) gets updated to be 100% complete.
This is also a way to split payments to vendors – many contracts have a schedule of payments linked to the achievement of key milestones. Your budget could be weighted in the same way as how you track performance.
3. Percentage Complete
We’ve talked about % complete already, but this version of it is just based on the project manager’s
This isn’t hugely accurate either – although it depends on the project manager. It takes experience to be able to pick a percentage out of the air and have it reflect reality. Generally, project management tools can help with this by playing back to you the % complete of your project schedule, so at least in that case you should have something underpinning the number you give.
4. Percentage Complete with Gates
This is similar to weighted milestones but instead of waiting to hit the ‘gate’ point, you can report any percentage complete up to the approved limit for that milestone.
For example, when you hit Milestone 1 you can say the project is 15% complete, as we saw above. With weighted milestones, until that point the project would be 0% complete. With gates, you can set a % complete every day if you like, working up to 15% at the point of hitting the gate (the target milestone date or achievement).
It’s like a blend of using your professional judgement but being constrained to not say you are too far ahead because you can only ever hit a certain percent complete through the nature of where you are on the project.
It sounds complicated to explain but this is my favourite approach for measuring project performance.
5. Level of Effort
Finally, you can track effort against the elapsed time. Alternatively, you can track against some other task or work package on the plan. For example, ‘Complete Testing Documentation’ might be linked to ‘Complete Testing’ and the two activities progress in parallel.
You’d track performance for ‘Complete Testing’ and then, as you know that testing documents are being updated as you go, apply the same % complete to ‘Complete Testing Documentation.’
Which one(s) of these do you use? And which do you avoid? Do you use these as standalone techniques or do they link to your Earned Value Management activities? Let us know in the comments below!