chapter5 project-management

Elec3017:Electrical Engineering Design

Chapter 5: Project Management

A/Prof D. S. Taubman

August 9, 2006

1 Purpose of this ChapterProject management is a significant topic in and of itself, which cannot be cov-ered completely in the present course. On the other hand, project managementhard to appreciate through theory alone. This course provides an excellentopportunity for you to experience the challenges and benefits of project man-agement first hand through your concurrent team-based design project. In manyways, project management is form of applied common sense; it certainly isn’trocket science. When design projects fail, however, they often do so primarilybecause of project management failures. This demonstrates that many of thedisciplines of project management are not intuitively obvious when you firstset out. This chapter aims to provide you with sufficient tools to manage yourproject well, while putting these tools in a more general context — real projectsare more complex than your design project in this course.

2 IntroductionThe term “project management” refers to a set of disciplines and tools, whichhave been found beneficial in managing the budget, resources and timely com-pletion of non-repetitive activities. Such activities are known as projects. Morespecifically, projects have the following attributes:

• Projects are temporary activities, with well-defined starting and finishingdates.

• Projects have a well-defined scope. In the broadest possible terms, thismeans 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 shouldbe possible to define ahead of time.

• Projects are unique activities. An activity which has been done before, inessentially the same way, is not really a project.

1

c°Taubman, 2006 ELEC3017: Project Management

New product design fits the definition of a project quite nicely. Certainly,design is a temporary and unique activity. Design activities should also havebounded scope. Whether or not the scope can be well-defined from the outsetis not quite so clear. The design activities conducted by consulting engineeringfirms typically have very well-defined scope, established up front via a contractwith the client. The scope of a product design activity, however, may evolve asmore is understood about the true needs of consumers. Nevertheless, a designactivity which goes on forever cannot be profitable, so considerable effort mustbe 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 keycomponents of project management are: 1) planning ; 2) monitoring progress;and 3) taking control of schedule, budget or other problems as they arise. Thesecomponents 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 companiesincreasingly moving toward project oriented organization structures. It is worthbearing in mind, however, that not all commercial activities are projects. Someimportant 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 whichcan 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 mouldat all.

Long term research: There has been considerable debate about whether re-search should be considered as a project. Some of the methods of projectmanagement can also be helpful in managing research, but the fundamen-tal question is whether it is possible to say enough up front about what thedeliverables of a research activity will be. If you knew the outcomes aheadof time, it probably would not be research. The type of research whichcan lead to disruptive technologies is, by definition, difficult to bound inscope or time.

Activities such as these are often better served by more traditional “operationsmanagement” structures. Figure 1 illustrates the differences between projectand operations management structures. Project management structures arefocused on deliverables and schedule, drawing staff from within (or from out-side) the organization as required. A single individual might work on differentprojects, quite often in different capacities — manager of one project, team mem-ber in another, etc. By contrast, operations management structures are focusedon roles. Roles are essentially ongoing activities which must be performed, so itmakes 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


CEO

Project 1 Project 2

Manager

Staff 1

Staff 2

Manager

Staff 1

Staff 2

CEO

Function 1Manager

Function 2Manager

Director Director

CEO

Project 1 Project 2

Manager

Staff 1

Staff 2

Manager

Staff 1

Staff 2

CEO

Function 1Manager

Function 2Manager

Director Director

Figure 1: Project (left) and operations (right) management structures. Shadedregions 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 managementproblems. Most modern organizations employ a mixture of project and opera-tions management structures so as to best serve their diverse needs.

3 Project PlanningYou may be thinking of planning as a one-time, up-front activity to set thepath for a project and then let it run. In practice, however, this is far fromthe case. Like all systems which involve uncertainty, feedback is essential inreaching the desired outcomes. You should expect your plan to change over thecourse of the project, as you learn more about the difficulties you are up againstand as you react to unpredictable outcomes and circumstances. The fact thatthe plan changes does not necessarily mean that the project’s deliverables needchange — you may find creative ways to achieve the original deliverables withinthe original time frame, even if your initial plan goes seriously astray.

The important thing about the plan is not that you stick to it, butrather that it gives you a way of knowing how you are progressing inrelation to the project’s objectives, allowing you to react to unfore-seen eventualities in a controlled and informed manner.


Planning is a forward looking process. As the saying goes, “There is no pointin crying over spilt milk.” Whatever successes or failures you have had in the pastare irrelevant, except to the extent that you can learn from these experiences.All that matters is the remaining time, the remaining budget, and the projectdeliverables which have not yet been met. To emphasize this point, if the timetaken to perform project management activities were negligible, you shouldideally discard your plan and generate a new one each time new informationbecame 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. Eachtask is a kind of mini project (or sub-project). Not surprisingly, then, eachtask should also have a well-defined time frame and a well-defined scope (setof deliverables). In complex projects, tasks may be further decomposed intosub-tasks in an hierarchical manner. If decomposition of the project into tasksis to be useful, each task must be less complex to manage than the project (orsuper-task) to which it belongs. In view of this, good tasks should generallyhave the following attributes:

Limited duration: With a few possible exceptions, the duration of a taskshould be small in comparison to the duration of the entire project.

Limited scope: Each task should have a well-defined scope, significantlysmaller than that of the entire project. The scope of a task may be statedin terms of its deliverables alone, but it is often more helpful to describethe scope of a task in terms of its inputs and its outputs. The inputs to atask are the outputs from any other tasks on which it depends

Limited level of effort: The human and other resources required to completea task should be significantly smaller than those required by the entireproject.

Measurability: It should be possible to measure progress on a task, so thatit can be tracked for management purposes. If the task is defined insuch a way that it is only possible to say whether or not the task hasbeen completed, it may not be possible to plan around unexpectedly slowprogress until the expected task completion date has significantly passed.You should aim to define tasks in such a way that a percent completedfigure can be judged relatively easily.

Responsibility: Just as the entire project has a manager, so each of its tasksshould also have an assigned person who is responsible for managing thetask’s progress. More often than not, tasks flounder if they are not as-signed directly to individuals.


conceptgeneration

conceptselection

developprototype

develop testdocumentsdetailed

design

design frontpanel

design PCBdetaileddesign

sequential tasks

parallel tasks

coupled tasks

conceptgeneration

conceptselection

developprototype

develop testdocumentsdetailed

design

design frontpanel

design PCBdetaileddesign

sequential tasks

parallel tasks

coupled tasks

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 classifiedas sequential, parallel or coupled, as depicted in Figure 2. Sequential tasks mustbe 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; thisprovides the greatest flexibility in scheduling. Coupled tasks exhibit complexinter-dependencies. In some cases, this occurs because the tasks have not beenanalyzed carefully enough; a more detailed analysis may reveal a collection ofsmaller tasks which can be completed in sequence. In other cases, coupled tasksare best treated as a single larger task. In any event, coupled tasks cannot bescheduled independently, so for planning purposes at least, they must either beconsidered 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, showingwhen you expect each task to start and finish. This is essentially the role playedby a Gantt chart. Gantt charts are bar diagrams, with time on the horizontalaxis and bars corresponding to each task arranged vertically. The bar associatedwith 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. Inthe example of Figure 3, the development of test documentation could easily


conceptgeneration

conceptselection

developprototype

develop testdocuments

detaileddesign

systemdesign

design project duration

slack

testprototype

conceptgeneration

conceptselection

developprototype

develop testdocuments

detaileddesign

systemdesign

design project duration

slack

testprototype

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 notrequired until much later, when the more time consuming task of prototypingcompletes. This possibility is quite easy to see when there are only a smallnumber of tasks with simple dependencies. For complex projects with hundredsor thousands of tasks, a more formal approach is required to capture the truedependencies and constraints. One such approach is the Program Evaluationand Review Technique (PERT), which was developed by the US military formanaging highly complex projects.The PERT approach captures task precedence information (shown with ar-

rows), along with minimum and maximum expected completion times for eachtask, in a network diagram (often also called a PERT diagram) such as thatshown in Figure 4. Network diagrams embody the supposed scheduling con-straints, without imposing unnecessary, artificial constraints on task startingtimes. Based on this information, it is possible to compute best case and worstcase 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 computedscheduling information is deterministic rather than statistical. We will use thissimple case to illustrate the computation of the minimum project completiontime and the slack in each task’s scheduled starting time. We do this via theso-called critical path method (CPM). To describe the critical path method, letT = {Ti}i denote the complete set of tasks, indexed by i. For each i, let Ai ⊆ Tbe the set of predecessors for task Ti and Si ⊆ T be the set of successors fortask Ti. Specifically, Ai consists of all tasks whose outputs are inputs to task


conceptgeneration(3-4 days)

conceptselection(1-2 day) develop

prototype(7-15 days)

develop testdocuments(3-4 days)detailed

design(8-13 days)

systemdesign

(4-6 days)

testprototype(2-5 days)

conceptgeneration(3-4 days)

conceptselection(1-2 day) develop

prototype(7-15 days)

develop testdocuments(3-4 days)detailed

design(8-13 days)

systemdesign

(4-6 days)

testprototype(2-5 days)

Figure 4: Simple network diagram.

Ti, while Si consists of all tasks whose inputs are outputs from task Ti. CPMinvolves a forward and a backward pass through the tasks. The purpose of theforward pass is to assign an “earliest start time” ei to each task Ti, while thebackward 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 = 0else

for each Tj ∈ Ai such that ej is not already known, execute“forward_pass(Tj)”

set ei = maxTj∈Ai {ej +Dj}}

Min completion time: Evaluate Dminpro ject = maxi {ei +Di}

Backward pass: For each task Ti, execute “backward_pass(Ti),” which isdefined as follows:

backward_pass(Ti) {

if Si is empty (no successors for task Ti), set fi = Dminpro ject

else

for each Tj ∈ Si such that fj is not already known, execute“backward_pass(Tj)”

set fi = minTj∈Si {fj −Dj}}

1You can trivially implement this with a few lines of code in C, Java or another program-ming language or your choice.


Those tasks for which fi − ei = Di are known as “critical tasks” and aresaid to lie on the “critical path.” Starting these tasks late, or exceeding theirexpected duration, will cause the entire project to be delayed. Non-critical taskshave some slack time (also called float time)

floati = fi − ei −Di

which represents the amount by which the task’s start date may be delayedbeyond ei or, if started at ei, the amount by which the task’s duration may beextended 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 diagramonto a timeline. “Microsoft Project” does this, allowing you to visualize theschedule as a pure network diagram, a Gantt chart, or a combination of the two(Gantt with dependency arrows and scheduling constraints). We also note thatmost plans include additional scheduling constraints in the form of milestones.A milestone typically represents the latest finishing date for some specific taskor collection of tasks. For example, the due date for your ELEC3017 designproject proposal is a milestone. It marks the completion of a task which youmight 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 planninga design activity. It is important that you become aware of these risks as earlyas possible, so that you can allow for them in the plan. This may involve theintroduction of extra slack time in a critical task which has high risk. Some risksmight have more far reaching consequences than just delaying a task. While risksrelate to unpredictable outcomes, this does not prevent you from estimating thelikelihood of a risk occurring. Nor does it prevent you from thinking ahead ofmeasures 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 thelikelihood 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 wouldinvolve ordering such components as early as possible. Another common sourceof risk is technical incompetence. A particular design strategy may prove toodifficult, given the technical capabilities of the personnel involved. One wayto 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 bethe basis of a fallback plan you have waiting in the wings in the event that asuperior, 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


and you have no fallback plan, the principle cause of failure is probably yourproject management, rather than the technical challenge itself.

4 Project MonitoringAs mentioned at the start of Section 3, planning is not a static activity, but adynamic one. The plan must be regularly updated in response to actual progresson tasks, amongst other things. This is only possible if you invest effort inmonitoring progress. This, in turn, requires the establishment of a reportingschedule and the designation of individuals responsible for updating progressdata. The reporting schedule might be as simple as weekly team meetingsfor a small project, whereas larger projects might involve substantial reportdocumentation 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 identifyingthe completion percentage for each outstanding task on the plan. Along withscheduling aspects of the plan, a real project will also have cost estimates for eachtask. We will look at costing in Chapter 11. For now, though, it is sufficient tonote that budget monitoring is also important, comparing planned developmentcosts against actual expenditure. A final aspect of project monitoring involvesattention to risks. Have previously unforeseen risks emerged? Have previouslyanticipated risks occurred or been avoided? All of this information affects yourongoing management of the project.

5 Project ControlNow that you have a plan and you are monitoring your progress against thatplan, 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 andreassigning resources so as to keep progress on track. If critical tasks are takinglonger 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, thisshould 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 thecritical path.

3. Rework the task breakdown so as to decouple activities — i.e., produce moreparallel tasks. This can often be done by decomposing larger tasks intosmaller sub-tasks, some of which may be able to run in parallel. Reducingdependencies allows tasks to be performed more quickly, subject to theavailability of sufficient resources.


4. Consider outsourcing some critical tasks. Of course, this usually adds tothe cost of development, but delays may be more costly to the success ofthe product in the long run.

5. Analyze “safety margins” that have been built into your time estimatesfor the remaining tasks. If there are a large number of sequential tasks,each with safety margins in their duration estimates, the expected projectcompletion time may be overly pessimistic. In this case, aggregating safetymargins may provide a more realistic estimate of the time remaining tocomplete the project, which then affects other decisions.

6. Consider commencing a task before the completion of some other task, onwhich it depends. In practice, this is often possible, because partial resultsfrom a predecessor may be sufficient to get the next task going. Of course,this approach increases the risk that resources are wasted, since somework done on a sequentially dependent task may be wasted if unexpectedoutcomes later emerge from a task on which it depends. For example, youcould start the system design phase before concept generation is complete— in fact, this usually happens. There is, however, a risk that new conceptswill be developed which render early system design work invalid.

6 Roles, Perspectives and ReportingIt is all very well to think of planning and monitoring in an abstract sense, butin practice, the way people respond to the needs and developments of a projectwill depend on their perspective. For example, the design engineer, immersedin the technical challenges of the design problem, is less likely to see budgetoverruns as a serious problem. Promotions executives might be particularlyconcerned about delays in the project’s completion date, but less worried aboutspecific 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 5illustrates the perspectives associated with these roles, and the tensions whichexist between them. In a consulting engineering firm, the client is usually easyto identify — this is the customer who approaches the company with a problemto 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 reasonableto assign consumers are direct role in the project management process. It isbest to view the client as that segment of the organization (or a third partyorganization) which is most immediately affected by the output of the productdesign process. In a large electronics manufacturing company, clients for a de-sign project would typically be manufacturing centres and product promotionsdepartments.The project director fits between the client and the project manager, as

suggested by Figure 5. The project manager will naturally be deeply involved


client project director project manager

• Most immediately affectedby project outcomes

• Takes the perspective ofthe client, at least in part

• Reports to the client –e.g., major design reviews

• Plans, monitors andcontrols all aspects of theproject

• Reports regularly to theproject director

• May report directly to theclient

client project director project manager

• Most immediately affectedby project outcomes

• Takes the perspective ofthe client, at least in part

• Reports to the client –e.g., major design reviews

• Plans, monitors andcontrols all aspects of theproject

• Reports regularly to theproject director

• May report directly to theclient

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 isresponsible for taking a more objective view, incorporating the perspectives ofthe client. The project director and/or project manager also provide progressreports and consult with the client on matters related to project progress andcontrol, but this is less frequent and usually less detailed than the interactionbetween 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 oflimited 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 foryou to designate one team member as the project manager, rather than simplydistributing the role equally. This does not mean that only that individual willplan and monitor tasks and report to the board. It does, however, mean thatat least one individual will take responsibility for ensuring that these activitiesactually occur.

chapter5 project-management

Documents