Project Management

21/07/2014
1
School of Electrical and Electronic
Engineering
Project Management
for
Electrical Engineering
&
Sustainable Energy Sustainable Energy
3024 & 3029
f G Mr. Alfio Grasso
Office i3.58
alfio.grasso@adelaide.edu.au g @
School of Electrical and Electronic Engineering
Project Management
3024 for Electrical Engineering
3029 for Sustainable Energy
Mr. Alfio Grasso
UNIT 1 - Project Management
1
Mr. Alfio Grasso
Office i3.58
alfio.grasso@adelaide.edu.au
Table of Contents
Definitions .......................................................................3
Teamwork 24 Teamwork ...................................................................24
Team Definition .............................................................29
Effective Teams ............................................................35
Development Stages ....................................................40
Group Rules .................................................................47
TeamTips .....................................................................51 Team Tips .....................................................................51
Effective Meetings ........................................................64
Decision Making ...........................................................70
Conflict ..........................................................................74
2
Project
A TEMPORARY ENDEAVOUR
UNDERTAKEN TO CREATE A
3
UNDERTAKEN TO CREATE A
UNIQUE PRODUCT OR SERVICE
PROJ ECT DEFINITION
Has a defined beginning
Has a defined end
Makes use of resources allocated to the project
People, Time, Money
Produces a unique outcome
Follows a planned, organised approach
Usually involves a TEAM of people
and
4
and
Has a unique set of stakeholders
Each with differing expectations
Project Management
Application of
Knowledge, Skills, Tools, Processes
To Achieve Objectives
Cost, Time, Quality, Acceptance
5
Our Project
3024 & 3029 ALL held in 3
rd
year labs,
EM305/318/319
3024 - Robot based project
36 hrs practical scheduled
3029 => Power Systems based project
36 hrs practical sched led
6
36 hrs practical scheduled
PMEE Project: Robot Project
The project will be to The project will be to
build and program a
robot rover to follow a
sequence of movement
commands.
The robot is a two-
7
The robot is a two
wheeled rover based on
a microcontroller.
The Project is about
Project Management
NOT
Project to build a robot!
Students will undertake the project in
groups.
The main objective of the project is for
students to practise the project
management methods and techniques and
gain technical skills in developing an
8
gain technical skills in developing an
embedded electronic product.
PMSE Power Project
The project will be to The project will be to
design and build a
Photo-voltaic power
analysis system.
9
Project - Groups
Students will work in groups of four.
You can choose your own groups. y g p
Project Blank group list, at the end of the lecture Select
your class.
Enter a group number next to each member of your
group, 1 to 25.
I will review group membership and re-issue before the
practical on Wednesday.
Once you have confirmed your group membership you
10
Once you have confirmed your group membership you
should meet with other members of your group and
commence work on the project.
You and your group members are required to submit the
Project Group Ground Rules Contract Form to the
teaching team by Friday 1
st
August 2014 3:00 pm.
Project Planning
Project plan, due by 22
nd
August 2014 must include
a Gantt Chart
A copy MUST be emailed to me!
Software can be developed in parallel, it is NOT
recommended that a serial approach be taken.
Allocate tasks to group members
EACH MEMBER MUST DEMONSTRATE WORK IN
11
C US O S O
SOFTWARE Development
Schedule
Lectures (10 in total)
Mondays 2 to 3 pm, MawsonLabs G19 MawsonLecture Theatre
Mondays 4 to 5 pm, Napier G03
Tutorials (5 in total)
Take a lecture spot
Practical Sessions
Tuesday 9 to 12:00 noon (First one starts at 9:10 in EM319, dont
be LATE!)
12 formally scheduled
Last one is for demonstration
All ti l t b h ld i EM305/318/319
12
All practicals to be held in EM305/318/319
Practical Sessions for PMSE in EM305/318/319
Schedule.xls
NOTE: No week 13 activities
PMEE/PMSE Assessment
Team project (60%)
Written examination (40%). ( )
The project work shall be performed during the
semester; the written examination shall be held in
November.
The project work marking scheme:
Documentation (30%)
Project Plan
Software Design Document
P j t R t
13
Project Report
Project management, monitoring and progress reporting (15%)
Project D delivery, demonstration and presentation (15%)
Project Deliverables
& Assessment (60%)
Deliverable Deadline Marks
Project Plan
Tuesday, 22
nd
August @ 3.00 pm
10% Project Plan
y, g @ p
10%
Project Software Design & Test Plan
Document
Tuesday, 19
th
September @ 3.00 pm
10%
Project Final Report
Friday, 31
st
October @ 3.00 pm
10%
Project Product and Demonstration
Tuesday 28
th
October 9:00 am
15%
Project Performance 15%
14
Exam
Project Management is about understanding the
clients requirements and interpreting them clients requirements and interpreting them,
formulating a plan of action.
I will only stay for 10 minutes after the reading
time.
If you dont understand something in the exam,
state your assumption d th k f
15
state your assumption, and then work from
that assumption. The assumption must be
appropriate.
Assumptions
Clients are not always clear on their instructions.
By stating your assumptions the client has the By stating your assumptions the client has the
opportunity to correct a misunderstanding. It is
always best to get those assumptions down in
writing as soon as possible.
16
Life Experience
In project management there are
ti lti l t d sometimes multiple correct answers, due
to assumptions. Those assumptions are
different because of difference in
experience (lifetime experiences) of
different project managers.
17
Real Life
Project Requirements can change
Clients (Customers) change their minds
Customers are always right
Your Practical Tutors are your clients
They will be difficult, they will test you, but
18
they are there for assistance as well.
Weekly Individual Time Sheets
Students must submit their individual weekly
time sheet every week until the final submission y
of the project.
Submit your time sheets to your MyUni group
folder using the Weekly Time Sheets template.
Individual weekly time sheets shall be submitted
by 12:00 noon every Monday.
A final individual summary time sheet shall
19
y
contain the total time spent in each category,
and be submitted by 4.00 pm on Friday 31
st
October, 2014
Fortnightly Meetings
Your group will meet the teaching team fortnightly.
The meeting will take place during your practical session.
Th i i dt th ti d d d it The group is required to prepare the meeting agenda and deposit
the agenda onto your group folder in MyUni for all participants to
access one working day before the meeting.
The Agenda MUST include an updated Gantt Chart
either Microsoft Project, Excel, or hand drawn (scan & distribute)!
The meetings must be fully minuted, and the minutes must be
posted to your MyUni group folder within one working day after the
meeting.
The meeting is usedas a mechanismfor the teachingteamto
20
The meeting is used as a mechanism for the teaching team to
assess your progress and a forum for you to seek guidance from the
teaching team.
Helpful Hints in running the client meetings
The Chair should ensure that all team members are prepared and
ready BEFORE the scheduled start of the meeting
The Chair should open the meeting
The secretary should provide hard copies of the previous meeting
minutes (if there was a previous meeting) and the Agenda to the
clients
Chair should control the meeting. You must finish the meeting in the
allocated time!
The Chair should CLEARLY introduce each member.
The Chair should invite each member to speak, in the order as
outlined in the agenda
The Chair should use the agenda to guide them through the
meeting, dont change the order in the meeting, unless you have a
very good reason, e.g. a person is absent!
21
Hints Continued
Each person should summarise what they did in the previous period
and what they are going to do in the next period
All participants should plan what they are going to say, maybe have
some notes, BUT J UST DONT READ THE NOTES!
Dont argue amongst yourselves, this does not instil confidence
Support your Chair
The Chair should
Highlight milestones achieved
Advise of upcoming milestones p g
Dont ask technical questions, these can be asked after the meeting
has closed
The Chair should formally close the meeting, and now the clients
become tutors and technical questions can be asked!
22
Course Assessment
Examination
40%
1.5 hour duration
Project
60%
No replacement assessment available
23
No replacement assessment available
YOU MUST participate in your project group
TEAMWORK
24
Unit 1: TEAMWORK
Learning Objectives
When you have completed this unit you will
be able to
identify some of the factors that make a team
effective
understand the dynamics of teamdevelopment
25
understand the dynamics of team development
and
understand conflict resolution process
Groups/Teams
26
Groups and Teams
The terms group
and team are and team are
often
interchangeable.
Not all groups are
teams.
Howto tell the
27
How to tell the
difference?
Group Team
Strong clear focus leader Shared leadership roles Strong clear focus leader Shared leadership roles
Individual accountability Individual & mutual accountability
The groups purpose is the same as the
broader organisational mission
Specific team purpose that the team
itself delivers
Individual work-products Collective work-products
Run efficient meeting Encourage open-ended discussion and
active problem-solving meetings
28
Measure its effectiveness indirectly by
its influence on others
Measure performance directly by
assessing collective work-products
Discusses, decides & delegates Discusses, decides & does real work
together
Source: Katzenbach and Smith, 1993.
Definition of a TEAM
29
Team - Definition
Four Categories
Pseudo Team
Potential Team
Real Team
High Performing Team
30
Source: Smith, K.A.: Teamwork and project management, second edition
Pseudo Team
Assigned to work together, but they have no interest in
doing so. g
Believe that they will be evaluated individually
While they talk to each other they are competing
They see each other as rivals who must be defeated
Block, interfere with others learning
Hide information
Mislead and confuse each other
31
Mislead and confuse each other
Distrust.
This group would achieve more if they worked alone
Potential Team
Assigned to work together, and accept it.
Still believe that they will be evaluated as Still believe that they will be evaluated as
individuals
Seek information, but have no motivation to
teach what they know
Helping and sharing is minimised
Some seek a free ride, on the work of others
32
Some seek a free ride, on the work of others
The conscientious members feel exploited
The sum of the whole is potentially greater than
individuals
Real Team
Assigned to work in group, and believe that the
tasks require diversity tasks require diversity
Success depends upon all efforts
Group format clearly defined
Goal to maximise all members learning
Members individually and collectively accountable
Members do the work
33
Teamwork skills
Analyse their effectiveness
Continual Improvement Processes
High Performance Groups
Same characteristics as for a REAL TEAM
L l f it t t th d Level of commitment to the group and
each other
Trust each other
Respect each other
Mutual concern for each others personal
th
34
growth
Unfortunately such groups are Very
RARE!
Effective Teams
35
Effective Teams
To be most effective, teams need to do
t thi ll two things very well:
Accomplish the task
Get better at working with one another.
Both of these require leadership
not just froma single person acting as a
36
not just from a single person acting as a
leader but from every member contributing to
the leadership of the team.
Characteristics of Effective Teams
Positive interdependence
The teamfocuses on a common goal or single The team focuses on a common goal or single
product.
Individual and group accountability.
Each person takes responsibility for both her or his
own work and the overall work of the team.
Promotive interaction
37
Promotive interaction
The members do real work, usually face-to-face.
Teamwork Skills
38
Teamwork skills
Each member has the skills for and practises Each member has the skills for and practises
effective communication (especially careful listening),
decision making,
problem solving,
and conflict management.
Group processing
The teamperiodically reflects on howwell the teamis
39
The team periodically reflects on how well the team is
working.
Celebrates the things that are going well
Problem-solves the things that arent.
Sources: Katzenbach and Smith, 1993; K.A. Smith, 2004.
Team Development Stages
40
Team Development Stages
There are distinct differences in the way a team
acts and interacts at the beginning middle and acts and interacts at the beginning, middle, and
end of a project. The team development can be
decomposed into 5 stages:
Forming.
Storming.
Norming.
41
Norming.
Performing.
Mourning.
TD Stage: Forming
Members get to know one another and
t t t l t k t th i th start to learn to work together in the
forming stage.
Because the team is new, many members
tend not to voice their opinions, instead
allowing more assertive personalities to
42
allowing more assertive personalities to
take the lead.
TD Stage: Storming
During the storming stage, the team tests
it lf T b fid t itself. Team members are more confident
now, challenging assumptions, expressing
disagreements, voicing opinions.
43
TD Stage: Norming
During the norming stage, team members
b i t ttl d i t th i ti begin to settle down into their respective
roles, managing conflicts and reaching
some agreements, both spoken and
unspoken, regarding their roles.
Communicationimproves.
44
Communication improves.
TD Stage: Performing
This stage reveals a mature teamthat has
dth h th i t moved through the previous stages
successfully.
Team members can execute their roles in
the project at a high level of achievement.
45
TD Stage: Mourning
The group dissolves during the mourning
t stage
46
Group Rules
47
Organisation - Group Norms
A common way to promote
more constructive and
productive teamwork is to
have a team create a set of
guidelines for the group,
sometimes called group
norms.
The example listed in the next
2 slides was adopted fromthe
48
2 slides was adopted from the
Boeings training manual for
team members
Code of Cooperation
Every member is responsible for the teams progress
and success.
Attend all team meetings and be on time.
Come prepared.
Carry out assignments on schedule.
Listen to and show respect for the contributions of other
members;
be an active listener.
Constructively criticise ideas not persons
49
Constructively criticise ideas, not persons.
Resolve conflicts constructively.
Pay attention; avoid disruptive behaviour.
Avoid disruptive side conversations.
Code of Cooperation, Cont
Only one person speaks at a time.
Everyone participates; no one dominates Everyone participates; no one dominates.
Be succinct;
avoid long anecdotes and examples.
No rank in the room.
Respect those not present.
Ask questions when you do not understand.
50
Attend to your personal comfort needs at any
time, but minimise team disruption.
Have fun.
Source: K.J . Smith, 2004
Tips for working in a TEAM
51
* Source: Randy Pausch, for the "Building Virtual Worlds" course at Carnegie Mellon, Spring 1998.
Meet people properly
It all starts with the introduction.
Then exchange contact information
Make sure you know how to pronounce
everyone's names.
52
Exchange phone numbers
find out when it is acceptable to call.
Do you know the first name of
everyone in this room?
If not make a point to introduce
lf BEFORE t
53
yourself, BEFORE our next
lecture!
Find things you have in common
You can almost always find something in
common with another person.
Starting from that baseline, its much
easier to then address issues where you
have differences
54
have differences.
If nothing else, you probably have in
common things like the weather.
Make meeting conditions good
Have a large surface to write on
Make sure the room is quiet and warm
enough
Ensure that there aren't lots of distractions.
Make sure no one is hungry, cold, or tired.
55
Meet over a meal if you can;
Food softens a meeting.
That's why they "do lunch" in Hollywood.
Let everyone talk
Even if you think what they're saying is
t id stupid.
Cutting someone off is rude, and not worth
whatever small time gain you might make.
Don't finish someone's sentences for him
or her; they can do it for themselves
56
or her; they can do it for themselves.
Remember: talking louder or faster doesn't
make your idea any better.
Check your egos at the door
When you discuss ideas, immediately
label them and write them down.
The labels should be
descriptive of the idea,
not the originator
57
not the originator.
Praise each other
Find something nice to say, even if it's a
t t h stretch.
Even the worst of ideas has a silver lining
inside it, if you just look hard enough.
Focus on the good, praise it
Thenraise any objections or concerns you
58
Then raise any objections or concerns you
have about the rest of it.
Put it in writing
Always write down who is responsible for
h t b h what, by when.
Be concrete.
Arrange meetings by email, and establish
accountability.
Never assume that someone's roommate
59
Never assume that someone's roommate
will deliver a phone message.
Politics
Also, remember that "politics is when you
h th 2 l have more than 2 people
Always copy any piece of email within the
group, or to the lecturer, to all members of the
group.
This rule should never be violated.
60
Don't try to guess what your group mates
might or might not want to hear about.
Be open and honest
Talk with your group members if there's a problem,
and talk with me if you think you need help. a d ta t e you t you eed ep
The whole point of this course is that it's tough to
work across cultures.
If we all go into it knowing that's an issue, we should
be comfortable discussing problems when they
arise.
after all that's what this course is really about
61
after all, thats what this course is really about.
Be forgiving when people make mistakes.
Don't be afraid to raise the issues when they come
up.
Avoid conflict at all costs
When stress occurs and tempers flare, take a
short break short break.
Clear your heads, apologise, and take another
stab at it.
Apologise for upsetting your peers, even if you
think someone else was primarily at fault;
the goal is to work together, not start a legal battle
h t i
62
over whose transgressions were worse.
It takes two to have an argument, so be the
peacemaker.
Phrase alternatives as questions
Instead of
" I think we should do A, not B,"
try
" What if we did A, instead of B?"
That allows people to offer comments
63
That allows people to offer comments,
rather than defend ones choice
Effective Meetings
Meetings are a principal way of
k i th t b t
64
keeping the team members up to
date.
Source: K.J . Smiths Teamwork and Project Management, adapted from Meetings, Bloody Meetings, starring J ohn Cleese,
1993.
Plan the Meeting
Be clear on objectives of the meeting
Be clear why you need the meeting
List the topics to be addressed
65
Inform
Make sure everyone knows exactly what is
b i di d h d h t t being discussed, why and what you want
from the discussion
Anticipate what people and information
may be needed and make sure they are
there
66
there
Prepare
Prepare the logical sequence of
items
Allocate time on the basis of
importance, not its urgency
67
Structure and Control
Put all evidence before
interpretation and action
Stop people from jumping back
and going over old ground
68
Summarise and Recall
Summarise all decisions and
record them with the name of the
person responsible for any action
69
Decision Making
70
Decision Making
Making decisions and providing information so that others can make
decisions are two of the most important and common activities of
practisingengineers practising engineers.
The starting point involves the determination of whether a decision
needs to be made, and what would happen if a decision was not
made.
The common steps in decision-making process are:
Frame
Decide what you are going to decide and what you are not going to
decide.
Gather intelligence
71
g
Gather real intelligence, not just information that will support your
biases.
Develop alternatives.
Evaluate alternatives, and
Come to conclusion
Team decision making
Determine how your team will act on the intelligence it
gathers, and select the best alternative(s). g ( )
Learn from experience
Evaluate and feedback concerning how well the decision
process is implemented.
Team members project decisions often made through an
interaction process.
There is evidence that a team will make better decisions
72
on the project than an individual.
There will likely be a greater support and motivation to
support the decision.
However, there are cost and risks to consider.
Team Decisions - Risks
The decision process may take too long to complete especially if the
team members are not working in close proximity.
Because time is usually a valuable resource teamdecision can be Because time is usually a valuable resource, team decision can be
costly.
There is a tendency that a strong individual of the project team can
interfere with effective team decision-making by dominating the
discussions and the decision making process.
The project leader can minimise the individual dominance risk by:
encouraging every team member to express doubts and criticisms of
proposed solutions
breaking the team into sub-teams to analyse the decision, and then
having the sub teams confront one another to examine their differences
73
having the sub-teams confront one another to examine their differences,
and
having the team discuss how they feel about how the decision process
is being carried out.
Conflict
74
Managing Team Conflict
Inevitably, differences in personality will cause
tension and conflict in your project team. y p j
Although conflict is not necessarily bad, it is an
issue that has to be resolved by the team leader
and the members.
A necessary first step is to analyse the source of
conflict carefully and objectively.
Is the conflict:
75
Misunderstood instructions or priorities?
A difference in work styles?
A basic incompatibility of management styles and
team member expectations?
Conflict prevention
Preventing conflict is the most effective method
of handling situations that can generate conflict of handling situations that can generate conflict.
The project leader must ensure that all team
members understand what is expected of them
and that they are familiar with the project plan.
The project leader should also ensure project
teammembers understand the top level of the
76
team members understand the top level of the
projects objectives and the concept for
executing the project.
Conflict resolution
A process that can help to resolve conflict on a
project teamincludes the following: project team includes the following:
Gather and have a full understanding of the facts
around which the conflict has occurred.
Effort should be made to reach agreement on what
the real issue(s) are at the base of the conflict.
Potential impact on the projects work or the project
team members should be determined.
77
Carefully identify the alternatives, and consider their
relative costs and benefits.
The team should come up with appropriate
recommendations, identifying options if required.
Useful tips
Separate the problem from the person wherever
possible. p
People who feel personally attacked close their ears and will
refuse to listen to possible solutions.
Listen to the other side.
It is vital to hear what others involved in the conflict have to say.
Propose a solution.
If it is a change in behaviour on the part of a member or
members put it in writing
78
members, put it in writing.
If it is an improvement in quality of work, be very specific as to
what the team wants to see and when the team expects to see it.
Be specific as to what the consequences are for failure.
Useful tips Cont
Praise
Make certain to praise those who participated
in the resolution of the conflict.
Last resort
If a team is unable to resolve the conflict on its
own, then a resolution should be sought from
79
g
higher level managers.
only after the above attempt
at least two solutions have been discussed
Teamwork Challenges and
Problems
Members who dont show up for meetings or
who showup unprepared who show up unprepared
Members who dominate the conversation
Members who dont participate in the conversion
Time wasted by off-task talk
Members who want to do the entire project
80
themselves because they dont trust others
Group meeting scheduling difficulties
Challenges and Problems Cont
No clear focus or goal
Lack of clear agenda Lack of clear agenda
Subgroups excluding or ganging up on one or
more members
Ineffective or inappropriate decisions and
decision-making processes
Suppression of conflict or unpleasant flare-ups
among group members
81
among group members
Members not doing their fair share of the work
Lack of commitment to the groups work by
some members
Addressing group problems
The problems on the previous 2 slides are
l t db t d t ( d commonly encountered by students (and
professionals) working in teams and
groups.
The following process is widely used to
address group problems.
82
address group problems.
Step 1:
Id tif i h ll diffi lti d Identifying challenges, difficulties and
barriers to effective group work
Develop an individual list of challenges, barriers and
difficulties by each group member
Share the individual lists and create a joint list that
includes at least one item from each member
83
Be realistic and specific
Work cooperatively.
Step 2:
Address challenges, difficulties and barriers Address challenges, difficulties and barriers
Have each group member select one item from the
joint list
Make sure all members have a common
understanding of what the item means
Identify three possible actions that will eliminate the
barrier
Prioritise the possible solutions:
84
Prioritise the possible solutions:
Plan A, Plan B, Plan C
Focus on what will work; be positive and constructive
Implement the solutions; report back; celebrate and
extend the ones that are effective.
The format/process of
problem identification, p obe de t cato ,
problem formulation,
followed by problem solving
does not guarantee that your teamwork
experiences will be free of trouble.
But having a format/process for getting the
problems out on the table and then dealing with
85
p g
them in a problem-solving manner usually
reduces the frustration of group problems.
Source: K.J . Smith, 2004
First deliverable First deliverable
Friday 12:00 NOON
86
Group Ground Rules
Contract Form
The project group ground rules describe the general responsibilities of every member to the group. You
can adopt additional ground rules if your group believes they are needed. Your signature on this
contract form signifies your commitment to adhere to these rules and expectations.
All group members agree to:
Come to class andteammeetings ontime Come to class and team meetings on time.
Come to class and team meetings with assignments and other necessary preparations done.
Additional ground rules:
1.
2.
If a member of the project team repeatedly fails to meet these ground rules, other members of the group
are expected to take the following actions:
Step 1:(fill in this step with your group)
If not resolved:
Step 2: Bring the issue to the attention of the teaching team.
If not resolved:
Step3:Meet as a groupwith the teachingteam
87
Step 3:Meet as a group with the teaching team.
The teaching team reserves the right to make the final decisions to resolve difficulties that arises within
the groups. Before this becomes necessary, the team should try to find a fair and equitable solution to
the problem.
Group Number:
Members Signature
1. 3.
2. 4.
Source: K.J . Smith, 2004 -- adapted from a form developed by Dr D. Allen, University of Delaware.
References
Cleland, D.I., Ireland, L.R.: Project manager's portable
handbook. McGraw Hill, 2000.
Covey, S.R.: The seven habits of highly effective
people. Simon and Schuster, 1989.
Hughes, B., Cotterell, M.: Software project management.
3rd ed, McGraw-Hill, 2002.
Katzenbach, J .R., Smith, D.K.: The wisdom of teams:
creating the high-performance organization.
HarperBusiness, 1994.
88
Pausch, R.: Tips for working successfully in a group.
Smith, K.A.: Teamwork and project management. 2nd
ed, McGraw-Hill, 2004.
School of Electrical and Electronic Engineering g g
PROJ ECT LIFECYCLE
Mr. Alfio Grasso
Offi i3 58
92
Office i3.58
Table of Contents
Project structure ....................................95
Successful Projects .............................100
Project Lifecycle ..................................107
Feasibility Study ..................................112
Development Lifecycle ........................116
Water Fall Model .................................129
V-Shaped Model ..................................134
Spiral Model .........................................141
93
Learning Objectives
Unit 2: PROJ ECT LIFECYCLE
Wh h l t d thi it When you have completed this unit you
will be able to:
identify the essential structure in a project
recognise factors that contribute to a
successful project
d
94
and
select appropriate models for developing
projects
Project Structure
95
Projects Essential Structure
A project has the following essential structure:
Goal.
It has a clearly defined goal or problem that needs to be
solved. The problem can be the design of a product, or it
can be a non-tangible decision to make.
Scope.
The process may be the design of the product, or it may
be the research and evaluation of information required to
make a decision.
96
Complex.
It contains structure of some complexity. The structure of
your project may include multiple steps and will often have
sub-steps
Structure Cont
One-time completion.
The one-time characteristic differentiates project e o e t e c a acte stc d e e tates p oject
activities from daily tasks in that they are not habitual
and are done only once (for a particular problem,
goal, or product you are working on).
Uniqueness.
No two projects are alike, regardless of how routine
they are to the organisation. Each one is
characterised by some degree of customisation.
97
y g
Product.
It results in a product. The end result of the project will
either be a physical product (eg, a detailed research
report) or an intangible (eg, a decision to make).
Example
You wish to purchase a farewell gift for a friend.
Using the formal structure to characterise the g
project.
Goal: purchase a farewell gift for a friend.
Scope: Decide on a suitable gift, then shop to find it.
Complexity: To find a suitable gift, you should be
familiar with your friends tastes. Gift should be nice
but affordable.
Completion: Limited to this farewell occasion
98
Completion: Limited to this farewell occasion.
Uniqueness: You will not buy the same gift for the
same person again.
Product: A suitable gift that is wrapped and ready to
give.
Exercise
Apply the formal structure of a project to
an example of organising a birthday dinner an example of organising a birthday dinner
for your good friend.
Goal:
Scope:
Complexity:
Completion
99
Completion:
Uniqueness:
Product:
Successful Projects
100
Keys to Project Success
Some Engineering Activities
Design, es g ,
problem solving,
and product development
A project is successful if it
achieves something desirable, planned, or attempted
Success if the project is
on time delivery
101
on time delivery
within budget
meeting performance specifications and requirements
receiving client acceptance.
Success
a small portion of space
102
Meeting these four requirements requires good
understanding of what to plan and how to realise the plan.
We will explore in later units good practices used in
product development and what is involved in electronics
design process.
Project Lifecycle
103
Project Lifecycle
Projects go through distinct phases, as:
Defining,
Planning,
Implementing, and
Completing.
104
Defining the project
Th f thi h i The purpose of this phase is
to determine if a project is feasible.
You may need to justify the project and
define the values in terms of cost and
benefits
105
benefits.
Planning the project
The focus in the planning phase is
to define the goal (what),
to decide the approaches to take (how),
to work out the schedule (when) and
to determine the resources required (how
much) for the project.
106
) p j
The project plan is the roadmap for the
project to reach its predefined goal
Implementing the project
The focus is
to execute the Project Plan and to execute the Project Plan and
control any deviations to that plan.
Actual tangible work (e.g., design, implement,
evaluate, manufacture) takes place.
As changes occur, risks are identified, and
issues arise, the project team and project leader
107
are expected to
evaluate the impact and
make the decisions required to ensure a favourable
project outcome and results.
Completing the project
In the closing phase,
the project is handed over to the client.
In addition, this is an opportunity
to consider what the team may have done
differently and
share that insight with the organisation.
108
share that insight with the organisation.
The ability to make changes varies over
th j t lif l Th t i t d the project lifecycle. The cost associated
with these changes also varies.
Ability to
change
Cost to
change
109
Defining
Planning
Implementing
Completing
Remarks
You have more flexibility early in a project and it
is cheaper to make changes then so dont is cheaper to make changes then, so dont
skimp on planning during the early stages
As the project progresses into the later part of
the lifecycle, monitoring (of activities and risks)
and control (when changes occurred etc)
become more important.
Th f j t i d t i d l l
110
The success of a project is determined largely
by its planning process and its monitoring and
controlling process
Some key questions
At various stages of the project include:
Is the teamdoing hat it needs to do? Is the team doing what it needs to do?
Is the project on time, and within budget?
Are the key resources in place?
Is the client happy?
Is the team happy?
111
Answering these questions will help to do
the work that needs to be done to
complete the project.
Feasibility Study
Pre-project
112
Feasibility Study
After the initial concept of idea, it may be
t f f ibilit t d necessary to perform a feasibility study,
before embarking on a project.
Investigation to determine if it is worthwhile
proceeding with the project
Information gathered
113
Clients Requirements
Development and Operational Costs
Benefits are Estimated
Feasibility Report
At the conclusion of the feasibility study, a report
is provided to stakeholders detailing amongst is provided to stakeholders detailing amongst
other information the following:
Introduction
Identify what the document is
Problem Description
Proposed Developments
114
p p
Business and Financial Aspects
Technical Aspects
Organisational Aspects
Feasibility Report
Proposed Developments Cont
Estimated Costs
Development Costs
Operational Costs
Envisaged Benefits, and
Recommendations
115
Development Lifecycle
116
Lifecycles
There are two distinct lifecycles at work in
a project:
The Project lifecycle
The Systems Development lifecycle
117
The Systems Development lifecycle
The Project Lifecycle
E ll th j t ti iti Encompasses all the project activities
Planning,
Administration, and
Leadership.
Those activities necessary to ensure that
118
Those activities necessary to ensure that
plans and processes are in place to ensure a
smoothly running project.
Systems Development lifecycle
Focuses on the technical aspects of
d i th j t d li bl producing the project deliverables.
These will be investigated in a future unit.
119
Both Needed
It is incorrect to assume that either the
j t lif l th t project lifecycle or the systems
development lifecycle is sufficient by itself.
Both are needed to successfullymanage
any project.
The project lifecycle and the systems
120
development lifecycle models have
overlapping activities.
Project/Development Lifecycle
121
Projects Lifecycle activities
Initiation phase
gathering data
identify project requirements
establish project scope
develop high level WBS*
estimate resources
122
estimate resources
* WBS =Work Breakdown Structure, discussed in the next Unit
Planning phase
assemble project team
develop detailed WBS
develop network analysis
develop budget and schedule estimates
write project plan
123
write project plan
kickoff project
Monitor and control
set up project organisation
set up and execute work packages
direct, monitor and control project
124
Closing the project
conduct technical and financial audits
obtain customer acceptance
prepare transfer responsibility plan
evaluate and document results
close project
125
close project
Customer service and system
i t maintenance
transfer project responsibility
follow-up with customer
126
Modelling Lifecycle
127
Modelling Systems/Product
Development Lifecycle
Managing a project involves complex planning
and control.
As in any control system, a good model can
provide insight into what processes are involved
and how these processes can be better
controlled to help achieving the project goal.
Engineers love models.
A number of models exist:
128
Waterfall
V-Shaped
Spiral
Waterfall
129
The Waterfall Model
The waterfall model, or the linear
ti l d l t t ti sequential model, suggests a systematic,
sequential approach to product
development that begins from top to
bottom.
130
The Waterfall Model
131
Splash Back
Splash back are the arrows pointing
upwards and backward upwards and backward.
This indicates that a later stage may
reveal the need for some extra work at an
earlier stage, but this should be the
exception rather than the rule.
Aft ll th fl f t f ll h ld b
132
After all, the flow of a waterfall should be
downwards with the possibility of just a
little water splashing back.
The limited scope for iteration is in fact
f th t th f thi d l one of the strengths of this process model.
In a large project you want to avoid
reworking tasks previously thought to be
completed.
Havingto reopen completed activities play
133
Having to reopen completed activities play
havoc with promised completion dates.
V shape
134
The V-shape lifecycle model
The V-shaped model shows the sequential
project activities and a series of detailed project activities and a series of detailed
deliverables.
By specifying how to test deliverables
during the planning, this model enables
both the customer and the project team to
agree upon project behaviour and
135
agree upon project behaviour and
recognise when the project has reached
its conclusion.
136
The Customer Requirements phase
d t i th d f th t d determines the needs of the customer and
the tests that will be performed later during
the Acceptance Testing phase.
137
The Project Definition and Analysis
h i l d l i f th bl t phase includes analysis of the problem at
hand.
It concludes with a system specification
specifying the external behaviour of the
systemto be built, and test definition for
138
system to be built, and test definition for
the System Testing phase.
The High Level Design phase defines the
ll d i d th j t t overall design and the project components
to implement the design.
Details of the interface between project
components should be sufficient to allow
individual teammembers to work through
139
individual team members to work through
their own Implementation and
Integration and Testing phases.
Presenting the Deliverables near the end
f th j t h it th t of the project phase permits the customer
to perform Acceptance Testing where the
functionality of the system is compared
with the Project Requirements.
140
Spiral
141
Spiral model
In the spiral model (Boehm, 1988), the project
teamworks on multiple aspects of the project team works on multiple aspects of the project
simultaneously, incremental improving in each
area as the project, especially the design,
converges on completion.
The spiral model is well suited to model project
work involving both hardware and software
142
work involving both hardware and software
design, or complex design methodology as in
systems-on-a-chip design.
* Expanded view at back of
Unit Notes
143
Source Boehm 1998
Example
In Unit 6, we will use an electronics
t j t t l i i d t il th system project to explain in detail the
phases in the systems/product
development lifecycle.
144
Exercise
Use the waterfall, the V-shape and the
i l d l t d ib th spiral process models to describe the
development lifecycle of your robot
project.
145
References
Blanchard, B.S., Fabrycky, W.J .: Systems engineering and analysis.
3rd edition, Prentice Hall, 1998.
Boehm B W: A spiral model of software development and Boehm, B.W.: A spiral model of software development and
enhancement. IEEE Computer, vol 21, no 5, pp 61-72, 1988.
Hughes, B., Cotterell, M.: Software project management. 3rd edition,
McGraw-Hill, 2002.
Keating, M., Bricaud, P.: Reuse methodology manual for system-on-
a-chip designs. 3rd edition, Kluwer Academic Publishers, 2002.
Smith, K.A.: Teamwork and project management. 2nd edition,
McGraw-Hill, 2004.
Smith, M.R., Eberlein, A.: Changinga 4th year teamdesign project
146
Smith, M.R., Eberlein, A.: Changing a 4th year team design project
course to meet expectations from regular and returning internship
students. Session 1432, ASEE99, North Carolina, J une, 1999.
Sommerville, I.: Software engineering. 7th edition, Addison Wesley,
2004.
PROJ ECT PLANNING
Mr. Alfio Grasso
Offi i3 58
147
Office i3.58
Lecture 5 Lecture 6
Table of Contents
Work Breakdown Structure ........................................152
Network Analysis 166 Network Analysis ........................................................166
Precedence Diagram Method .....................................172
Activity of Arrow ..........................................................188
Gantt Chart .................................................................191
Project Planning ........................................................ 199
Project Plan ............................................................... 216 Project Plan ............................................................... 216
Cost Estimation ..........................................................233
Risk Management ...................................................... 237
Evaluating Risk ...........................................................244
148
Begin with the end in mind Begin with the end in mind
Stephen R. Covey
The Seven Habits of Highly Effective People
149
Learning Objectives
When you have completed this unit you
ill b bl t will be able to:
use project management methods and tools
for project planning
understand the project planning process, and
prepare a project plan
150
p p p j p
Four essential project management
tools are
work breakdown structure (WBS)
network analysis
Gantt (bar) chart
earned value analysis
151
Work Breakdown Structure
Lecture 4
152
Work Breakdown Structure
WBS allows a project manager to develop every
other tool needed to manage the project. g p j
It provides the basis for planning, scheduling,
budget and control of the project.
A WBS provides a structured way of
decomposing a large project into sufficiently
small enough chunks that can define resources
and time interval to perform with some degree of
fid
153
confidence.
There are two ways to represent a WBS:
Indented WBS format
Graphical WBS format
Indented WBS format
154
Graphical WBS format
155
Usually, a WBS is developed to the third
f th l l or fourth level
it rarely needs to be developed to the fifth
level.
156
Example - WBS
Source: adapted from Taylor, J ., 2004.
1.0 Information Software System
1 1Gap Analysis 1.1 Gap Analysis
1.1.1 Needs assessment
1.1.1.1 Survey state of current systems
1.1.1.2 Determine additional capability requirements
1.2 Requirements specification
1.2.1 Develop preliminary software specifications
1 2 2D l d t il d ft ifi ti
157
1.2.2 Develop detailed software specifications
1.2.3 Develop preliminary hardware specifications
1.2.4 Develop detailed hardware specifications
Example WBS Cont
1.3 System Engineering
1.3.1 Develop alternative software approaches p pp
1.3.2 Develop alternative hardware approaches
1.3.3 Develop cost estimates for each alternative approach
1.3.4 Determine best technical and most cost-effective
approach
1.3.5 Develop preferred system architecture
1.4 System Design
1 4 1Develop preliminarysystemdesign
158
1.4.1 Develop preliminary system design
1.4.1.1 Design software modules
1.4.1.2 Design hardware subsystems
1.4.1.3 Integrate systems
1.4.1.4 Develop detailed system design
Example WBS Cont
1.5 System Development
1 5 1Write code for systemmodules 1.5.1 Write code for system modules
1.5.2 Construct hardware subsystems
1.5.3 Develop prototype
1.6 Testing
1.6.1 Write test plans
1.6.2 Test units
159
1.6.2.1 Test code
1.6.2.2 Modify code
1.6.2.3 Test hardware
1.6.2.4 Modify hardware
Example WBS Cont
1.6.3 System testing
1 6 3 1Integrate system 1.6.3.1 Integrate system
1.6.3.2 Test code
1.6.3.3 Modify code
1.6.3.4 Test hardware
1.6.3.5 Modify hardware
1.6.4 Prototype tests
1.6.4.1Conduct prototype tests
160
1.6.4.1 Conduct prototype tests
1.6.4.2 Document test results
1.6.4.3 Modify module code/hardware
Example WBS Cont
1.7 Develop Production Model
1 7 1Develop production tests 1.7.1 Develop production tests
1.7.1.1 Conduct tests
1.7.1.2 Document test results
1.7.2 Conduct deployment
1.7.2.1 Deliver system
1.7.2.2 Install system
1 7 3M i t i t
161
1.7.3 Maintain system
1.7.3.1 Detect/correct faults
1.7.3.2 Modify/enhanced system
Example WBS Cont
1.8 Project Management
1 8 1Assign project manager 1.8.1 Assign project manager
1.8.2 Assign project engineers
1.8.3 Assign administrative assistant
162
Developing a WBS
Developing a WBS ensures that every project task is
identified.
If a task is not included in the WBS, it is not in the
project.
A simple approach used by Martin & Tate for creating a
WBS is to
gather the project team
provide team members with pad of sticky notes
k t b t it d ll th t k th thi k f
163
ask team members to write down all the tasks they can think of
have team members place their sticky notes on chart paper
and then
have members work together to rearrange them.
Past Exam Question
Past Exam Question on Gantt Chart
You are starting a renovation project at home, and want to apply the principles of project management to minimise disruption
t f il Th j t i t f ti th b th th d l b th i th h h ld Mi i i i to your family. The project consists of renovating the bathroom, the one and only bathroom in the household. Minimising any
impact on the schedule is crucial. You are the project manager and will be making use of contract labour (labourer, plumber,
electrician, tiler, painter, glazier, and cabinet maker) to undertake the project.
The bathroom is to be completely renovated. The existing fixtures in the bathroom need to be removed. The labourer has
indicated that this will take 1 day. Upon the removal of existing fixtures, three small jobs need to be undertaken, one is to
relocate pipes buried in the solid brick walls, the second is to provide new cabling for a combined heater/fan/light in the centre
of the ceiling and the third is the painting of the ceiling. All three jobs will take 0.5 days, and the first two can be performed in
parallel, while the third one must follow the electrical installation of the light. All of these 3 jobs must be completed beforetiling
can begin. The tiler has indicated that the complete tiling job is expected to take 6 days, 1 day to waterproof the wet areas, 4
days for tiling, and the last day for grouting.
The shower will be custom made, and can only be measured after all the tiles have been laid, but can be measured before the
164
grouting. Similarly for the vanity unit (cabinet), it will be custom made, and will go from wall to wall, and hence can only be
measured after the tiles have been laid. For the purposes of this exercise you can assume that the actual measurement takes
no time, but it can only be performed after all the tiles have been laid, i.e. just prior to the grouting stage. The shower cubical
will take 10 working days to manufacture and install. The shower cubical takes 1 day for the silicon to cure. The cabinet will
take 5 days, to manufacture and install, and also uses silicon to seal the wet areas, and hence 1 day to cure. After the cabinet
has been installed, the plumber can come back to fit all of the fittings, that activity takes 1 day.
Bathroom Renovation Project
Removal of Fixtures
Minor jobs pre-tiling
Relocate Pipes
New cabling
Paint Ceiling
Tilingg
Waterproof
Lay Tiles
Grout
Shower Cubical
Measure Shower
Manufacture Shower Cubical & Install
Silicon Seal Shower Cubical
Cabinet
165
Measure Cabinet
Manufacture Cabinet & Install
Silicon Seal Cabinet
Install Fittings
Network Analysis
166
Network Analysis
Network diagrams are tools used in project
schedulingto showtask relationships scheduling to show task relationships.
One common network technique is the
precedence diagram method (PDM).
It has its origin from the PERT
(performance evaluation & review
t h i ) di
167
technique) diagram.
Another form is the (CPM) Critical Path
Method
Network Models
Both PERT and CPM are activity-on-
(AOA) d l arrow (AOA) models
The network is visualised as activities drawn
as arrows, joining circles or nodes.
PDM uses an activity-on-node model
(AON)
168
( )
Activities are links and the nodes are events
of activities starting and finishing.
Example CPM (AOA)
169
Example PERT (AOA)
170
Example PDM (AON)
171
Precedence Diagram Method
AON
172
Activity on Node
Rules for AON
Only one start node
If more than 1 activity can start immediately, insert a dummy activity
startof 0 duration and 0 resource start of 0 duration and 0 resource.
Only one finish node
Less confusion, insert a dummy activity finish of 0 duration and 0
resource.
Nodes to have a duration
Links have no duration
Except for lagging activities
Example start an activity after the start of a parallel activity
Precedents are the immediate preceding activities
173
p g
Time moves from left to right
A network cannot contain a loop, and
A network cannot contain any dangles
Labelling Conventions
174
AON - Construction Rules
An AON is developed using the following 6 steps.
Estimate the duration of each task
Use the average-case duration - not the worst-case, nor the best-
case.
Tasks at risk, relative to possible unavailable resource numbers or
skills, should be planned with a contingency factor.
Determine task interdependencies
Consider each task in turn, and its relationship to every other task to
produce a precedence table.
Construct a precedence diagram
175
C p g
Conduct a forward pass
Conduct a backward pass, and
Determine the critical path of the project
Precedence table
176
Precedence Diagram
177
Forward Pass
The forward pass is carried out to calculate the earliest dates on
which each task may be started and completed.
The forwardpass and the calculation of earliest start dates is The forward pass and the calculation of earliest start dates is
calculated according to the rule that the earliest start date for a task
is the earliest finish date for the preceding task, and that where there
is more than one immediately preceding tasks, we take the latest of
the earliest finish dates for those tasks.
Thus,
A, B & F may start immediately, so the earliest to start is 0.
A takes 6 wks, so the earliest it can finish is wk 6.
For B &F, the earliest finishes are wk 4and wk 10, respectively.
178
For B & F, the earliest finishes are wk 4 and wk 10, respectively.
C can start when A has finished, so its earliest start is wk 6. It takes
3 wks, so the earliest finish is wk 9.
and so on.
Result after Forward Pass
179
Backward pass
Carry out a backward pass to calculate the latest
date at which each task may be started and date at which each task may be started and
finished without delaying the end date of the
project.
The backward pass rule is: the latest finish date
for a task is the latest start date for all the tasks
that may commence immediately when that task
is complete
180
is complete.
Where there is more than one task that can
commence, we take the earliest of the latest
start dates for those tasks.
Results after backward pass
181
FOR EXAMPLE
Assume D takes 5 weeks, THIS IS JUST FOR AN EXAMPLE ONLY!!!!!
182
Critical Path
There is at least one path that defines the duration of the
project.
This is known as the critical path.
Tasks that have equal earliest and latest times are
critical tasks.
Any delay to any task on this critical path will delay the
completion of the project.
Float, or Total Float (sometimes referred to as slack).
The difference between a tasks earliest start date and its latest
start date (or equally, the difference between a tasks earliest
andlatest finish date) is knownas the tasks float it is a
183
and latest finish date) is known as the tasks float it is a
measure of how much the start or completion of a task may be
delayed without affecting the end date of the project.
Any task with a float of zero is critical.
184
Activity Span
Difference between earliest start date and
l t t fi i h d t i k th ti it latest finish date is known as the activity
span
It is a measure of the maximum time
allowable for the activity
185
Free Float
While each task has a total float, sometimes >0,
it is not wise to rely on this float it is not wise to rely on this float.
Example, in the previous PDM, both A and C have 2
weeks float. If A uses its 2 weeks, C has no float left!
Free float
The time which an activity may be delayed without
affecting any subsequent activity.
186
g y q y
Difference between the earliest completion date and
the earliest start date of the succeeding activity
Interfering float
The difference between total float and free
fl t float.
Once the free float is used, the interfering
float is the amount by which the activity
can be delayed, without delaying the
project end date, even though it will delay
187
project end date, even though it will delay
the start of the subsequent activities.
Activity on Arrow
188
Activity on Arrow Rules
Only one start node
Only one finish node Only one finish node
Links have a duration
Nodes have no duration
Lagging activities represented with dashed
dummy links
Nodes are numbered sequentially
Ti f l ft t i ht
189
Time moves from left to right
A network cannot contain a loop
A network may not contain any dangles
AOA Labelling
190
Gantt Charts
Lecture 5
191
GANTT Charts
The WBS is the basis of all project schedules.
It decomposes the project into the required tasks and allows the p p j q
project team to estimate the duration of each task.
The precedence diagram provides a network showing the
earliest and latest start and end times for each task and for the
entire project.
With that information, Gantt charts can be prepared to show
graphically the project schedules.
Developed by Henry L. Gantt, c1917, the bar chart
h l d d t l f b f
192
shows planned and actual progress for a number of
tasks displayed against a horizontal time scale.
The chart is an effective communication tool because it
can portray a lot of data quickly to the interested parties.
Example
Per 1 Per 2 Per 3 Per 4 Per 5 Per 6 Per 7 Per 8
PROJECT PHASE
PREFEASIBILITY
FEASIBILITY
PLANNING
IMPLEMENTATION
HANDOVER
193
HANDOVER
CLOSE OUT
* Source Practical Project Management for Engineers and Technicians IDC Technologies, 2001
Gantt Charts
Bar Graph
Activities to be performed on the vertical axis
Time progresses on the horizontal axis Time progresses on the horizontal axis
Schedule Activities
Early Start
Each activity started as early as possible, without violating any activity precedence
Latest Start
Each activity is delayed as much as possible, without delaying the project finish.
The difference between the Earliest Start and Latest Start is called the float,
or slack.
Activities with no float or slack are critical
Any delay on these activities will delay the project
194
y y y p j
The sequence of such critical activities that connect the start and finish is called
the critical path.
The sum of the durations of critical activities equals the length of the project
Milestones are activities with zero resources and of zero duration, and
Progress of an activity can be shown by shading (percentage)
Example
Given the precedence table, draw the Gantt chart.
195
Past Exam Question
From the previous home renovation
j t project
Assume the WBS calculated previously,
draw a Gantt Chart
On the graph paper assume the time scale
of 10 mmequals 1 day
196
of 10 mm equals 1 day
1 Bathroom Renovation Project
1.1 Removal of Fixtures (1)
1.2 Minor jobs pre-tiling
1.2.1 Relocate Pipes (0.5) precedent 1.1
1 2 2 New cabling (0 5) precedent 1 1 1.2.2 New cabling (0.5) precedent 1.1
1.2.3 Paint Ceiling (0.5) precedent 1.2.2
1.3 Tiling
1.3.1 Waterproof (1) precedent 1.2.1 & 1.2.3
1.3.2 Lay Tiles (4) precedent 1.3.1
1.3.3 Grout (1) precedent 1.3.2
1.4 Shower Cubical
1.4.1 Measure Shower (0) precedent 1.3.2
1.4.2 Manufacture Shower Cubical & Install (10) - precedent 1.4.1
197
1.4.3 Silicon Seal Shower Cubical (1) precedent 1.4.2
1.5 Cabinet
1.5.1 Measure Cabinet (0) precedent 1.3.2
1.5.2 Manufacture Cabinet & Install (5) precedent 1.5.1
1.5.3 Silicon Seal Cabinet (1) precedent 1.5.2
1.5.4 Install Fittings (1) precedent 1.5.3
198
Project Planning
199
Project Planning
Project Planning is the process of thinking
through and making explicit the objectives through and making explicit the objectives,
goals, and strategies necessary to bring the
project through its lifecycle to a successful
satisfaction of its cost, schedule, and technical
performance objectives.
Project Planning Process
200
Project Planning Process
The process comprises two major phases:
Project initiation
Detailed project planning.
Initiation Phase
201
Identify the client
Every project requires the identification and
agreement of the client who has authorised the agreement of the client who has authorised the
project.
Every project needs an established client, the
person(s) that has ultimate authority to
establish goals, budgets, constraints, and so
on
202
on.
The client may be an executive in your
organisation, an outside client, or yourself.
Identify project requirements
The project manager must interpret the
t i t d l th customers requirements and plan the
project with minimum help because the
project team cannot be formed until the
amount of work required is established.
203
Establish the project scope
The first task is to determine quickly the
l d th kill t d d general scope and the skill sets needed.
204
Estimate resources
Once the general scope is determined,
th j t b i ti t the project manager can begin estimate
the number and type of resources for the
project.
It is not realistic to have all the
requirements identified.
205
requirements identified.
Develop a high-level WBS
A high-level WBS is needed before any final
estimates of the type and number of resources estimates of the type and number of resources
can be made, or the cost and schedule
estimates can be developed.
The WBS must be sufficiently developed to
have an
accurate viewof what the project entailed
206
accurate viewof what the project entailed,
what resources are required, and
what functional groups in the organisation are
needed to support the project.
Develop the project charter
The charter is a document that sets the
t i t d th li it management requirements and the limits
for the project.
It generally contains a brief scope
statement of the company and the
project, and who the project manager is.
207
project, and who the project manager is.
Sample project charter format
Purpose (Scope statement) Purpose (Scope statement)
Project Establishment (Business reason for the project
and how it supports the companys strategic goals)
Project Manager Designation and Authority
Project Team Organisation (Describe where the project
team is within the organisational hierarchy)
Project Managers Reporting Chain
208
Project Manager s Reporting Chain
Project Team Composition, and
Support Organisations and Support Requirements
Source: Taylor, J ., 2004.
When the project charter is signed by a
i th i ti i h person in the organisation senior enough
to have functional authority over the
project and all the supporting functional
areas, then the project manager has the
authority to start the project.
209
Planning Phase
210
Detailed Planning Stage
Assemble project team
Develop a detailed WBS
Develop a network analysis
211
Create a project schedule
Your project schedule should identify project
tasks tasks
with their completion dates,
establish a desired completion date (or time)
for the entire project,
and list milestones for deliverables and
l ti f
212
evaluation of progress.
Develop project budgets
Project costs are usually developed on a
task by task basis task-by-task basis.
Each task is assigned resources that
include labour and material and any other
direct and/or indirect costs.
Assigning costs on a task basis allows
h d l d b d t t b il
213
schedules and budgets to be easily
adjusted without complicated
recalculations.
Identify risks and contingencies
A good way to identify potential risks is to
l t th j t h d l t h t evaluate the project schedule to see what
things are most likely to go wrong.
Once these risks have been identified and
analysed, you should establish plans or
contingencies for dealing with them.
214
Write a project plan
A project plan is
written by the project team
and approved by the client.
It describes
what the team plans to produce (the interim
and final deliverables)
215
and final deliverables)
and what resources and considerations are
needed to deliver the product
Project Plan
216
The project plan
Details of the project plan vary depending Details of the project plan vary depending
on the type of the project and organisation.
However, the content of most plans should
include the following sections:
217
Executive Summary
Executive summary should be written last
b it i t t b h t because it is meant to be a short
descriptionof the project intended for
senior managers.
It is a synopsis of the reasons for the
project and its major characteristics and
218
project and its major characteristics and
functional capabilities.
Introduction
This section briefly explains what the
document is and why it has been document is and why it has been
produced.
It should also include:
The identity of the client that is, the
organisation for whom the work is to be done
short description of the project
219
short description of the project
identify of the project authority - the person
within the client organisation who will have
authority over the projects direction.
Background
This includes:
circumstances leading to the current project
work already carried out in the area of the
project
stakeholders in the project, i.e., all those who
will be affected by the project or who have
220
some interest in it.
Project Objectives
The objectives must define
what is to be achieved
and the method of measuring the extent of the
achievement.
221
Constraints
This sets out the constraints that affect the
j t d i i d t project decision and management.
Constraints can include:
customer-mandated milestones or special
reporting requirements
legal requirements
222
legal requirements
specific standards.
Risk Analysis
This describes
possible project risks,
the likelihoodof these risks arising
and the proposed risk reduction strategies.
223
Methods and Techniques
This section
describes and justifies the development
strategychosen for the project.
It describes the approaches,
methods
andtechniques to be used duringthe
224
and techniques to be used during the
requirements specification, implementation,
verification, validation and test.
Project Requirements
This is a numbered list of identified project
requirements requirements.
The numbered list of requirements can be
used to verify requirement traceability in the
system/HW/SW design document.
225
Project Products
This is a numbered list of all the products,
i t i d fi l d li bl th t th interim and final deliverables, that the
project will produce.
The numbered list of deliverables can be
used to associate with the tasks in the
work breakdown structure.
226
work breakdown structure.
Work Breakdown
This describes the work breakdown of the
j t i t project into
tasks
and identifies milestones
and deliverables associated with each task.
227
Project Schedule
It includes:
Master schedules
Detailed phase schedules
Milestone chart
Deliverable schedule
Meeting or other client-required schedules
228
Meeting or other client required schedules.
Resource Requirements
Resources include anything needed to
li hth j t l accomplish the project goals.
It includes
Equipment,
Materials, and
People
229
People.
Cost Estimates and Budget
Evaluation Criteria
This describes criteria designed to measure
how well the project is doing against the
customers requirements.
These criteria may include milestones, sign-
off points by the client, or quality checks by
th j t b i d d t
230
the project manager, or by an independent
person.
Appendixes
Additional required plans and items such
h d l i l d d di as schedules are included as appendixes
231
Review the Plan
Th j t l h ld b l l The project plan should be regularly
revisedduring the execution of the project
plan.
Some parts, such as the project schedule,
will change frequently; other parts will be
232
g q y; p
more stable.
Cost Estimation
Lecture 6
233
Project cost estimation
Project cost is either direct or indirect.
Direct costs are incurred specifically because of the Direct costs are incurred specifically because of the
project for example, hiring a project officer or purchase
special equipment.
Indirect costs are costs that are ongoing and would have
been incurred anyway for example, office space.
Only direct costs will be used to develop your budget.
Costs are usually developed on a task-by-task basis.
234
Each task is assigned resources that include labour and
material and any other direct or indirect costs.
Cost estimates
When putting together your cost estimates, you
should document your replies to these should document your replies to these
questions:
Do you expect your estimate to be 50% accurate or
90%?
What assumptions did you make to come up with
your estimate?
235
y
What factors might affect the accuracy of your
estimate? For example, will resource costs go up or
down if the project does not start on time?
Cost Estimates
In software and hardware development projects, a good
rule of thumb is to estimate as if nothing will go wrong,
th i ti t t ti i t d then increase your estimate to cover anticipated
problems.
A further contingency factor to cover unanticipated
problems may also be added to the estimate.
This extra contingency factor depends on the type of
project, the process parameters (deadline, standards,
etc.) and the quality and experience of the of software
and hardware engineers working on the project
236
and hardware engineers working on the project.
Add 30% to your original estimates for anticipated
problems then another 20%to cover other things one
hasnt thought of.
Risk Management
237
Risk Management
S
HIGH
COMMON
DISASTER
RARE
CATASTROPHE
C
O
N
S
E
Q
U
E
N
C
E
LOW
FREQUENT
IRRITATION
UNLIKELY
INSIGNIFICANT
238
* Source Practical Project Management for Engineers and Technicians IDC Technologies, 2001
LOW
LOW HIGH LIKELIHOOD
INSIGNIFICANT
Project Risks
Risks may cause your project to overrun its
timescale and budget timescale and budget.
Determining a project risk requires that you look
closely at any potential obstacles or problems
that may prevent you from completing your
project as defined in the project of scope.
239
Risk Types
There are three major types of risk:
Those caused by the difficulties of estimation Those caused by the difficulties of estimation
Some tasks are harder to estimate than others. It
may be due to the lack of experience of similar
tasks.
Those due to assumptions made during the planning.
At every stage of the planning, assumptions are
made which, if not valid, may put the plan at risk. It
240
is important that all assumptions made must be
explicitly listed.
Those of unforseen (at least unplanned) events or
hazards occurring.
Risk management
The process of risk management involves:
Risk identification Risk identification.
Risk analysis.
The likelihood and consequences of these risks are
assessed.
Risk planning.
Plans to avoid or minimise the adverse effects of uncertainty
by avoiding the risks and by drawing up contingency plans
for dealing with them
241
for dealing with them.
Risk monitoring.
The risk is constantly assessed, and plans for risk mitigation
are revised as more informationabout the risk becomes
available.
242
Risk Mitigation
How much time do we spend in
attempting to reduce risk?
Enough time to reduce/minimise the risk
Use the ALARP Principle
Mitigate Risk so that it is As Low As Reasonably Practicable
243
Evaluating Risk
244
Evaluating risk
to the schedule by PERT
We use PERT to evaluate the effects of uncertainty on
the schedule.
Instead of using a single estimate for the duration of each
task, PERT requires three estimates:
Most likely time, m
Optimistic time, a
Pessimistic time, b.
A single expected duration is obtained using
245
where t
e
is the expected duration of the task
Example
The expected duration for each task is calculated.
246
The PERT network after the forward pass
i di t th t t th j t t t k indicates that we expect the project to take
13.5 weeks.
We have used the activity-on-arrow
network.
247
PERT network
after the forward pass
248
Standard Deviation
Standard deviation can be a second measure
to tell howmuch one can believe the expected to tell how much one can believe the expected
duration we have computed.
The task standard deviation, denoted by s, can
be found using
s =(b - a) / 6.
The formula is based on the rationale that there
249
are approximately six standard deviations
between the two extreme tails of many statistical
distributions.
Example Cont
With a set of standard deviations for the
tasks in the schedule we can rank the tasks in the schedule, we can rank the
degree of uncertainty of the tasks.
250
251
Likelihood of meeting targets
We can find the standard deviation of a project
event by carry out a forward pass event by carry out a forward pass.
Consider event 3. It depends solely on task B.
The standard deviation for event 3 is 0.33.
For event 5, there are two possible paths, B+E
or F. The total standard deviation for path B+E is
(0 33
2
+0 50
2
)
1/2
=0 6 and for path F is 1 17
252
(0.33
2
+0.50
2
)
1/2
=0.6, and for path F is 1.17.
Thus, the standard deviation of event 5 is the
greater of the two, i.e. 1.17
PERT network
after standard deviation
* Expanded view at back of Unit Notes
253
Example
Suppose that we must complete the project
within 15 weeks at the outside within 15 weeks at the outside.
We expect it to take 13.5 weeks but it may take
more, or perhaps less.
Suppose that task C must be completed by
week 10, and that event 5 represents delivery of
intermediate product to customer and must be
l t d b k 10
254
completed by week 10.
These three target are shown (in blue) in the
diagram.
Calculating the z values
The z value is calculated for each node
that has a target date using the formula that has a target date using the formula
z =(T - t
e
) / s
where T is the target date.
The z value is equivalent to the number of
standard deviations between the nodes
255
expected and target dates.
The z value for event 4 is (10 9.00) /
0.53 = 1.8867.
Converting z values to
probability
A z value may be converted to the
b bilit (i %) f t ti th t t probability (in %) of not meeting the target
date by using the table of the standard
normal deviations.
256
Probability of NOT meeting
the target date
257
Another Example
The z value for the project completion
( t 6) i 1 23 (event 6) is 1.23.
Using the table, this equates to a
probability of approx 11%, that is, there is
an 11% risk of not meeting the target date
of the end of week 15.
258
of the end of week 15.
Exercise
Find the probability of not achieving events
4 5 b th i t t d t f th d f 4 or 5 by their target dates of the end of
week 10.
What is the likelihood of completing the
project by week 14?
259
References
Blanchard, B.S., Fabrycky, W.J .: Systems engineering
and analysis. 3rd edition, Prentice Hall, 1998.
Hughes, B., Cotterell, M.: Software project management.
3rd edition, McGraw-Hill, 2002.
Martin, P., Tate, K.: Project management memory
jogger: a pocket guide for project teams. Goal/QPC,
1997.
Sommerville, I.: Software engineering. 7th edition,
Addison Wesley, 2004.
260
Taylor, J .: Managing information technology projects
[electronic resource]: Applying project management
strategies to software, hardware, and integration
initiatives, American Management Association, 2004.
PROJ ECT MONITORING AND
CONTROL
Mr. Alfio Grasso
Offi i3 58
261
Office i3.58
Table of Contents
Earned Value Analysis .............................................. 264
Planned Value 265 Planned Value ............................................................265
Earned Value ..............................................................265
Actual Cost .................................................................265
Cost Variance ............................................................ 267
Schedule Variance .................................................... 268
Cost Performance Index ........................................... 275 Cost Performance Index ........................................... 275
Schedule Performance Index ................................... 277
Status Reporting ....................................................... 280
Change Management ............................................... 283
262
Learning Objectives
ill b bl t will be able to:
perform earned value analysis for monitoring
project progress
generate status reports
understand change management in a project
263
g g p j
Earned Value Analysis
Earned value is a technique for tracking
progress against actual accomplishment.
It is based on the WBS budget and schedule It is based on the WBS budget and schedule
estimates.
In earned value analysis, percentage completion
is an input parameter, and the Gantt chart
provides a quick reference for this parameter.
Can use the 0/100
0% until finished then 100%
264
50/50
50% when started and then 100% when finished, could be
misleading!
Milestone
Milestones assigned a percentage value.
Three terms used in earned value analysis are:
Planned value (PV) Planned value (PV)
PV is the amount that you estimate the task or
project will cost.
Actual cost (AC)
AC is the actual amount of money paid for the
work as it progresses.
Earned value (EV)
265
Earned value (EV)
EV is the value of the work actually completed and
measured against the planned completion amount
for that period.
Example (Earned Value
Calculations)
The cost of the task is $50/week.
The total planned value cost of the task is The total planned value cost of the task is
$1,000 (=$5020 wks).
We wish to assess the progress at the end of wk
5.
Assume that the actual amount of work
completed is equivalent to 7 weeks of work. (We
266
p q (
are ahead of schedule!)
PV is $250 at the end of wk 5.
EV is $350 (=$507)
Cost Variance
C t i (CV) i th diff b t th Cost variance (CV) is the difference between the
earned value and the actual work produced.
CV =EV - AC
A positive CV means the project is under
budget.
267
If the CV is zero, then the project is on budget.
A negative CV implies the project is over budget.
Schedule Variance
Schedule variance (SV) is the difference
between the earned value and the planned between the earned value and the planned
value.
SV =EV - PV
A positive SV tells us the project is ahead of the
schedule.
A zero SV means the project is exactly on
268
p j y
schedule.
A negative SV means the project is behind
schedule.
Monitoring Project Progress with
To show the use of earned value analysis
i d t i i h ll j t i d i in determining how well a project is doing
in comparison with the original plan, we
use an electronic engineering project as
an example.
The project is 14 weeks in duration.
269
The project is 14 weeks in duration.
At the 6th week point, we are going to
assess the projects progress.
270
From the bar chart, we see that the work is
ahead of schedule ahead of schedule.
We cannot determine from the chart
whether we are on budget.
That has to be done by comparing what is
completed against what have spent.
271
Earned value analysis is used.
The most convenient way to collect earned
value data is in tabular form:
272
Where EV =%Complete*Total Task PV
Because the CV is a negative number, we know that the
project is over budget. p j g
Looking at the task set:
Requirements definition and system architecture design are
completed when we take the assessment at the 6th week. Their
PV and EV are equal to the amount estimated.
The SW design task is also on schedule.
SW coding is a little different we had no plan to begin the task
until the 6th week so its PV is zero. The shaded area indicates
h h k b i d h fi i h d k k
273
that the task begins sooner and has finished one week work
(25% of the coding) already. Hence, its EV is 25%$10,000, or
$2,500.
HW design is progressing well - the PV to date is 67% of $2,000
and the EV is 83% of $2,000.
Project Control Through
Variance Management
One way to control budget is to determine the
acceptable bounds away fromthe planned acceptable bounds away from the planned
budget and scheduled that we can tolerate.
Generally, about 10%
Variation above or below the planned budget or
schedule is about the maximum that can be
tolerated
274
tolerated.
The CPI and the SPI measures are often used.
CPI
CPI (cost performance index)
gives an indication of how the project is
progressing against the planned cost.
The index is normalised to the actual costs
CPI =EV / AC
275
In our example, the CPI is:
11 670 /11 800 =0 99 11,670 /11,800 0.99
The figure means that for every dollar we spend
on the project, we are getting 99c back. If the
CPI ratio is less than 1.0, then it indicates that
the project is over budget, which is also the
result we obtained when we calculated cost
variance.
276
Because CPI is normalised to actual costs rather
than a dollar figure, it has more meaning to
senior management, and hence it is important.
SPI
SPI (schedule performance index), in
terms of a percentage indicates howthe terms of a percentage, indicates how the
project is progressing against the planned
schedule.
SPI = EV / PV
The SPI in our example is
277
11,670 /8,850 = 1.32.
The number greater than 1.0 tells us that
we are ahead of schedule.
Another Example
278
The plot shows that the CPI and SPI are
l h t th 1 0 li close enough to the1.0 line.
Hence, this project is progressed
according to plan, or at least within
acceptable variations from the plan.
279
Status Reporting
A status report is a verbal description of the projects
progress, usually provided to senior management and p g y p g
the customer representative on a regular basis, say,
each month.
The frequency of this report is a function of how complex
or risky the project is.
Most electronic and IT projects are complex and risky, at
least with regards to schedule and technology issues.
Th th j t ill b k d t id
280
Thus, the project manager will be asked to provide
informal reports frequently
even daily
with a formal written report to follow weekly.
An example of a typical status report format is
shown shown.
It aims to answers questions such as:
What has been done during the reporting period?
What problems were encountered and how were they
handled?
What is going to be done during the next reporting
281
What is going to be done during the next reporting
period?
Do you expect any problems during the period?
Status Report
Project Name:
Report Date:
Phase:
Report Period:
Project Manager:
Summary of Progress:
Project Issues/Problems/Actions Taken:
Planned Activities for Next Reporting Period:
Milestones:
Met during this period
Planned for next period
Financials:
Report Dates:
282
Report Dates:
Planned Spending
Actual Expenditures
Actions/Decision Pending:
Attachments:
* Source: Taylor, J . (2004)
Managing Change in A Project
Change in project is inevitable, particularly
in a complex developing and evolving in a complex, developing, and evolving
electronic engineering project.
A documented and functional change
control methodology is important to project
success.
Th t t f h th j t
283
There are two types of changes the project
team and organisation need to be aware
of and track closely.
Customer Initiated
The first are those changes that the customer initiates as
he evaluates the needs.
They occur because the project requirements were not
clear at the start, the technology changes, or the need
changes because of market considerations.
This type of change constitutes change to the scope and
must be accomplished with change to the contract or,
with an internal customer, a formal memorandum of
understanding
284
understanding.
The reason for a formal change procedure is that most
scope changes will impact the budget, the schedule, or
both.
Internal Change
The second type of change occurs within the
project as it develops project as it develops.
These changes are usually those that become
evident as more of the design and development
is understood.
They may not constitute scope change.
Thi t f h i i t l t th j t d
285
This type of change is internal to the project and
the organisation, but every change requires the
customers consent before implementation.
Change Management
There needs to be a formalised process
f h t th t th j t for change management that the project
team, and all functional personnel,
understand and follow.
A change control procedure is shown in
the next slide.
286
the next slide.
287
All change requests or recommendations must
be directed to the project manager so that they be directed to the project manager so that they
can be tracked, documented, and acted upon.
All potential changes that exceed the project
managers authority are passed on to a change
(or configuration) control board (CCB).
The CCB is usually a group of three to five
b h f ti i t l t h
288
members whose function is to evaluate change
requests, their viability, and the impact to the
project scope.
Once the change is approved, the project
manager must manager must
document the changes,
update the project specifications,
publish the changes and
inform all stakeholders of the change.
The one major caution in managing change is to
289
The one major caution in managing change is to
ensure that every change is implemented only
after it is agreed to by all stakeholders and
documented.
References
Martin, P., Tate, K.: Project management
memory jogger: a pocket guide for project memory jogger: a pocket guide for project
teams. Goal/QPC, 1997.
Smith, K.A.: Teamwork and project
management. 2nd edition, McGraw-Hill, 2004.
Taylor, J .: Managing information technology
projects [electronic resource]: Applying project
t t t i t ft h d
290
management strategies to software, hardware,
and integration initiatives / American
Management Association, 2004.
PROJ ECT CLOSEOUT
Mr. Alfio Grasso
Offi i3 58
291
Office i3.58
Table of Contents
Project Closeout ..................................294
Lessons Learned .................................300
Evaluation Guidelines ..........................301
Final Report .........................................303
292
Learning Objectives
will be able to:
understand the closeout phase of the project
lifecycle
293
Project Close - Out
294
Activities of the Closeout Phase
The project managers function is largely administrative
during this phase of the project.
It is time to ensure that
all requirements have been met,
the product is delivered and working,
all bills are paid,
all invoices are sent,
the project office is properly closed, and
all team members are assigned new jobs.
The project teamstarts planning for the project closeout
295
The project team starts planning for the project closeout
when there is a clear understanding of all the project and
product requirements.
It should occur before the product development begins.
A WBS for the closeout phase
296
Scope Verification
This activity comes at the end of the
t t k h d th j t events tasks, phases, and the project.
The objective is to ensure all the scope
requirements for that event, whether a
task, or the project, are accomplished.
Scope verification constitutes two audits:
297
Scope verification constitutes two audits:
the technical audit and
the audit of the projects financial status.
Product Completion & Delivery
The primary objective of the project is to complete and
deliver the end product to the customer.
The product is completed at the end of the
implementation phase, but there still are some final test
and clean-up chores required before the product can be
delivered.
Most often, acceptance is contingent upon a successful
acceptance test.
The final step is delivery and installation of the product,
which incidentally may come before the acceptance
298
which, incidentally, may come before the acceptance
demonstration.
In other words, it is not uncommon to install the system
and then conduct the final tests in front of the customer.
Customer Sign-Off
The customers sign-off means they have
agreed that you have indeed developed the agreed that you have indeed developed the
system to specification and that it is accepted.
One of the critical elements of any contract,
external or internal to the organisation, is a clear
explanation of the acceptance criteria.
If there are no criteria then the customer can
299
If there are no criteria, then the customer can
always assert that the product does not meet the
requirements.
Lessons Learned
At the end of the project it is important that
the teamholds a lessons learnedmeeting the team holds a lessonslearned meeting
and conducts an end-of-the-project
evaluation.
Dont let the meeting degenerate into a
session of placing blame for problems that
have occurred
300
have occurred.
And remember to look at your successes,
as well as your failures.
Evaluation Process Guidelines
How close to scheduled completion was the project actually
completed?
What did we learn about scheduling that will help us on our g p
next project?
How close to budget was final project cost?
What did we learn about budgeting that will help us on our
next project?
Upon completion, did the project output meet client
specifications without additional work?
If additional work is required please describe
301
If additional work is required, please describe.
What did we learn about writing specifications that will help
us on our next project?
What did we learn about staffing that will help us on our next
project?
Source Haynes (1989)
Guidelines Cont
What did we learn about monitoring performance that will
help us on our next project?
What did we learn about taking corrective action that will
help us on our next project?
What technological advances were made?
What tools and techniques were developed that will help
us on our next project?
What recommendations do we have for future R&D?
What lessons did we learn fromour dealing with service
302
What lessons did we learn from our dealing with service
organisations and outside vendors?
If we had the opportunity to do the project over, what
would we do differently?
Final Report
Closing the project book, which is a
collectionof all the project related plans collection of all the project related plans,
reports, and other pertinent
documentation, requires one final report.
The report is referred to as the final project
audit.
O thi fi l t i il d it i t
303
Once this final report is compiled, it is sent
to all the project stakeholders and is
included in the project archives.
Final Project Audit Report
Executive Summary
Introduction
Project Review Project Review
Planning Effectiveness
Project Management Effectiveness
Effectiveness of Technical Solutions
Project Deliverables
Quality
Schedule
Finances
Resources Utilisation
304
Individual Team Member Assessment & Recommendations
(Submitted as separate, confidential report)
Lessons Learned, and
Recommendations
References
Martin, P., Tate, K.: Project management
memory jogger: a pocket guide for project memory jogger: a pocket guide for project
teams. Goal/QPC, 1997.
Smith, K.A.: Teamwork and project
management. 2nd edition, McGraw-Hill, 2004.
Taylor, J .: Managing information technology
projects [electronic resource]: Applying project
t t t i t ft h d
305
management strategies to software, hardware,
and integration initiatives / American
Management Association, 2004.
ELECTRONICS SYSTEM
DEVELOPMENT
Mr. Alfio Grasso
Offi i3 58
306
Office i3.58
Table of Contents
Lifecycle ......................................................................310
Development and Design Flow 314 Development and Design Flow ................................. 314
Concept ..................................................................... 318
Analysis Requirements .............................................. 324
Evaluation and Partitioning ........................................ 326
Feasibility and Modelling ........................................... 328
SystemSpecification ................................................. 330 System Specification ................................................. 330
Functional Requirements .......................................... 332
Non- Functional ......................................................... 333
Design ....................................................................... 335
307
Table of Contents - Cont
Design Documentation................................................350
Software Design Document 353 Software Design Document ...................................... 353
Implementation .......................................................... 356
Configuration Management ....................................... 364
Verification, Validation and Test ................................ 367
Initial Manufacture ..................................................... 374
Volume Manufacture ................................................. 378 Volume Manufacture ................................................. 378
308
Learning Objectives
will be able to:
understand the Systems Development
process
describe the electronic development flow
309
describe the electronic development flow
Lifecycle
There are two distinct lifecycles at work in
j t a project:
The project lifecycle
encompasses all the project activities in planning,
administration, and leadership all those activities
necessary to ensure that plans and processes are
in place to ensure a smoothly running project.
310
in place to ensure a smoothly running project.
The systems development lifecycle
focuses on the technical aspects of producing the
project deliverables.
Lifecycle Cont
It is a mistake to assume that either the
j t lif l th t project lifecycle or the systems
development lifecycle is sufficient by itself.
Both are needed to successfully manage
any project.
311
development lifecycle models have
overlapping activities.
312
We have covered the phase activities of
th j t lif l i U it 3 5 the project lifecycle in Units 3-5.
In this unit we will use an electronics
system project to explain the phases in the
systems development lifecycle.
313
Development and Design
Flow
314
Development and Design Flow
of Electronics System Products
The systems development lifecycle of
h d d ft t i ft hardware and software systems is often
expressed as development and design
flows.
A high-level development flow is shown in
the next slide.
315
the next slide.
316
The development flow fits the waterfall
d l ith th f db k th process model, with the feedback paths
being water splashing back.
317
Concept
318
Concept Phase
The concept (definition) phase is the most
fundamental phase of the whole project fundamental phase of the whole project.
Mistakes made at this stage can lead to
very expensive consequences later on.
Definition / Concept
Need
319
Timescale
Existing solutions and proposed improvement
Requirements specification
Need
A key aspect of the concept phase is to
determine the needs of the customer and extract
quantitative data from the users whenever
possible.
Example of quantitative statement
Phases such as shall provide a significant
improvement in performance over the existing
system contain very little information.
A significant improvementneeds to be quantified
320
A significant improvement needs to be quantified
is it 3db improvement in signal-to-noise or 10db, or 20db, for
that matter?
Is it a factor of 2 improvement in processing time or factor of
10? and so on.
Timescale
Even at the concept phase, it is essential
t t bli h ti l f th j t to establish a timescale for the project
because this limits the options available.
A solution required by the end of the week
does not allow extensive engineering!
321
Existing solutions and proposed
improvement
Market research and examination of
i ti l ti (b th l ti f existing solutions (both solutions of your
competitors and your existing products)
are key aspects of the concept phase.
Your new product must have significant
advantages over and above existing
322
advantages over and above existing
solutions and it is important to be clear as
to what these are.
User requirements specification
The output of the concept phase is the user
requirements specification.
The specification forms the basis for all subsequent
engineering.
The user requirements specification must be reasonable
and realistic
The requirements achievable and the timescales for achieving
them realistic.
Making sure that the specification is reasonable can
often lead to disagreement in particular between those
323
often lead to disagreement, in particular, between those
whose job is to sell the new product and those who have
to design it.
It is important to resolve such issues fudging the issues leads
to more serious problems later on.
Analysis Requirements
324
Analysis and Requirements Phase
The analysis phase converts the requirements
specification into a systemspecification specification into a system specification.
Analysis consists of:
Evaluation and partitioning
Feasibility and behavioural simulation
System specification
Preliminary design
325
Preliminary design
and
Design approval and sign-off
Evaluation and partitioning
We evaluate the requirements and partition the required
functions into a set of smaller functions.
Partitioning forms the basis of top-down design.
The way the work breakdown is carried out depends on
the particular system and there are no set rules that
applies to all cases.
There are a few general rules:
The functions of each part of the design must be described
l t l l ti l i l d bi l
326
completely, relatively simply and unambiguously
The interactions between each part should be as simple and as
few as possible
The parts themselves must be realisable
Usually a WBS is developed to the third or fourth level.
Partitioning
The relationships between the elements and the
interactions are described and quantified as far q
as possible without going into the details of how
they are to be implemented.
The elements must be described generally so
that they do not limit the choices of solutions to
be examined during the design phase.
General concept such as data flow, frequency
t d b i b d diti
327
response, etc, and basic boundary conditions,
IO interfaces imposed by the external world are
usually adequate to provide a clear and detailed
system specification.
Feasibility and modelling
The feasibility of the system specifications must
be established as part of the analysis phase, p y p ,
and modelling is a major activity in this phase.
In electronic design, it is increasing popular to
simulate the behaviour of the product using a
software model in a programming language (eg
C/C++) or a hardware description language
(HDL).
Eith th d l i l t th t t i
328
Either way, the model simulates the outputs in
terms of inputs and does this without reference
to the details of the way that the product will be
implemented.
Prototyping
Alternatives, such as lab prototyping using
FPGAs can demonstrate the feasibility of the FPGAs can demonstrate the feasibility of the
A major advantage of prototyping is the ability
that it gives to model very complex systems and
exercise them over many hours of elapsed time
using data rates that are close to the real
situation
329
situation.
The cost of building such prototype often
outweighs the advantage
System specification
The system spec is a major output of the
analysis phase analysis phase
Verification, which is the process of ensuring
that the final product confirms to this
specification.
Usually, little or no information on how the
system specifications are to be met is dictated,
330
but schedule and budget are often stipulated.
All interfaces to existing software and hardware
should be clearly defined.
Testing and System Spec
A major component of the system specification
should describe the overall approach to the should describe the overall approach to the
testing of the final product
in particular, how testing will be used to demonstrate
conformance to the functional components of the
From a testing perspective, it is at this point that
test requirements are determined and committed
331
test requirements are determined and committed
to a former test plan.
The test plan is used as the blueprint for the
creation of test cases used in the testing phase.
Functional Requirements
The system specification document includes specific
information about functional requirements those
t f t th t b di tl t t d b ti system features that can be directly tested by executing
the program.
Example:
The following text described a functional requirement for
an aircraft navigation system.
Within 1 millisecond of issuance of the level 1, high-priority
interrupt, the navigation subsystem shall make available all
compensatedaccelerationdata to the main computer, which will
332
compensated acceleration data to the main computer, which will
read it via DMA. This data cannot be updated while the main
computer is in the process of reading it.
Other specific functional requirements include system
response times and throughput requirements, etc.
Non-functional Requirements
Non-functional requirements are characterised as system
features that cannot be tested by program execution or hardware
operation operation.
Non-functional requirements include specification of the type of
machine that the system will run on, programming language to
use, time- and memory- loading, and version control.
Other non-functional requirements might cover tests conducted,
maintainability, modularity, second sourcing of key components,
programming style, and security of the development site.
Example:
The followingexcerpt fromthe nuclear power plant systemis a
333
The following excerpt from the nuclear power plant system is a
non-functional requirement.
The system shall be coded to ANSI-C using accepted
practices of software engineering. No GOTO statements are
permitted.
Analysis and Requirements
The analysis and requirements phase and the
concept phase are coupled and some concept phase are coupled, and some
practitioners simply combine the two.
It can be argued that the two are separate
because the requirements generated during the
concept phase are not binding, whereas those
determined in the requirements phase are
334
determined in the requirements phase are.
This difference is also important from a testing
perspective.
Design
335
Preliminary design
The preliminary design has been evolving from
the requirements analysis feasibility studies the requirements analysis, feasibility studies,
and trade-off analysis.
In fact, the preliminary design should be pretty
much completed by this point except for any
refinements necessitated by finalising the work
breakdown structure and product requirements.
I th d th fi l t h b t
336
In other words, the final touches can now be put
to the detailed design and to any plans that need
updating.
Design approval and sign-off
The next step in the process is to obtain
t d t k h ld l th t customer and stakeholder approval so that
the detailed design can be developed.
337
Documentation passing between
phases
338
Design Phase
The design phase is characterised by the
conversion of the requirements document to a conversion of the requirements document to a
detailed design document.
Preparation of the detailed design document
cannot begin until the requirements have been
fully defined.
The design document specifies how the
i t t b t b titi i th
339
requirements are to be met by partitioning the
functional features prescribed in the
requirements document into software and
hardware modules.
Testing
Verification is to be carried out at every stage of
the design phase so that as each element is the design phase so that, as each element is
created, it can be shown to conform to the
Concurrent with the preparation of the design
document, a set of test cases based on the test
plan are developed.
Th t i th i t d t i t th
340
That is, the requirements document is to the
design document as the test plan is to the test
case.
Design
Design Elements consist of:
Standards
HW/SW partitioning
Structured design
Detailed design, and
Detailed design document
341
Detailed design document
Standards
Many decisions need to be made during the
design phase. g p
It is important that these are made consistently
by all members of the team and that all
members agree on what basis these are to be
made.
Standards (such as those of ISO 9000, IEEE
830 and so on) may be forced on the project by
th d f th t th i t i
342
the needs of the customer or the environment in
which the product is to be used (military,
hospitals etc), and often large companies (such
as Motorola) have their own standards.
Standards
It is necessary to establish standards as working
practices for the team. p
For example, all software for the project must be written
in one language.
Other examples include coding style guides for both HDL
and high level programming languages.
Standardisation of the decision making process is an
important part of structured design.
343
Although it is often opposed by designers when it is
introduced because it reduces their design freedom, the
benefits later in the project and in developing second
generation products are appreciated by all.
Hardware-software partitioning
A major decision to be made early in the design
phase is the partition of functionality between phase is the partition of functionality between
hardware and software.
It is a difficult choice influenced by many factors.
Establishing the criteria that will be used on a
particular project should be done and
standardised at the outset of the design phase.
344
Further partition takes place for both the
software into modules and the hardware into
units.
Structured design
Before and during the partitioning, it is useful to
model the systemin a general way that model the system in a general way that
design is carried out hierarchically
at each level a set of specifications is created.
The nature of the description is appropriate to
the level of the design of the product.
A standard format should be adopted for the
345
A standard format should be adopted for the
specifications at each level in the design.
Detailed design
Design flow for custom circuits
The development flow outlined so far is at the
top level of the hierarchy top level of the hierarchy.
It is essential that designers work within well
defined guidelines no matter they are designing
the whole product at the highest level or whether
they are designing an individual chip (an FPGA,
for example), which implements a small part of
the total functionality
346
the total functionality.
The diagram, next slide shows an outline flow for
the design of an FPGA.
* Expanded view at back of
Unit Notes
347
Detailed design
- Software design flow
A similar flow exists for the design of the
software components of the product software components of the product.
Flows can be of different kinds and have
different characteristics depending on the
nature of the software.
For example, the flow of a real-time
ft f i t ll i it
348
software for engine controller is quite
different to that for an off-line batch
process for a large set of data analysis.
Detailed design
Incorporating design for test and design for
manufacture
Design for test (DFT) and design for manufacture (DFM)
are key elements of a structured approach to design and
th d t j t h they do not just happen.
Ignoring DFT and DFM until the final stages of the
project can create a design that is untestable, or too
expensive for volume manufacturing.
DFT and DFM must be incorporated throughout the
design flow.
It is not too early at the analysis stage, when the system
specification is being formulated to specify the test
349
specification is being formulated, to specify the test
methods, the DFT procedures and the DFM standards
that you propose to use.
Adherence to these standards can then be checked at
the end of every subsequent phase.
Design Documentation
When preparing the design document and the
systemrequirements specification document system requirements specification document,
one should follow the following principles:
The document must be complete.
There should be no holes or gaps.
This goal of writing requirements and design documents is
the most difficult to achieve.
Th d t h ld b t
350
The document should be correct.
No laws of physics should be violated.
The specified system must be consistent with the intent of
the final deliverable product.
Design Document Cont
The document should be consistent.
There should be no internal conflicts or There should be no internal conflicts or
contradictions.
351
Design Document Cont
Each requirement or design element should
be testable be testable.
Specifying that a system should have reliable
performance is meaningless because it cannot be
objectively tested.
Specifying that no faults should be detected before
one hour of operation is meaningful.
352
Software design document
The software design document is one major
output from electronic projects that contain p p j
sufficient amount of programming.
Technical organisations such as the IEEE
promote recommended practice for software
design descriptions (SDDs).
The recommended design views include some
combination of decomposition, dependency,
i t f d d t il d i ti
353
interface, and detail descriptions.
A standard template for SDDs is given in the
next two slides.
Proposed Structure
1. Introduction
1.1 Purpose
1 2Scope 1.2 Scope
1.3 Definitions and Acronyms
2. References
3. Decomposition Description
3.1 Module Decomposition
3.1.1 Module 1
3.1.2 Module 2
3.2 Concurrent Process Definition
3.2.1 Process 1 Description
354
p
3.2.2 Process 2 Description
3.3 Data Decomposition
3.3.1 Data Entity 1 Description
3.3.2 Data Entity 2 Description
4. Dependency Description
4.1 Intermodule Dependencies
4.2 Interprocess Dependencies
4.3 Data Dependencies
5. Interface Description
5.1 Module Interface
5.2 Process Interface
6. Detailed Design
6.1 Module Detailed Design
6 1 1M d l 1 D t il
355
6.1.1 Module 1 Detail
6.1.2 Module 2 Detail
6.2 Data Detailed Design
6.2.1 Data Entity 1 Detail
6.2.2 Data Entity 2 Detail
Implementation
356
Implementation
Having
Proposed the product in the concept phase, p p p p ,
Defined the product requirements in the requirement phase,
Partitioned the SW and HW functions in the design phase,
Approved and signed-off the design by the customer,
The hardware and software designers can now
write the code
and assemble the hardware in what is termed the
implementationphase
357
implementation phase.
In theory, this phase should only begin when the design
phase has completely ended.
Implementation Cont
In practice, however, there is some overlap
which is desirable since problems in the which is desirable since problems in the
requirements not detected in the design phase
are usually flushed out during implementation.
In addition, the software test team can
implement the test cases specified in the design
phase in some form using batch files or other
techniques
358
techniques.
This approach guarantees the efficacy of the
tests and facilitates repeat testing.
Implementation and Test
Consists of
HW and SW implementation
BoM
Configuration management
Verification and validation
359
Verification and validation
Test
Implementation HW
development and programming
Having designed the product down to the lowest level,
the next stage is implementation.
The responsibility of the HW and SW engineers in this
phase is to
build,
write and
debug the HW and SW modules to perform as specified in the
detailed design document.
Thus the development engineers now fill in the detailed
omittedin the design phase
360
omitted in the design phase.
The HW development and programming end
when the HW-SW have been integrated and
has successfully passed the integration testing specified by the
system designers.
Implementation Bill of
Materials
Implementation of the hardware centres on the Bill of
Materials (BoM). ( )
It is the process of converting a set of specifications into
a list of parts and data necessary to integrate those parts
into the product.
The process is of course not pure top-down.
In real life, design is carried out with knowledge of the
components that are available.
361
During implementation, sets of schematic diagrams or
netlists are created for the electronics part of the design.
Drawings are created for the mechanical
parts of the design parts of the design.
Functions, procedures, objects, routines
and programs are created for the software.
Each is created at the lowest level; verified
and, finally, integrated to form the next
hi h t l l
362
highest level.
Implementation is, therefore, carried out
bottom-up.
Implementation
Technology choices
At the lowest level of both design and implementation,
choosing the right technology is very important. g g gy y p
It can make the difference between success and failure.
The criteria of choice are vital and should be established
as part of the design process even considered at the
analysis phase although,
specifications should not be formulated with a particular
implementation in mind.
However it must be clear right fromthe earlier stage of
363
However, it must be clear right from the earlier stage of
the product development process
that a feasible technology exists, and
that the engineers who will make the implementation choices will
have clear criteria to enable them to do that successfully.
System configuration
management
The configuration of a system is the particular
arrangement of elements that compose the whole
d i ti description.
During the development of a product, there will be many
configurations that represent the various stages of the
product development.
There will also be many versions of the documentation,
the hardware, the software, and so on.
Some of these will work together and some will not.
364
Unless you can be sure that what you are working is a
consistent set, a lot of time can be wasted.
Managing the configuration in large project using a
consistent approach must be done from the beginning of
the design phase.
Configuration control
Configuration control consists of activities and
procedures needed to document all changes to the p g
configuration and ensures that changes take place only
after they have been approved.
It provides traceability and accountability for the
evolution of the configuration throughout the Systems
Development lifecycle.
Configuration control is particularly important when
building prototypes so as to ensure that all models are at
365
building prototypes so as to ensure that all models are at
the same revision.
The management of the programming phase can be
greatly enhanced with version control software.
Version Control
Version control software is a system that manages the
access to the various components of the system from p y
the software library.
Version control prevents multiple access to the same
source code, provides mechanisms for tracking changes,
and preserves version integrity.
In the long run, it increases overall system reliabilities.
To assist you in the administration of the programming
h f A li d M t P j t
366
phase of your Applied Management Project,
Subversion version control system has been made
available in the project lab and the computing suite of the
School.
VVT
Verification, Validation, Test
367
Verification, Validation and Test
Verification takes place throughout the design
and implementation cycle and implementation cycle.
Validation and test, on the other hand, are
carried out on a complete design.
Barry Boehm, the software engineering guru,
sums up
lid ti i th ti A b ildi
368
validation as answering the question: Are we building
the right product?
verification as answering the question Are we
building the product right?
Verification
Verification and validation are two distinct processes
that satisfy the need to confirm that the system conforms to both y y
the requirements specification (validation) and
the system specification (verification).
Verification (evaluating, rectifying and documenting) is
planned and executed at each level of integration.
Verification is planned top-down as part of the design
process but is executed bottom-up as part of the
implementation process
369
implementation process.
The idea is to test every component prior to it being
assembled in the next level of the structure.
Validation
Validation, on the other hand, is planned
t f th l i h d i as part of the analysis phase and is
executed on the complete design.
370
Testing
Testing - although ongoing testing is an implicit
part of the software and hardware development p p
process, an explicit test phase exists as well.
The explicit phase begins when the
programming and HW construction phase has
completely ceased.
It is during the explicit testing phase that the
software is confronted with a formal set of test
( d l d t l l) d l d i
371
cases (modules and system level) developed in
parallel with the software.
Acceptance or rejection of the software is based
on how well it fares against the test set.
Test Phase
This test phase is rigidly controlled in that only bonded
code is used and no changes to the documentation are
ll d allowed.
The phase is completed when either
the criteria established in the software test requirements
document are satisfied, or
failure to meet the criteria forces the project to re-enter a
previous phase (such as design phase).
Regardless of the outcome, one or more test reports are
prepared summarising the conduct and results of the
372
prepared summarising the conduct and results of the
testing.
This test phase, then, takes care of the following items.
Perform software validation, and
Prepare test reports
Verification, Validation & Test
(VVT)
Effective VVT will depends on how carefully the earlier
phases of the project have been carried out. p p j
Standardisation of VVT is important.
The QA requirements and the test plan should form part
of the early specifications.
The system test plan is part of the systems specifications
and the test specifications apply to every level of the
implementation process.
373
Every requirement established in the system
specification should be verifiable by the system test plan.
Initial Manufacture
374
Initial Manufacturing
During the Initial Manufacturing, work continues on the
BoM to ensure that the necessary components are y p
available and that they are as cost-effective as possible.
Detailed changes to the design and the BoM take place
at this stage.
A trial number of units is produced and the full
production process is run for the first time.
Some beta units are released for evaluation by
f i dl t i fi ld t i l
375
friendly customers in field trials.
Some units are test marketed, shown at trade-shows.
Initial Manufacturing
Encompasses
BoM
Design data and drawings
Pre-production build
Field trials
Software maintenance
376
Software maintenance
Product Deployment
During the product deployment, problems
in the software will invariably be found and in the software will invariably be found and
areas for improvement identified.
Any changes in the software due to these
sources are usually handled by making a
software change and then performing
testing
377
testing.
The software maintenance ends when the
product is no longer supported.
Volume Manufacturing
378
Volume Manufacturing
The final phase in the product design and
development flowis volume manufacturing development flow is volume manufacturing.
It is largely a matter of scheduling the production
of large volume.
This involves very little input from the project
team.
Th j t lif l i i th l t h
379
The project lifecycle is in the closeout phase,
and later the customer service phase.
References
Australian Microelectronics Network: A managers guide
to the electronics design process. Reprint from the g p p
booklet of the same name produced as part of the UK
Department of Trade and industrys Electronics Design
program, 2004.
Laplante , P.A. : Real-time systems design and analysis.
2nd edition, IEEE Press, 1997, Ch 4.
Taylor, J .: Managing information technology projects
380
strategies to software, hardware, and integration
initiatives / American Management Association, 2004,
Ch 3.
Source Boehm 1998
Project Management for Electrical Engineering 1/2

Project Management for Electrical Engineering 2/2
Field Programmable Gate Array

FPGA is a technology in which fixed digital logic resources are accessed via
programmable interconnect. This allows FPGAs to be sold as standard parts and
configured for their required logic function by the designer. FPGAs range in size from
small PLD-like devices to complex multi-million gate devices. Large FPGAs require
similar front-end design techniques to ASIC, since debugging in the lab without prior
simulation-based verification is practically impossible.

Since FPGAs are purchased as standard parts there is no hardware non-recurring
engineering (NRE) charge associated with developing a design. Part costs range from a
few dollars to a few thousand dollars. FPGA design is stable, and being used in volume, a
programmed FPGA can be turned into hardwired device to reduce cost. Translating into
ASIC (application specific integrated circuit) will yield further cost reductions for high
volume production.

Project Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management

Uploaded by

Copyright:

Available Formats

21/07/2014

You might also like