Below you will find videos on all the Project Schedule Management sections from the PMBOK Guide.
If you want to see the “Key Concepts & Tools” for Project Schedule Management, click here. Enjoy!
Project Schedule Management – Overview
Plan Schedule Management
Define Activities
Sequence Activities
Estimate Activity Durations
Develop Schedule
Control Schedule
Well done for improving your knowledge on Project Management! If you want to see the “Key Concepts & Tools” for Project Schedule Management, click here. Enjoy!
Below you will find videos on all the Project Integration Management sections from the PMBOK Guide.
If you want to see the “Key Concepts & Tools” for Project Integration Management, click here. Enjoy!
01 – Project Integration Management
Overview
Develop Project Charter
Develop Project Management Plan
Direct and Manage the Project Work
Manage Project Knowledge
Monitor and Control Project Work
Perform Change Control
Close Project or Phase
Well done for improving your knowledge on Project Management! If you want to see the “Key Concepts & Tools” for Project Integration Management, click here. Enjoy!
What happens if we want to compress our schedule? Maybe it’s going to take a long time and we want to make it shorter – that’s where schedule compression techniques come into play.
Schedule compression is a technique that’s used to shorten or accelerate the schedule duration without reducing the project scope. We still want to deliver what we are delivering – that business value as part of our project – but we might have certain schedule constraints, imposed dates that we need to meet or other schedule objectives. So we need to compress that schedule.
There are two main compression techniques that you’ll see on the PMP exam and in the Project Management Body of Knowledge, and even in your project management career. Those two are “crashing” the schedule, which shortens the schedule duration by adding resources. That can be very costly as we’re adding more people or things. The other one we’re looking at is fast tracking, where activities or phases normally done in sequence are now performed in parallel or at the same time for at least a portion of their duration. That way we’re able to cut back on the time frame.
Let’s look at a few examples.
Crashing might involve approving over-time, adding resources, paying to expedite the delivery of activities on the critical path. Of course because of that crashing may result in increased risk, and certainly an increased cost.
As an example up the top here we’ve got Task 1, Task 2, Task 3 as our normal schedule with just one person assigned to each. But if we’re crashing this project schedule we’re adding resources to it, so now all of a sudden we’ve got a lot more resources there and we’re able to shorten the time of that task.
You have to be aware of the law of diminishing returns here, where sometimes adding more and more people -your return on that investment will get less and less over time. Sometimes adding more people isn’t the answer. But in this case, when we’re crashing a project we’re looking for that to be the answer to reduce our project schedule.
The other one is fast tracking, where we’re performing tasks in parallel. Again this might result in rework and an increased risk and cost, and it only works when activities can be overlapped to happen at the same time, to shorten the project duration on the critical path. We’re using the lead time, if there’s any lead time that we can take up we’re using that to perform those tasks in parallel. For example one, two, three in sequence but now one, two, three we’re performing some of these activities at the same time by fast tracking our project. Because we’re able to do that we don’t have to add more resources in this case, so the cost is a little bit less than if we were to crash the project with project resources. And that is the idea of schedule compression, crashing your schedule and fast tracking your schedule.
You will definitely see project estimating techniques mentioned as part of the PMP exam, so it’s good to know the four main different types and the differences between them.
Throughout your project you’ll be asked to make those estimations of future performance, and that could be in your Schedule, it could be in the Cost of the project, it could even be in the quality of your project. The four main methods that you will come across as part of the PMBOK guide are:
Parametric estimating
Bottom up estimating
Analogous estimating, and;
3-point estimating.
They might sound a little bit funny at first, so let’s go into them in more detail.
First of all we’ve got parametric estimating. This is where we’re actually using a parameter to estimate per item. So it’s a simple parameter, for example 55 meters or $55 per square meter or square foot. We might have a thousand dollars per roll of metal, or twenty days per delivery in our schedule for example, where it might take to get something to another country. We might be looking at two-week sprints per each feature that we’re delivering in a software project, or a team might take an eight-hour workshop to complete a risk assessment. All of these are parameters that we might assign to the activities so that we can estimate for those activities.
Next up we’ve got bottom up estimating. This is where we’re estimating project resources by assigning a value to the lower-level components of the Work Breakdown Structure. We’re starting from the bottom and we’re working our way up. And when we say the bottom we mean the the lower level tasks that have been assigned to our teams. Now these of course go up in the work breakdown structure to the larger tasks or features, and then to an overall delivered feature (and this is where we start getting into Agile potentially or Feature Driven Development) but the idea of that is that this team can estimate on their piece of work, this team can estimate on their piece of work or their single task or one or two tasks, and that might be say $10,000, this one might be $20,000, this one might be $5,000, and then we take all of those items and we bring them up into the feature so the total there could be $50,000 and then the total for the overall feature could be $100,000 for example. But the key is that we’re starting at the very lowest level of the activity, we’re starting from the bottom.
Next up we have Analogous estimating. This is where we’re finding an analogy, something similar to what we’re currently doing. We’re estimating the duration or cost of an activity or a project using historical data from a similar activity or a similar project. Of course this is frequently used to estimate project duration when there is a limited amount of detailed information, so we haven’t gotten down into the Work Breakdown Structure yet at the team level, we only have a really high-level idea. Using Analogous Estimating we can get a rough idea of how much it will cost, or how long it will take by looking at another similar project. It’s like an analogy, it’s similar to what we’re currently doing. Generally it’s less costly and less time-consuming than our other techniques, but also it is less accurate because we’re not really delving into the detail.
Last but not least there is 3-point estimating. This uses an average of three points – we might have the Optimistic estimate, the Pessimistic estimate, and the Most Likely estimate. The way that we end up working it out is: Let’s say our Optimistic schedule (O) is five days, our Most Likely (M) is seven days and then our Pessimistic (P) is ten days. We add each of them together and then we divide that by three, and that gives us the answer.
In fact here’s a better version that doesn’t take as much math or any decimals – let’s say we’ve got five, nine and ten divided by three – because 24 is a nice round number – we divide that by three and we get eight. And that’s how we do three-point estimating.
You might see a variation of this which is “Beta” or “PERT” (Program Evaluation Review Technique), where we’ve got Optimistic, then four times the most likely, and then our pessimistic as well, all divided by six instead.
And those are the project estimating techniques we will come across in the PMP Exam.
When we’re developing the project management plan a lot of the time we’re going to need to create baselines.
Baselines are one of the key concepts that is really important, because they are a point in time where data or information is locked in place, with any changes needing to go through a formal change or configuration management process to be reviewed, approved and accepted.
There are multiple documents that require baselining in your project management plan, and most of those will relate to the key constraints in your project such as:
Scope – the scope that you are going to deliver.
Time or the schedule – you might have your Gantt chart or the locked-in schedule, and you don’t really want that to change because you’re delivering something at the end and your customers are relying on that to be delivered.
Cost – if someone is sponsoring this project or paying for this project then of course they don’t want that cost to change, at least not without the proper approval process.
So what are these documents that we’re talking about? Well the need to be baselined fairly early on in your project, during the initiation and planning of your project.
First of all we’ve got the scope baseline. This is the approved version of a scope statement, a nice simple statement of what you are delivering to your customer. Then you’ve got the associated work breakdown structure or WBS and its associated WBS dictionary. That’s basically the scope broken down into smaller parts.
Then ultimately the activities that we’ll need to to deliver those parts – all of those parts of your scope – we want to lock that in so that we know that we’re going to deliver it on time, and we know if we’re not going to deliver it on time.
Then there is the schedule baseline, which is the approved version of the schedule model (that can be your Gantt or even just dates and activities depending on how you outline that in your project management plan) and can be used as a basis for comparison to the actual results so once it’s locked in. For example, how are we actually tracking over time? Are we on track, or we not going well? That’s what we really want to know.
Lastly we’ve got the cost baseline. This is the approved version of the time based project budget where we’ve got our activities, the things that need to be completed and we’ve got the cost associated with those activities. All of the schedule and the scope – if any of that changes then obviously that will have a big impact on the cost of the project as well, so all of these things are interrelated.
Before a baseline is actually defined, all of these documents can be updated as many times as necessary. You’ll find that right at the beginning of your project, during the project charter and maybe just before you’ve locked in your project management plan, no formal process is required at that time. But once that baseline is locked in then they can only be changed through the “perform integrated change control” process which we’ll probably notice is around 4.6 in the PMBOK guide. Any stakeholder can raise a change request, that’s how this is done. Anyone related to your project, whether it’s someone impacted by the project or whether it’s the sponsor who’s sponsoring the project, whether it’s the people doing the the work packages in the team of the project, they can raise a change request for that to be looked at which will go through the change control process. That change control process is usually outlined in your project management plan as the configuration management plan.
What Does a Configuration Management Plan Process look like?
It will be different for each organisation and even each team you work in. Maybe the process for you is raising a change request to the project manager, the project manager checks it out with a few different stakeholders or the required information, or maybe that’s someone in the project management team who then goes through to the sponsor or to the associated steering committee for example. Depending on how your project is outlined, which of course relates to the enterprise environmental factors which you’ll see come up a lot in the PMBOK guide. This is how the company operates, and every company is different. There will be similarities, there might be templates, there might be different politics or different parts of the company that need to be approached, or maybe different parts of the company that don’t talk to each other at all. You need to be aware of these enterprise environmental factors in how to get work done and that will impact the configuration management plan, which is how to make changes to your project and your project baselines once they are locked in. And that is project Baselines.
In a project manager role you will experience politics and power, and you’ll need to understand both of those things in order to get things done in an organization.
“Leadership” and “management” involve getting things done, but to do that a project manager needs to understand how an organization works. What is the culture? And what are the unwritten laws of getting things done? That will give you a higher chance of success, and that’s where you need to have a hefty serve of emotional intelligence to understand the politics and the power sources, and how to use those to your advantage. You’ll need to influence and guide and help deliver that business value as a project manager.
There’s a great list from the PMBOK guide on the types of power that you will come across.
You’ve got positional power, where you’re directly in the position of power as a manager or a leader.
Informational power, where you have information and you don’t need to share that with everyone – they need to come to you for that information.
Referent power, where you’re saying “The CEO asked me to do this, so everyone gather round and let’s get this done.” – we’re referring to someone else’s credibility.
Situational power, where maybe there’s a crisis involved and now all of a sudden we have more power because we need to really urgently get something done.
Personal power, using charm and attraction.
Relational power, where you are using your network of people
Expert power, where you have expertise in a certain area.
Rewards, where you can give rewards for certain things and that makes people want to do things for you.
Coercive power, where you might say “Something bad will happen if you don’t do this,” you’re coercing people into doing what you need.
Ingratiating power, where you’re using flattery – “Look how wonderful you’re doing, such a great job, you’re a wonderful person because you’re helping me out.”
All of these are valid, and you’ll find that when you’re aware of them you’ll see them more and more in your own workplace, and even in your day to day life. Within your family, within your friendship groups, it’s really great to be aware of.
And there are more.
You have pressure based power, limiting that freedom of choice.
Guilt based power, where maybe you did something for them and now you’re putting a bit of a guilt on them.
Persuasive power where you’re simply providing the right arguments, and lastly;
Avoiding power, where you’re simply refusing to participate.
These types of power will be on the PMP exam you’ll usually encounter them in some way shape or form simply because they’re part of everyday life and getting things done.
There are also different personalities that you’ll come across in your life as a project manager, and they are:
Authentic,
Courteous,
Creative,
Cultural where you’re measuring the sensitivity to other’s cultural values,
Emotional, being able to perceive other’s emotions quite easily,
Intellectual, which is just human intelligence and management practice
Political, understanding the political environment and how to make things happen,
Service-oriented where we’re serving others, maybe as a servant leader.
Social,
Systemic, where we’re understanding the need to build systems around things and ways of work and making it easier for people through processes as opposed to just forcing things through.
Those are the types of power and types of personalities you will find in your career and on the PMP Exam.
Below you will find all the project management lessons so you can learn all about Project Management. Direct from the Project Management Body of Knowledge (PMBOK), these lessons will help you navigate the often difficult waters that are a part of completing a project or change in your organisation.
Project Management Introduction, Overview and Basics
Well done for working towards a better career and improving your life and knowledge! Project Management is one of the best overall disciplines to help you navigate difficult organisation situations when you are trying to delivery value and make a positive difference.
This article is about the importance of project management itself, and managing that project in a successful way from beginning to end.
There are benefits to having good project management – effective project management leads to meeting stakeholder objectives, increasing the chances of the project success, resolving problems and issues as they arise (which they always do), responding to risks that might arise, as well as optimizing the use of organizational resources so the people that you’re bringing on board to your project can be used in the absolute best way. Identifying failing projects and sometimes terminating them if you absolutely need to, and managing all of the constraints – money, scope, time frame – all of those need to be managed or shuffled around so you can still meet the project objectives.
Poor project management on the other hand is a different story. I’ve seen this many times and I’m sure you have to, because project management is quite difficult. That’s why it’s nice to have a framework to operate by. You could have missed deadlines where now all of a sudden your project is late. You could have cost overruns where now all of a sudden it’s going to cost two million dollars instead of 1 million dollars or fifty thousand dollars instead of twenty thousand dollars whatever it is.
You could have poor quality – so it’s not actually meeting what the customer wanted. You could be having to rework things to redo them over and over again and the customer is not happy about that. Expansion of scope, otherwise known as scope creep, where the things that the customer wants actually end up being more and more and more and they weren’t designed in the initial project for what we wanted to deliver.
Using a Proven Project Management Framework
There are lots of things that can happen if a project is not managed well, and even when it is managed well. These things can go wrong but that’s the benefit of having a framework to manage it by – you know you’re doing the absolute best you can to try and get these things on the left here (meeting those stakeholder needs, increasing the chances of success) rather than having missed deadlines or cost overruns.
Operations, Projects, Programs, Portfolios
There is a relationship here between three things and we’ve got basically at the very base level, at the operating level where things are done on a day to day basis we’ve got the operations of a business. And that’s where we’ve got shared resources and shared stakeholders, we’re going to have to use these resources and these people from within the organization to help us get the project done, and that’s an essential thing that we need to manage throughout the life of a project.
The next layer from there are our projects, and these are the things that are delivering change to our BAU or operations, but sometimes you want to have a really good overview of all of these multiple projects – there’s lots of projects happening and you need something to clearly define a bunch of those projects in one, and that’s where we come into a program.
Program managers might have a couple of projects, a handful maybe 10 maybe even 20 sometimes where they’ve got multiple projects all delivering the same strategic objective, they’re all delivering a similar thing but doing different things.
Lastly made up of programs and projects and operations are our portfolios. A portfolio manager will have multiple programs and then multiple projects under each of those programs and then lots and lots of BAU teams and operations within the operations side of the business.
There are many different business documents that you’ll need to help kick-off and then manage your project, and we call these Project Management Business Documents that we’re going to need in the managing of our project. There are two main business documents, which are the project business case, and the project benefits management plan. Ultimately the business case will help us kick off the project and start the project but the project management benefits plan will help us manage those benefits that we’re wanting to deliver and make sure that we are delivering on those benefits when the project is delivered. The pre-work we’re looking at is the needs assessment – for example what’s the need of this project? Why is it being kicked off? Why is it being initiated? That helps us and feeds into our business case.
Benefits Management Plan
The project business case also has the benefits management plan within that, so that we know what benefits we’re delivering. All these documents will feed into our project charter which ultimately is one of the first steps, or is the first step in initiating a project. From there the project charter will feed in with all of the information that we’ve gathered from our needs assessment, business case, the risks involved, the stakeholders as an early view of the stakeholders, and risks and scope and schedule that might be involved and all of that feeds into the project management plan on a larger scale where we’re using that now to manage our project on a daily basis.
Project Business Case
So let’s dive into the project business case. What is actually in it? There are a few things usually, and they include business needs – so a description of what is prompting the need for action. Maybe customers have fallen off over the last year and we’re wanting to get more customers, maybe there’s a lot of rework that’s happening in a certain area and we’re wanting to reduce that rework. Whatever the business need is, we’re wanting to include that in the project business case. It’s a feasibility study of why we’re initiating the project. We usually give an analysis of the situation, so what are the facts, what is currently happening, are we currently at 80% capacity but we need to be at a hundred percent capacity? Whatever it is put the raw data and that project management data and info into this analysis of the situation for your business case, and then based on that we’re wanting to give a recommendation.
What’s the need, what’s the current situation, and based on that what are we recommending that people do to make a change and deliver what we need to deliver for this project.
Lastly once we’ve done that of course we’re wanting to see how the benefits that we’re delivering will be measured. Will it be Bob over there in a certain department measuring this for the next two or three months to make sure that things are on track and that it’s actually delivering what we want to deliver? However we’re going to measure it we want to put that in the plan as well.
Project Benefits Management Plan
Which leads us into the project benefits management plan. How are we managing these benefits? We want to usually include what the target benefits are, is it increasing this or decreasing that, include it in the project benefits management plan. We want the time-frame for realizing those benefits – is it a year? Is it six months? Is it one month?
Next, who owns the benefits. This comes back to our BAU, our operations. What are the metrics that we’re measuring, what are the assumptions that we’re making when we’re here measuring these things? We just need to know what those assumptions are in case they end up being wrong, and then we can see why we didn’t meet the the target or maybe we did better than the target (or whatever it is).
Ultimately we want to see what risks there are to meeting those benefits as well and put those in the project benefits management plan.
How to Measure the Project Benefits
There are many different ways to measure these things and measure these benefits and some of these are called out in the project management body of knowledge. They are Net Present Value – you will need to know this for the exam usually they’re fairly straightforward to go into and often the way they’ll word it on the exam will be “you have a net present value of of this and a net present value of that, so which one should you actually choose?” And you choose the highest.
For your Return On Investment we just want the highest return on investment. Internal Rate of Return – we want the higher rate of return as well. The payback period we want a shorter payback period if possible, and the benefit to cost ratio we usually want a higher benefit to a lower cost if possible.
But all of those are just numbers and numerical objectives and financial objectives – usually we can also have things like meeting non-financial objectives, fulfilling contract terms or conditions, meeting governance or regulatory requirements, achieving stakeholder satisfaction, meeting organizational strategy or goals – all these things could be non-monetary benefits that we’re realizing at the end of the project and we can also include.
And those are the project management business documents as part of our foundational elements of project management.
This is the Agile Practice Guide from the Project Management Institute and Agile Alliance, and this particular one is delivering in an Agile environment.
Check out the video and article below!
Delivering in an Agile Environment
There are two things in focus when delivering in an Agile environment, and the first is the team and the project charter. The second is the way we measure results – it can be very different than that of a traditional approach when we’re using Agile. First let’s look at the Charter.
Charter the Project and the Team
Usually in a traditional approach using the project management body of knowledge, which goes through very set steps that will initiate a project with a project charter. It will go through what the project stands for, what the risks are, who the stakeholders are, all those things. It will initiate that project and kick it off.
Now in addition to that when we’re using an Agile approach, our cross-functional team will initiate with a team Charter. What that means is you’ve seen the cross-functional team before where we’ve got the roles like the facilitator, we’ve got the product owner, and they represent the customer or the business. And then we’ve got our cross-functional team members who are those T-shaped members who have a general knowledge of a lot of things and then one really deep specialty knowledge. So these team members are extremely valuable because they might have one deep specialty of development and then many many general knowledge areas such as design or testing or or even leadership. All of those different things.
Our team Charter includes the project vision or the purpose, and this is so important and it’s so wonderful as well. Why? Because we want to start with “why”. Start with why is a classic book by Simon Sinek, and it’s just a wonderful way to get everyone on the same page and make sure everyone is heading in the right direction. “Why” is it that we are doing this in the first place?
Once we’ve got that, we work on a clear set of working agreements and that can involve many different things. When we were working on the purpose and the why we ask the questions “why are we doing this project, who benefits from this project,” and what does done mean for this project? What is the definition of done, when do we finish working? And then how are we going to work together. Now the best role and this can be anyone who has this leadership quality is the Servant Leader, who may facilitate that chartering process sitting down with the team, facilitating everyone, getting them working together and extracting that information from the team.
So they can put it down into words where it may have been hidden before. The servant leader’s role is also to help coach and to help remove blockers.
Now the team charter is also a social contract. That social contract can include things like team values, such as the sustainable pace and the core hours. We’ve talked about the sustainable pace before – we don’t want people to be working the midnight shift and then crashing and burning the next day. Or really going crazy one week and then having three days off sick – it’s just not sustainable, and it’s not a great way to work. From an Agile perspective we want that sustainable pace, and we want to put that down in words. What is that sustainable pace? Do we have set breaks, do we have set hours, what are our core hours, are they late or are they early, does everyone get in at the same time? All of those things, let’s write it down.
We have working agreements such as what “ready” means, so the team can take in work. So when are you ready to take in more work? What done means – so when are you finished that work? And the team can judge that completeness consistently.
Respecting the time box – so they are iterations of two to four weeks, and their work in progress limits. If the team is working in an Agile format where they’ve got cards and maybe they have limits for how many cards they can take on at a time, you don’t want all of your cards sitting in the backlog of work, but likewise you need to make sure that everyone understands when they can take on a new piece of work as well. And that goes in the team charter.
We want ground rules, such as one person talking in a meeting at a time. Or maybe you want a lot of discussion, a lot of collaboration at a time and maybe everyone agrees with that. And we want group norms such as how the team treats meeting times – is everyone on time? Or can someone miss it if they’ve got something really important on? What are those rules and does everyone agree?
Of course you can put any other behavior that the team wants to work with or address. Maybe something has bugged someone in a previous working arrangement and they just want to bring it up and they want to say – “Hey this didn’t work well the last time or maybe this worked really well,” and they want to bring this up and that can go in the team charter
as well.
How Agile Teams Measure Results
As we’re delivering in an Agile environment, Agile teams measure things quite differently to that of a normal project. The way they do that is that they actually measure results in the way that the project is delivered in other words the pieces of the project that are delivered, the functional pieces.
Agile favors value-based measurements, and that’s value from the perspective of our customer. So what are the valuable pieces that our customer can get their hands on and use, and how many of those pieces have we delivered? Instead of normal predictive measurements like Earned Value Management or Schedule Management or cost management that we could use in a more traditional waterfall approach, by measuring what is done and re-planning at each iteration by iteration there’s less room for error and more room to correct course.
And we’ll see that in the way that we measure those results with a burn-up chart or a burndown chart, and these burn up charts or burndown charts are basically these story points remaining. As you can see we might have features and then often many smaller “stories” will make up those features. And features can make up larger increments that we’re delivering to a customer.
The pieces of work that we’re working on as a team – maybe we have a thousand stories altogether in the in the product backlog and then per iteration we might have 20 or 30 or 50, but each time one of those stories is finished we’re marking it off on the chart, so we’re basically counting down the number of stories that we have completed. We want to aim for a certain amount of stories so as you can see here over 10 iterations we’re wanting to
finish that amount of stories but in reality sometimes it is a little bit different. So we can give ourselves a guide but obviously when it’s happening it might fluctuate – it might go up and down or not go at the exact pace that we want it to, because life happens and things get in the way.
So by making it visual and by measuring by the story points and the features that we’re releasing and the things that are getting done and the value that we’re adding to the customer – that is the way that an Agile team will measure results.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
Project Schedule Compression Techniques
Baselined Documents in Project Management
