Chapter5 project-management
0 likes1,972 views
This document discusses project management and outlines key concepts. It defines a project as a temporary, unique activity with a defined scope and timeline. Project management focuses on planning, monitoring progress, and problem-solving. Planning involves identifying tasks, scheduling tasks, and assessing risks. Tasks should have a limited duration and scope, measurable progress, and a responsible individual. Project management structures are focused on deliverables, while operations management focuses on ongoing roles.
Chapter5 project-management
- 1. Elec3017: Electrical Engineering Design Chapter 5: Project Management A/Prof D. S. Taubman August 9, 2006 1 Purpose of this Chapter Project management is a significant topic in and of itself, which cannot be cov- ered completely in the present course. On the other hand, project management hard to appreciate through theory alone. This course provides an excellent opportunity for you to experience the challenges and benefits of project man- agement first hand through your concurrent team-based design project. In many ways, project management is form of applied common sense; it certainly isn’t rocket science. When design projects fail, however, they often do so primarily because of project management failures. This demonstrates that many of the disciplines of project management are not intuitively obvious when you first set out. This chapter aims to provide you with sufficient tools to manage your project well, while putting these tools in a more general context — real projects are more complex than your design project in this course. 2 Introduction The term “project management” refers to a set of disciplines and tools, which have been found beneficial in managing the budget, resources and timely com- pletion of non-repetitive activities. Such activities are known as projects. More specifically, projects have the following attributes: • Projects are temporary activities, with well-defined starting and finishing dates. • Projects have a well-defined scope. In the broadest possible terms, this means that there must be a way of knowing when the project is complete. The scope of the project is essentially the set of deliverables, which should be possible to define ahead of time. • Projects are unique activities. An activity which has been done before, in essentially the same way, is not really a project. 1
- 2. c °Taubman, 2006 ELEC3017: Project Management Page 2 New product design fits the definition of a project quite nicely. Certainly, design is a temporary and unique activity. Design activities should also have bounded scope. Whether or not the scope can be well-defined from the outset is not quite so clear. The design activities conducted by consulting engineering firms typically have very well-defined scope, established up front via a contract with the client. The scope of a product design activity, however, may evolve as more is understood about the true needs of consumers. Nevertheless, a design activity which goes on forever cannot be profitable, so considerable effort must be invested to keep the scope as tight as possible. Project management is acutely focused on the deliverables of the project and the constraints within which those deliverables must be achieved. The three key components of project management are: 1) planning; 2) monitoring progress; and 3) taking control of schedule, budget or other problems as they arise. These components are the subject of Sections 3, 4 and 5, respectively. As a management style, project management has a lot to offer. Its methods have been growing in popularity for the last couple of decades, with companies increasingly moving toward project oriented organization structures. It is worth bearing in mind, however, that not all commercial activities are projects. Some important examples are: Maintainance: This is a classic example of a recurring activity, which is nei- ther temporary nor unique. There are plenty of related activities which can be identified, such as security and customer service. Staff development, mentoring and evaluation: These are critical func- tions in any commercial enterprise, which do not fit the project mould at all. Long term research: There has been considerable debate about whether re- search should be considered as a project. Some of the methods of project management can also be helpful in managing research, but the fundamen- tal question is whether it is possible to say enough up front about what the deliverables of a research activity will be. If you knew the outcomes ahead of time, it probably would not be research. The type of research which can lead to disruptive technologies is, by definition, difficult to bound in scope or time. Activities such as these are often better served by more traditional “operations management” structures. Figure 1 illustrates the differences between project and operations management structures. Project management structures are focused on deliverables and schedule, drawing staff from within (or from out- side) the organization as required. A single individual might work on different projects, quite often in different capacities — manager of one project, team mem- ber in another, etc. By contrast, operations management structures are focused on roles. Roles are essentially ongoing activities which must be performed, so it makes the most sense to attach roles to specific individuals. It is quite unhelpful, for example, to think of the regular evaluation of employees as a project with
- 3. c °Taubman, 2006 ELEC3017: Project Management Page 3 CEO CEO Project 1 Project 2 Function 1 Function 2 Manager Manager Director Director Manager Manager Staff 1 Staff 1 Staff 2 Staff 2 Figure 1: Project (left) and operations (right) management structures. Shaded regions connect project management roles which are performed by the same per- son. deliverables. Such an activity is much better understood as an ongoing role, which requires accumulated knowledge and ongoing interaction. In view of the above arguments, it is important not to get carried away in thinking that project management is the solution to the world’s management problems. Most modern organizations employ a mixture of project and opera- tions management structures so as to best serve their diverse needs. 3 Project Planning You may be thinking of planning as a one-time, up-front activity to set the path for a project and then let it run. In practice, however, this is far from the case. Like all systems which involve uncertainty, feedback is essential in reaching the desired outcomes. You should expect your plan to change over the course of the project, as you learn more about the difficulties you are up against and as you react to unpredictable outcomes and circumstances. The fact that the plan changes does not necessarily mean that the project’s deliverables need change — you may find creative ways to achieve the original deliverables within the original time frame, even if your initial plan goes seriously astray. The important thing about the plan is not that you stick to it, but rather that it gives you a way of knowing how you are progressing in relation to the project’s objectives, allowing you to react to unfore- seen eventualities in a controlled and informed manner.
- 4. c °Taubman, 2006 ELEC3017: Project Management Page 4 Planning is a forward looking process. As the saying goes, “There is no point in crying over spilt milk.” Whatever successes or failures you have had in the past are irrelevant, except to the extent that you can learn from these experiences. All that matters is the remaining time, the remaining budget, and the project deliverables which have not yet been met. To emphasize this point, if the time taken to perform project management activities were negligible, you should ideally discard your plan and generate a new one each time new information became available concerning your progress or the prevailing circumstances. In the remainder of this section, we discuss the three most important aspects of planning: 1) identifying tasks; 2) scheduling tasks; and 3) assessing risk. 3.1 Project Tasks Breaking a project plan into tasks is the key to managing complexity. Each task is a kind of mini project (or sub-project). Not surprisingly, then, each task should also have a well-defined time frame and a well-defined scope (set of deliverables). In complex projects, tasks may be further decomposed into sub-tasks in an hierarchical manner. If decomposition of the project into tasks is to be useful, each task must be less complex to manage than the project (or super-task) to which it belongs. In view of this, good tasks should generally have the following attributes: Limited duration: With a few possible exceptions, the duration of a task should be small in comparison to the duration of the entire project. Limited scope: Each task should have a well-defined scope, significantly smaller than that of the entire project. The scope of a task may be stated in terms of its deliverables alone, but it is often more helpful to describe the scope of a task in terms of its inputs and its outputs. The inputs to a task are the outputs from any other tasks on which it depends Limited level of effort: The human and other resources required to complete a task should be significantly smaller than those required by the entire project. Measurability: It should be possible to measure progress on a task, so that it can be tracked for management purposes. If the task is defined in such a way that it is only possible to say whether or not the task has been completed, it may not be possible to plan around unexpectedly slow progress until the expected task completion date has significantly passed. You should aim to define tasks in such a way that a percent completed figure can be judged relatively easily. Responsibility: Just as the entire project has a manager, so each of its tasks should also have an assigned person who is responsible for managing the task’s progress. More often than not, tasks flounder if they are not as- signed directly to individuals.
- 5. c °Taubman, 2006 ELEC3017: Project Management Page 5 concept concept generation selection sequential tasks develop test documents detailed design parallel tasks develop prototype design PCB detailed design coupled tasks design front panel Figure 2: Different categories of task dependencies. As elements of the complete project, tasks have a relationship to one an- other which must be identified. Relationships between tasks may be classified as sequential, parallel or coupled, as depicted in Figure 2. Sequential tasks must be completed in order, since each task in the sequence depends upon the com- pletion of its predecessor. Parallel tasks are not dependent on one another; this provides the greatest flexibility in scheduling. Coupled tasks exhibit complex inter-dependencies. In some cases, this occurs because the tasks have not been analyzed carefully enough; a more detailed analysis may reveal a collection of smaller tasks which can be completed in sequence. In other cases, coupled tasks are best treated as a single larger task. In any event, coupled tasks cannot be scheduled independently, so for planning purposes at least, they must either be considered as a single larger task or decomposed into smaller non-coupled tasks. 3.2 Task Scheduling Arguably the simplest form of task scheduling is to draw a timeline, showing when you expect each task to start and finish. This is essentially the role played by a Gantt chart. Gantt charts are bar diagrams, with time on the horizontal axis and bars corresponding to each task arranged vertically. The bar associated with each task extends from its expected start date to its expected finish date. A very simple example is shown in Figure 3. The drawback of Gantt charts is that all tasks must be assigned well-defined starting and finishing times, even though many tasks could happily “float,” starting earlier or finishing later, without impacting progress on the project. In the example of Figure 3, the development of test documentation could easily
- 6. c °Taubman, 2006 ELEC3017: Project Management Page 6 concept generation concept selection system design detailed design slack develop test documents develop prototype test prototype design project duration Figure 3: Simple Gantt chart. For a real Gantt chart, the horizontal axis should, of course, be labelled (e.g., days, weeks, months). start later without affecting project completion, since the test documents are not required until much later, when the more time consuming task of prototyping completes. This possibility is quite easy to see when there are only a small number of tasks with simple dependencies. For complex projects with hundreds or thousands of tasks, a more formal approach is required to capture the true dependencies and constraints. One such approach is the Program Evaluation and Review Technique (PERT), which was developed by the US military for managing highly complex projects. The PERT approach captures task precedence information (shown with ar- rows), along with minimum and maximum expected completion times for each task, in a network diagram (often also called a PERT diagram) such as that shown in Figure 4. Network diagrams embody the supposed scheduling con- straints, without imposing unnecessary, artificial constraints on task starting times. Based on this information, it is possible to compute best case and worst case times required to complete the entire project. We say “best” and “worst” times because true PERT charts assign each task a range of possible durations. This allows us to compute statistical estimates of the project completion time, as well as the slack in each task’s scheduled starting time. A simpler form of network diagram (often still called a PERT diagram) contains only a single fixed duration for each task. In this case, the computed scheduling information is deterministic rather than statistical. We will use this simple case to illustrate the computation of the minimum project completion time and the slack in each task’s scheduled starting time. We do this via the so-called critical path method (CPM). To describe the critical path method, let T = {Ti }i denote the complete set of tasks, indexed by i. For each i, let Ai ⊆ T be the set of predecessors for task Ti and Si ⊆ T be the set of successors for task Ti . Specifically, Ai consists of all tasks whose outputs are inputs to task
- 7. c °Taubman, 2006 ELEC3017: Project Management Page 7 develop test documents concept concept system detailed (3-4 days) test generation selection design design prototype (3-4 days) (1-2 day) (4-6 days) (8-13 days) develop (2-5 days) prototype (7-15 days) Figure 4: Simple network diagram. Ti , while Si consists of all tasks whose inputs are outputs from task Ti . CPM involves a forward and a backward pass through the tasks. The purpose of the forward pass is to assign an “earliest start time” ei to each task Ti , while the backward pass assigns a “latest finish time” fi to each task. These must satisfy fi − ei ≥ Di where Di is the task duration. The two may be defined recursively, as follows1 . Forward pass: For each task Ti , execute “forward_pass(Ti ),” which is de- fined as follows: forward_pass(Ti ) { if Ai is empty (no predecessors for task Ti ), set ei = 0 else for each Tj ∈ Ai such that ej is not already known, execute “forward_pass(Tj )” set ei = maxTj ∈Ai {ej + Dj } } min Min completion time: Evaluate Dpro ject = maxi {ei + Di } Backward pass: For each task Ti , execute “backward_pass(Ti ),” which is defined as follows: backward_pass(Ti ) { min if Si is empty (no successors for task Ti ), set fi = Dpro ject else for each Tj ∈ Si such that fj is not already known, execute “backward_pass(Tj )” set fi = minTj ∈Si {fj − Dj } } 1 You can trivially implement this with a few lines of code in C, Java or another program- ming language or your choice.
- 8. c °Taubman, 2006 ELEC3017: Project Management Page 8 Those tasks for which fi − ei = Di are known as “critical tasks” and are said to lie on the “critical path.” Starting these tasks late, or exceeding their expected duration, will cause the entire project to be delayed. Non-critical tasks have some slack time (also called float time) floati = fi − ei − Di which represents the amount by which the task’s start date may be delayed beyond ei or, if started at ei , the amount by which the task’s duration may be extended beyond Di , without affecting the overall project completion time. Before concluding this sub-section, we note that the timing information de- rived via critical path analysis can be used to map tasks in a network diagram onto a timeline. “Microsoft Project” does this, allowing you to visualize the schedule as a pure network diagram, a Gantt chart, or a combination of the two (Gantt with dependency arrows and scheduling constraints). We also note that most plans include additional scheduling constraints in the form of milestones. A milestone typically represents the latest finishing date for some specific task or collection of tasks. For example, the due date for your ELEC3017 design project proposal is a milestone. It marks the completion of a task which you might call “project proposal writing.” Milestones might be hard constraints, such as a client review deadline. Other milestones might be softer constraints, such as internal review dates. 3.3 Identifying and Assessing Risks Plans usually deal with uncertainty, and this is particularly so when planning a design activity. It is important that you become aware of these risks as early as possible, so that you can allow for them in the plan. This may involve the introduction of extra slack time in a critical task which has high risk. Some risks might have more far reaching consequences than just delaying a task. While risks relate to unpredictable outcomes, this does not prevent you from estimating the likelihood of a risk occurring. Nor does it prevent you from thinking ahead of measures to mitigate the risk or deal with it if it eventuates — i.e., having a “plan B.” Such activities will minimize unexpected surprises and increase the likelihood of a success in your product development project. One common very common source of risk is the delay associated with sourc- ing critical components. To minimize the impact of this risk, a good plan would involve ordering such components as early as possible. Another common source of risk is technical incompetence. A particular design strategy may prove too difficult, given the technical capabilities of the personnel involved. One way to minimize the impact of this risk is to develop two different design concepts, at least to the point of system design. The second, simpler concept might be the basis of a fallback plan you have waiting in the wings in the event that a superior, yet more complex concept proves too challenging. Remember that things do go wrong. This might be beyond your control, but good planning is something that is within your control. If things go wrong
- 9. c °Taubman, 2006 ELEC3017: Project Management Page 9 and you have no fallback plan, the principle cause of failure is probably your project management, rather than the technical challenge itself. 4 Project Monitoring As mentioned at the start of Section 3, planning is not a static activity, but a dynamic one. The plan must be regularly updated in response to actual progress on tasks, amongst other things. This is only possible if you invest effort in monitoring progress. This, in turn, requires the establishment of a reporting schedule and the designation of individuals responsible for updating progress data. The reporting schedule might be as simple as weekly team meetings for a small project, whereas larger projects might involve substantial report documentation to be generated. Progress monitoring does not take place in a vacuum, but is tied concretely to the plan. Schedule monitoring essentially consists of regularly identifying the completion percentage for each outstanding task on the plan. Along with scheduling aspects of the plan, a real project will also have cost estimates for each task. We will look at costing in Chapter 11. For now, though, it is sufficient to note that budget monitoring is also important, comparing planned development costs against actual expenditure. A final aspect of project monitoring involves attention to risks. Have previously unforeseen risks emerged? Have previously anticipated risks occurred or been avoided? All of this information affects your ongoing management of the project. 5 Project Control Now that you have a plan and you are monitoring your progress against that plan, what should you do when things are not going according to the plan? Project managers need to take control of situations before they get out of hand. One way in which this is done is by updating the plan, rescheduling tasks and reassigning resources so as to keep progress on track. If critical tasks are taking longer than expected, there are several things which can be done, as follows: 1. Trim non-critical features from the scope of the project. Of course, this should be done with careful reference to customer requirements and mar- keting information. 2. Move resources (e.g., personnel) from less critical tasks to those on the critical path. 3. Rework the task breakdown so as to decouple activities — i.e., produce more parallel tasks. This can often be done by decomposing larger tasks into smaller sub-tasks, some of which may be able to run in parallel. Reducing dependencies allows tasks to be performed more quickly, subject to the availability of sufficient resources.
- 10. c °Taubman, 2006 ELEC3017: Project Management Page 10 4. Consider outsourcing some critical tasks. Of course, this usually adds to the cost of development, but delays may be more costly to the success of the product in the long run. 5. Analyze “safety margins” that have been built into your time estimates for the remaining tasks. If there are a large number of sequential tasks, each with safety margins in their duration estimates, the expected project completion time may be overly pessimistic. In this case, aggregating safety margins may provide a more realistic estimate of the time remaining to complete the project, which then affects other decisions. 6. Consider commencing a task before the completion of some other task, on which it depends. In practice, this is often possible, because partial results from a predecessor may be sufficient to get the next task going. Of course, this approach increases the risk that resources are wasted, since some work done on a sequentially dependent task may be wasted if unexpected outcomes later emerge from a task on which it depends. For example, you could start the system design phase before concept generation is complete — in fact, this usually happens. There is, however, a risk that new concepts will be developed which render early system design work invalid. 6 Roles, Perspectives and Reporting It is all very well to think of planning and monitoring in an abstract sense, but in practice, the way people respond to the needs and developments of a project will depend on their perspective. For example, the design engineer, immersed in the technical challenges of the design problem, is less likely to see budget overruns as a serious problem. Promotions executives might be particularly concerned about delays in the project’s completion date, but less worried about specific features or performance issues. Good project management practice aims to incorporate these diverse per- spectives through the recognition of three different roles. These roles are identi- fied as the “client,” the “project director” and the “project manager.” Figure 5 illustrates the perspectives associated with these roles, and the tensions which exist between them. In a consulting engineering firm, the client is usually easy to identify — this is the customer who approaches the company with a problem to be solved. For product design, the client is a bit more difficult to identify. Ultimately, the product’s client is the consumer. However, it is not reasonable to assign consumers are direct role in the project management process. It is best to view the client as that segment of the organization (or a third party organization) which is most immediately affected by the output of the product design process. In a large electronics manufacturing company, clients for a de- sign project would typically be manufacturing centres and product promotions departments. The project director fits between the client and the project manager, as suggested by Figure 5. The project manager will naturally be deeply involved
- 11. c °Taubman, 2006 ELEC3017: Project Management Page 11 client project director project manager • Most immediately affected • Takes the perspective of • Plans, monitors and by project outcomes the client, at least in part controls all aspects of the • Reports to the client – project e.g., major design reviews • Reports regularly to the project director • May report directly to the client Figure 5: Roles of the client, project director and project manager. with the technical aspects of the project, but this can lead to a loss of objec- tivity. The project manager reports directly to the project director, whose is responsible for taking a more objective view, incorporating the perspectives of the client. The project director and/or project manager also provide progress reports and consult with the client on matters related to project progress and control, but this is less frequent and usually less detailed than the interaction between project manager and project director. For your ELEC3017 design project, you may be wondering how it is possible to incorporate so many roles, when project teams are small and projects are of limited duration. For this project, the lecturer will assume the role of the client (amongst other roles) during your final seminar and demonstration. Meanwhile, your technical advisory board members can provide you with some of the ob- jectivity associated with the role of project director. It would be helpful for you to designate one team member as the project manager, rather than simply distributing the role equally. This does not mean that only that individual will plan and monitor tasks and report to the board. It does, however, mean that at least one individual will take responsibility for ensuring that these activities actually occur.