In the following clips we will show you all you need to know about project scheduling.
These are a few of the topics that are covered in the clips:
1. How to define tasks and activities.
2. What task dependencies are.
3. How to use buffers for more accurate schedule.
4. The steps of building a project plan.
5. The main reasons why project schedule fail.
6. Using Agile planning for better project control.
7. Task classifying and prioritizing.
8. How to avoid the 4 most common scheduling mistakes.
9. The right way to monitor the project progress.
And much more… You don’t want to miss it!
Hi, Bob here again.
And me, Allison.
As you know, we here at Elementool have been telling you the ins and outs of project management. We’ve talked about how to get the information you need from your client, how to document it, and how to use our requirements management software to get your project up and running. And I’d like to think that we’ve helped make that process a simple and rewarding one.
Definitely. But the truth is that all that planning and foundation-laying won’t amount to much if you aren’t prepared to properly schedule your project and practice responsible time management.
That’s right. Time management is a key element of good project management, and to manage time, you need a project schedule. The project schedule determines how the project plan is going to work. It clarifies the way that the team will pursue the project’s objectives, and it lays out a timeline showing when the team will accomplish each of its goals.
Using the requirements document, and also figuring in project objectives and priorities, the project manager must build a list of the features needed in order for the project to be successfully completed by the team and resources.
We strongly recommend using scheduling software to manage project schedule data. There are a number of items that you should be certain to have in your final schedule. These include:
– All the various phases in the project’s development cycle
– Activities that the team will perform, the ordering of those activities, and of course resources assigned to those activities
– A measure of the amount of time and effort required to complete activities
– Start and finish dates
– Major milestones
The best project schedules successfully capture the vital actions needed to complete the project, without being bogged down in excessive detail.
Bear in mind that the project plan is a guidance tool, but is never set in stone. Although you want to make the schedule as accurate as possible, the reality is that the ultimate timing, as well as the cost, usually turns out to be different from the initial plan. It’s a bit like when you use your GPS to help guide you to a destination. You know where you’re going, and you’ve already worked out the route you want to take, but traffic, detours, and accidental missed turns are just a few of the problems you might encounter on the way. Fortunately the GPS is there to take those changes into account and recalculate the route for you. You may not end up at your destination exactly when you planned, or the way that you planned, but you will get there.
The project schedule will serve as a guide for your team and resources as they take actions to meet the project’s goals. You need to both track and report everyone’s progress, and then take care to make adjustments as changes or new obstacles arise during the project development.
And remember that it’s the project manager’s role to help clients determine their priorities and to communicate to them how the development team will achieve their goals. The project manager should always keep the lines of communication with the client open, ensuring that the client understands that all new decisions made will have an effect on the project as its being developed.
When all is said and done, managing a project schedule is chiefly about building the development plan, tracking your progress, figuring out what your status is, and making course corrections along the way.
There are a lot of advantages to creating efficient schedules for your projects. First of all, efficient schedules allow for better communication. You’ll see that your team communicates more effectively when they have an efficient schedule to work with, and it also provides a standard in which reporting to the schedule will occur.
Secondly, efficient schedules give the project’s many stakeholders a better understanding of what actions have to be performed in order to finish the work. By clearly outlining the actions that must be completed, the schedule ensures that important activities aren’t forgotten, while also preventing the team for duplicating activities or developing unnecessary activities.
Thirdly, an efficient schedule is one that creates common expectations. For instance, it aids team members in understanding how their work might affect other resources downstream. And because the schedule will make them aware of the tasks they have coming up, the team will be better able to plan their work. Furthermore, the schedule reflects the complexity of the work to be done, giving clients insight that will help them understand why a project takes as long as it does to be completed.
A fourth benefit of efficient scheduling is that it boosts stakeholder confidence by demonstrating that the project is being carefully managed and has a guiding document to help keep all participants on track. This helps alleviate people’s fears that the project is unplanned or veering out-of-control.
To make certain that your project is in fact being carefully managed, you need to practice good time management. Time management begins with activity identification. Identifying activities also helps you figure out how your team will achieve the project’s objectives through their work.
When writing activities, they need to be expressed as actions, meaning that you always want to begin the activity statement with a verb. For instance, you might write: Design the graphics, or create a menu. You want your activities to be descriptive enough that it’s obvious to the reader what has to be done, but don’t go overboard and make it too detailed. When you have completed your activity list, check to make certain you haven’t duplicated any descriptions.
Look over your activities and see if any of them can be broken down into smaller activities. Building a web site, for instance, is an activity, but it’s a pretty big one! You can actually break it up into several more specific activities, such as: Writing the text, designing the buttons, and creating the graphics. However, you don’t want to make the activity list too long, populated with tiny items that only take 10 or 20 minutes to complete. In this case, what you might want to do is make the creation of each page of the web site its own activity.
On the other hand, if, say, writing and coding are each done by different members of the team, you might want to divide the work on each page so that the team members are assigned the activities suited to their skill set. An activity length should be between one day to a week. If you have an activity that is longer than a week, you should check if you can divide it into smaller tasks. Having shorter tasks enables you to have better control over the development progress. It also feels better from the developers point when they are able to complete a task and move on to the next one, rather working on a long task that never ends.
Just a little tip about dealing with activities: An activity is always easier to deal with during project execution and control when there aren’t any more than two or maybe three unique resources assigned to it.
One of the most important methods of time management is the use of milestones. Milestones mark points in time, and they generally represent major events that occur during the project lifecycle. A couple small facts about milestones: They have a duration of zero, and you never assign work effort or resources to them.
What are some examples of milestones, you might be wondering? A significant completion point in a project would be a milestone. An important event occurring in the project plan that needs to be seen by management might be a milestone. Even an event outside the project’s scope that has to be finished before the team is able to start another activity could be a milestone.
This process of organizing activities includes two components for each task: Predecessors, which are activities and milestones occurring before. And successors, which are activities and milestones occurring after. You’ll discover that some activities depend on the completion of a predecessor activity and therefore can’t begin until that predecessor activity is finished. For instance, you might want to surf the web, but you can’t do that until you turn on your computer. This is known as mandatory logic.
Mandatory logic dictates the order in which the work has to be completed, and it’s important to document it as such, to make certain that the project schedule shows the correct timing of all activities.
When describing activities that have a sequence of occurring but don’t absolutely have to happen in a particular order, we use the term Preferred Logic. An example of preferred logic might be, say, brushing and flossing your teeth. You can’t perform those activities at the same time – one has to come before the other. But it doesn’t really matter which order you do them in. Some people like to brush, then floss, and others like to floss then brush. Either way is fine.
There are some activities where these two types of logic don’t apply because the activities in question can actually be done in parallel. Like when my wife and I have family over for dinner and we’re preparing the meal. She can be getting the main course ready while at the same time I’m making the side dishes.
In project scheduling, you should know the different dependency types that exist. There are four types of relationships that you can record into the project schedule. The first is Start to Start, which is a situation where successor activities can’t begin until a predecessor activity begins. However, that doesn’t mean that they are required to begin at the exact same time.
The second is Start to Finish. In this case, the predecessor activity needs to start before the successor activity can be permitted to finish. For instance, you have to start designing your web page’s layout before you can finish the graphic design.
Third, you have Finish to Start. The most common relationships in scheduling, Finish to Start is used as the default in most software scheduling tools. This situation occurs when a predecessor activity has to complete before a successor activity can start.
And then there’s Finish to Finish, which is when one or more subsequent activities can’t finish until a predecessor activity does. An example of Finish to Finish would be someone who is coding a web page and can’t finish the job until he has received the graphics and text from his team members.
There are other kinds of dependencies known as External Dependencies. These are conditions that exist outside the project scope, but have an impact on the schedule nonetheless. A common external dependency issue that arises is when you have to wait for a vital component from a customer before you can begin working on a particular activity in your project.
The project team rarely has control over external dependencies, so the project manager should always monitor them carefully. They can be marked on the project schedule as milestones that are linked to relevant activities.
When establishing your project schedule, you want to be careful to not let it get so complex that it becomes impossible to understand or to manage. To ensure that your project, particularly if it’s a really big project, stays manageable, make certain that the schedule includes the minimum elements needed to do the following: One, define the activities that have to be performed. Two, represent the activities to deliverables as well as timeline phases. And three, represent important events that have to be tracked.
A truly efficient schedule should have no more than three levels, one of which is detailed, and two of which are summary levels. The first level is made up of the high-level stages of a project, like iteration name or project name. Under project level comes the task summary level, which groups tasks that are related to a specific feature. That could be a feature that is divided into smaller tasks, with each task being responsible for the completion of that part of the feature. Under the summary level should be the executable work packets that will start in that phase. These are the actual tasks that the team works on as well as milestone events. These are the tasks that the team has to complete.
Both setting and meeting your end date are key challenges when it comes to scheduling and time management. The defined dependencies between activities and milestones are key in determining an achievable end date for your project. You must start by linking all activities with each other. Include milestone events at the end of any requirement that represents the completion of that deliverable. The last activity in the set of activities ought to link to this milestone.
In some cases, activities from different summary levels may be connected to each other. By the end of dependency definition, all of the activities and milestones should be related to each other with just two exceptions: 1) the activities that can begin right away (that is, the ones with no predecessor). And, 2) the project finish milestone, which is the concluding event in the schedule.
When considering the risk management side of your project planning, be sure to add schedule reserves. No matter how confident you might be in the efficiency of your team, it’s always smart to build a reserve of additional time into your project plan in the event that resource availability problems create delays in your schedule.
You’ll want to consider two types of buffers to add to the schedule. One is the Individual Buffer, where you add a small buffer at the end of each individual activity. The other is a Global Buffer, where you add a lengthier buffer at the very end of the activity chain. Remember in college, when you would stay up till 3am working on a paper that was due the next day?
I have no idea what you’re talking about.
Come on, Allison, I bet even you occasionally left a major project to the last minute.
Okay, maybe once. But just once.
That phenomenon is sometimes called the student syndrome, and it refers to the way people will often only completely apply themselves to a particular task at the last possible moment before it’s due. The reason I mention this is because the student syndrome is a good argument against using Individual Buffers. The idea is that the person doing the task, aware that the buffer exists, will just spend that much more time working on the activity. As Parkinson’s Law puts it, work tends to expand to fill the space of the time available for its completion. As a result, the Individual Buffer becomes fairly pointless.
That’s why we at Elementool favor the idea of using Global Buffers. Adding the schedule contingency at the global level ensures that the buffer time won’t be wasted away at the activity level. The project manager will monitor this global buffer, while making certain that the individual task estimates remain achievable. In order to calculate how much time to add for a buffer, you need to take the risk factors for each task into consideration. Think of what might go wrong and how much extra time it would take to deal with that problem. Estimate a buffer time for each individual task, then add it up to get one large buffer for the end of the project.
When you begin calculating the schedule, you start with what is known as the initial schedule, which represents the combination of task sequence and task duration. The reason we call it the initial schedule is because we haven’t yet taken people and equipment limitations into account. For the next planning step, you’ll use the initial schedule as your starting point, balancing it against the resources that you have available for the project.
When calculating the schedule, create a Gantt chart. The most popular display used for project scheduling, the Gantt chart is noted for its clarity. Some software solutions, like Elementool, create the Gantt chart for you. All you need to do is define the project structure and tasks, and assign duration for each task. Elementool will do the rest.
Now to work out how long it will ultimately take to complete the entire project, you must determine the critical path of the project. The critical path is the longest dependency chain of activities that establishes how long the project will take to finish. To complete the critical path, you must define these three elements: activities, durations, and dependencies. You do this by identifying the path of activities that brings the project from start to finish. You need to add up the duration of each activity to its predecessors. If there are parallel activities, then just select the longest one. Add up these activities, and the sum will tell you the critical path and the length of time it will take for the project to be completed.
Once you’ve built the project plan, you should compare it to the target date previously set by the client. Providing the dates are similar, you can do project analysis and adjustment in order to meet the goal date. However, if there is a pretty big difference between the two dates, we’d strongly recommend that you meet with the client, explain the reason for the discrepancy, and work together on finding a way to narrow that gap.
Assuming that time is the biggest constraint, some solutions you can consider are: bringing in more money in order to procure more resources, or improving resource skill in order to better your team’s overall performance. Altering the schedule structure for the purpose of completing activities in parallel – rather than using a sequenced approach – can also help you finish the project more quickly. Another step to consider is reducing the project scope to basic solution functionality by the client’s needed date, and then providing the remaining functionality later on.
If it turns out, though, that scope or cost are more important constraints, then the client should agree to accept a different end date – either the one that has been calculated by the schedule, or some other date in between.
As you remember from our estimating session, you should resist the temptation to shorten the estimates just to get the project to fit the deadline. Otherwise, you might reach the deadline date too soon, before the project can be completed.
Now we want to start getting into some of the nitty gritty of the planning process. First, I have a few facts for you to think about. Did you know the average project exceeds its schedule by 100%? Or that 65% of projects significantly overrun their cost estimates? And get this – 64% of the features included in products are rarely used or never used at all. Statistics like these are an important reminder that a lot of thought needs to go into project planning.
Planning the schedule is a major process that requires the effort of your entire team. We’d like to share a few brief guidelines that are key secrets to successful planning. First, everybody needs be involved in the process and fully committed to the success of the project. Second, when you’re discussing estimates with the team, be sure that they all understand that estimates can never be completely accurate.
Third, revisit and revise your plans often, using each iteration as a way of judging the project’s progress. Then make changes accordingly. Fourth, track and report progress. Fifth, divide the project’s features into smaller tasks. Sixth, be certain to prioritize each feature.
Now I don’t want to sound like a pessimist …
Uh-oh.
Hear me out. Those are great tips, and each of those steps is important if you want to make and follow-through with a solid project plan. However, planning does fail more often than many project managers would like to admit. So I think it’s worth taking a moment to talk about why those failures happen. That way, we can help you avoid the same fate.
That’s a really good idea, Bob. There are many reasons why planning fails. One of the most common is when people plan by activity rather than by feature. The traditional approach to planning frequently focuses on completing activities rather than on delivering features. This is a big mistake because your client doesn’t get any value from activities being completed. It’s the features, not the activities, that customers value. That’s why planning should always be at the level of features rather than activities.
Very true. A related problem is lateness being passed down through the schedule. Since traditional plans are so often activity-based, they get focused on the dependencies between the various activities. An early start of a later activity demands that you first complete the activities that it’s dependent on. So if any early activities run late, then the rest of the activities that come after it are also going to be late.
Multitasking is another source of planning problems as it often causes delays. Traditionally we think of multitasking as a good thing. If I’m able to put in eight hours at work, take my daughter to a playdate, do the grocery shopping, finish the laundry, catch up on my favorite TV show, and send out a dozen or so emails before bedtime, that’s not half bad, right?
That’s a talent.
In the workplace, though, multitasking can require you to spend quite a bit of time switching from one task to another, especially when you’re trying to remember where you last left off. It’s a process that can actually result in a great deal of wasted time.
Another notable reason for planning failure is when the work outlined in the plan isn’t prioritized by its value to the users and customers. When this is the case, developers will just work on the features in random order. Then, as the end of the project nears, the developers have to start dropping some features in order to make the deadline. Since the high priority features weren’t earmarked to be completed first, they’re in danger of getting dropped.
Refusal to acknowledge uncertainty can lead to serious planning disasters. You shouldn’t just assume that the initial requirements analysis resulted in a complete specification of the project, or that the users won’t come up with new or different needs during the period of the project schedule. Developing the project in short iterations can be helpful in reducing uncertainty. Be sure to show the software to its users and ask for their feedback every few weeks.
One more reason that planning sometimes fails is that the project manager allows the estimate to become an actual commitment. This is an enormous mistake. An estimate is only a probability. Your commitments should be made to dates, not probabilities.
Now that we’ve got the potential pitfalls out of the way, let’s discuss some of the types of plans that you will utilize. Take, for instance, an Agile Plan. As the name indicates, this is a plan that has some wiggle room. An agile plan is a plan that is easy to change. Of course we don’t want to change it for no reason, but we may want to change it because we’ve learned something new along the way.
Just because we might change the plan, though, doesn’t mean that we’re going to change the dates. We want to try to keep the dates intact, but some ways we might change the plan without altering the dates include reducing the scope of a feature, dropping a feature entirely, or adding new people to the project.
As you go into planning, remember that the entire project can’t be defined at the beginning, therefore you can’t do all of the project’s planning at the beginning. Agile planning is usually spread fairly evenly across the project’s duration.
One advantage of agile planning is that it involves frequent planning. At the start of each iteration, an iteration plan is created. After each of a few iterations, the release plan is then updated. Through this process, the team is able to revise and update the project plan based on the actual project, rather than attempting to create the perfect plan at the very start of the project.
Another advantage of agile planning is that it has short cycle times. Each iteration is a mini-project that has its own particular list of features. Clients can share their feedback on the features being developed at the conclusion of each iteration, allowing for a more controlled development process. This keeps the team from wasting time developing unwanted or unneeded features.
The iterations that agile teams work on always end on time even if functionality is dropped. On an agile project, there isn’t an upfront requirements phase, followed by analysis and architectural design, and so on. Instead there is a very short design and modeling period at the beginning of the project. Once the project begins moving forward, then the design, analysis, coding, testing, and other work is done within each iteration.
The agile team turns one or more requirements into coded and tested software during the course of each iteration, so they are regularly making progress on the project by delivering features in each iteration. The product needs to be brought to a potential shippable state at the finish of each iteration. In some cases, one or more iterations complete a set of related functionality, and this is known as a release.
It’s important for agile teams to maintain their focus on business priorities, delivering features in the order laid out by the product owner. You don’t want there to be too many technical dependencies between features, since that can complicate the product owner’s attempt to prioritize features into a release plan. The agile team needs to concentrate on delivering user-valued features, not just completing various isolated tasks.
Because the plan devised at the start of the project doesn’t necessarily dictate how the project will actually go, an agile team needs to inspect and adapt. Technologies fail, people come and go, clients change their minds … who can say what will happen? And each of these changes means that you have to update the plan. So agile teams incorporate any changes and new knowledge learned during the previous iteration at the start of the next one, adapting accordingly.
Release planning is the process of a high level plan which covers a period longer than an iteration. A release, which typically covers 3 to 12 months of development, allows the product manager to determine what is going to be developed and how long it will be before a releasable product is ready. This helps to create expectations and to provide the team with a target to focus on, so that they aren’t simply moving from one iteration to the next.
Planning a release requires you to figure out how much can be accomplished by what date. Sometimes you might start with a date and see how much work can be finished by then. Other times, you might begin with a specified set of features and see how much time it takes to develop them. In the release planning stage, it’s best not to assign tasks to people yet, since at that point there is only general information available about what work needs to be completed.
Before even beginning the release plan, it’s vital that you know what factors will make the project a success or a failure. Ask yourself: What are the business objectives that this project needs to achieve? Once you’ve answered that question, you need to estimate the features. At this point, keep the estimates pretty general – you don’t need to get into every detail in each feature.
Next, decide on the iteration length. Two to four weeks is fairly standard. After that, you should estimate the velocity, or, how much time it will take for the team to complete their tasks. If your team has worked together before, try basing the estimate on previous projects.
If you have a deadline set for the release, you should determine how many iterations can be fit into the deadline. Then, based on the estimates, decide which features can be finished in that time frame. The product owner will choose the high priority items, which will go into the first iteration. You can then distribute the other features into the following iterations, working on the highest priority features down to the lower priority items until the release plan is ready. Be sure to update the release plan regularly, based on how the project is progressing.
Now let’s discuss iteration planning, which will give you a detailed, short-term plan that the team can use to develop the project. An iteration plan is created in a meeting called especially for that purpose, and the meeting should include the product owner, programmers, database engineers, user interface designers, testers, and others involved in the project.
Don’t assign tasks to team members during the iteration planning meeting – wait until the iteration actually begins. At that point you will usually want to assign one or two tasks to each person on the team. Tasks don’t start until previously assigned tasks are finished. Team members should choose tasks based on their availability and the availability of their teammates.
The process of assigning tasks in an iteration is pretty simple. Just remember to start by identifying the business objective. Next you select features that support that business objective. Follow that with breaking the features down into tasks, and estimating those tasks, then defining priorities. Finally, assign tasks to your team.
You’ll want to hold an iteration review meeting to discuss important details about what needs to be accomplished during the iteration. This meeting will likely take around an hour, or as long as a half a day for a really big project that has several teams. After the meeting, the team members should identify what should be accomplished during the iteration, and then.decide on priorities. Once features are broken down into tasks, team members need to estimate each task.
There are four main priority classifications. “Low” means that the feature can either be developed during a major system revision sometime in the future, or it can not be developed at all. “Medium” means that the task should be completed after all serious tasks have been dealt with. “High” tells you that this task should be developed as soon as possible during the normal course of development activity, before the software is released. And “Immediate” means that the tasks needs to be resolved, well, immediately.
Another type of classification for software features is a severity classification, which is based on the degree of the feature’s impact on the project objectives. There are four types of severity classifications, starting with “Low,” meaning that the feature is an aesthetic enhancement or a result of non-conformance to a standard. The “Medium” classification means that the feature doesn’t impair usability, doesn’t interfere in the fluent work of the system and its programs, and it will not cause a failure of meeting the objectives. Classify the task severity as “High” if the task causes the system to produce inconsistent, incorrect, or incomplete results. The severity is “Critical” in cases where the project cannot be considered as successful without this feature.
Bear in mind that part of the iteration will include fixing bugs found during development. Estimates for coding a feature should always include extra time for fixing bugs that might be found in the process. Or you can define a separate task specifically for fixing bugs. Defects that are found later on, not as part of the iteration, can be dealt with the same way as features – prioritize the defects and add them to another iteration.
A task in an iteration that is dedicated to researching and answering a question about the development of a feature is called a Spike. Estimate and add spikes to the plan just as you would any task.
The length of an iteration determines how often the software can be shown to users and customers. We recommend showing them the product at the conclusion of every iteration and asking for their feedback so that you know the project is being developed in a way that meets the client’s business objectives.
If it turns out that they want something added, removed, or changed, it’s much better (and less costly) to do it after just one iteration than at the end of the whole project. Some users will change their minds about a feature once they’ve seen it in action. The feature that seemed like a good solution in theory may turn out not to be so great in reality, so they want to change it.
By the end of the iteration, you can get a sense of how quickly the project is developing, which allows you the opportunity to re-estimate the rest of the project more accurately. The project manager is better able to determine if the project is on track by measuring the progress this way on a regular basis.
As you might expect, shorter projects will have shorter iterations than lengthier projects. For instance, if you’re working on a project scheduled to take only two months, one-month long iterations aren’t going to be very helpful to you, since you’ll already be halfway through the project before you’re able to measure any progress or make adjustments. Having the end of the iteration too far off in the future also reduces the sense of urgency amongst the team members. When iterations are short, it pushes the team to work harder so that they complete their tasks by the end date.
Then again, you don’t want too much pressure on your team. Try to find a good balance when deciding on iteration length. If the iteration end date is unrealistically short, the team will start to feel like the deadline is impossible to meet, which will reduce their morale and their efforts. Also try to keep to the same approximate length for each iteration, since that will give the team a helpful sense of rhythm.
To monitor the iteration plan, you should utilize a task board. This gives the team a way to organize their work and to show how much work is left to accomplish. The task board shows which tasks are part of the iteration, grouped by status. Each row represents a iteration. Tasks are sorted by their priority, with the highest priority tasks displayed higher than the low-priority tasks. The developers may change the estimate of any task at any time, in the event that they have reason to believe a new estimate is in order. Remember that bugs are tasks too, so they should also be added to the board.
Because agile team members are only assigned to tasks when they are actually ready to work on them during each iteration, you will see tasks on the board that are still waiting to be assigned to someone.
So you’ve created your project plan and schedule. Good work! Now you’re done with scheduling, right? Mmm, wrong. Monitoring your progress is crucial to making sure that the schedule is going to plan. By tracking and reporting the process as it goes along, you will be able to note problems and refine the plan as needed.
As project manager, you need to manage two types of reporting: Status Reports, which come to you from the project team via team leaders; and Project Progress Reports, which go from the project to external stakeholders such as the client. Information that you get from the status reports will go into the project progress report.
To make this go smoothly, we advise project managers to develop a process for status reporting that provides accurate and useful information about the project’s progress, but doesn’t require resources to spend an overwhelming amount of time focusing on reporting during their work.
When talking to your team about status reporting, consider how you want your resources to define completion. Often, project managers are too attached to the notion of “percent complete”. But that doesn’t give much information about the amount of work that still has to be completed, at least not until the resource provides unit values. Keep in mind that a truly effective status report ought to ensure that the resources will be able to begin their planned work on time, and report any new status or risks that need to be addressed.
Another method of reporting that you should know about is that of work effort and end date. This method demands a little more work from the resource, but the project manager gets better information from it. This type of reporting should show the total amount of time that was scheduled, how much has already been used, how much remains, and an answer to the question of whether or not the task will be completed on time. You could find that the total number of hours spent is greater than what was planned, yet the work is still finished on time. If that’s the case, the project manager needs to ask how the additional hours will be added to the extra cost or time taken from other tasks.
Burndown charts are a useful way of measuring your team’s progress, and, more to the point, showing you how much still needs to be done. In a release burndown chart, the vertical axis shows how many hours remain in the project, while the horizontal axis shows the iterations. By showing the amount of work that still remains at the start of each iteration, the release burndown chart serves as a good indicator of how quickly the team is reaching its goal.
Iteration burndown charts can be created in the same way as release burndown charts. Iteration burndown charts are also very useful in illustrating how much work still needs to be done. For instance, if you’ve spent 10 hours on a task that was supposed to be finished in 12, and you’ve completed 50% of the task, the fact that you spent 10 hours working on it doesn’t actually tell you much. The more valuable piece of information is the fact that you’ve completed 50% of the task, and the iteration burndown chart makes it easy to see this.
Ultimately, when it comes to tracking and reporting, the project manager needs to find a balance between getting all the details necessary to keep the plan on target, while also taking everybody’s time into consideration.
There’s no question that scheduling can be a tough process, even for the most experienced project managers. Expect to encounter a few bumps in the road along the way. We’ll help you understand some of the challenges you might be facing, and how you can make adjustments to the schedule as needed.
A common mistake that project managers make when it comes to time management is attempting to build the schedule right at the beginning of the project. This is tempting because there is often pressure from the client to know precisely when the project will be finished. The team, too, tends to become focused on what needs to be done to complete the project. But no matter how motivated everyone is to get to the finish line, you need to start by defining the project’s requirements and objectives.
A pretty typical problem that you will come across in scheduling is discovering that you have an over-allocated resource. This is a team member who has been scheduled to work more hours than what they actually have available. There are several ways to deal with this situation.
One solution is to simply leave the over-allocation as scheduled and expect that person to work overtime. Obviously there are downsides to that solution, and they include the higher cost of overtime payments and the additional risk of project delays in the event that the employee is unavailable or already scheduled for overtime. On top of that, permitting a resource to be over-allocated at the baseline is really just bad practice. You should only go this route as a last resort or when you’re trying to get the project back on track, and, even then, expect problems.
Another option is to fix the over-allocation and retain the current schedule timeline by either replacing the current resource with a more productive person who can bring about the same results in less time, or by adding a resource to help out the over-allocated one. The second choice might be more costly, and it may not turn out as you hope if the newbie has a learning curve. In some instances, adding a resource can actually result in it taking longer to complete the activity.
Your last option is to resolve the over-allocation through resource leveling – also known as spreading out. Be aware that if the activity that the resource is working on is on the critical path, this may lengthen the project’s timeline. But if the activity isn’t on the critical path, then spreading out the resource’s work time might not have any effect on the end date of the project.
If it becomes necessary for you to reduce the total length of the project, there is a technique that you can use to adjust the schedule called Duration Compression. Duration Compression is accomplished using one of these two methods: Fast Tracking and Crashing.
Fast Tracking is when dependency logic is removed from the schedule so that activities may be worked on in parallel. But of course some dependencies can’t be removed, since the nature of the work demands sequences. Crashing, on the other hand, involves shortening the duration of one or more activities within the schedule – specifically activities that are on the critical path. There’s no use in crashing activities off the critical path, since that would only increase float without actually lessening the project’s duration. Generally, crashing involves either adding to or replacing resources in a way that results in shorter activity duration.
There are several issues to take in to consideration when crashing. First, which activities are on the critical path? Only consider those that are fixed work or fixed resource tasks. Second, consider cost and ask yourself which of these activities would be most cost effective to add resources and skills to? You may find that some will cost more than others. Third, think about timing. Which of the activities will truly be shortened by adding resources? Fourth, which of the identified activities will experience the least reduction in quality as a result of the added resources? And finally, consider resource availability – which of these activities needs a skill set that is available?
Sometimes you will find that you have to make project plan adjustments, and there are a couple of different methods you can employ to do this. One is Scope Slimming, which can be used when it’s possible to reduce the deliverables of the project with approval, for the purpose of keeping the original date. Remember that Scope Slimming should go through the change control process. There is a possible downside of this method, which is that the final product might not perform as needed to meet the business objectives, therefore resulting in a potentially unhappy client.
Another method is Quality Slimming, which results when you reduce the functionality of the deliverables as a means of keeping the end date. This needs to go through the change control process as well. With Quality Slimming, there is also the possibility that the final product won’t perform as required to meet business objectives.
Well, there you have it. We’ve talked about the process of scheduling, the benefits of creating efficient schedules, techniques for good time management, setting end dates, planning, tracking, overcoming challenges, and a whole lot in between.
We know a process like this can appear daunting at first, but we at Elementool feel very strongly that Scheduling is one of many project management duties that can be easily mastered with a little practice and a lot of great advice.
And we hope that you found our advice – which comes from years of project management experience – helpful. Any parting secrets about scheduling to share, Bob?
Just one. As project manager, you should try to encourage a spirit that says “We’re all in this together,” so that everyone on your team is eager to do their part – even if that sometimes means helping with a task that isn’t in their normal job description. Research has shown that a committed team is one of the keys to a successful project.
That’s so true. So keep up the good work, keep your team motivated, and we’ll see you again soon!
