Chapter5 project-management

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

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

c

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 diﬃculties 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 ﬁnd 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.

c

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.

c

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

c

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

c

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.

c

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

c

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.

c

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

c

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 ﬁnal 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.

Chapter5 project-management

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Chapter5 project-management

Similar a Chapter5 project-management (20)

Más de Vin Voro

Más de Vin Voro (20)

Chapter5 project-management