Balancing Time, Cost, and Scope in Project Management

I want to explain some fundamental project management concepts. The first is the project triangle, and that is that the quality of the outcome of our project is going to be affected by balancing three things: time, cost, and scope. We refer to this as the project triangle, or iron triangle, or triple constraints, and the idea of this is that essentially we have the time element, which is how long our project is going to take.

We have the cost, which is all of the expenses that we're going to have, in other words, the budget, and then we have the scope. What work are we going to do in this project? And we are doing this under the idea of project scope, not product scope, of what the product is that we're creating, because you can do lots of different projects to create a product, so we're focusing on that project scope. What is the work required to deliver this particular project? All of the different tasks and phases and stuff, so basically, what work are we doing, how much is it going to cost, and how long is it going to take to do it? When we think about balancing these things, you can't change one of these things without changing at least one or two of the other parts.

There's a balance between them, so if you think about it, let's say, you want something to go faster, so you want to decrease the amount of time you want the project to happen faster, you want to get it done earlier. Well, one way is you could increase the cost, you could hire more labor, potentially hire more people to get the job done faster, so you can't just magically make the project go faster without changing something. What are you going to change? So you want the project to be done quicker, then maybe we can get more people, but that'll cost more.

Or another change could be that if you want it done faster, maybe we can reduce the scope, maybe we can do less work, so that we can get the project done faster. That would not increase costs, so what do we care about more? What is the client or what is the sponsor of the project? What do they value? Do they want the same amount of scope, but they want it done faster? Get more people to contribute. Do they just want it done faster, and they can't afford more? Well, maybe we can reduce the scope and get it done faster.

So it depends on people's priorities as to what we change, but keeping this in mind later, as we go through things like scheduling issues or budget issues, we need to always have these things in balance among these three concepts. Scope, cost, and time. Now, another way that you could express this, but don't ever show this to a client, is the idea that oftentimes clients will want something cheap, they want it fast, and they want it good.

But the intersection of those three things is virtually impossible to have it cheap, fast, and good. And we often say that we get to choose two. We can have something cheap and good, but it's probably going to be slow to get it.

We want something cheap and fast, probably not going to be of very good quality. And if we want something fast but good quality, it's probably going to be expensive. Just don't tell clients this and tell them to pick two.

This is just something for you to kind of keep in mind. It's kind of a humorous but realistic way of thinking about the iron triangles, thinking about balancing the things. What are our priorities? What do we want? Going a little bit more in-depth here also about the project scope.

So the project scope is the work that we're doing. Now, a lot of people just think of, okay, we're going to do some work, and we're going to produce some deliverables, right? So we're outcome-focused; the project will do something. It's going to deliver what, right? It's going to deliver something.

And so once we produce the deliverables, then everything's good, right? But we need to make sure that the customer or sponsor is satisfied that the deliverables meet their requirements. That is truly how we accomplish the objective. We can't just produce something if what we produce is not good.

And this is actually something where experience can sometimes make you wiser. I know on projects in the past, when I first got started early on in my career, you know, I assumed success and assumed everything would be good. And so let's say, for example, you know, I'm showing you slides right now.

What if I hired a teacher who maybe had some good experience? Maybe they produced slides before, or they've created course material before. What if I hire them to create a course, and maybe the slides aren't very good, right? But they produce the slides, right? So they make the slides. Did they produce the deliverables? Yes, they made some slides.

But to us, did they meet our requirements? What if they produce slides, but they weren't very good? Did that meet the objective of the project, which was maybe to create a new class? Just because they did the work doesn't mean that the work is of good enough quality. So we need to not only do the work, but also make sure that it's good. So that might mean that our budget needs to change, our schedule needs to change.

Because if I just assume that the project is done, when they give me the slides, I could potentially have a problem. Because what if their slides aren't good? What if I don't double-check them? So am I going to have something, some other person double-check that person's work? That's going to take some time, right? Am I going to review it? Is somebody else going to review it? So once I get those slides, they did produce the deliverables, but the project isn't done. I need to make sure that they are meeting their requirements.

And then if they don't meet the requirements, then who is responsible for making changes and corrections? See, we can't assume success. We can't assume everything is perfect. We have to make sure that it is.

And that can take time, that can take money. So those are all things that we need to work towards. We can make sure that we have success, but we have to plan for those things.

So we need to make sure that we don't just do the work, but that it is good quality work. So that's a concept that we need to think about as well. Overall, in project management, as an industry, as a job, things that you want to be thinking about are that we're going to be planning, and we're going to talk more about these concepts.

We are going to be, as project managers, we're going to be planning. We're going to be organizing things and collecting all the information from various sources. We are going to be commanding or leading people.

So the people that are in the team, we're going to be making sure that people know what they're supposed to be doing, leading them through examples, through directions, coordinating with all the people that are in the team, and trying to kind of manage and control the various resources to accomplish the objective. We're going to talk about resource management, allocating resources. We're going to talk more about that later, but these are kind of at a very high level, the kinds of things that are involved in managing projects.

Now, to be a bit more specific about the life cycle in which a project goes through, and we're going to focus on, in level one, we're going to start with initiation and planning. And then in level two, we'll move on to execution, monitoring, controlling, and closing. But these are not things that are completely one is done and then the next starts.

You'll notice that there can be some overlap. So I'm going to go through right now. I'm going to overview all four phases.

And depending on the group, like PMI is the Project Management Institute, they have a slightly different way of grouping these. They call them process groups, and they consider monitoring and controlling a different kind of group. So they might have, this is one, two, three, four, five process groups versus our four phases, but they're kind of similar to each other.

But the way we're going to break this down is into four phases: we're going to initiate, we're going to plan, we're going to execute, and close. And monitoring and controlling are kind of an always-there phase. I want to overview these and then hone in first on the initiation and planning.

So let's talk about these four phases. There can often be an overlap, where we're initiating and doing some planning. So there can be some aspects kind of commingled, and we are technically executing or kind of doing the project right from the beginning.

We're starting to do the work, but the vast majority of the work is going to be done here. So let's see an overview of these four different phases. Initiation.

This is where we need to identify that there is a problem, an opportunity, something that we have some reason to do a project, right? So there's going to be some problem we're solving, some need, some opportunity. This involves identifying the project. There can be lots of ideas for projects, and we're going to talk about how we identify potential project ideas.

And out of all those project ideas, you probably cannot do all of them. So it's important to select which project or projects you're going to do out of all of those ideas. So initiation is really deciding which projects you're going to do, which means identifying potential projects, choosing which you're going to do, and which ones you're not going to do.

And then you might write a project charter document to get into the details of the projects that you're going to do. We'll talk more about this in depth, but the idea of initiation is identifying potential projects, choosing which ones you're going to move forward with, and then moving them into planning. During the planning phase, this is where we think about, you know, what needs to be done? What is the scope? What are we delivering? How is it going to get done? What is the sequence of all the different activities and tasks? Who's going to do those? So, figuring out our resources, what is necessary, assigning responsibility, how long are things going to take, the durations of the tasks, what is the overall schedule, the sequencing of things, and how much is it going to cost? And if you think about the iron triangle of time, cost, and scope, this is really planning out all of those things.

Now, as I said, right now, we're going to do a high-level review first, so we can quickly get an idea of the life cycle of a project, and then we're going to dive more into initiation and planning, and then in level two, we'll come back, and we'll talk about the third and fourth phases. Now, just to go a little bit more into depth with planning, on a high level, what would be the steps in the planning process? First, you need to know what your objective is. What is this project trying to do? That might sound obvious, like, of course, you know what you want to do.

No, not necessarily. Sometimes you are assigned something, and it's kind of amorphous. It's not very well defined.

So we really do need to establish exactly what is being done and clarify that. If it's ambiguous, if it's confusing, let's figure out what we're doing, because we need to know what we are planning. So what is it that we're trying to do? And you define the scope of what we are going to do, what we're not going to do.

For this particular project, what is the scope? What is the amount of work that we're doing? Because there might be some things that you could do, like, for example, a website could have a blog. It could have an e-commerce. It could have all sorts of things, but what are you going to have in the context of this particular project? So, for your project, what is included and what is not included in the scope? And we can break that work down that we've defined.

We can break that down and get our task list. We'll talk more about these steps and how to create a work breakdown structure in a little bit. We can assign responsibility for those tasks.

So basically, we define the overall scope, break it down into tasks, and assign responsibility for those tasks. We think about the sequencing of those tasks or activities. We estimate what sort of resources are necessary to do those.

We think about how long those things would take on the activity or task level. And we can develop a schedule because we thought about, you know, who's going to do what, how long it's going to take. And based on that information, we can also start to estimate activity costs because if we know who's going to do what and how long it's going to take, we can start to add up our costs for those things, the resource costs, and those sorts of things.

And that will let us create an overall budget. Now, this is in the planning process. Can you see into the future? Because I can't.

And so these things are all estimates, right? We estimate things. It's what we think is going to happen. I so wish I could see into the future and know exactly what's going to happen.

But unfortunately, that superpower does not exist. So what we create is what we call the baseline plan. We have not executed the plan.

We've not done the plan, but this is a plan of what we think is going to happen. So in this example here, this is actually something that was planned and then executed. But in the planning phase, you create what's called the baseline.

It's what you think is going to happen. Once you move into the execution phase of doing the project, you will see whether you matched the plan or not. Did things start to slip and fall behind? Did you go over budget? So you will have to see, did I execute the plan according to what the plan was? The baseline is there for the sake of comparison. So we're going to compare what actually happened to what we planned, what we hoped would happen.

So, for example, we thought we would start on April 1st, and we did. And we thought we'd finish on the 6th, but we finished on the 8th. So we finished two days late.

There was a variance of two days. Okay. So that meant we finished two days later than we thought; our initial estimate was wrong for whatever reason that might've happened.

The idea being that you might plan on something happening, but things might start late. Maybe, you know, in this case, they just started late. They might take longer than expected.

In this case, we planned on this task here, one, two, three, four days. It did take four days, but it just started three days late. Unfortunately, we planned that this four-day task would be immediately followed by this task.

And there was a day in between. So maybe there was a delay in approvals or something. And so, you know, we are now one, two, three, four, four days past when we plan to have this done.

So our baseline plan is not being executed as faithfully as we thought it would be. There have been deviations from the plan. So this is moving us into executing, which is the execution of that plan.

So once you have that baseline plan, you start to perform the work. And during that time, instead of waiting for closing, I like to talk about recognizing, making people feel seen, appreciating achievements as they go through, and people in your team are doing the work. You know, I could wait until closing to kind of say some of that stuff, but projects can take a long time, potentially.

And you want people to feel appreciated and feel like their work is being seen and appreciated during the project, which can be the vast majority of the project timeline, here, which is people doing the work. So don't wait until the very, very end to thank people and recognize people and make them feel seen and heard. This is an opportunity to do this throughout the project as people are executing and doing that work.

Our role as a project manager during this process can be to monitor and try to control the process. So we got to see, are we actually executing according to the plan? How much are we achieving that baseline plan? So we're comparing what's happening to the baseline plan. Are we doing the correct schedule? Are we falling behind? How are we doing on budgets? We'll talk more about that in level two.

And, you know, maybe we're going over budget, and how could we try to get back on track? How can we take control of the process? And we're also thinking about risk, which we talk more about in level two of managing that risk, identifying risks, trying to mitigate or minimize those risks. And we'll talk about plans for doing so. So during that execution phase, that is when risks can arise and become issues.

So we want to be monitoring things and trying to control the process as best we can until the project winds down and we close the project. So this is where we can make sure that final payments are arranged. There can be final staff recognition and evaluations depending on the project, the team, and the company.

Sometimes these can be done very informally. Sometimes they're done informally. It all depends on the needs of the company, the departments, and, you know, how formal things are set up.

We can look back at the project and see what are areas that maybe we could have improved upon, but don't just look at things from a negative standpoint in the sense that what are ways that people and we as a project team could have been better. Also, look at it as a positive thing about what worked well. You know, we want to make sure that we encourage the good things.

Don't just focus on, oh, well, you can improve this, or you can improve this, or we could have done this, or we could have done this. What are the things that worked well? We want to make sure that we praise those positives because by praising those positives and saying, oh, that was great work. I love that.

Keep doing that. Good job. Praising those good things makes people, number one, feel appreciated, feel good about what they're doing, but also helps to let them know that those are good things, that they should keep doing those things.

So we praise those positives. We pull those out, and we point those things out. And yes, there could be a time when we can talk about things that we can improve on, but look at things from both a positive and a negative standpoint. Yeah, there are some areas we can improve, but also what are the things that worked well? Let's keep doing those.

Let's encourage those through positive reinforcement. And there might be lessons that we can learn, things that worked well, things that didn't work so well, so we can look back. Again, this can be very formal.

It could be very informal. We archive our project documents and basically kind of close things up. I will remind you that your inbox is not an archive.

It's hard for people to access the things that are in your email inbox, which is only accessible to you. So instead of waiting until everything is closing down, consider that when things come into your inbox, be the funnel that funnels it into the right place. If you have a document asset management system or if you have a server, this could be informal.

It could be something like Dropbox, Google Drive, or OneDrive, where you have different project folders, and you start to put shared things like receipts, approvals, contracts, plans, whatever kind of documents are coming through. If they're coming through you, be the funnel. Make sure that they get put into the correct place, not just stuck in your inbox.

Don't wait until the last minute. Don't wait until closing because that almost becomes a project in and of itself. If you do it during the project, during the execution phase, it is just the whole time.

It is much easier than trying to do it at the very end. And this might be something where you want to get feedback from your customer. Again, whether it's informally or formally, you might want to find out what they thought of it and then maybe report that to your upper management, things like your sponsor or your client.

Have a feedback session and make sure that they are happy with this project.