EM275

Project Management

Week 3

Onur Asan, PhD

School of Systems and Enterprises
oasan@stevens.edu
TA: Yutong Zhao
yzhao102@stevens.edu

1
Project Team members
Group 1: Victoria, Johnny, Melissa, Anthony

Group 2: Nelson, Kristy, Sanjana, Vanessa

Group 3: Jonathan, Alexis, Juliana, Cormac

Group 4: Elli, Austin

Group 5: Kayleigh, James, Fiona, Aidan

The Context of Information Technology Projects

• Project context
– IT projects are diverse.
– Has a critical impact on which product
development life cycle (Agile, waterfall etc)
will be most effective for a particular
software development project
• Several issues unique to the IT industry have
a critical impact on managing IT projects
The Nature of IT Projects

IT projects can be very diverse in terms of size,

complexity, products produced, application area,
and resource requirements

The nature of software development projects is

even more diverse than hardware-oriented
projects

IT projects also support every possible industry

and business function
Characteristics of IT Project Team Members

IT project team members often have diverse backgrounds

and skill sets

Many companies purposely hire graduates with degrees in

other fields such as business, mathematics, or the liberal
arts to provide different perspectives on IT projects

Some IT projects require the

But some require inputs from
skills of people in just a few job many or all of them
functions
Diverse Technologies
IT projects use diverse technologies
that change rapidly
Differences in technical knowledge
can make communication between
professionals challenging
New technologies have also
shortened the time frame many
businesses have to develop, produce,
and distribute new products and
services
Recent Trends Affecting Information Technology Project
Management

• Globalization
• Outsourcing: Outsourcing is when an organization acquires goods and/or
sources from an outside source. Offshoring is sometimes used to describe
outsourcing from another country
• Virtual teams: A virtual team is a group of individuals who work across time
and space using communication technologies
• Agile project management: - move quickly/easily - Requirements are
unknown and continuously changing.
– Also, an organization agility, not just about being fast, but also capacity
to remain in touch with customer needs
– Transformation is more than technology going Agile, it is a change in
mindset across the organization to be adaptable
Globalization

Issues

• Communications: Teams work in different time zones

• Trust: Build trust immediately by recognizing and respecting others
• Common work practices: Align work processes and develop modus
operandi
• Tools: free tools, Project Management Software tools all inclussive

Suggestions

• Employ greater project discipline

• Think globally but act locally
• Consider collaboration over standardization
• Keep project momentum going
• Use newer tools and technology
Outsourcing

Organizations remain competitive by using

outsourcing to their advantage, such as finding
ways to reduce costs

Practice can be unpopular on some countries

Project managers should become more familiar

with many global and procurement issues
Virtual Teams (1 of 2)
A Virtual Team
- Group of people who work together despite time and space
boundaries using communication technologies
• Advantages
– Lowering costs – no office space and so on
– Providing more expertise and flexibility or increasing
competitiveness and responsiveness by having team
members from across the globe working any time of
day or night
– Eliminating fixed office hours and the need to travel
to work – better work/life balance
Virtual Teams (2 of 2)

• Disadvantages

– Isolating team members

– Increasing the potential for communications problems
– Reducing the ability for team members to network and transfer
information informally – AT&T i2i
– Increasing the dependence on technology to accomplish work
Agile (1 of 2)

Agile means being able to move quickly and easily, but some
people feel that project management, as they have seen it
used, does not allow people to work quickly or easily

As technology and businesses

Early software development became more complex, the approach
projects often used a waterfall was often difficult to use because
requirements were unknown or
approach continuously changing

Agile today means using an approach where requirements and

solutions evolve through collaboration
Agile (2 of 2)
• Manifesto for Agile Software Development
– In February 2001, a group of 17 people that called itself the
Agile Alliance developed and agreed on the Manifesto for Agile
Software Development, as follows:
– “We are uncovering better ways of developing software by doing
it and helping others do it. Through this work we have come to
value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan”*
Scrum (1 of 4)

According to the Scrum Alliance, Scrum is the leading agile

development method for completing projects with a
complex, innovative scope of work.

The term was coined in 1986 in a Harvard Business Review

study that compared high-performing, cross-functional
teams to the scrum formation used by rugby teams.
Scrum (2 of 4)
(Repeat steps until enough items completed or budget finished or deadline arrives)

(retrospective)
Kanban (just in-time inventory control method)
– Technique that can be used in conjunction with
Scrum
– Developed in Japan by Toyota Motor Corporation
– Uses visual cues to guide workflow
– Kanban cards show new work, work in progress,
and work completed

Scrum (3 of 4)
Scrum (4 of 4)
• The PMBOK®Guide describes best practices for what should
be done to manage projects.
• Agile is a methodology that describes how to manage
projects.
• The Project Management Institute (PMI) recognized the
increased interest in Agile, and introduced a new certification
in 2011 called Agile Certified Practitioner (ACP).
• Seasoned project managers understand that they have always
had the option of customizing how they run projects, but that
project management is not easy, even when using Agile.

(PMBOK = Project Management body of knowledge)

Case Study 2: JWD Consulting’s Project Management Intranet Site
(Agile Approach)

• An agile project team typically uses several

iterations or deliveries of software instead
of waiting until the end of the project to
provide one product
– Teams do not normally make a snap decision
about whether to manage a project using an
agile approach or not
Scrum Roles, Artifacts, and Ceremonies (1 of 5)
Product owner: person responsible
for the business value of the project
and for deciding what work to do and
in what order, as documented in the
product backlog
ScrumMaster: person who ensures
that the team is productive, facilitates
the daily Scrum, enables close
cooperation across all roles and
functions, and removes barriers that
prevent the team from being
effective
Scrum team or development team:
cross-functional team of five to nine
people who organize themselves and
the work to produce the desired
results for each sprint, which
normally lasts two to four weeks
Scrum Roles, Artifacts, and Ceremonies (2 of 5)

An artifact is a useful object created Scrum artifacts

by people
Product backlog: list of features prioritized by
business value
Sprint backlog: highest-priority items from the
product backlog to be completed within a sprint
Burndown chart: shows the cumulative work
remaining in a sprint on a day-by-day basis
Scrum Roles, Artifacts, and Ceremonies (3 of 5)

• Scrum ceremonies (facilitated by SM)

– Sprint planning session: meeting with the team to select a set of
work from the product backlog to deliver during a sprint
– Daily Scrum: short meeting for the development team to share
progress and challenges and plan work for the day
– Sprint reviews: meeting in which the team demonstrates to the
product owner what it has completed during the sprint
– Sprint retrospectives: meeting in which the team looks for ways
to improve the product and the process based on a review of
the actual performance of the development team
Scrum Roles, Artifacts, and Ceremonies (4 of 5)
 Process Scrum Activity
Group
Scrum Roles, Artifacts, and Ceremonies (5 of 5)
Initiating
Determine roles
Decide how many sprints will compose each release and the
scope of software
to deliver
Planning
Create product backlog
Create sprint backlog
Create release backlog
Plan work each day in the daily Scrum
Document stumbling blocks in a list
Executing
Complete tasks each day during sprints
Produce a shippable product at the end of each sprint
Table 3-18 Unique Scrum activities by process group
Main differences between pre-initiation in this
case and the first case
– Determining roles and deciding what functionality
would be delivered as part of each release
– How many sprints will be required to complete a
release
– How many releases of software to deliver

Project Pre-Initiation and Initiation

Planning (1 of 3)

Because Scrum implies that

team members work as a self- Descriptions of work are
directed group, coached by the identified in the product and
ScrumMaster, a team charter sprint backlogs
should not be necessary

More detailed work is Team must estimate a velocity

documented in technical stories or capacity for each sprint
Planning (2 of 3)

• Notice that the process groups do not follow a simple linear pattern
• Also, several process groups are repeated for each sprint resulting in several releases of a
usable SW product
 Product Backlog Sprint Backlog
Planning (3 of 3)
1. User story templates, samples, 1. User story templates, samples,
and point person and point person
2. WBS templates, samples, and 2. WBS templates, samples, and
point person point person
3. Project schedule templates, 3. Project schedule templates,
samples, and point person samples, and point person
4. Ability to charge customers for 4. Ability to charge customers for
some intranet products and services some intranet products and services
5. Ability to collect user suggestions 5. Ability to collect user suggestions
6. Business case templates, samples,
and point person
7. Ask the Expert feature
8. Stakeholder management
strategy templates, samples, and point
person
9. Risk register templates, samples,
and point person
10. Etc.
Executing
• The most time and money should be spent
on executing
– Plans are implemented to create the desired
product
• Agile approach: team produces several
iterations of a potentially shippable
product
– Users can access and make suggestions
• Communications are different
– Project team meets every morning, physically
or virtually
Monitoring and Controlling (1 of 2)

• The two main tools for monitoring and controlling in the Scrum
framework
– Daily Scrum: held each morning to plan and communicate work
for the day and discuss any risks, issues, or blockers
– Sprint review: work progress within a sprint can be represented
on a sprint board maintained by the ScrumMaster
• This is where tasks status are entered within a sprint – Not
Started, In progress, Ready to Test, Tested, Closed (Devs ,
Testers and product Owner update these statuses )
• Burndown chart: an important artifact used to graphically
display progress on each sprint
Monitoring and Controlling (2 of 2)

Burndown chart shows whether the team is doing well in that sprint, or if there is potential for trouble
Based on burndown chart,
• if it indicates trouble for completion, hence those stories should be removed,
• if team is doing very well, stories should be added to the sprint,
Closing
• After the sprint review, the ScrumMaster
leads a sprint retrospective
– Team reflects on what happened during the
sprint
• Sprint retrospective is intended to answer
two fundamental questions
– What went well during the last sprint that we
should continue doing?
– What could we do differently to improve the
product or process?
32
Identifying Major Tasks
When you are planning a new project, the major tasks (activities) should be
identified

This is like building an outline – what are those things that have to be done to
succeed

Think Major Tasks, not features and specifications, e.g. Design Phone Case
not choose material (minor task)

33
Examples of Major Tasks*
Project planning phase
Budgeting phase
Getting your project under contract (e.g. Government contract)
Getting a vendor under subcontract
Acquiring materials
Inspections
Major tests
Approvals
and the list goes on…

34
Milestones
While managing a project, it is important to measure
your progress toward the project goal
It is also important to have intermediate successes
A milestone can be an event, or a deliverable,
that marks a point in time in your projects progress

These are important events to achieve

They are a measure of progress
Why is measuring progress important?

35
Learning Objectives

At the end of this module, you will be able to:

• Understand the steps in the project planning process

• Explain the role of the WBS in the planning process
• Develop a simple Work Breakdown Structure (WBS)
• Explain how a WBS is critical in managing any project
• Discuss common errors in building a WBS

36
The Planning Process

“The first 90% of a project takes 90% of the time, and the
last 10% takes the other 90%.” Tom Cargill, Bell Labs

 Great Planning requires three things:

 Knowledge of the work to be done
 Understanding the process of planning
 Capability with the tool to be used
 Very few projects today are planned well
 Poor planning is very expensive

37
Work Breakdown Structure:
What is a WBS?
You can’t plan the work if you don’t understand the work!
 Identifies the work that must be performed
 Illustrates project architecture
 Partitions work into work packages
 Reflects how you will integrate key components
 Illustrates how work will be assigned

 Basis for
 The project schedule
 Bottom-up cost estimate
 Earned Value management
 Assessing risks and opportunities

38
Purpose of the WBS

You can’t plan the work if you don’t understand the work!

 Represents what could be called a project

architecture
- Partitions work into manageable work packages
- Reflects how you will integrate key components

39
The WBS
Last time we identified out major tasks and milestones for the project
Now we are going to translate that into the Work Breakdown Structure (WBS)

The WBS defines and groups individual, or

discreet, project work elements, or tasks

“Marching orders”

40
Why the WBS is so important …

 The WBS is the key to a successful project plan, and a

successful project plan is key to a successful project.

 It is the basis for all subsequent planning and

execution management of the project.

 A poorly defined WBS will result in a poorly managed

project destined for failure. All issues will be fruit of the
“poison tree”.

41
Work Breakdown Structure:
What does it take to create a WBS?
The WBS reflects how the PM intends to manage the project.
 Involve the right people
 PM, SE, Key Subsystem managers, Contract managers,
 Subcontractors, Consultants

 Start with the Product Breakdown Structure

 Identifies all project deliverables/end products
 Identify all intermediate products and tasks to produce those end products

 Define the work down to your level of risk

 Define all the work that you intend to manage or delegate

 Show traceability between WBS and Requirements

 All requirements should be traceable to one/more WBS elements

42
Product Breakdown Structure

Decomposition of the Final Deliverable

 Part of the Planning Process
 Product based (or Service based) planning technique
 Defines all the deliverables for the project through decomposition into
components.
 Product Breakdown Structure (PBS) defines where you want to go -
necessary outcomes of the project.
 Leading to….
 Work Breakdown Structure (WBS) tells you how to get there – activities
needed to achieve that goal.

43
Work Breakdown Structure:
Developing a WBS—Best Practices
How many ways can you build a barn?
BARN

Architectural Lumber Permits Electrical Project

Drawings System Management

BARN BARN

Choose Hire General

Purchase Prepare Install
Design Contractor
Pre-Fab Site On-Site

44
Work Breakdown Structure:
I want to build a bicycle…

45
Work Breakdown Structure:
I want to build a bicycle…
1.0
BICYCLE

46
Work Breakdown Structure:
I want to build a bicycle…
1.0
BICYCLE

1.1 1.5 1.6

1.2 1.3 1.4
Gear Installation Manual
Frame Brakes Seat
Assembly & Test Documentation

47
Work Breakdown Structure:
I want to build a bicycle…
1.0
BICYCLE

1.1 1.5 1.6

1.2 1.3 1.4
Gear Installation Manual
Frame Brakes Seat
Assembly & Test Documentation

48
Work Breakdown Structure:
I want to build a bicycle…
1.0
BICYCLE

1.1 1.5 1.6

1.2 1.3 1.4
Gear Installation Manual
Frame Brakes Seat
Assembly & Test Documentation

1.1.1 1.1.2 1.1.3 1.1.4

Chain Shift Levers Cables Gear Mechanism

49
Work Breakdown Structure:
I want to build a bicycle…
1.0
BICYCLE

1.1 1.5 1.6

1.2 1.3 1.4
Gear Installation Manual
Frame Brakes Seat
Assembly & Test Documentation

1.1.1 1.1.2 1.1.3 1.1.4

Chain Shift Levers Cables Gear Mechanism

Notice that we maintain a consistent, structured

1.1.1.1 1.1.1.2 numbering scheme across levels and between
Develop Procure
Chain Specs Chain levels. 1.0>1.1>1.1.1>1.1.1.1

50
Indentured Format—WBS for Bike

51
Task Flow
Begin asking yourself – what is the best order
that these tasks should be performed?
What are my dependencies?
Do some things have to be done
before other items?
Can some things be done at the
same time to reduce overall
schedule?
Can you create a flow of events?

52
WBS Example 2

53
Another Example

54
WBS Development Tips…

Before you add the final level of tasks, you have a

Product Breakdown Structure.
When you add the lowest level “tasks” (verbs) you then
have a Work Breakdown Structure.
Do not start with a “functional” approach.
(trust me on this!)
WBS development is a team effort.
If the WBS is wrong, the schedule will be wrong, the
budget will be wrong, and your EV system will not be
workable.

55
How much detail?

 One level below expected management visibility

(verbs)
 At the level of work assignment – one person in
charge for one deliverable
 One level above the detailed planning level
 HOWEVER also consider…
 Risk – more risk, more detail
 Complexity – more complexity, more detail
 Understanding of the problem –
less understanding, more detail

56
WBS Concepts (Week 3.2)
Summary tasks
These are probably your top level activities we identified last time

Decomposition of tasks
Decompose those major tasks into smaller tasks or individual tasks

Work package
Collection of tasks

57
Work Breakdown Structure:
Developing a WBS—Best Practices
The WBS reflects how the PM intends to manage the project.

• Involve the right people

PM and representatives from the right disciplines
• Start with the Product Breakdown Structure if one exists
• Identifies all project deliverables/end products
• Identify all intermediate products and tasks to produce those
end products
• Define the work down to your level of risk
• Define all the work that you intend to manage or delegate
• Show traceability between WBS and Requirements
• All requirements should be traceable to one/more WBS
elements

58
Function WBS – the WRONG way
too easy to miss steps/parts

59
Phase Breakdown – Alternative
(we will use product breakdown)

60
Product Break

61
How much Detail?
However, in general I have found an easy rule of thumb is
that the lowest level task/work packages that end up in
the schedule should be about a reporting cycle long.

In other words, if the schedule is being updated weekly

(and most projects should probably do at least weekly
updates) tasks should at a level of 2 days to 2 weeks.

If the schedule is being updated every other day, then

tasks should be, order of magnitude, about 2 days i.e.
anything from 1/2 day to no more than 4 days.

62
WBS Dictionary
WBS Dictionary defines parts of WBS.

 Details description of each task and WBS item

 Describes coding scheme (1.1.1.1 or F35.E.7.2.1)
 Defines the deliverable product
 WBS and the WBS Dictionary form the Scope Baseline
Includes but not limited to:
Code of account identifier Resource Required
Description of Work Cost Estimates
Responsible Organization Quality Requirements
List of Schedule Milestones Acceptance Criteria
Associated Schedule Acitivites Technical References
Contract Information

63
WBS Dictionary
WBS Dictionary defines parts of WBS.

64
WBS Development Tips…

 Many companies and organizations (including

governmental and military) have WBS templates that
define the level of decomposition. Generally for
governmental projects the lowest level must be one
below that required for financial reporting.
 The team will use the WBS to define the work and plan
the work. Finance will use the WBS to manage the
finances (and cash flow) of the project.
 If your project has more risk and more complexity, you
will want more detail in your WBS.

65
WBS Block by Block
1. Clear direction/definition
2. Appropriate level of
complexity
WBS Guidelines Block Castle Guidelines
Make sure you have successfully Have a clear understanding of what it is
completed your project you’re about to build before you
initiation activities before start. Trying to change from a castle to a
embarking on a detailed WBS. bridge halfway through will be
troublesome.
Develop the WBS to an Building a castle using only 10 blocks might
appropriate level of detail—one be quick, but it won’t be very
that provides the information useful. Alternatively, trying to build a
you need to control the project, 10,000 block version of Edinburgh Castle
but doesn’t swamp you with will probably consume more time than you
data/information. realistically have available.

3. Team work The content of the WBS should
be mostly provided by your
project team and key project
stakeholders – not by the
project manager.
If you recruit your family to build the castle,
with your help and direction, they are more
likely to appreciate the end result, and less
likely to knock it down when you’re not
looking.

66
 WBS Block by Block
WBS Guidelines
4. Completeness The WBS should describe the
work of your whole
project. And there shouldn’t
be anything in the WBS that
isn’t part of your project.
5. Accuracy When documenting the
detailed boxes (children)
underneath a WBS element
(parent), the children must
completely and exactly
describe the same amount of
work as the parent, just in
more detail.
Block Castle Guidelines
Make sure you build all of the castle’s
features, as one with only three walls
isn’t very effective. And castles generally
don’t have swimming pools – so don’t
include one in your castle floor plan.
Make sure the first floor of your castle is
complete and well-aligned – otherwise it
will not support the blocks that comes
later, and you’ll be left with all your floors
combined into one.
67
Lab Time/In class assignment 2

Open MS Project

WBS Quick manual

Youth 10K/run manual. Replicate as a practice ( 30 min)

In class assignment: Create WBS Hoboken Kindergarten Roadside Show (30

min) Submit in Canvas by end of class

68
Homework 2 – Create WBS

Create a WBS for your project down

3-4 levels of detail

This is our first attempt at WBS, you

will do your best as a team and we
will review/revise as class lessons.

Submit via Canvas by February 12,

8.59 am
69