6 hours 23 minutes
Hello and welcome to a lesson five project execution inclusion. Er,
I'm your instructor, Dr Kane, and I'd like to welcome you to less than five
today. What we're gonna be going over is something that, honestly, if there was a easy way to
make sure that you executed enclosed each project successfully, I would be a very wealthy man. The reality is that about half of all projects fail,
and part of the challenge is trying to determine what can go wrong will go wrong during execution and how to go about fixing that.
So let's get started
the project execution phase and meet back up for a quick second within PM Eyes framework. They have execution as well as monitoring and controlling. And these are different knowledge areas. So if you're preparing for a PMP exam, just kind of disregard that for this course. This is not a PMP type course,
So we're not going to spend too much time breaking up the different knowledge areas. What we're talking about is the actual
phase of the project. So in execution phase, what you have is the actual work of the enterprise project being completed hopefully
and how you can go about making sure that the project execution phase goes off successfully. And again, there's no 100% to find way to guarantee if you do steps A, B and C that your project is going to be successful. So really, what we have here is,
ah, framework of best practices that you'll have to either
use or discard based on your project, your organizational structure and what your individual challenges are.
But in execution, we know that we are doing the work of the project, whether it's something of a more agile nature,
where you're continually doing value delivery to the customer or a waterfall type structure where the value delivery happens toward the end,
you're all in the project lifecycle stage. And what makes enterprise project so difficult with an execution is, of course, the level of complexity and the level of complication
within the project. The numerous differentiations between operations and project work and you're talking about something that has spread across the organization
and really has deep, deep tentacles within the organization.
But some of the areas that you should definitely be looking at are the bullet points on the slide here, so the 1st 1 is managing the churn, and what the term refers to is the fact that on a day to day basis, especially in enterprise project for your project team made number in the dozens or even hundreds.
There's a lot of individual efforts that air being undertaken by individuals within your organization.
Now, how do you as the project manager
gained visibility and monitor that level of work? And we're gonna go through some examples of that later on in this course?
one of the key key challenges is to manage that turn now. One of the things I like to talk about in this slide here is
the tasks and the task aeration. So
within a lot of project management courses in Project Management Training's you'll see, for example, that gan chart that we did in the last lesson where the task oration might be 2030 40 days because it takes, you know, a month or more to set up the data model for a particular system or whatever the case might be.
The problem with tasks that air that long as part of this managing of the churn is task completion, especially in enterprise. I T projects
is really sort of a binary kind of thing. So and what I mean by that is, if I have a 30 days to build a database and I tell you one day 15
that I'm halfway done. Okay, cool. I'm on schedule. On halfway done.
We're doing good.
The problem is, is that
anybody who's been in software development or database development you know, you can run into a problem at any time and sort of get waylaid
sometimes a great deal based on the type of bug you're getting or the error or the challenge that you're facing, because it is an unpredictable thing.
So that's what I mean by task completion, a sort of binary. So either
I'm done when I say I'm done or I'm not right. It's a one or a zero.
So the longer your task orations become within your schedule during execution,
the more that the ability exists, where you're gonna have a project task that's late and not know about it. So a good best practice for this is to look at
maybe 40 80
hours. Maybe, you know, 120 hours. That's really about your upward limit for task management because at the end of the day,
what you want to know as the project manager is, Are you completing your task on time? Or are you late? And the only way you're gonna officially no, that is to have a task due date and say either my task is donor is not done that do their zero earl.
So by de compiling your work breakdown structure for these enterprise projects, even though it seemed like a lot of extra work, it actually makes managing the project execution a lot easier because, as that sure is occurring within the project on a day to day basis every week, two weeks, maybe three weeks,
you're able to look at the schedule and ask the question
that really matters to you is Is this task complete? Because if it's not, it's late. If it is complete, it's on time or its earlier Whatever.
Those are the areas that you can, you have to manage that because if you look at all your tasks that air 12345 months long and say, Well, the person performing this task says that they're halfway done and we're halfway through the task oration and life is good.
That may very well be true, but you don't know that for a fact until that task is actually completed and turned in. And then you compare that task completion date to when it was supposed to be completed.
Which brings us to the next area, which is called base lining.
Base lining is more of a waterfall project activity, and basically, what you're doing is kind of what it sounds like. You're taking a snapshot of your project's schedule on your saying okay before we start execution, this is baseline zero. This is what I think
is going to occur and how long I think it's gonna take for these things to be completed
and then every month, quarter every six months. Whatever the case might be for your project, you're gonna compare that baseline against the actual execution. So every time a task is completed
earlier than your baseline date, you're going to see a positive variance every time that your task is completed later than the baseline, you're gonna see a negative variance. And what you're really looking for is baseline baseline and my trending on time and my trending earlier on my trending late
For some of these enterprise level projects, you might have 34 5000 individual tasks being performed. There's no way that you can manage that at a task level. You have to baseline the schedule during execution and then compare those trends because there's just
so many variables so many people involved in completion of the project.
So base lining is a good practice. It into Microsoft Project will baseline for you pretty easily. Pretty automatically. Smart feet will submit others, and basically what you're doing is you're saying at a macro level at an aggregate level within my project, how am I doing in my own time? In my early in my late
was What's my cost look like? Based signing also freezes that cost information on my on budgets in my under budget and my overbudget someone so on. So you want to get in the habit and you wanna build a baseline plan,
especially if you're doing sort of a waterfall. Ask or a hybrid type of project so that you can compare your predicted versus your actual.
And as we get into project closure, this becomes even more important. But even during execution, you have to apply the lessons learned by using base lining. So when you baseline a project and it says that you're trending 20 days late because your
business analysis phase took an extra 20 days because your subject matter experts are
overscheduled, you have to then take that information and apply it to the remainder of your schedule. So if my S Emmys are over schedule, which is very common in enterprise projects
during business analysis by 20 days, there's a really good chance that they're gonna be over scheduled and run late during the testing phase. Because who else is gonna do? You're testing besides your experts on the system
or the business process or whatever. So you need to take that extra 20 day variants and then look downstream at the rest of your project and say, Are there other areas in this project where I'm going to have to extend the schedule because of this particular issue
and that in that manner you can use base lining to forecasts and adjusted schedule in a proactive manner to make sure that your stakeholders and your project governance understands that you're reacting to the reality on the ground and that hopefully in the future your predictions will become more and more accurate as you go.
In addition, change management tends to be.