Translate your plan into action
Upcoming SlideShare
Loading in...5
×
 

Translate your plan into action

on

  • 747 views

 

Statistics

Views

Total Views
747
Views on SlideShare
747
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Translate your plan into action Translate your plan into action Document Transcript

  • Plan your project the right way ITworld.com 5/9/00 There are a number of project management tools on the market, but why are they rarely used to track a project's execution? Answer: Garbage in, garbage out. Here are a few tips on how to correct the problem. There are a number of project management tools on the market. From small personal systems to grandiose multi-team, multi-project, enterprise-wide systems, there seems to be no end to the number of products to choose from. All of those products can produce countless reports, build PERT diagrams, crank out the Gantt charts, and calculate your earned value analysis. Project managers can spend hours at their computers, playing what-if scenarios with the data. Then why do so many project managers become quickly frustrated with their project planning tools? Why is the project plan quickly tossed aside in so many cases, something that really bears no reflection on what is actually happening in the project? Why are project plans rarely used to track progress in the execution phase of the project? The answer is simple: garbage in, garbage out. And in that case, the garbage going into the plan is the poor work done in creating the work breakdown structure or WBS. Building the WBS is the most critical part of project planning. A good WBS will allow you some probability of success in planning and executing your project. A poor WBS is worse than useless since it paints an inaccurate picture of the work to be done, raises improper expectations on when it will be done, and pretty much guarantees that the project manager will spend most of the project fighting fires that were not anticipated in the project's planning stage. It makes sense to take time to build a good WBS. How is a WBS built? There are variety of ways. Here are some guidelines you might want to follow: Get the team involved Since your team will be executing the plan, it makes sense to have them involved in planning the work. That builds a sense of ownership and commitment to the project. It is also a way to see who might be most motivated to get a particular task done. Start with the top two layers. Build a graphic to be used as an aid in the WBS planning process. That graphic should be in the form of a tree diagram. The root of the tree should be the project itself, the next level down should identify the major disciplines or phases of the project. For example, if our project was to build a house, the root might say "build house" and the next level down might be "masonry, carpentry, electrical, plumbing." If we were to break the project down by phases, they might be "prepare foundation, rough framing, finishing, install fixtures." 1
  • Plan your project the right way ITworld.com 5/9/00 Whatever way you choose to break down the project the idea is to keep drilling down the tree until you get to tasks that you think you can manage. How do you know when you can manage a task? While each manager will have a different rule of thumb, I like to use "one person/one week". That means that once I get to the point where a task will take one person about one week to accomplish, I know that I have done enough detailing. That is only a general rule of thumb, and I often break it, depending on how critical the task is, my degree of confidence in the individual, etc. Another area in which project managers go wrong is not understanding the difference between a task and an ongoing activity. Tasks must meet the following criteria: • They have defined start and finish dates • They require some input to initiate, and they produce a tangible output (a deliverable) • They can be assigned to an individual who will be accountable for their completion A metric exists to evaluate the quality of the deliverable We can produce an estimate for the work, effort, or duration of the task When completed, the WBS tells the story of how the project will be run, how the deliverables will be produced, and what linkages exist between the various tasks. The linkages are known since every task requires an output from some other task to start and produces an output that will be used by another task. By the way, that is also an excellent way to validate tasks. Building a good WBS may take a couple of tries. In some organizations, templates may already exist for commonly run projects (such as software engineering). If you can find them and if they are of good quality, they can save you a great deal of time. Otherwise, try to get some experts involved, in addition to your team. That will help to ensure that you're not missing anything when you put together your WBS. Once you have a solid WBS, you can feed it into your project planning tool. That will result in a solid plan that you can monitor and track during project execution. You will have a better idea of what has to be done, when it has to be completed, and who will be doing the work. Go on, break it down and get busy. 2
  • Plan your project the right way ITworld.com 5/9/00 Build a precedence network ITworld.com 5/23/00 Last column I laid out some of our motivation in structuring a work breakdown structure (WBS) into a project plan. This column will show you how to get started. Before you begin structuring your project there is a fundamental question that you will have to answer, "Do I use an automated planning tool or not?" While there are many advantages in getting involved with a computer-based project planning tool there are also a number of disadvantages. The advantage of using such a tool is that it automates much of the drudgery of project planning, makes project tracking easier, allows the project manager more flexibility in testing "what-if" scenarios and can more easily accommodate changes to the plan. On the down side, using such a tool can require a high learning curve, it does not allow the team to be quite as involved in the planning process, it never works quite the way you expect, and you run the risk of spending more of your time in front of a computer screen instead of working with your people and managing the project. My advice is that if your project is small, say 20 tasks or less, and the number of people involved is less then 5, you can probably make do with a pen and paper approach. Or, as it is sometimes known, "The Post-It" approach, since the ubiquitous Post-It note is the project manager's friend and we will use extensively in planning our project. Once the project gets much larger then 20 tasks you will probably want to consider the use of an automated project planning tool. One last word on project planning tools. They are not created equal. Some are best suited for smaller, single person use, while others are intended to handle very large projects. If you are going to get involved in one of these packages, make sure you are using a tool that is suitable for the complexity of your project environment. In other words, do some research before you start learning how to use the product. Anyway, back to our WBS. Our first activity will be to convert the tasks that we have identified into a precedence network or, as it is sometimes called, a PERT Chart. PERT stands for Performance Evaluation Review Technique and was developed by the US Navy to help them in running very complex projects such as the building of nuclear submarines. 3
  • Plan your project the right way ITworld.com 5/9/00 The precedence network describes the relationship between the different tasks. There are two ways it can be created, automated (using a computer program) or non-automated (the Post-It approach). Let's start with the Post-It approach. Start by making up a Post-It for each task that you have identified on your WBS. The Post-It should contain: • The name of the task • A unique identifier for the task • The estimated duration for the task • Inputs required for the task • Outputs that the task will produce All of these items should be available from your WBS. Start laying out the Post- Its on a white board and drawing lines to link them together. The links represent the flow of outputs from one task into the inputs of another. In other words, since every task requires an input to initiate, and every task must produce an output, we should be able to indicate the flow of these inputs and outputs using lines to link the tasks together. There is a golden rule that you can follow in building a precedence network: "Every task must have one or more successors" This only makes sense since if a task produces an output that no other task needs, then why are we doing it? This also allows us a good way to do a preliminary "sanity check" in our plan. If we find a task that requires an input that is not the output of any other task, then we know we have missed something. It is also useful at this stage of the structuring process to create "dummy" milestone events called "Start" and "Finish". A milestone is defined as zero- duration event that represents some significant achievement. We need the Start and Finish milestones to act as anchor points on either side of our plan so that all tasks will have a predecessor and successor. In other words, there may be some tasks early on the project that really don't require any input to initiate. We would link these to the Start milestone. And the final tasks in the project would be linked to the End milestone. Make up Post-Its for the Start and End milestones. If you've done the work properly up to this point you should now have a network diagram on your wall. Every Post-It represents a task, the links allow you to see the dependencies that exist between the tasks. Any task that does not have at least one predecessor and one successor needs to be examined more closely. You should update each Post-It by including the unique identifier for all its predecessors and all its successors. 4
  • Plan your project the right way ITworld.com 5/9/00 As I mentioned, you can also build a precedence network using an automation tool. Each of these software packages will allow you a way to input your tasks and then will automatically draw the PERT chart for you. When the total number of tasks begins to grow, this is the only way to go. You have now built a precedence network or PERT chart. But what do we use it for? Ah, for that, and the answer to many other interesting and exciting project management questions, you'll have to check in for the next column. 5
  • Plan your project the right way ITworld.com 5/9/00 Translate your plan into action If you haven't read my piece Plan your project the right way on how to put together a good work breakdown structure (WBS), you might want to check that out first. For today's column, I thought it might be a good idea to discuss how we translate a WBS into a project plan. The main job of performing a WBS process is to identify the entire set of tasks that must be accomplished in order to finish a project. For the moment, we can define the end of the project as the acceptance, by the project stakeholder, of the entire set of deliverables that was agreed to when the project began. While the WBS tells us what should be done, it really doesn’t provide us with any sequencing of the tasks. In other words, which tasks should be done first? Which tasks can be done in parallel? What is the relationship between the tasks with respect to their start and finish dates? These are all important questions since one of the primary focus points of the stakeholder will be the expected completion date of the project. Those of you who have read my columns on estimating remember that there are three variables in planning a project: • Work – the amount of effort involved in producing a deliverable, normally expressed in person/days • Resources – the number of people assigned to a task or project • Duration – the elapsed amount of time that a task or project will take. When we are building the WBS, we would normally estimate for Work. For example, to install the cable for a new office LAN might take 12 person/days. While this number is very useful in calculating the cost of the project it really doesn’t tell us how long the job will take. And, for the users in the office, the completion date is much more important then the cost. Continuing this example, suppose we had some additional tasks that were being done as part of the same project. One might be the installation of new office furniture, estimated at 5 person/days. Another might be laying new carpet which has been given an estimate of 3 person/days. Further, we know that the carpets must be laid before the furniture can be installed, but the LAN cable can be installed at any time. 6
  • Plan your project the right way ITworld.com 5/9/00 And here’s another complication. Suppose we have to pay for the office furniture as soon as it arrives. So we would like to delay delivery of the furniture as late as possible. Preferably we would like to get the stuff just before we need it. So we may want to build some sort of delay or lag between the laying of the carpet and the installation of the office furniture. So here’s the question, if our project starts on the first of the month, when will the work be complete? Answer, we don’t know yet. As you might imagine, as we add more and more tasks, it gets increasingly difficult to estimate a the overall duration of the project. Project mangers have to determine the best way to link the various tasks together, use the resources available in the most efficient manner, and be able to identify the most critical tasks in their plan. That is why project managers translate their WBS into PERT charts, Gantt charts and a number of other planning aids. As we move from the WBS stage of project planning into the actual task scheduling, our focus shifts from estimating for Work to estimating for Duration. Since the stakeholder normally has a completion date in mind, a new set of questions now become the project manager’s imperative. Can we get the job done in time? How many people will we need to do all the work? When do I need these people? How can I make sure that none of these people are scheduled to work on multiple tasks at the same time? What tools are available that will help me track how the plan is developing? Are there any tasks that are more critical to my plan then others? In my years as a project manager I have found that many new project managers avoid these questions when a project gets too complicated. Since they are unfamiliar with how and why they should be using the various tools that are available their projects inevitably devolve into a set of unplanned, unscheduled, set of “firefights”. And, as the completion date approaches, staff is working longer hours, corners are being cut, tempers are fraying, and in general, no one is having a good time. This doesn’t have to be the case. There is a better way. Over the next number of columns I will be discussing the role of the PERT and Gantt charts in project planning, how to build them, and how to interpret the results. We will examine the critical path and introduce the topics of slack in a schedule. We will look at a variety of ways of linking tasks together and making sure that the plan is internally consistent. We will also consider resource allocation, resource tracking and how to handle resource overload situations. 7
  • Plan your project the right way ITworld.com 5/9/00 Create the paths to completing your project tasks At the end of my last column Build a precedence network, we created a PERT chart that described the sequence of tasks to be accomplished in order to complete our project. Every task had one or more predecessors and one or more successors. The only exceptions to this rule were the two dummy milestones -- called "Start" and "Finish" -- that were used as the logical beginning and end of the project. The Start milestone has no predecessors and the End milestone has no successors. So, a simple PERT might look like this: Where W = the work associated with the task. You will recall, however, that we also want to show Duration on our PERT, since we are trying to estimate the completion date. From a previous column, we understand the relationship between Work (W), Resources (R) and Duration (D): W=R*D Therefore, D=W/R Of course it is difficult to calculate the Duration at this point, since the only estimate that we developed in the WBS part of the planning process was for Work. Before we can calculate Duration, we have to know how many people (i.e. Resources) will be working on the task. And we may not have this information available until later on in the scheduling process (I'll be talking about resource allocation in a later column). So in order to proceed, we will have to make an assumption to help us calculate Duration. Not to worry though, if our assumption turns out to be incorrect, we will be able to easily fix our error. For the moment though, let us use the following rule: "All things being equal, R=1" 8
  • Plan your project the right way ITworld.com 5/9/00 In other words, unless we know that we will have more than one person available, we can assume that only one person will work on each task. Let us apply this rule to our PERT chart. We will assume that R=1 for all tasks except Task A, which will have two people working on it (or R=2). We can now redraw our PERT: I should point out that some tasks always have a fixed duration, no matter how many resources we assign to it. For example, if we paint a room, it will take 24 hours to dry. There is no way to speed this process by assigning more resources to the task. It is important that you identify which tasks are fixed-duration and which are effort-driven. Effort-driven tasks have variable duration depending on the number of resources that you assign to the task. Fixed-duration tasks are not sensitive to changes in resource assignment. As you might expect, most tasks are effort- driven. In examining our PERT chart, we can now see that there are different paths to a project’s completion: A:C which has a total duration of 21 days B:C which has a total duration of 18 days B:D which has a total duration of 23 days So, B:D is the longest path through our PERT. There is no way to complete this project in less then 23 days. Project managers have a special term for this type of path. It is called the Critical Path. The critical path represents the shortest amount of time in which the project can be accomplished. Project managers are very interested in the critical path, since any delay of any task on the critical path will delay the entire project. In our example, if task B is delayed by 2 days then our project can not be completed in less then 25 days. Had we based our calculation on the first PERT chart (where we used W), the critical path would have been shown as A:C, which would have been incorrect. Critical paths must be calculated on Duration, not Work. 9
  • Plan your project the right way ITworld.com 5/9/00 Calculating the critical path in a small project is quite easy. But when the number of tasks begins to grow and the interdependencies between the tasks become more complex, calculating the critical path is best left to software. Knowing the critical path is crucial for a project manager. It lets you know where you must focus your attention, maintain the tightest controls, and assign your best resources. In addition, project managers involved in performing project tasks should avoid assigning themselves to tasks that are on the critical path. When running a project, you will face daily interruptions and fire-fighting jobs. Trying to split your attention between project-management tasks and a critical task is a challenging balancing act; the best idea is to assign critical tasks to other team members. Jerry Golick is an independent project manager, and freelance writer, specializing in networking technology. In addition to consulting, he also provides custom technical training programs on a variety of topics. 10