Lecture notes Project management

lecture notes on software project management and lecture notes on project planning and management pdf free download
FrankRoberts Profile Pic
Published Date:11-07-2017
Your Website URL(Optional)
CHAPTER 1 CHAPTER 1 An Overview of Project Management hat’s all the fuss about, anyway? Since the first edition of this book was published, in 1997, the Project Management ® Institute (PMI ) has grown from a few thousand members to nearly 450,000 in 2011. For those of you who don’t know, W W PMI is the professional organization for people who manage projects. You can get more information from the institute’s website, www.pmi.org. In addition to providing a variety of member services, a major objective of PMI is to advance project management as a profession. To do so, it has established a certi- fication process whereby qualifying individuals receive the Proj- ® ect Management Professional (PMP ) designation. To do so, such individuals must have work experience (approximately five thousand hours) and pass an online exam that is based on the ® Project Management Body of Knowledge, or the PMBOK Guide. A professional association? Just for project management? Isn’t project management just a variant on general management? Yes and no. There are a lot of similarities, but there are enough differences to justify treating project management as a discipline separate from general management. For one thing, proj - ects are more schedule-intensive than most of the activities that 1 American Management Association • www.amanet.org2 Fundamentals of Project Management general managers handle. And the people in a project team often don’t report directly to the project manager, whereas they do re- port to most general managers. So just what is project management, and, for that matter, what is a project? PMI defines a project as “a temporary endeavor undertaken to PMI defines a proj - produce a unique product, service, or ect as “. . . a tem- ® result” (PMBOK Guide, Project Man- agement Institute, 2008, p. 5). This porary endeavor means that a project is done only one undertaken to time. If it is repetitive, it’s not a project. A project should have definite starting produce a unique and ending points (time), a budget product, service, (cost), a clearly defined scope—or mag- nitude—of work to be done, and specific or result.” performance requirements that must be met. I say “should” because seldom does a project conform to the desired definition. These constraints on a project, by the way, are referred to throughout this book as the PCTS targets. Dr. J. M. Juran, the quality guru, also defines a project as a problem scheduled for solution. I like this definition because it re- minds me that every project is conducted A project is a to solve some kind of problem for a com- pany. However, I must caution that the problem scheduled word “problem” typically has a negative for solution. meaning, and projects deal with both positive and negative kinds of problems. —J. M. Juran For example, developing a new product is a problem, but a positive one, while an environmental cleanup project deals with a negative kind of problem. Project Failures In fact, the Standish Group (www.standishgroup.com) has found that only about 17 percent of all software projects done in the American Management Association • www.amanet.orgAn Overview of Project Management 3 United States meet the original PCTS targets, 50 percent must have the targets changed—meaning they are usually late or over- spent and must have their performance requirements reduced— and the remaining 33 percent are actually canceled. One year, U.S. companies spent more than 250 billion on software devel- opment nationwide, so this means that 80 billion was com- pletely lost on canceled projects. What is truly astonishing is that 83 percent of all software projects get into trouble Now, lest you think I am picking on software companies, let me say that these statistics apply to many different kinds of proj - ects. Product development, for example, shares similar dismal rates of failure, waste, and cancellation. Experts on product devel- opment estimate that about 30 percent of the cost to develop a new product is rework. That means that one of every three engi- neers assigned to a project is working full time just redoing what two other engineers did wrong in the first place I also have a colleague, Bob Dudley, who has been involved in construction projects for thirty-five years. He tells me that these jobs also tend to have about 30 percent rework, a fact that I found difficult to believe, because I have always thought of con- struction as being fairly well defined and thus easier to control than might be the case for research projects, for example. Never- theless, several colleagues of mine confirm Bob’s statistics. The reason for these failures is consistently found to be inad- equate project planning. People adopt a ready-fire-aim approach in an effort to get a job done really fast and end up spending far more time than necessary by reworking errors, recovering from diversions down “blind alleys,” and so on. I am frequently asked how to justify formal project manage- ment to senior managers in companies, and I always cite these sta- tistics. However, they want to know whether using good project management really reduces the failures and the rework, and I can only say you will have to try it and see for yourself. If you can achieve levels of rework of only a few percent using a seat-of-the- pants approach to managing projects, then keep doing what you’re doing However, I don’t believe you will find this to be true. American Management Association • www.amanet.org4 Fundamentals of Project Management The question I would ask is whether general management makes a difference. If we locked up all the managers in a company for a couple of months, would business continue at the same levels of perfor- Project manage- mance, or would those levels decline? If they decline, then we could argue that ment is application management must have been doing of knowledge, skills, something positive, and vice versa. I doubt that many general managers tools, and tech- would want to say that what they do doesn’t matter. However, we all know niques to project that there are effective and ineffective activities to achieve general managers, and this is true of proj- ect managers, as well. project require- ments. Project What Is Project management is ac- Management? ® complished through The PMBOK Guide definition of proj- ect management is “application of the application and knowledge, skills, tools, and techniques to project activities to meet the project integration of the requirements. Project management is ac- project manage- complished through the application and integration of the 42 logically grouped ment processes of project management processes compris- initiating, planning, ing the 5 Process Groups: initiating, planning, executing, monitoring and con- executing, monitor- ® trolling, and closing” (PMBOK Guide, ing and controlling, Project Management Institute, 2008, p. 6). Project requirements include the and closing. PCTS targets mentioned previously. The various processes of initiating, planning, and so on are addressed later in this chapter, and the bulk of this book is devoted to explain- ing how these processes are accomplished. American Management Association • www.amanet.orgAn Overview of Project Management 5 ® It would be better if the PMBOK Guide specified that a proj- ect manager should facilitate planning. One mistake made by in- experienced project managers is to plan the project for the team. Not only do they get no buy-in to their plan, but that plan is usually full of holes. The first rule of Managers can’t think of everything, their project manage- estimates of task durations are wrong, and the entire thing falls apart after the ment is that the project is started. The first rule of project people who must management is that the people who must do the work should help plan it. do the work should The role of the project manager is help plan it. that of an enabler. Her job is to help the team get the work completed, to “run interference” for the team, to get scarce resources that team members need, and to buffer them from outside forces that would disrupt the work. She is not a project czar. She should be—above everything—a leader, in the true sense of the word. The best definition of leadership that I have found is the one by Vance Packard, in his book The Pyramid Climbers. He says, “Leadership is the art of getting others to want to do something that you be- “Leadership is the lieve should be done.” The operative art of getting word here is “want.” Dictators get oth- ers to do things that they want done. So others to want to do guards who supervise prison work do something that teams. But a leader gets people to want to do the work, and that is a significant you believe should difference. The planning, scheduling, and con- be done.” trol of work represent the management —Vance Packard or administrative part of the job. But, without leadership, projects tend to just satisfy bare minimum requirements. With leadership, they can ex- ceed those bare minimums. I offer a comprehensive application of project leadership techniques in Chapter 13. American Management Association • www.amanet.org6 Fundamentals of Project Management It Is Not Just Scheduling One of the common misconceptions about project management is that it is just scheduling. At last report, Microsoft had sold a ® huge number of copies of Microsoft Project , yet the project fail- ure rate remains high. Scheduling is certainly a major tool used to manage projects, but it is not nearly as important as developing a shared understanding of what the project is supposed to accom- plish or constructing a good work breakdown structure (WBS) to identify all the work to be done (I discuss the WBS in Chapter 6). In fact, without practicing good project management, the only thing a detailed schedule is going to do is allow you to document your failures with great precision I do want to make one point about scheduling software. It doesn’t matter too much which package you select, as they all have strong and weak points. However, the tendency is to give people the software and expect them to learn how to use it without any training. This simply does not work. The features of scheduling software are such that most people don’t learn the subtleties by themselves. They don’t have the time, because they are trying to do their regular jobs, and not everyone is good at self-paced learn- ing. You wouldn’t hire a green person to run a complex machine in a factory and put him to work without training, because you know he will destroy something or injure himself. So why do it with software? One-Person Projects When is managing a project not project management? When only one person is involved. A lot of people are sent to my seminars to learn how to manage projects, but they are the only person working on their projects. Now it is true that a one-person job can be called a project, because it has a definite starting point, target, end date, specific perfor- mance requirements, defined scope of work, and a budget. How- ever, when no one else is working on the project (including outside vendors), there is no need for a critical path schedule. A critical American Management Association • www.amanet.orgAn Overview of Project Management 7 path schedule is one that has a number of parallel paths, and one of them is longer than the others and determines how long it will take to complete the job or, ultimately, whether the given end date can be met. When you’re working on a job by yourself, there aren’t any parallel paths—unless you are ambidextrous One-person projects do require good self-management, or good time management, but all you need is a good to-do list, which comes from a task listing. However, unless you are coordi- nating the work of other people, you aren’t practicing true project management. The Big Trap—Working Project Managers It is common to have individuals serve as project managers and require also that they do part of the actual work in the project. This is a certain prescription for problems. If it is a true team, con- sisting of several people, the project manager inevitably finds her- self torn between managing and getting her part of the work done. Naturally, the work must take precedence, or the schedule will slip, so she opts to do the work. That means that the managing does not get done. She hopes it will take care of itself, but it never does. After all, if the team could manage itself, there would be no need for a project manager in the first place (remember our argu- ment about whether project management matters?). Unfortunately, when the time comes for her performance evaluation, she will be told that her managing needs improving. Actually, she just needs to be allowed to practice management in the first place. Yes, for very small teams—perhaps up to three or four people— a project manager can do some of the work. But, as team sizes in- crease, it becomes impossible to work and manage both, because you are constantly being pulled away from the work by the needs of your team members. One of the reasons for this situation is that organizations don’t fully understand what project management is all about, and they think that it is possible for individuals to do both. The result is that nearly everyone in the company is trying to manage projects, and, American Management Association • www.amanet.org8 Fundamentals of Project Management as is true in every discipline, some of them will be good at it and others will have no aptitude whatsoever. I have found that a far better approach is to select a few individuals who have the apti- tude and desire to be project managers and let them manage a number of small projects. This frees “technical” people (to use the term broadly) to do technical work without having to worry about administrative issues and allows project managers to get really good at their jobs. It is outside the scope of this book to discuss how to select project managers, but, for the interested reader, the topic is cov- ered in a book by Wysocki and Lewis titled The World-Class Proj- ect Manager (Perseus, 2001). You Can’t Have It All One of the common causes of project failures is that the project sponsor demands that the project manager must finish the job by a certain time, within budget, and at a given magnitude or scope, while achieving specific performance levels. In other words, the sponsor dictates all four of the project constraints. This doesn’t work. The relationship among the PCTS constraints can be written as follows: C = f(P, T, S) In words, this says, “Cost is a function of Performance, Time, and Scope.” Graphically, I like to show it as a triangle, in which P, C, and T are the sides and S is the area. This is shown in Figure 1-1. In geometry, we know that if we are given values for the sides of a triangle, we can compute the area. Or, if we know the area and the length of two sides, we can compute the length of the remaining side. This translates into a very practical rule of project management: The sponsor can assign values to any three variables, but the project manager must determine the remain- ing one. American Management Association • www.amanet.orgAn Overview of Project Management 9 Figure 1-1.  Triangles showing the relationship between P, C, T, and S. C P P C S S T T So let’s assume that the sponsor requires certain performance, time, and scope from the project. It is the project manager’s job to determine what it will cost to achieve those results. However, I always caution project managers that they should have a para- medic standing by when they give the cost figure to the sponsor because she will probably have a stroke or heart attack, and the paramedic will have to revive her. Invariably, the sponsor exclaims, “How can it cost that much?” She had a figure in mind, and your number will always exceed her figure. And she may say, “If it’s going to cost that much, we can’t justify doing the job.” Exactly And that is the de- cision she should make. But she is certain to try to get the project manager to commit to a lower number, and, if you do, then you only set up yourself—and her—to take a big fall later on. It is your obligation to give the sponsor a valid cost so that she can make a valid decision about whether or not the project should be done. If you allow yourself to be intimidated into committing to a lower number, it is just going to be a disaster later on, and you are far better off taking your lumps now than being hanged later on. Of course, there is another possibility. If she says she can afford only so much for the job, then you can offer to reduce the scope. If the job is viable at that scope level, then the project can be done. Otherwise, it is prudent to forget this project and do something else that can make profits for the company. As someone has said, American Management Association • www.amanet.org10 Fundamentals of Project Management there is a higher probability that things will accidentally go wrong in a project than that they will accidently go right. In terms of cost estimates, this means that there is always There is a higher a higher likelihood that the budget will be overrun than that the project will probability that come in below budget. This is just an- things will acciden- other way of stating Murphy’s law, that “whatever can go wrong will go wrong.” tally go wrong in a project than that The Phases of a Project they will acciden- There are many different models for the phases a project goes through during its tally go right. life cycle. One of these captures the all- too-frequent nature of projects that are not managed well and is shown in Figure 1-2. I have shown this diagram to people all over the world, and they invariably laugh and say, “Yes, that’s the way it works.” Figure 1-2.  Life cycle of a troubled project. American Management Association • www.amanet.orgAn Overview of Project Management 11 I suppose the comfort I can take is that we Americans are not the only ones who have the problem, but the bad news is that there are a lot of dysfunctional projects if everyone recognizes the model. At the simplest level, a project has a beginning, middle, and end. I prefer the life-cycle model shown in Figure 1-3, but there are other versions that are equally valid. In my model, you will notice that every project begins as a concept, which is always “fuzzy,” and that the project team must formalize the definition of the job before doing any work. However, because of our ready-fire-aim mentality, we often start working on the job without ensuring that we have a proper definition or that the mission and vision for the job are shared by everyone. This invariably leads to major problems as the project progresses. This is illustrated by the example that follows. Definition Phase Some years ago, a project manager in one of my client companies called me and said, “I’ve just had a conference call with key members of my project team, and I realized that we don’t agree on what the project is supposed to accomplish.” I assured him that this was common. “What should I do?” he asked. I told him that he had no choice but to get the team members Figure 1-3.  Appropriate project life cycle. CONCEPT DEFINITION PLANNING EXECUTION CLOSEOUT Define Develop Marketing DoallWork FinalReports Problem Strategy Input Monitor Lessons- Develop Implementation Progress Learned Surveyof Vision Planning Competition Corrective Review WriteMission Risk Action Statement Management EFFORTEXPENDEDINPLANNING American Management Association • www.amanet.org12 Fundamentals of Project Management all going in the same direction by clarifying the mission of the proj- ect. He asked me to facilitate a meeting to do this. At the meeting, I stood in front of a flip chart and began by saying, “Let’s write a problem statement.” Someone immediately countered by saying, “We don’t need to do that. We all know what the problem is.” I was unmoved by this comment. I said, “Well, if that is true, it’s just a formality and will only take a few minutes, and it would help me if we wrote it down, so someone help me get started.” I’m going to be a little facetious to illustrate what happened next. Someone said, “The,” and I wrote the word on the chart, and someone else said, “I don’t agree with that” Three hours later, we finally finished writing a problem statement. The project manager was right. The team did not agree on what the problem was, much less how to solve it. This is funda- mental—and is so often true that I begin to think we have a de- fective gene in all of us that prohibits us from insisting that we have a good definition of the problem before we start the work. Remember, project management is solving a problem on a large scale, and the way you define a problem determines how you will solve it. If you have the wrong definition, you may come up with the right solution—to the wrong problem In fact, I have become convinced that projects seldom fail at the end. Rather, they fail at the definition stage. I call these proj- ects headless-chicken projects because they are like the chicken that has had its head chopped off and runs around spewing blood everywhere before it finally falls over and is “officially” dead. Proj- ects work the same way. They spew blood all over the place, until someone finally says, “I think that project is dead,” and indeed it is. But it was actually dead when we chopped off its head in the beginning—it just took a while for everyone to realize it. Once the project is defined, you can plan how to do the work. There are three components to the plan: strategy, tactics, and lo- gistics. Strategy is the overall approach or “game plan” that will be followed to do the work. An example of strategy was related to me by a friend who is into military history. American Management Association • www.amanet.orgAn Overview of Project Management 13 Strategy During World War II, defense contractors were under great pres- sure to build weaponry at an intense level. To accelerate con- struction of ships and planes in particular, many new assembly methods were invented. Avondale shipyards, for example, worked on the method of building ships. The traditional way had always been to build the ship in an upright position. However, ships built from steel required welding in the bottom, or keel area of the boat, and this was very difficult to do. Avondale decided to build its ships upside down, to make the welding easier, and then turn them over to complete the structures above the top deck. This strategy was so effective that Avondale could build boats faster, cheaper, and of higher quality than their competitors, and the strategy is still being used today, nearly seventy years later. Implementation Planning This phase includes tactics and logistics. If you are going to build boats upside down, you must work out the details of how it will be done. A fixture must be constructed that will hold the boat and allow it to be turned over without being damaged. This is called “working out the tactics.” It also includes the sequence in which the work will be done, who will do what, and how long each step will take. Logistics deal with making sure the team has the materials and other supplies needed to do their jobs. Ordinarily we think about providing teams with the raw materials they need, but if the project is in a location where they can’t get food, work will soon come to a grinding halt. So provisions must be made for the team to be fed—and possibly housed. Execution and Control Once the plan has been developed and approved, the team can begin work. This is the execution phase, but it also includes con- trol, because, while the plan is being implemented, progress is monitored to ensure that the work is progressing according to the plan. When deviations from the plan occur, corrective action is American Management Association • www.amanet.org14 Fundamentals of Project Management taken to get the project back on track, or, if this is not possible, the plan is changed and approved, and the revised plan becomes the new baseline against which progress is tracked. Closeout When all the work has been completed, the closeout phase re- quires that a review of the project be conducted. The purpose is to learn lessons from this job that can be applied to future ones. Two questions are asked: “What did we do well?” and “What do we want to improve next time?” Notice that we don’t ask what was done wrong. This ques- tion tends to make people defensive, and they try to hide things that may result in their being punished. In fact, a lessons-learned review should never be conducted in a blame-and-punishment mode. If you are trying to conduct an inquisition, that’s different. The purpose of an inquisition is usually to find who is responsible for major disasters and punish them. Lessons-learned sessions should be exactly what the words imply. I have learned during the past few years that very few organi- zations do regular lessons-learned reviews of their projects. There is a reluctance to “open a can of worms.” And there is a desire to get on with the next job. The problem is that you are almost sure to re- peat the mistakes made on the previous project if no one knows about them or has an understanding of how they happened so that they can determine how to prevent them. But, perhaps most im- portant, you can’t even take advantage of the good things you did if you don’t know about them. It has been said that the organizations that survive and thrive in the future will be those that learn faster than their competitors. This seems especially true for projects. The Steps in Managing a Project The actual steps to manage a project are straightforward. Accom- plishing them may not be. The model in Figure 1-4 illustrates the steps. American Management Association • www.amanet.orgAn Overview of Project Management 15 Figure 1-4.  The steps in managing a project. Define the Problem Develop SolutionOptions Plan the Project What must be done? Who willdo it? How willitbe done? When must itbe done? How much willitcost? What do we need todo it? Execute the Plan Monitor & Control Progress Are we on target? If not, what must be done? Should the plan be changed? Close Project What was done well? What should be improved? What else didwe learn? Subsequent chapters of this book elaborate on how each step is accomplished. For now, here is a brief description of the actions involved. American Management Association • www.amanet.org16 Fundamentals of Project Management Define the Problem As was discussed previously, you need to identify the problem to be solved by the project. It helps to visualize the desired end re- sult. What will be different? What will you see, hear, taste, touch, or smell? (Use sensory evidence if things can’t be quantified.) What client need is being satisfied by the project? Develop Solution Options How many different ways might you go about solving the prob- lem? Brainstorm solution alternatives (you can do this alone or as a group). Of the available alternatives, which do you think will best solve the problem? Is it more or less costly than other suit- able choices? Will it result in a complete or only a partial fix? Plan the Project Planning is answering questions: what must be done, by whom, for how much, how, when, and so on. Naturally, answering these questions often requires a crystal ball. We discuss these steps in more detail in Chapters 2 through 4. Execute the Plan Obvious. Once the plan is drafted, it must be implemented. In- terestingly, we sometimes find people going to great effort to put together a plan, then failing to follow it. If a plan is not followed, there is not much point in planning, is there? Monitor and Control Progress Plans are developed so that you can achieve your end result suc- cessfully. Unless progress is monitored, you cannot be sure you will succeed. It would be like having a roadmap to a destination but not monitoring the highway signs along the way. Of course, if a deviation from the plan is discovered, you must ask what must be done to get back on track, or—if that seems impossible—how the plan should be modified to reflect new realities. American Management Association • www.amanet.orgAn Overview of Project Management 17 Close the Project Once the destination has been reached, the project is finished, but there is a final step that should be taken. Some people call it an audit, others a postmortem (sounds a bit morbid, doesn’t it?). Whatever you call it, the point is to learn something from what you just did. Note the way the questions are phrased: What was done well? What should be improved? What else did we learn? We can always improve on what we have done. However, asking “What did we do wrong?” is likely to make people a bit defen- sive, so the focus should be on improvement, not on placing blame. More on this later. The Project Management Body of ® Knowledge (PMBOK ) The Project Management Institute has attempted to determine a minimum body of knowledge that is needed by a project manager in order for him or her to be effective. As I mentioned earlier when I defined project management, there are five processes ® defined by the PMBOK Guide, together with nine general areas of knowledge, and I will give brief summaries of them. If you want a complete document, you can get one by visiting the PMI website: www.pmi.org. Project Processes A process is a way of doing something. As previously mentioned, ® the PMBOK Guide identifies five processes that are used to man- age projects. Although some of them will be predominant at cer- tain phases of a project, they may come into play at any time. Broadly speaking, however, they tend to be employed in the se- quence listed as the project progresses. That is, initiating is done first, then planning, then executing, and so on. In the event that a project goes off course, replanning comes into play, and if a proj- ect is found to be in serious trouble, it may have to go all the way back to the initiating process to be restarted. American Management Association • www.amanet.org18 Fundamentals of Project Management Initiating Once a decision has been made to do a project, it must be initi- ated or launched. There are a number of activities associated with this. One is for the project sponsor to create a project char- ter, which defines what is to be done to meet the requirements of project customers. This is a formal process that is often omitted in organizations. The charter should be used to authorize work on the project; define the authority, responsibility, and accountability of the project team; and establish scope boundaries for the job. When such a document is not produced, the team members may misinterpret what is required of them, and this can be very costly. Planning One of the major causes of project failures is poor planning. Ac- tually, I am being kind. Most of the time the problem is caused by there being no planning The team simply tries to “wing it,” to do the work without doing any planning at all. As I have explained earlier in this chapter, many of us are task oriented, and we see planning as a waste of time, so we would rather just get on with the work. As we will see when we turn to controlling the project, failing to develop a plan means that there can be no actual con- trol of the project. We are just kidding ourselves. Executing There are two aspects to the process of project execution. One is to execute the work that must be done to create the product of the project. This is properly called technical work, and a project is conducted to produce a product. Note that we are using the word “product” in a very broad sense. A product can be an actual tangible piece of hardware or a building. It can also be software or a service of some kind. It can also be a result—consider, for ex- ample a project to service an automobile that consists of changing the oil and rotating the tires. There is no tangible deliverable for such a project, but there is clearly a result that must be achieved, and if it is not done correctly the car may be damaged as a result. American Management Association • www.amanet.orgAn Overview of Project Management 19 Executing also refers to implementing the project plan. It is amazing to find that teams often spend time planning a project, then abandon the plan as soon as they encounter some difficulty. Once they do this, they cannot have control of the work, since without a plan there is no control. The key is to either take cor- rective action to get back on track with the original plan or to re- vise the plan to show where the project is at present and continue forward from that point. Monitoring and Controlling Monitoring and controlling can actually be thought of as two separate processes, but because they go hand in hand, they are considered one activity. Control is exercised by compar- ing where project work is to where it is supposed to be, then taking action to correct for any deviations from target. Now the plan tells where the work should be. Without a plan, you don’t know where you should be, so control is impossible, by definition. Furthermore, knowing where you are is done by monitoring progress. An assessment of quantity and quality of work is made using whatever tools are available for the kind of work being done. The result of this assessment is compared to the planned level of work; if the actual level is ahead or behind of the plan, something will be done to bring progress back in line with the plan. Naturally, small deviations are always present and are ig- nored unless they exceed some pre-established threshold or show a trend toward drifting further off course. Closing In too many cases, once the product is produced to the cus- tomer’s satisfaction, the project is considered finished, or closed. This should not be the case. A final lessons-learned review should be done before the project is considered complete. Failing to do a lessons-learned review means that future projects will likely suffer the same headaches encountered on the one just done. American Management Association • www.amanet.org