00:00:00 - Welcome to our final nugget in 3.0 Project Execution and Delivery.
00:00:05 - This nugget is 3.4 Project Delivery Management. Now the official
00:00:11 - definition of 3.4 from CompTIA is 3.4 Given a scenario, select
00:00:18 - which components of a project plan is affected and select what
00:00:22 - action should be taken, and gives a very long list of the traditional
00:00:27 - project management principles and approaches, such as managing
00:00:31 - risks issues, preparing performance reports, dealing with risk
00:00:36 - registers, communication plans, issues logs, and so on. I'm taking
00:00:41 - a somewhat different approach for 3.4 for project delivery management
00:00:47 - and focusing project delivery management on specific issues around
00:00:52 - project tracking, recognizing that many of the other components
00:00:56 - as listed in CompTIA for 3.4 for scheduling meetings, managing
00:01:01 - scope, following the communications plan are addressed directly
00:01:06 - in the other nuggets in this series. So again, while 3.4 is focused
00:01:12 - on project delivery management and selecting appropriate actions,
00:01:17 - this nugget is going to focus on project delivery management
00:01:21 - in the form of project tracking.
00:01:26 - As I mentioned, this nugget is going to focus on project tracking
00:01:29 - and the aspects of project execution and delivery partly as defined
00:01:34 - in the PMBOK for the execution component of our project life
00:01:38 - cycle, but specifically calling out project management activities
00:01:44 - that we would traditionally do in the execution phase to ensure
00:01:48 - that we're delivering a complete definition of project management
00:01:52 - principles in this nugget series. As I said, recognizing that
00:01:56 - the other components for issue risk management will be discussed
00:02:01 - in other nuggets in this series. So project tracking is focused
00:02:06 - on three things. Managing the status of the project.
00:02:11 - Once we know what the status of the project is, we may need to
00:02:16 - take actions to eliminate roadblocks, i.e. to make the team more
00:02:19 - productive. And directly related to that is taking the appropriate
00:02:27 - steps to optimize the project performance to ensure our project
00:02:32 - remains on target, on budget, going to complete according to
00:02:38 - the project plan.
00:02:41 - Recognizing that managing status and of course reporting on status
00:02:50 - is really the biggest job that we, as project managers, have.
00:02:55 - People expect us to tell me how the project is doing. Are we
00:03:00 - on schedule? Are we on budget? Are we going to complete on schedule?
00:03:04 - Are we going to complete on budget? And that's all
00:03:08 - maintaining, managing, and reporting on the status of the project.
00:03:14 - In order to do that, we need to gather the information to allow
00:03:17 - us to understand whether we are on target, and we do that through
00:03:21 - weekly status with the team.
00:03:27 - As part of doing weekly status with the team,
00:03:31 - we need to gather two key pieces of information. We need to know
00:03:36 - the actual effort by task
00:03:42 - of the actual work
00:03:46 - done. And we need to know from the team member their estimate
00:03:51 - to complete
00:03:54 - ETC by task
00:03:56 - based on the actual work they've completed to date and a realistic
00:04:04 - estimate to complete.
00:04:09 - And depending on how well projectized
00:04:13 - your organization is, gathering these two key pieces of information
00:04:19 - may be a substantial challenge in your organization.
00:04:23 - Gathering actual effort by task
00:04:27 - sometimes is a lot of work to convince the team members that
00:04:33 - you need it, that they have to provide this information for you.
00:04:37 - Team members want to say, "Our organization works a 40-hour week,
00:04:41 - so therefore, Steve, my actual effort to you is 40 hours."
00:04:48 - But that's not good enough. What did you work on this week? Which
00:04:53 - tasks did you work on this week? "Oh, yes, right. I worked on
00:04:59 - tasks 1, 3, and 8. There you go. I worked in tasks 1, 3, and
00:05:04 - 8, and I spent 40 hours working this week because that's what
00:05:09 - the organizational work week is." Again, you need to go back
00:05:12 - and say, "No, I'm sorry, that's not good enough. Of the 40 hours,
00:05:18 - how much time was spent on task 1? How much time was spent on
00:05:21 - task 3? And how much time was spent on task 8?"
00:05:26 - And they are going start to get annoyed with you and say, "But
00:05:29 - you're taking time away from me doing project work. You're making
00:05:33 - me come up with all of these fictitious numbers
00:05:38 - and trying to make me invent how much time how I did my work."
00:05:42 - And they are going to say, "Well, I spent about half the week
00:05:45 - on task 1 and I guess I'll split the remaining 40 hours evenly
00:05:50 - across 3 and 8."
00:05:53 - Again, we need to look them in the eye and say, "Is that really
00:05:57 - what you did? Did you really spend exactly
00:06:02 - 20 hours on task 1 and did you really spend exactly 10 hours
00:06:07 - on task 3 and did you really spend 10 hours on task 8?" And they're
00:06:12 - going to say, "No, of course not, but that's a good guess."
00:06:16 - Again, you need to go back to them and say, "I really need you
00:06:19 - to do better than a good guess. For this week, yes, I'll take
00:06:23 - your good guess. But for next week, could you please try to do
00:06:27 - a better job of tracking how much time you spent on each task
00:06:32 - so at the end of the week, you can give me realistic,
00:06:36 - actual effort by task." And what you'll find, more times than
00:06:42 - not, had they actually tracked their time, it's not going to
00:06:46 - be distributed as evenly as 20-10-10.
00:06:49 - It's going to be 18,
00:06:52 - it's going to be 12, and it's going to be nine.
00:06:57 - And you're going to say, "But Steve,
00:07:01 - that doesn't add up to 40, and our organization works 40 hours
00:07:06 - in a week."
00:07:07 - And you're going to say, "Yes, that's what I expected."
00:07:12 - We have other duties as assigned. We spend time on the organizational
00:07:17 - payroll being real employees to our organization. I'm not suggesting
00:07:22 - that we are trying to sneak time away from work and get paid
00:07:25 - for it. But we spend real organizational value time on the payroll
00:07:31 - that is not going to typically be directly related to project
00:07:35 - activities. We may have attended a branch meeting or an area
00:07:39 - meeting or a departmental meeting. We may have spent some time
00:07:42 - doing help to other projects, doing peer support. More times
00:07:47 - than not, our team members are going to spend time within their
00:07:51 - 40 hours doing valid organizational activities that do not directly
00:07:56 - contribute to my project, and as the project manager, I want
00:08:00 - to know the real time, not
00:08:04 - the wild guess time. And sometimes, again, depending on how projectized
00:08:10 - your organization is, convincing the team members that I need
00:08:14 - these real actuals, and I almost find that's a funny word, real
00:08:19 - actuals versus fake actuals, but these were fake actuals, and
00:08:24 - I need the team members to try to give me real actuals for their
00:08:28 - effort. It's going to allow me to do a better job of managing
00:08:33 - the project.
00:08:35 - And then once I win that argument, then I need to start the next
00:08:40 - argument with my team members and say, "And now I need real ETCs."
00:08:45 - You're working on a task that has a 36-hour estimate. Task 1
00:08:52 - had original estimate of 36 hours. The team member has spent
00:08:56 - 18 real hours to date on it. Therefore, they are going to simply
00:09:01 - tell me their ETC is 18,
00:09:05 - which is just simply mathematical
00:09:09 - ETC. To which again I say, "Is 18 really, really what you believe
00:09:16 - it's going to take you to finish the task?" And they are going
00:09:19 - to say, "No, but if the original estimate was 36 and I've already
00:09:23 - spent 18, the answer you're going to want to hear is I'm going
00:09:27 - to be done in 18 hours."
00:09:29 - To which my response is, "That's the answer I'd like to receive,
00:09:33 - but the answer I want to receive is your very best
00:09:39 - estimate on what's left. Are you going to get it done in 18 hours?
00:09:44 - Or maybe you're going to get it done in 16 hours, which puts
00:09:47 - your task ahead of schedule? Great. Or maybe you're not going
00:09:52 - to get it done without putting at least 20 hours, or maybe it
00:09:56 - really even needs as many as 24 hours to get the job done, which
00:10:01 - is going to give me a six-hour variance overrun." But I want
00:10:06 - to know that now. I want to know a week early that this task
00:10:11 - 1 is going to take six more hours to get the job done because
00:10:16 - I may have other team members waiting for the results of task
00:10:19 - 1 that I then need to reschedule. Or if all of my team members
00:10:25 - are telling me that task 1 and task 2 and task 5 and task 16
00:10:29 - are all coming in overestimate, then again, that's telling me
00:10:34 - I have a trend in my project. Maybe I have a learning curve issue.
00:10:37 - Maybe I have a tools issue. Maybe I have bad estimate issues.
00:10:41 - I don't know what the issue is going to be until my team members
00:10:45 - tell me the real facts,
00:10:48 - the real actuals as opposed to the fake actuals that's related
00:10:53 - to the project. But getting my team members to the point that
00:10:57 - they are able
00:10:59 - and willing to give me real actual effort and real validated
00:11:06 - estimates to complete often will take a lot of care and a lot
00:11:10 - of support,
00:11:12 - but we have to get them to that point because we need good solid
00:11:17 - information in terms of the actuals and the ETCs. We take that
00:11:22 - information. We put it back into our project scheduling software,
00:11:26 - and we use the facts we've gathered from the team to assess what
00:11:32 - the impact of a week's work on the project has on the project.
00:11:37 - Have me moved forward exactly on schedule? Are we moving ahead
00:11:42 - of schedule? Or are we starting to slip? But by getting this
00:11:47 - information on a weekly basis, it's giving us the information
00:11:51 - we need as project managers to allow us to manage our project
00:11:56 - by facts. And that's what's managing the status is all about,
00:12:00 - is getting the facts
00:12:03 - needed. Other facts that we need are far less numerical, but
00:12:09 - we need to gather from our team their successes. What's made
00:12:13 - them feel good so that we can give them some accolades and some
00:12:17 - pats on the back. But we also need to understand what their challenge
00:12:21 - and what their issues are, what's going to prevent them from
00:12:24 - getting the task done in 16 or even the 24 hours. What is holding
00:12:30 - them back? What are their challenge? What are the issues? What
00:12:34 - are the things that we need to do as project managers to remove
00:12:38 - those challenges and those issues? And we'll talk about that
00:12:41 - in just a couple of moments in the discussion on removing the
00:12:44 - roadblocks. Once we have good reliable weekly status from our
00:12:51 - team, our job as project managers is then to consolidate
00:12:58 - the individual team members' status reports and produce a project
00:13:06 - weekly status report. Now, this is where the Steve laziness comes
00:13:10 - in. When I gather the information from my team members,
00:13:16 - their successes, their failures, their accomplishments and their
00:13:20 - issues, I want to gather the information from my team members
00:13:24 - in exactly the same format, i.e. use the same template that I'm
00:13:29 - going to consolidate the team members and give to my project
00:13:34 - sponsor and to my boss. This is where the Steve laziness comes
00:13:38 - in. Gather the source data in the same format that you are going
00:13:41 - to use to present
00:13:45 - to the sponsor, and then the consolidation becomes a cut and
00:13:51 - paste activity. Now, it's definitely more than a cut and paste
00:13:53 - activity because you're going to get a degree of granularity
00:13:57 - from the team members that we're not going to want to consolidate
00:14:00 - and give to our project sponsor. And we're probably going to
00:14:03 - get some less than a Shakespearean prose from our individual
00:14:08 - team members that we may not present as is to our project sponsor.
00:14:13 - But even I get it in the raw format that's consistent, I can
00:14:17 - do my cut and paste to do my consolidation, and then I can do
00:14:21 - the wordsmithing
00:14:27 - to make it more presentable, to make it more summarized. And
00:14:31 - when I say "wordsmithing," I'm not talking about changing the
00:14:34 - facts that I've gotten from my team member. If my team member
00:14:38 - gives me a fact that there is a project issue, then I will absolutely
00:14:42 - deal with the project issue within my power and authority, and
00:14:46 - I will tell my sponsor the issue that I'm dealing with. I just
00:14:50 - may wordsmith it to make it a little more presentable, use proper
00:14:56 - English, as opposed to maybe the more technical speak that I'm
00:15:00 - going to get from my team members. But again, my recommendation
00:15:04 - is gather the data in a consistent format. Use cut and paste.
00:15:09 - Do some
00:15:10 - wordsmithing. Produce the weekly status report. Then again, I'm
00:15:15 - going to do a cut and paste activity,
00:15:18 - and I'm going to consolidate, and I'm going to produce a monthly
00:15:21 - status report. Recognizing that again, a monthly status report
00:15:26 - is probably going to go to a higher level of management, so it
00:15:29 - needs to be consolidated even more. There probably needs to be
00:15:32 - some more attention to wordsmithing, and we probably want to
00:15:36 - start using things like graphs and trend lines
00:15:41 - as we consolidate to the monthly. But again, if the raw data
00:15:46 - is gathered weekly, it absolutely facilitates the production
00:15:50 - of the monthly. And again, I'm going to consolidate and create
00:15:56 - more pictures, more trend lines, more pie charts, more graphs,
00:16:01 - and I'm going to present my project status quarterly to senior
00:16:04 - management. But this is what project execution and delivery,
00:16:09 - this is what project tracking is all about: gathering the right
00:16:13 - raw data,
00:16:15 - realistic actuals from the team members, and then consolidating,
00:16:22 - working with, managing the project based on those facts,
00:16:28 - and reporting those facts upwards and outwards within the project
00:16:33 - stakeholder world.
00:16:36 - Effective project tracking is going to be based heavily on the
00:16:40 - team status reports as I just discussed, but to do a full view
00:16:45 - of the project, the full status report
00:16:50 - of the project, we probably need to gather information from a
00:16:54 - few more sources.
00:16:57 - We will have to review the issues. Again, we are going to get
00:17:01 - issues reported to us by our team.
00:17:04 - But we probably need to have there is no probably need to it
00:17:09 - we need to have an issue management log.
00:17:14 - And as part of our weekly status and monthly status, we need
00:17:17 - to review the issue management log, extract
00:17:26 - and bring forward the appropriate issues as part of status to
00:17:30 - get them to the attention of management. Same thing goes for
00:17:34 - risks. We will have a risk management log, to be discussed in
00:17:38 - a future nugget, but we will extract the information from the
00:17:42 - risk management log and we will consolidate it in our status
00:17:46 - report. We've discussed it already. We're going to take the actuals
00:17:53 - and the ETCs from our team status report. We're going to plug
00:17:58 - it back into our software scheduling tool, and we are going to
00:18:03 - assess the impact
00:18:10 - of one week
00:18:12 - of execution.
00:18:17 - Each team member should have spent a week's worth of effort on
00:18:20 - the project. Did we get a week's worth of effort from the project?
00:18:25 - And probably not on a weekly basis but probably more appropriately
00:18:30 - on a monthly basis, we are going to get live
00:18:34 - actual dollars from accounting,
00:18:40 - from finance.
00:18:43 - So again, we need to extract, produce that information on to
00:18:48 - our status report, again, recognizing that typically, we're only
00:18:52 - going to get financial information from the finance department
00:18:55 - on a monthly basis. And typically, it's going to be a week
00:19:00 - or maybe even two weeks
00:19:02 - past the real date. So our month status report is due on the
00:19:07 - 31st or 30th of the month, but it may be a week or even two weeks
00:19:13 - after the month closes before we get the actual dollars from
00:19:19 - finance. But again, we need to do the appropriate information
00:19:24 - gathering and gather all of the information from the appropriate
00:19:28 - multiple sources within the project
00:19:32 - and external to the project
00:19:35 - as needed to produce reliable, consistent, and accurate status
00:19:41 - reports to allow us to do the proper project tracking. And with
00:19:45 - proper project tracking in place, we can do the management. We
00:19:49 - can begin to take those proactive decisions that we need to make
00:19:54 - as project managers to continue to move the project forward.
00:20:00 - Which leads us to the next step of tracking the project, which
00:20:03 - is the analysis of the facts
00:20:07 - and the taking
00:20:10 - actions based on the facts. So based on the facts that I've gotten,
00:20:17 - taking the actuals and plugging them into my scheduling software,
00:20:21 - is the project still on time, on schedule? If so, great. If not,
00:20:28 - what do we need to do
00:20:32 - to fix?
00:20:35 - Talk to the team members. Why are these tasks taking longer?
00:20:38 - Do you have the right tools? Do you need more training? Or did
00:20:43 - we just create bad estimates? Sometimes, we can take corrective
00:20:47 - actions, get better tools, better training. Sometimes, we just
00:20:51 - have bad estimates and we have to accept the fact that the project
00:20:54 - is going to have a 10% overrun. But we can then proactively
00:21:01 - communicate that we underestimated the complexity of the project,
00:21:08 - and therefore, we are going to delay
00:21:12 - the milestones
00:21:16 - by two weeks.
00:21:20 - And that's never a message that a project manager wants to deliver
00:21:24 - to their sponsor. "Hey sponsor, guess what? The project is going
00:21:27 - to be two weeks late." No. We don't want to go there. But sometimes
00:21:32 - we have to go there. But believe me, it's better if we go to
00:21:37 - the sponsor and say, "The project is going to be two weeks late
00:21:40 - but we're telling you
00:21:48 - this two months
00:21:52 - in advance."
00:21:55 - So based on taking the facts, plugging them into my software,
00:22:00 - analyzing what's going on, determining that we have a problem
00:22:04 - with underestimating due to complexity of the project, but proactively,
00:22:10 - I know these now two weeks before the milestone, the completion
00:22:15 - of development is due. If I tell the project sponsor two weeks
00:22:19 - or two months early that the project is going to be delayed,
00:22:24 - yes, they are still going to get angry with me. They are still
00:22:26 - going to challenge me. They are going to still say, "Steve, have
00:22:30 - you done everything within your power and authority to fix this?"
00:22:33 - And I can look them in the eye and say, "Yes, I have talked to
00:22:37 - the team. I have assessed why the schedule is running late. I
00:22:42 - have asked the team whether we can improve this, what are the
00:22:45 - options available for improvement. And the short and long of
00:22:48 - it is we are working as smart and as effectively as possible.
00:22:53 - The problem is the complexity is more than we originally assumed.
00:22:58 - The estimates are bad and the project is going to be late." But
00:23:03 - if I can tell you this now two months early, we can make the
00:23:07 - appropriate management decisions to accept the delay of the project,
00:23:11 - or we can make appropriate management decisions to remove scope
00:23:15 - or to change some of the other project constraints, i.e., adding
00:23:20 - more cost by adding more team members, but we can proactively
00:23:24 - take the steps two months out, knowing the project is going to
00:23:29 - be late, as opposed to waiting for the day before the milestone
00:23:35 - was due and say, "Hmm. We are not there yet. Hmm. I wonder when
00:23:39 - we are going to be there." That's not effective proactive project
00:23:43 - management. But with the facts and the appropriate analysis,
00:23:48 - we can take the actions early and take better actions early to
00:23:52 - change the scope, to change the team component, to take whatever
00:23:55 - actions we can to try to get back on time or accept the fact
00:24:00 - that it's simply going to be late, and do the appropriate downstream
00:24:04 - adjustment to delay the printing of the forms, to delay the marketing
00:24:08 - program, to delay whatever else was dependent upon our completion
00:24:13 - of our development milestone early as opposed to late. We need
00:24:18 - to do the analysis on the schedule. We need to do the analysis
00:24:21 - on the budget. And we need to be proactive
00:24:26 - based on the facts that we have. That allows us to determine
00:24:30 - whether we are delivering our project to specification and at
00:24:33 - the agreed quality.
00:24:36 - Take the facts,
00:24:39 - analyze the facts, and determine
00:24:44 - the proactive steps
00:24:49 - to deal with the facts.
00:24:56 - And if they're facts and we trust the facts, then we can take
00:25:00 - appropriate proactive actions to correct for, to accommodate
00:25:05 - for, to deal with the facts. But we are doing this proactively
00:25:10 - two months early, not doing it reactively when we suddenly just
00:25:14 - discover that we are going to be late for a milestone a day or
00:25:17 - two days before the milestone is due.
00:25:22 - And taking those proactive steps to eliminate project challenges
00:25:26 - is best summed up in eliminating the roadblocks, doing everything
00:25:30 - in our power as project managers to eliminate the roadblocks
00:25:34 - that are preventing our team members from being as effective
00:25:38 - as possible. Ensuring they have access to the resources. Can
00:25:43 - they get into the building?
00:25:46 - May sound oversimplified,
00:25:49 - but there may be instances where the building has 24-hour security
00:25:53 - requirements and the team member can only be inside the building
00:25:57 - from 7 AM to 7 PM. You have some IT people who are extremely
00:26:02 - early risers who want to be in the building before seven. You
00:26:06 - have other IT team members who are extreme night owls and want
00:26:09 - to be in the building past seven
00:26:12 - PM. Ensuring they have access to the resources. Ensure they can
00:26:15 - get at the code libraries.
00:26:20 - Do their user IDs have the appropriate rights and permissions
00:26:23 - to get out the information that they need? Do their user IDs
00:26:27 - have the appropriate rights and permissions to get at the data
00:26:30 - that they need to test their programs? So ensuring our team has
00:26:34 - access to all of the right resources, ensuring that any decisions
00:26:39 - on their issues,
00:26:41 - on their challenges
00:26:44 - that they're reporting on their weekly status reports are resolved.
00:26:48 - Taking those issues, those challenges forward to the sponsor,
00:26:53 - taking those issues and challenges forward to your IT manager,
00:26:56 - taking those issues and challenges forward and getting effective
00:27:00 - decisions to keep our team members working productively, basically
00:27:06 - securing commitment that everything within the power and authority
00:27:11 - of Steve and within the power and authority of the organization
00:27:15 - to enact is going to be put in place to keep our team working
00:27:21 - as productively as possible, and obtaining the optimal project
00:27:26 - performance from our team, which is our last discussion point
00:27:30 - for this nugget, optimizing the project performance. What can
00:27:34 - we do to deliver the project smarter? I've talked about using
00:27:39 - better tools, getting the right software, getting the right computers,
00:27:44 - getting computers with enough memory, with enough horsepower
00:27:48 - in the CPU to allow our team members to work effectively. Finding
00:27:53 - others in the organization that have done it before or going
00:27:57 - out and buying third party software tools that were going to
00:28:01 - allow the team members to work effectively. We want to reuse.
00:28:06 - We want to buy tools. We don't want to invent. We don't want
00:28:10 - to sit spinning the wheels. We need our team to work smarter,
00:28:15 - not harder, and our job as project managers is to remove the
00:28:20 - roadblocks, to listen to the team, to deal with their issues,
00:28:24 - to deal with their concerns, and put the wheels in place, put
00:28:29 - the processes in place, allowing the team to be productive so
00:28:33 - that when we are gathering their actuals,
00:28:37 - gathering their ETCs, we know they are working as effectively
00:28:41 - as possible. And therefore, when we take those actuals and we
00:28:44 - take those ETCs and we plug them into our schedule, we know we
00:28:48 - are getting a realistic optimized view of what it's going to
00:28:53 - take to complete our project and give us that proactive view
00:28:57 - as to whether the project is going to be delivered on schedule
00:29:01 - and on budget to specification, or whether there is going to
00:29:05 - be some project delivery challenges,
00:29:07 - which summarized this nugget on project tracking. Managing the
00:29:12 - status, getting real
00:29:15 - actuals as opposed to fake actuals, and realistic
00:29:23 - ETCs from the team, understanding what their issues are,
00:29:28 - understanding what their challenges are, taking all of that,
00:29:33 - building it, consolidating
00:29:37 - into the project status
00:29:43 - on a weekly, on a monthly, and on a quarterly basis, presenting
00:29:49 - that to the sponsor and the stakeholder community to keep them
00:29:52 - appraised of how well the project is doing, and taking the information
00:29:57 - from our team members to eliminate the roadblocks and optimize
00:30:01 - the project performance is the support that we as project managers
00:30:06 - will be doing during the project execution phase of our project.
00:30:11 - And with that, we conclude 3.0 Project Execution and Delivery
00:30:16 - and pave the way for the next series in this
00:30:21 - nugget process, which is 4.0 The Change, the Control, and the
00:30:25 - Communication, the activities we, as project managers, do during
00:30:31 - the execution of the project.
00:30:34 - This concludes our Nugget on Project Delivery Management, or
00:30:38 - as I have focused on, Project Tracking. I hope this module has
00:30:42 - been informative for you, and thank you very much for viewing.