CompTIA Project+ PK0-003

Develop Project Schedule and Resources and Roles

by Steve Caseley

Start your 7-day free trial today.

This video is only available to subscribers.

A free trial includes:

  • Unlimited 24/7 access to our entire IT training video library.
  • Ability to train on the go with our mobile website and iOS/Android apps.
  • Note-taking, bookmarking, speed control, and closed captioning features.

What is Project Management

Project+ and how to prepare for the exam

Pre-Project Setup

Project Planning

Prepare Scope Statement

Create WBS and WBS Dictionary

Define Change Management Process

Develop Project Schedule and Resources and Roles

00:00:00 - Back at our project road map for 2.0 project planning this nugget
00:00:04 - focuses on two elements, the first is 2.4 develop project schedule
00:00:09 - and the second is 2.9 resources and roles and if I give you the
00:00:14 - full name from CompTIA 2.4 develop a project schedule based on
00:00:20 - WBS project scope and resource requirements and 2.9 identify
00:00:26 - roles and resource requirements based on WBS and resource availability.
00:00:32 - So I believe from that long definition from CompTIA we understand
00:00:37 - the similarities
00:00:42 - and understand why I have chosen to combine 2.4, the developing
00:00:48 - of the schedule, and 2.9, the resources and roles, because the
00:00:52 - schedule is developed based on the understanding of what resources
00:00:58 - and roles are assigned to the project schedule. Again, following
00:01:03 - from the CompTIA we start from the WBS which has all of the work
00:01:07 - packages identified, we take the WBS, we assign the roles,
00:01:13 - the resources to the WBS, and we use that to develop the project
00:01:18 - schedule with one extra piece that we have to talk about as part
00:01:22 - of this nugget which is estimating.
00:01:28 - So this nugget is going to focus on taking the WBS already developed,
00:01:33 - understanding what resource and roles are required to complete
00:01:37 - each element, each work package in the WBS, developing the estimate
00:01:42 - for the work.
00:01:44 - and using that information to develop our project schedule. The
00:01:50 - first step I think is just to understand why we need to create
00:01:53 - a project schedule and probably the most self evident statement
00:01:57 - of why we want to create a project schedule I haven't even listed
00:02:00 - is to know
00:02:03 - the end date
00:02:06 - and everyone wants to know when the project is going to end.
00:02:08 - How long is this project going to be? Is it a six-month project,
00:02:11 - an eight-month project? Is this project going to be done in July
00:02:15 - or is this project going to be done in September? So the most
00:02:18 - self evident reason why we create a project schedule is to know
00:02:22 - the end date which is part of the overall project characteristics. So
00:02:27 - again I think that's a self evident statement
00:02:31 - worth mentioning but other reasons why we need to create a project
00:02:35 - schedule is so that we can integrate the project with other organizational
00:02:40 - activities. If we have an understanding of, A, when the end date
00:02:45 - is we can integrate that with other organizational activities.
00:02:49 - Perhaps there are other organizational activities/projects
00:02:53 - that are ongoing in your organization that are dependent upon
00:02:56 - or that are subsets of or that are prerequisites to your project.
00:03:02 - I implement a project once upon a time where I implemented a
00:03:06 - new point of sales system for a large grocery retail. My project
00:03:10 - was focused purely on the technology
00:03:14 - aspects of developing, testing, validating, and preparing the
00:03:19 - point of sale system for rollout but there were other organizational
00:03:22 - activities to do store redesign
00:03:25 - so you did a substantial redesign at the front end as part of
00:03:31 - the new POS rollout, there were other organizational activities
00:03:35 - for carpenters
00:03:38 - and other trade resources to win and actually change
00:03:44 - the frontend and so on. So there may be other related projects
00:03:49 - that need to know the end date or milestones
00:03:55 - within your project so that they are prepared and they have their
00:03:58 - work done to coincide with your project end dates. There may
00:04:03 - be other organizational activities that are just of interest
00:04:06 - when will resources be freed out, when will data be available,
00:04:10 - when will, when will, when will so if you know the project's
00:04:14 - end date and you know significant project milestones and publish
00:04:19 - that within the organization senior management can use that information
00:04:24 - to better integrate the project with overall organizational activities. More
00:04:30 - microscopic focus within my project creating a realistic project
00:04:35 - schedule and knowing specific milestones allows me to better
00:04:40 - coordinate project activities and better coordinate project resources,
00:04:44 - that I can have my resources
00:04:48 - the term I use is fully leveled
00:04:53 - that we have full time work for the business analyst, for the
00:04:58 - database architects, for the developers, that they don't have
00:05:02 - ebbs and flows, that they're not busy for two weeks and then
00:05:06 - they have part time availability and they drop down.
00:05:10 - We want to have the resources fully leveled and fully loaded
00:05:14 - for the project. We will know other resources maybe we need again
00:05:20 - carpenters, we may need other organizational resources. By having
00:05:25 - an effective published project schedule we can again better coordinate
00:05:29 - all of the components, the activities, the work, the resources,
00:05:34 - everything required to make our project a success. And finally
00:05:38 - knowing what our project schedule is with the appropriate milestones
00:05:42 - allows us to identify schedule conflicts that we're not done
00:05:47 - training in
00:05:52 - time for rollout or that the implementation
00:06:01 - conflicts with the corporate yearend.
00:06:10 - So there are lots of good reasons why we need a realistic and
00:06:14 - achievable project schedule that is much more than just knowing
00:06:18 - the end date. So let's have a better look at what's required
00:06:22 - to create that realistic and achievable project schedule. A
00:06:27 - project schedule is created in four steps. The first step identify
00:06:31 - all of the WBS elements. This is done
00:06:36 - in terms of review for this nugget series.
00:06:40 - Our previous nugget in planning discussed creating the WBS, identifying
00:06:46 - all of the work packages required to satisfy the scope. This
00:06:50 - nugget is going to focus on the next three elements 2, identifying
00:06:54 - the task estimates how long
00:06:58 - will each
00:07:01 - work package take to complete, how much work
00:07:06 - is required
00:07:10 - to complete each work package. Remember back when we were doing
00:07:13 - the WBS creation I said don't worry about developing the estimates,
00:07:16 - we're going to do that later? Well later has now come and in
00:07:20 - this nugget we're going to develop the estimates, identifying
00:07:22 - how much work each
00:07:26 - and every work package is going to take.
00:07:29 - We need to identify the resource assignments who should do it?
00:07:37 - Now back in creating the WBS elements we identified the role,
00:07:42 - that this should be done by an analyst
00:07:45 - or this should be done by a
00:07:48 - DBA or this should be done by a developer.
00:07:52 - In creating the project schedule we take it beyond the role
00:07:57 - and typically we identify the resource.
00:08:01 - This will be done by Fred
00:08:04 - or Sally
00:08:06 - or dot, dot, dot we assign each of the work packages to a unique
00:08:12 - identified team member on our project.
00:08:15 - And a fourth component of creating the project schedule is we
00:08:18 - need to identify the task dependencies A must
00:08:24 - be done before we can do B. And with all of the WBS elements
00:08:30 - identified and estimated, with resources assigned and the dependencies
00:08:36 - identified we plug this in the software,
00:08:42 - we plug it into project scheduling software,
00:08:47 - and using the I'm going to say magic of the project scheduling
00:08:51 - software we get a project schedule. Now it's not quite simple,
00:08:56 - using project scheduling software is a PM skill in and of itself,
00:09:00 - this nugget series does not focus on using project scheduling
00:09:04 - software, this is focused on the knowledge required to pass your
00:09:07 - Project Plus. We do have other nugget series focused on using
00:09:11 - project scheduling software, specifically Microsoft project and
00:09:15 - if you're interested in that aspect of project management I would
00:09:18 - encourage you to explore that nugget series as well.
00:09:23 - We identify the WBS, we assign the estimates, we assign the resources,
00:09:28 - we assign the dependencies, we plug it in the software, and we
00:09:32 - get a project schedule. That's how project scheduling to me is
00:09:37 - done in real life in project management. The next nugget in this
00:09:40 - series is going to look at the mechanics,
00:09:45 - the theory
00:09:48 - of how
00:09:50 - or what happens within I don't want to say how project scheduling
00:09:53 - software works but the mechanics what happens, the theory behind
00:09:57 - how project scheduling software works. We need to explore the
00:10:01 - mechanics and the theory in the next nugget because those are
00:10:05 - going to be questions on your Project Plus but in reality a day
00:10:08 - in the life of a project manager you do these four elements,
00:10:12 - you use your software, and you get your project schedule. There
00:10:17 - are three basic components to creating effective task estimates
00:10:21 - number 1 realistic estimates we will deal with processes, develop
00:10:26 - realistic estimates just in a few minutes in this nugget.
00:10:31 - I will discuss whether estimates should be based on actual effort
00:10:35 - or duration
00:10:38 - again next in this nugget series. I want to spend just a moment
00:10:42 - in time talking about how big an estimate should be and I'm not
00:10:47 - saying we will automatically always
00:10:52 - create estimates that are in the 40 to 80 hours but this is part
00:10:56 - of the consideration that we talked about earlier in the nugget
00:10:59 - series related to the WBS is it estimatable
00:11:06 - and is it manageable.
00:11:10 - And for estimation the generally agreed consensus is if an estimate
00:11:15 - ends up being in the 40 to 80 hour time range it should satisfy
00:11:22 - the estimatable and manageable characteristic that we used already
00:11:28 - to determine when we stopped decomposition
00:11:31 - of our WBS. Now that we're doing the real task estimating we
00:11:36 - want to apply this rule
00:11:40 - quite religiously I would suggest if in the process of developing
00:11:44 - our estimates we come up with a lot of 4-hour,
00:11:48 - 6-hour, 12-hour estimates for the WBS elements. I
00:11:55 - would suggest we probably did our decomposition in WBS creation
00:12:00 - too much and we may want to combine
00:12:04 - some of those WBS elements, i.e. we may want to decompose some
00:12:09 - of those WBS elements
00:12:11 - or if in the process of developing our estimates we're starting
00:12:15 - to come up with 120-hour,
00:12:17 - 200-hour, 400-hour estimates chances are we need to go back to
00:12:24 - our WBS decomposition
00:12:26 - and we need to further
00:12:30 - break down
00:12:34 - the WBS.
00:12:36 - Just a rule of thumb 40/80 hours there will absolutely be some
00:12:43 - very small tasks in your WBS that are of critical importance
00:12:48 - attend deliverable walkthrough presentation
00:12:53 - four hours.
00:12:55 - It's a critical task, we need to have it pulled out, there's
00:12:59 - no way we can create that discreet attending of a deliverable
00:13:03 - walkthrough presentation, there's no way it can be combined with
00:13:07 - any other task because it's so discreet so yes, there will be
00:13:11 - some very small tasks but again if we get a lot of them I would
00:13:14 - suggest we look at some way to combine, assuming they're not
00:13:17 - discreet and if we get a lot of large task estimates we probably
00:13:23 - need to do some further decomposition of our WBS. But now let's
00:13:27 - go on with estimating and let's look at developing realistic
00:13:32 - estimates and immediately following this we're going to look
00:13:35 - at a discussion on should we be estimating on effort or should
00:13:40 - we be estimating based on duration. A
00:13:43 - key consideration you have to make when developing your project
00:13:46 - estimates are you estimating effort
00:13:50 - or are you estimating duration? They're very different terms.
00:13:55 - Effort is actual work the hours
00:14:00 - or days
00:14:02 - or weeks or months required to heads down focus
00:14:08 - time to do the actual work where duration is elapsed time. And
00:14:15 - you may say "Well it's the same. If I assign a resource to do
00:14:19 - a task and it's got a 24-hour estimate on it it's going to take
00:14:22 - three days." Well maybe and let's explore that example. We have
00:14:27 - 24 hours of effort, if the task starts on a Thursday
00:14:33 - as 24 hours of effort it's going to end on a Monday.
00:14:38 - Is the duration five days, i.e. we've included Saturday and Sunday,
00:14:43 - or is it three?
00:14:45 - It depends on how you do your counting. If you're counting absolute
00:14:49 - calendar days the duration is five, if you're counting business
00:14:53 - days then yes, again, 24 hours of effort is the same as three
00:14:59 - days of duration or without trying to change my timelines
00:15:06 - three days of effort equals three days of duration all things
00:15:11 - being equal, a focused resource doing the task. But sometimes
00:15:15 - that's not the case let's explore the same scenario where we
00:15:19 - have three resources doing the task. If we have three resources
00:15:24 - doing 24 hours of work
00:15:27 - the duration is going to be one day. They're going to start and
00:15:30 - finish that task all on a Thursday.
00:15:34 - Or the opposite scenario we have a part time resource, we're
00:15:38 - only working on the project 50% of the time.
00:15:41 - If they're working on the project 50% of the time 24 hours of
00:15:46 - effort, three days at 50% is going to take six days of duration
00:15:53 - and I have the question mark in there because that's assuming
00:15:56 - a 50% if it's 25% versus 75%
00:16:00 - again the actual duration is going to change but in all cases
00:16:06 - the constant is the effort. Can you see I have a bias? I have
00:16:11 - an absolute bias that project estimating should be done on effort
00:16:18 - and not on duration. It gives you more flexibility, it ensures
00:16:22 - that weekends whether or not you count them as part of your calendar
00:16:27 - will not impact any calculations done and it gives you flexibility
00:16:31 - with resourcing. Where appropriate you can add multiple resources,
00:16:36 - where appropriate you can have part time resources it is the
00:16:39 - constant. I would recommend that most
00:16:47 - project tasks are estimated by effort
00:16:52 - again it's the constant.
00:16:55 - I say "most" because there will be some tasks that probably are
00:17:00 - not effort-based tasks.
00:17:03 - Attend training
00:17:09 - you're going to deliver a two-day
00:17:13 - training/orientation session for your project that task is going
00:17:22 - to take two days duration. If
00:17:25 - you have 10 people attending it's going to take two days to deliver
00:17:30 - the task; if you have 20 people attending it's going to take
00:17:33 - two days to deliver the training; if you have 5346
00:17:37 - people attending it's still going to take two days to deliver
00:17:40 - that task. So there will be some
00:17:43 - tasks that are absolutely duration-focused tasks but I would
00:17:49 - suggest most tasks should be estimated on effort. In
00:17:56 - continuing that discussion effort is work-based, duration is
00:18:00 - calendar-based. Again I recommend most of your tasks are estimated
00:18:05 - on effort,
00:18:07 - it is the constant. The other reason I recommend that you develop
00:18:12 - your estimates based on effort it's independent availability,
00:18:16 - part time
00:18:19 - or multiple
00:18:22 - we already explored that. Effort also gives us independence of
00:18:27 - productivity. What do I mean by productivity? If we develop our
00:18:33 - effort estimate that says it's going to take 24 hours for an
00:18:37 - average resource
00:18:42 - to do the job
00:18:45 - we have a bunch of green beans, new hires assigned to our project,
00:18:53 - we don't expect them to be fully productive on the project for
00:18:57 - a period of time. Using effort-based estimating we can adjust
00:19:03 - their availability per se to deal with productivity. So if we
00:19:07 - assign Joe
00:19:09 - to the task
00:19:11 - of 24 hours Joe is an existing
00:19:16 - average resource
00:19:19 - we're going to assign them at 100% availability. But if we have
00:19:23 - the green beans
00:19:26 - we're going to go through substantial learning curves, we're
00:19:30 - going to treat them as if they were part timers
00:19:33 - and we're going to say "They're only going to give me 50%
00:19:37 - productivity therefore that 24-hour task is going to take my
00:19:42 - green beans six days to complete but if I assign them to Joe
00:19:48 - I'm going to assign Joe at 100% availability and that task is
00:19:52 - going to get done in three days." Other benefits of using the
00:19:55 - effort-based it gives us the ability to be independent on holidays
00:20:00 - again we already talked about ignoring Saturdays and Sundays
00:20:04 - but what about holidays in the middle of your project, in the
00:20:07 - middle of the week, the long weekends?
00:20:12 - Our scheduling software will schedule around holidays therefore
00:20:16 - again effort is our best approach. Productivity and skills really
00:20:21 - can be considered into the same scenario
00:20:26 - if Joe is not a green bean, doesn't have the same level of productivity
00:20:31 - but is an existing resources but we don't believe they have the
00:20:34 - business skills,
00:20:39 - the background knowledge again we can adjust their availability
00:20:45 - to make them 75% productive or whatever. Theater consideration
00:20:50 - for effort-based
00:20:52 - and the ability to adjust the person's availability is it allows
00:20:57 - us to consider the other work that they have to do as part of
00:21:00 - being a corporate employee. Now let's explore this other work
00:21:04 - just a little bit further. Other
00:21:07 - work factors directly into our resources availability on the
00:21:11 - assumption that our organization works 40 hours a week is it
00:21:16 - fair to assume
00:21:19 - project resources
00:21:24 - actually work 40 hours a week? And I would suggest the answer
00:21:28 - is no.
00:21:30 - If this is a long term project we probably need to provide some
00:21:34 - allowances for vacation. If this project is going to transpire
00:21:39 - over 6 months, 12 months chances are some of our project resources
00:21:44 - are going to want to take vacations so we need to reduce
00:21:50 - their availability
00:21:54 - by some factor to an arbitrary number of 0.5 hours, depends on
00:21:59 - how long the project is, how far ahead your vacations must be
00:22:02 - booked, how many resources are on the project, etc. etc. So if
00:22:06 - you have a six-month project vacations are booked typically up
00:22:11 - to six months you have a pretty good understanding of what resource
00:22:15 - vacation plans are and you factor that directly into the plan
00:22:19 - and you can make this a very low number. If this is a 12-month
00:22:23 - project or even a two-year project and you certainly don't have
00:22:26 - vacations pre-booked for that period of time you might want to
00:22:29 - make this number substantially higher; in fact make it the equivalent
00:22:34 - of what the corporate allocation for annual leave would be per
00:22:39 - resource per week.
00:22:43 - Your project team members are going to get sick again depending
00:22:46 - on the project dynamics, I'm not going to say the time of the
00:22:49 - year but I will say the time of the year, different times of
00:22:52 - the year when we're heading into flu season we typically will
00:22:56 - get more sick time than we would in non-flu season so you may
00:23:00 - want to adjust.
00:23:02 - Other assignments, other work they have to deal with email, they
00:23:07 - have to deal with phone calls, they have to deal with other office
00:23:11 - stuff that is not project-related
00:23:14 - so therefore how much time in a week do we need to reduce our
00:23:17 - availability to deal with? If you're dealing with a senior team
00:23:22 - member chances are they do other support within the organization,
00:23:28 - other organizational members will come to your team members and
00:23:32 - say "Hey Joe, hey Sally, can you give me a hand? I'm doing something
00:23:36 - really difficult and I know you're a good person. Can you help
00:23:38 - me up?" So this is just general
00:23:43 - other things.
00:23:46 - And again what are your policies for corporate meetings, team
00:23:50 - meetings, departmental meetings? How much time do you need to
00:23:53 - reduce? So going with the basic assumption that we work 40 hours
00:24:00 - I would suggest you probably shouldn't be planning on your people
00:24:03 - working any more than 37 and a half, maybe 35, and for some of
00:24:08 - your senior resources that are going to be doing significant
00:24:11 - amounts of other support maybe it's realistic to say that you
00:24:15 - only work 30 hours out of a 40-hour week so we go back to that
00:24:19 - availability. No one is available 100%, they're available 90%,
00:24:26 - maybe even as low as 75%
00:24:29 - based on full time availability and then if they're a part timer
00:24:33 - that 75% gets cut in half and becomes a 37 or whatever per cent
00:24:39 - availability. Using effort-based estimating allows us to factor
00:24:45 - all of these in; using duration based estimating doesn't allow
00:24:51 - us to factor that in as effectively. Again, my bias is showing,
00:24:55 - I recommend effort-based estimating for the Project Plus Certification
00:25:00 - exam you need to know that you can estimate based on effort,
00:25:03 - you can estimate based on duration.
00:25:07 - This is my personal recommendation for on-the-job application
00:25:12 - of estimating. So the last component for estimating is where
00:25:17 - are we going to get our estimates from, how do we know
00:25:23 - that a task
00:25:25 - is going to be done in 24 hours of work
00:25:28 - and I use work and effort interchangeably throughout this nugget
00:25:32 - series how do we know that task is going to take 32 hours of
00:25:37 - work, how do we know that the task is going to take 65 hours
00:25:42 - or work? Well we have a random number generator
00:25:50 - and we program it to give us estimates between 40 hours and 80
00:25:55 - hours. No-some
00:25:58 - people may feel that estimating is as random as a random number
00:26:02 - generator but because the estimates are going to be used to develop
00:26:06 - our project schedule we need to put a great deal of thought and
00:26:10 - care and attention into our sources for estimating.
00:26:14 - Analogist where
00:26:17 - have we done something like this before?
00:26:23 - Use the estimates from the last project that we worked on that
00:26:27 - was similar. Call in a
00:26:31 - guru, find someone somewhere who has the analogist information
00:26:35 - to help you develop realistic estimates.
00:26:38 - Probably the most common methods of estimating for IT projects
00:26:43 - is some sort of quantitative paramedic type estimating. I have
00:26:49 - an average
00:26:51 - module for development.
00:26:55 - Using analogist or expert judgement you determine an average
00:26:59 - module for development is going to take three days;
00:27:04 - a complex
00:27:07 - module for development is going to take six days; and a simple
00:27:12 - module for development is going to take a day and a half. We
00:27:17 - then say for the purpose of our estimating we have 13 simples,
00:27:25 - we have 10 averages,
00:27:29 - and we have 8 complex.
00:27:33 - Using these metrics we can come up with a high level estimate
00:27:37 - for development in general and at the detailed work breakdown
00:27:41 - structure level we simply say this WBS element, this work package
00:27:45 - is one of my 13 simples so it's going to take a day and a half.
00:27:50 - And this particular module is one of my eight complexes so it's
00:27:53 - going to take six days. So we use some combination of analogist,
00:27:58 - expert judgement, and develop quantitative parametric processes,
00:28:04 - apply the math, and develop realistic sound estimates for each
00:28:09 - and every element of
00:28:13 - our WBS. So with estimating fully done it's now time to do a
00:28:17 - resources assignment. We've already said we're going to link
00:28:20 - resources to tasks based on skill.
00:28:24 - In the WBS creation
00:28:30 - we said task
00:28:32 - number 6 should be done by an analyst
00:28:36 - and task number 9 should be done by the DBA and so on. It's time
00:28:43 - to take the skill
00:28:46 - of analyst and assign to name
00:28:51 - resources. We have three analysts we have Tom,
00:28:57 - we have Sally, and we have Betty
00:29:02 - we need to take all of the tasks in the WBS assigned to the general
00:29:07 - skill analyst and assign it to named resources.
00:29:12 - Now you can just randomly assign the analyst roles
00:29:19 - to the unique named individuals but it would be more appropriate
00:29:23 - to understand
00:29:27 - each resource
00:29:30 - specific skills because
00:29:35 - I don't believe anyone
00:29:38 - would disagree with me when I say all analysts are not created
00:29:42 - equal some analysts are going to be better with business interviews,
00:29:45 - some analysts are going to be better in process definition, some
00:29:49 - analysts are going to be better in documentation processes, and
00:29:53 - soon so knowing what each individual task is it will allow us
00:29:59 - to better match the resources specific skills to the tasks. And
00:30:05 - there is no magic to that, it's simply sitting down going through
00:30:10 - WBS element saying "This is an analyst, this task should do this
00:30:15 - basic work. I believe analyst Tom is better suited for this one,
00:30:20 - the next task analyst Betty is going to be better suited for
00:30:23 - that." Now it gets complicated
00:30:27 - once we do that first pass and we run our project scheduling
00:30:32 - software we're going to find out that Tom
00:30:35 - is flat out
00:30:39 - and working 100% of his time and Sally
00:30:44 - is part time
00:30:49 - and Betty
00:30:52 - is almost idle.
00:30:55 - And that's because we said "Okay, Tom has the specific skills
00:30:59 - for doing business interviews, we assigned all of the business
00:31:03 - interview tasks to Tom, and it turns out that a lion's share
00:31:08 - of the analyst tasks we're doing the user interviews made Tom
00:31:13 - flat out and Sally did some work and Betty so now we need to
00:31:19 - adjust." Yes Tom was the optimal person to do that but we need
00:31:27 - to transfer a lot of Tom's tasks to Betty because Betty is very
00:31:31 - idle and we need to transfer some of Tom's tasks to Sally. Well
00:31:36 - wait, maybe we don't. If Tom is flat out and is working for three
00:31:41 - months and Betty is almost idle if we take half generically speaking
00:31:48 - half of Tom's tasks, move him down a month and a half, move Betty
00:31:53 - up to a month and a half maybe, just maybe, Sally is not going
00:31:58 - to be again fully occupied for the month and a half so we're
00:32:01 - going to adjust and we're going to iterate
00:32:05 - because maybe that one simple task of adjusting Tom to Betty
00:32:11 - is going to make everybody fully resourced, fully leveled, and
00:32:18 - maybe not but we need to do it based on availability and we need
00:32:23 - to adjust for resource calendars and vacation maybe we know Tom
00:32:28 - is on
00:32:30 - vacation for the entire month of March.
00:32:35 - If there are critical milestones for the month of March we're
00:32:40 - not going to assign Tom any of those resources. We need to let
00:32:46 - the overall resource availability find the schedule, we need
00:32:49 - to use our software,
00:32:56 - iterate our software assignments and come up with a fully
00:33:01 - leveled project. This
00:33:06 - is going to take time, this is not a one-time effort, this is
00:33:10 - going to take three, four, five iterations of adjusting the skills,
00:33:15 - adjusting the availability, dealing with the resource calendars
00:33:19 - but overall we want to let the resource availability define
00:33:25 - our schedule using our project management software. And
00:33:29 - just a quick note on resource assignment all along I've been
00:33:34 - discussing resources as human my Tom's, my Sally's, my Betty's
00:33:42 - and a lot of the resources you're going to assign on your project
00:33:46 - are going to be human resources but don't forget you're going
00:33:49 - to have equipment, you may have specialized
00:33:54 - technology that's going to be assigned to specific tasks, you
00:34:01 - may have a test jig, you may have a test lab that you need to
00:34:04 - schedule so you may need to assign and schedule equipment and
00:34:09 - you may have materials and these are consumables.
00:34:14 - But without the consumables, without the paper for the task lab
00:34:18 - to reprint the reports, without the disc drives or to be used
00:34:24 - or the magnetic tape units to be used to run the backups your
00:34:29 - project is not going to be a success. So it's important to recognize
00:34:32 - that there are multiple types of resources and I can practically
00:34:35 - guarantee you on your Project Plus Certification there will be
00:34:38 - questions about resource assignment, resource management, and
00:34:43 - resource scheduling that's not going to be human-based, it's
00:34:46 - going to talk about scheduling equipment, or it's going to be
00:34:48 - talking about ensuring that materials, that consumables are available
00:34:53 - for the project. Don't be thrown off by any discussion on equipment
00:34:57 - or materials, you treat them exactly the same as humans
00:35:04 - all resources
00:35:08 - equally. That means as a
00:35:13 - project manager you're allowed to treat all of your human resources
00:35:17 - with as much care and attention as you would a ream of paper
00:35:21 - no. When I say treat all resources equally from a resource allocation,
00:35:26 - resource scheduling viewpoint certainly we want to treat our
00:35:30 - human resources from an HR management very differently than we're
00:35:34 - going to treat a ream of paper and we'll discuss that at great
00:35:38 - length when we're in the executing and monitoring and controlling
00:35:41 - phases of this nugget series. But for the purpose of planning
00:35:45 - and scheduling treat all resources equally, don't get caught
00:35:48 - up on the Project Plus throwing equipment or material resources
00:35:53 - at you for scheduling. And
00:35:56 - one final topic I need to cover with you for your Project Plus
00:35:59 - Certification is resource planning.
00:36:03 - How do you go about resource selection? Do you get what you get,
00:36:11 - i.e. you go to human resources and say "Human resources, I need
00:36:15 - three analysts" and they say "You get them." Do you do interviews,
00:36:23 - do you do skills matching?
00:36:29 - There will most likely be questions on your Project Plus about
00:36:33 - the project selection process and from a Project Plus viewpoint
00:36:38 - resource selection does not consider you get what you get, you
00:36:42 - get whatever Human Resources throws at you, resource selection
00:36:45 - is certainly based on conducting interviews, selecting the most
00:36:50 - appropriate resources with the skills that match your project
00:36:54 - requirements. When you don't get all of the skills that you need
00:36:59 - part of resource planning is developing a resource training plan
00:37:03 - and then delivering on the resource training plan to ensure that
00:37:08 - you're provided the education, the trainings, the support you
00:37:12 - need to bring your resources up to the appropriate trained level. A
00:37:17 - key consideration once you have all of your resources assigned
00:37:21 - you may want to develop a resource assignment matrix where you
00:37:25 - say Resource
00:37:27 - 1, 2, 3, 4, 5 and they're responsible for
00:37:33 - key project components so leaders,
00:37:38 - project managers, and this person is responsible, this person
00:37:42 - is accountable, this person is assigned and so on to let everyone
00:37:46 - on the organization know who is doing what. Consistent with setting
00:37:51 - up a project resource assignment matrix you absolutely should
00:37:56 - publish job descriptions and titles so that again everyone on
00:38:00 - the project knows who their other project team members are and
00:38:04 - they know who they can go to to get answers to questions. A significant
00:38:10 - part of that is a project organization chart
00:38:15 - should be totally consistent with a resource assignment matrix,
00:38:19 - the description of job titles and responsibilities.
00:38:23 - You may choose to do one
00:38:26 - or two or these three components for defining your project organization
00:38:31 - but I would highly encourage you to do at least one and again
00:38:34 - you can expect there to be some degree of questions on your Project
00:38:38 - Plus Certification about how do you create, how do you communicate,
00:38:43 - how do you ensure that the entire team is aware of their role
00:38:48 - in the project and who they can go to on the project for help
00:38:52 - and assistance.
00:38:54 - Other considerations as part of resource planning is project
00:38:57 - orientation we talked when we were doing our estimating about
00:39:02 - duration task for project orientation we should always,
00:39:09 - and I will stress, always run a project orientation to make sure
00:39:13 - people are aware of the project and we should be prepared
00:39:19 - to repeat
00:39:22 - project orientation as new team members join the project. Maybe
00:39:27 - there's a second wave and a third wave and a fourth wave of staffing
00:39:30 - up the project at the end of analysis and other staffing up at
00:39:34 - the end of design to be prepared to repeat the project orientation
00:39:38 - with each new wave of staffing and be prepared to repeat the
00:39:43 - project orientation as you have single replacements. And this
00:39:48 - is where I find a lot of projects will fall down they'll do a
00:39:51 - great job of project orientation for startup, they'll probably
00:39:55 - do an adequate job of project orientation for second wave and
00:39:58 - third wave ramp up, but when they have a
00:40:03 - single team member join simply because they're replacing somebody
00:40:06 - who resigned
00:40:08 - we say "There's your desk, your task list is already outstanding
00:40:13 - because it took us two weeks to get you on board, so please start
00:40:16 - working." We need to resist the temptation to get people into
00:40:21 - assignments and start working, we should always be prepared to
00:40:24 - have a project orientation and repeat it whenever anyone, single
00:40:31 - ones join our projects. I
00:40:35 - already discussed the concept of a staffing plan this is the
00:40:38 - staff plan
00:40:42 - for startup,
00:40:44 - this is ramp up
00:40:47 - wave 1,
00:40:49 - and maybe part of ramp up wave 1 is also the releasing of some
00:40:53 - senior analysts so we have some very senior analysts on the project
00:40:57 - to take us through analysis, at the end of analysis we release
00:41:01 - 50% of our analysts and we ramp up the designers; at the end
00:41:05 - of design we have a wave 2 where we may remove again another
00:41:11 - 50% of our remaining analysts, remover 50% of our designers,
00:41:15 - and ramp up our developers. So we need to have staffing plans
00:41:20 - and if it's an especially long project we need to have staff
00:41:23 - rotation plans so people don't get stale and get
00:41:27 - bored. All considerations for resource planning and be prepared
00:41:31 - that you will have questions related to most of these topics
00:41:34 - on your certification exam itself. And our final topic in this
00:41:39 - nugget is task dependencies. There are three types of task dependencies
00:41:43 - we need to be aware of. One are discretionary dependencies,
00:41:48 - two is the mandatory dependencies, and three are the external
00:41:52 - dependencies. I'm going to focus on the mandatory dependencies. You
00:41:57 - need to be aware that discretionary dependencies exist and you
00:42:01 - need to be aware that external dependencies exist because those
00:42:05 - terminologies may come up in your certification exam itself but
00:42:10 - for the purpose of truly preparing for the certification exam
00:42:14 - we need to focus on the mandatory. Now let me quickly describe
00:42:18 - what discretionary is. This is optional.
00:42:22 - I would like
00:42:27 - for A to be done
00:42:31 - before B but
00:42:35 - it's not required.
00:42:38 - If it's discretionary, if it's optional, if it's based on resource
00:42:41 - availability my recommendation is do not build discretionary
00:42:52 - dependencies into your project at all. It complicates your dependency
00:42:56 - diagram and it may produce additional project scheduling challenges
00:43:01 - that you really don't need to deal with. If it's optional, if
00:43:06 - it's simple "I would like" or if it's optional based on resource
00:43:09 - availability don't build it in; if it's based on resource availability
00:43:13 - your software
00:43:16 - will do that for you automatically, your software is not going
00:43:19 - to allow your team members to ever work more than 40 hours in
00:43:22 - a week so don't be building in optional discretionary dependencies
00:43:27 - simply to make sure that resources don't work too much your software
00:43:32 - is not going to let that happen and if you build these optionals
00:43:36 - "I would like" it's simply going to complicate
00:43:41 - and make you're life more difficult. Externals are those elements
00:43:46 - for other
00:43:52 - organizational considerations
00:44:03 - not in scope at all for this discussion and actually not in scope
00:44:08 - at all for the Project Plus Certification that I'm aware of it's
00:44:11 - something we need to be aware of, you need to understand what
00:44:15 - an external dependency is going to be but I do not believe you'll
00:44:18 - ever see a direct question on how do you set up an external dependency,
00:44:23 - it's more if you need to tell other organizational resources
00:44:29 - or other organizational departments about your project, what
00:44:32 - type of dependency would that be, and it's an external. So let's
00:44:36 - focus on the mandatory this is where A must
00:44:41 - complete before
00:44:48 - B. Task A is Code
00:44:55 - Mod 15, B is Test
00:45:01 - Mod 15 there's no way we can test a piece of code before it's
00:45:07 - coded so that is a true mandatory must-complete before the other
00:45:12 - one can do. And that is this type of dependency described as
00:45:16 - Finish-Start. A must finish before B can start. I would say 90
00:45:23 - to 95%
00:45:25 - of all the dependencies you're going to create within your WBS,
00:45:29 - with your project schedule, are going to be of the type Finish-Start.
00:45:33 - A must complete before B can start. There are three other types
00:45:39 - of dependencies that we need to be aware of and that we'll probably
00:45:43 - be discussion points on your Project Plus.
00:45:46 - Start-Start A must start before B can start. You're
00:45:55 - going to say "That's a little odd. Why would I ever use that?"
00:45:57 - Well I'll give you an example you have team meetings
00:46:04 - and we'll make B the team meetings. A is the first task
00:46:11 - in the project so it's project
00:46:14 - initiation or the project orientation. As soon as we start the
00:46:19 - project, as soon as we do project initiation, as soon as we do
00:46:22 - project orientation this other task of executing your weekly
00:46:26 - team meetings will start. By setting it up as a Start-Start
00:46:31 - that says no matter when the project starts it could start today,
00:46:36 - it could be delayed until next week, it could be delayed to next
00:46:39 - month but as soon as we do that first task, project initiation,
00:46:43 - it's going to automatically kick off this long running task called
00:46:47 - weekly team meetings. And the same can apply for Finish-Finish
00:46:52 - A must finish
00:46:55 - before B can finish.
00:46:59 - And you could apply the same scenario final acceptance
00:47:08 - must finish before team meetings
00:47:13 - can finish. So those are I think two realistic examples of a
00:47:17 - Start-Start and a Finish-Finish. The last type of dependency
00:47:22 - is a Start-Finish and in my humble opinion this is an academic
00:47:29 - definition that's used for completeness of our possible scenarios. In
00:47:36 - my 20 plus years of being a project manager I have never once
00:47:40 - used a Start-Finish dependency and that's basically saying task
00:47:45 - B must start before A can finish,
00:47:51 - task B must start before A can finish. I have again been in this
00:47:56 - business for 20 plus years, I've read many, many, many textbooks
00:48:01 - on project management and it's only been recently that I come
00:48:05 - up with a textbook that provided me with even a good definition
00:48:09 - for Start-Finish. A lot of textbooks used the some comment that
00:48:12 - I just described. It's there for academic completeness. But a
00:48:16 - textbook I read recently at least gave me an example that I can
00:48:19 - relate to. The two tasks are B is you have a very specialized
00:48:26 - and very expensive piece of equipment that's in very rare supply,
00:48:31 - scarce supply that you need on your project.
00:48:35 - Task A is the preparation for using that piece of specialized
00:48:39 - equipment. The more time you spend on task A the shorter the
00:48:44 - amount of time you need to use that expensive piece of equipment.
00:48:47 - So Task A cannot finish until task B starts. If you spend a day
00:48:53 - preparing and B starts you stop preparing. If available you spend
00:48:58 - six days preparing until task B starts which is the usage of
00:49:04 - the specialized equipment. It's in your project's best interest
00:49:06 - to do as much prep time as possible whether it's a day, a week,
00:49:11 - I'm going to be extreme here, a month of prep time is going to
00:49:15 - shorten the amount of time that B is going to work. So there
00:49:18 - is a best example of a Start-Finish that I've come up with but
00:49:22 - again in my 20 plus years of experience I've never used a Start-Finish
00:49:27 - in real life, 90% of the time it's going to be a Finish-Start
00:49:33 - and there will be special applications of Start-Start and Finish-Finish.
00:49:37 - With task dependencies complete we are now complete
00:49:42 - project scheduling and ready to plug this all into our project
00:49:45 - scheduling software. And
00:49:47 - that concludes this long nugget on creating the project schedule.
00:49:51 - I apologize for the length of this nugget but it's all material
00:49:54 - that needed to be covered and all material that I felt was so
00:49:57 - directly related to each other that it needed to be covered in
00:50:00 - a single nugget. How to create a project schedule step number
00:50:04 - 1 was create and identify the WBS. This was done
00:50:09 - in a previous nugget.
00:50:16 - This nugget was focused on developing realistic task estimates.
00:50:21 - My recommendation is it's work/effort-based
00:50:26 - and it's for every
00:50:30 - element of the WBS. A lot of work, we're going to find some analogist,
00:50:37 - some expert guru, some way to learn from previous mistakes, and
00:50:43 - then apply quantitative
00:50:45 - parametric estimating that says every simple development module
00:50:50 - is going to take X hours, every average, every complex but we're
00:50:55 - going to find some way to develop realistic task estimates for
00:50:59 - every task in our WBS. We're then going to assign named resources
00:51:09 - with the right skills,
00:51:12 - we're going to use our scheduling software
00:51:19 - to adjust for availability,
00:51:23 - to adjust for vacations,
00:51:28 - and we're going to level
00:51:32 - our resources
00:51:35 - that every resource is working to their defined full time availability
00:51:41 - which is going to create the shortest
00:51:45 - possible schedule.
00:51:51 - And before we get in and run that scheduling software we address
00:51:55 - the last element of creating a project schedule where we identify
00:51:59 - the task dependencies. Most dependencies are going to be a Finish-Start,
00:52:06 - I'm saying 90 to 95%,
00:52:09 - we're going to focus purely on mandatory,
00:52:13 - A must
00:52:16 - complete before B can start, we're going to have some instances
00:52:20 - of Start-Start, we're going to have some instances of Finish-Finish,
00:52:25 - and we're aware of that other dependency which is the Start-Finish,
00:52:30 - academic completeness may show up on your Project Plus so don't
00:52:35 - ignore it, but focus your real life on these three types of dependencies,
00:52:40 - these four tasks
00:52:43 - or elements for creating a project schedule. And that is what
00:52:47 - we've discussed at great length in this nugget. This
00:52:52 - concludes our nugget on creating the project schedule and resource
00:52:56 - role assignment. I hope this module has been informative for
00:53:00 - you and thank you very much for viewing.

PERT/GANTT/CPM and Schedule Compression

Communications Management Plan

Risk Management Plan

Quality Management Plan

Cost Management Plan

Procurement Management Plan

Transition and Project Management Plan

Human Resource Management

Project Governance

Project Tracking

Project Change Management

Project Risk Management

Project Quality Management

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus

Course Features

Speed Control

Play videos at a faster or slower pace.


Pick up where you left off watching a video.


Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

Premium Features

Transcender® Practice Exams

These practice tests help you review your knowledge and prepare you for exams.

Offline Training

Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching

Develop and maintain a study plan with assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer


Area Of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development

Stay Connected

Get the latest updates on the subjects you choose.

  © 2015 CBT Nuggets. All rights reserved. Licensing Agreement | Billing Agreement | Privacy Policy | RSS