Yale waterfall delivery approach training deck

IT Project Delivery Approach
and how you can avoid sinking

A training class prepared by the ITS PMO – June 2010

Special thanks to Jenny Greene (http://www.stellman-greene.com) for letting us borrow some of the concepts and graphics used within

Why are we here?
To learn about the IT project delivery approach

WELCOME CLASS!

After this training you should:
Be able to describe and use the basic
structure of the IT project delivery
approach
Understand some of the best practices that
help projects to be successful
Know where to get more information and help
when you need it
Be better prepared to help your projects
succeed!!

2

Today‟s agenda - Timing may be variable!
Section Duration Start End
Introductions 30 9:00 9:30
Opening 30 9:30 10:00
SDLC
Placemat Orientation 10 10:00 10:10
Plan & Analyze 40 10:10 10:50
Break 10 10:50 11:00
Design/Build/Test/Deploy 45 11:00 11:45
Case Study I 20 11:45 12:05
Lunch 30 12:05 12:30
Case Study Feedback 15 12:30 12:45
Governance
Overview 30 12:45 1:15
Processes
Overview 30 1:15 1:45
Break, Case Study 60 1:45 2:45
Odds & Ends 15 2:45 3:00
3
Closing and Survey 15 3:00 3:30

Who are we?
Before we begin, let‟s get to know each other

Please tell us about:
 Your department and role
 Years at Yale
 Previous experience / familiarity with project
delivery methodologies
 One interesting project experience you‟ve had

4

So, what is a project?

Will deliver business and / or technical objectives in line
with the University‟s strategic direction

Runs for a defined period of time (has a start and end
date)

Has a budget

Uses University resources

5

Work Categories
All requested work can be categorized based on size or type

Central
A Major project, estimated at $250k or more

funding,
allocated by
officers each
year
B Minor project, estimated between $50-$249k

Client funded S Self funded request of any size

Baseline C Small enhancement, estimated at less than $50k
funding, pre-
set each year

M Maintenance and break/fix requests

6

What is a project delivery approach?
Our approach includes:

 Solution and business integration development lifecycle (SDLC)
– What activities do I perform?
– What deliverables do I create?
 Project governance framework
– Who is responsible for what?
– How are decisions made for a project? Across all projects?
 Project management Processes
– How do I manage scope, schedule, cost, resources, quality,
communications, risks and vendors?

7

What is project success?

Project success occurs when we have:

 A satisfied client (expectations met) Scope

 Delivered the agreed objectives

 Met an agreed budget ($, resources, etc)

 Within an agreed time frame

And, we‟ve done it all professionally
and without killing the team
Time Cost
“Scope, Schedule, Cost”
The “Golden Triangle”
of Project Success 8
According to Gartner, approximately
60 – 70% of IT projects fail

Simply put, success is a balancing act
YOU THINK THIS IS HARD?
IN MY LAST JOB I
MANAGED PROJECTS WITH
MULTIPLE STAKEHOLDERS
AND CONFLICTING
PRIORITIES

9

Before we look at the approach, let‟s
first examine why projects fail
The bridge was nicknamed “Galloping
Gertie” due to movement on windy days

Not all failures are this easy to spot . . .

 The Tacoma Narrows Bridge
project failed before the first
yard of concrete was poured

 There was nothing wrong with
the construction. Poor design
and badly planned cost cutting
in materials led to an
unfortunate end

 No human life was lost when
the bridge collapsed on
11/7/1940, but Tubby the dog
went down with his owners car
when he refused to be
removed 10

“This time it‟s different”
There‟s an old saying about how there are a million
ways to fail, but only one way to be right. When it
comes to projects, nothing‟s further from the truth.
Projects fail the same few ways over and over again.

Don‟t go in the basement!
Technology projects are a lot like cheesy horror
movies. After you‟ve seen a few of them, you know that
the first guy to leave the group is going to get an axe in
his head. Projects are the same way. People keep
making the same mistakes over and over, and it keeps
getting their projects killed.

11

You know you‟re on a failed project when . . .
JETSON,
YOU‟RE
A judge in 1964 said (and we paraphrase), “I FIRED!!!!
don‟t know how to define pornography, but I
know it when I see it.” And the same goes for
failing projects - we can all spot a failing
project when we see one.

What does a failing project look like?
You certainly know your project failed if it got aborted
and everyone was laid off. But there are other, less
obvious kinds of failure:

 The project costs a lot more than it should
 It takes a lot longer than anyone expected
 The product doesn‟t do what it was supposed to
 Nobody is happy about it
Justice Potter Stewart‟s concurring opinion in Jacobellis v. Ohio: “I shall not
12
today attempt further to define the kinds of material I understand to be
embraced within that shorthand description; and perhaps I could never
succeed in intelligibly doing so. But I know it when I see it.”

Sometimes failure seems normal
Nobody sets out to fail, but for some reason people
just accept that a lot of technology projects won‟t
deliver on time, on budget with the expected scope
intact. But talking about what causes failure makes
people uncomfortable, because nobody wants to give or
take that kind of criticism.

A show of hands, please…
We‟ve never met a single IT professional with more than
a few years of experience who hasn‟t been on at least
one failed project.

Are there any here?

13

Four basic ways projects can fail
There are plenty of ways that you can categorize
failed projects. We like to think of them like this:

 Things the product does (or doesn’t do)
How your project doesn‟t quite meet the needs of the people
you built it for

 Things the team should have done
Once in a while, it really is the team‟s fault

 Things that could have been caught
. . . but weren‟t until it was way too late

 Things the boss does
Classic management mistakes that can damage the project

14

Things the product does (or doesn‟t do)
It seems pretty obvious that you
should know what the software‟s
supposed to do before you start
building it... not that that stops
us.

 We only find serious problems after
we‟ve built them into the product

 Scope keeps changing and growi ng
 No one is sure who gets to choose what
the product does
 90% done, with 90% left to go

15

Things the team should have done
The team could have done the work more
efficiently, if only we‟d taken the time
to think it through.

 Planning is not done thoroughly

 Issues and risks are not identified and
acted upon quickly enough

 Dependencies are not understood

 Expectations are not managed well

16

Things that could have been caught
Which would you choose: a well built
product that doesn‟t do what you need
or a crappy one that‟s irritating to use
and does?

 Getting a few tech support people to
“bang on the software” is not testing

 Maybe we could‟ve caught that design
problem before the code was built

 Maybe we could‟ve caught that code
problem before we went to test

 Wishful thinking does not make an
application run faster

17

Things the boss does
Some problems start with senior
managers, others start with key
stakeholders, but they can all sink the
project.

 Over promising

 Ignoring issues and risks

 Artificial wall between the business
and technology

 Over simplifying

18

Brains are important too . ..
HOW MANY TIMES
A good approach is not a replacement DO I HAVE TO TELL
for good judgment and sound skills. We YOU, IT‟S RIGHT
TIGHTY, LEFTY
could have the best tools in the world, LOOSEY
but most of us still could not fix the
space shuttle or perform surgery.

 A sound approach is a good start, but
we also need to be the owners of our
own ability
 Understanding how to use the tools
and your own personal development
path is probably the most important
thing we would like you to learn today
 The good news is that a standard,
proven approach will help us to focus
on the execution of the work and help
us to better help each other

Goober worked at Wally's Filling Station, which he 19
eventually purchased and became the proprietor

The talent is there… the delivery management‟s not

Hoover Dam was finished two years
early, and under budget. Technology
projects are not so different that we
can‟t engineer them just as well.

 Our problems have, for the most part,
been solved
 Over and over and over again.
Seriously.
 We just have to stop ignoring the
solutions

The building of the Hoover Dam started in 1931 and finished in 1935,
two years earlier than scheduled. And this is the reason chief 20
engineer of the project, Frank T. Crowe, was nicknamed “Hurry up”.

Ok, let‟s get to the good part
Our approach encompasses three areas:

Solution and business integration lifecycle (our SDLC)

Project governance

Project management processes

Let’s start by reviewing the SDLC . . .

21

The Waterfall approach, or “how safe is
your barrel”?

Concept
 The Waterfall Method was introduced by
Winston Royce in 1970. It is the oldest and
Requirements & Plan
most widely used development approach
 SDLC and Waterfall are not the same –
Waterfall is one type of SDLC
Design Solution AND MY
 It involves a sequence of steps or stages, DRESS DIDN‟T
EVEN GET
output from one stage is input to the next WET
Build and Unit Test
Solution Parts  Stages can sometimes overlap, but there
are very definite goals for each phase
Integration Test and
Customer Acceptance
 Biggest drawback of the waterfall model is
that revision (scope and design changes) can
be difficult and costly if not managed
Deploy properly

Later we will talk about a concept called “Phase Containment”
that helps to manage some of the drawbacks of waterfall

22
Winston W. Royce (1929–1995) was an American computer scientist, director at Lockheed Software Technology Center in Austin, TX, and one of the leaders in software development in the second half of the 20th century. He was the
first who described the Waterfall model for software development

Phases
Plan Analyze Design Build Test Deploy

Operate
Initiate

Our implementation of the waterfall approach uses the following phases:

 Initiate – Request a new project and get approval to allocate resources (and spend $$!)
 Plan – Create project plan and define goals and expectations
 Analyze – Confirm requirements for the product
 Design – Detail the design of the product
 Build – Create the product
 Test – Validate that the product does what it is supposed to do
 Deploy – Move the product into production
 Operate – After the project is closed, run the product in production
23

Initiate Phase

Operate
Initiate
The project charter is the primary outcome of the Initiate
phase.

It prepares the project to officially launch, which means the
project can begin to allocate resources and spend money.

 Names sponsor, business relationship
manager and project lead
 Project purpose
 Strategic fit
 Success metrics
 Known scope & requirements (high level)
 Known stakeholders
 Known risks & constraints
 Project governance
 Rough order of magnitude (ROM) schedule,
resources and costs
 Milestones, resources and costs for next
phase (typically plan or plan and analyze) 24

Plan Phase – What we get Plan Analyze Design Build Test Deploy

Operate
Initiate
By the end of the plan phase, we
should know:
 What is in scope, what is out of scope
 The high level requirements of the target state applications, processes and
organization
 The current state of the applications, processes and organization
 The proposed target state of the applications, processes and organization
 The steps needed to move from current state to target state
 An approach for sourcing
 Approaches for managing the projects scope, schedule, cost, resources, risk, quality
and communications
 Which deliverables the project will produce
 Whether we will buy and / or build technology
 Which package(s) will be used for technology that will be bought
 The underlying technical infrastructure needed to support analysis and design
 Who the stakeholders are and what is important to them
 The potential impacts on the target organization
 Who we need to communicate to, when, how, why and to say what
 A draft plan, team and cost estimate on what it will take to move from current to
target
25

Plan Phase – What we do Plan Analyze Design Build Test Deploy

Operate
Initiate
Formally establish the project. Staff initial team members,
begin project meetings, establish steering committee,
create project status reports

Document how the project will be organized and governed –
consider who is responsible for each aspect of the project,
how the team will be organized, what forums will be used to
govern the project and who is on each forum

Define the underlying technical architecture required to
support the target application environment

Define who needs to know what, when, how and why

Assess the delivery approach and tailor it to the needs of
the project. This includes phases, activities, deliverables,
gating, sourcing, usage of vendors and other 3rd parties, etc

26

Plan Phase – What we create Plan Analyze Design Build Test Deploy

Operate
Initiate
The solution blueprint contains a definition of the target
state environment. This can include (but is not limited to)
the application, infrastructure, process and organization
target states. In addition, target training and the project
delivery approach are documented here
The stakeholder and organization impact analysis
documents the stakeholders, their degree of influence on
the project and how they will be impacted by the
project. It also documents potential organizational impacts

The project management plan documents the project scope,
schedule & cost and how these items will be managed /
governed
27

Analyze Phase – What we get Plan Analyze Design Build Test Deploy

Operate
Initiate
By the end of the analyze phase, we
should know:

 How the target state processes will work
 The detailed requirements that the target state must support
 Where there are gaps in how the vendor package(s) support the requirements
 General approach for filling the gaps (e.g., custom mod, drop requirement, etc)
 Use cases and the conceptual data model, for custom development
 Identification of the RICEFW widgets that will be designed and built (RICEFW =
Reports, Interfaces, Conversions, Extensions, Forms, Workflows)
 High level designs to reflect how the requirements will be supported (where
applicable and needed to determine RICEFW definition)
 The approach that will be used to test that the target solution meets the
requirements and does not have a negative impact on other systems or
processes
 The definition of, and the plan to build (where necessary) the technical
infrastructure needed to support build, test and deploy
 The approach that will be used to train users and other impacted parties on the
target solution
 Understanding of the current organization
 Understanding of the impact of new processes and technologies on the
organization, including roles, jobs, teams and performance measures
 A baseline plan, team and cost estimate on what it will take to move from current
to target 28

Analyze Phase – What we do Plan Analyze Design Build Test Deploy

Operate
Initiate
Document the requirements that the target solution must
support. Consider requirements across functional, technical
and operational areas, as well as prioritization and potential
phasing of requirements

Reports, Interfaces, Conversions, Extensions, Forms,
Workflows. Define the set of widgets that will be
designed, built and tested. In some cases, a high level
design will be needed to fully identify the widgets

Consider and plan for any infrastructure components that
need to be procured, built and / or configured. This should
include your desktop infrastructure as well. Let‟s not
forget about the managed desktop!

For components of design & build that will be done in an
iterative fashion (typically applies most easily to
components that involve user interaction, such as process &
form design) define the set of iterations that will be
executed

Document how the end users will be trained and educated
on the usage of the target solution. Consider who needs to
be trained, when they need to be trained, how they will
receive training, what needs to be designed & built to
support training

29

Analyze Phase – What we create Plan Analyze Design Build Test Deploy

Operate
Initiate
The RTM documents each requirement of the target
solution and facilitates traceability between requirements
and associated test scripts. The RTM can also be uplaoded
into a testing tool, such as SQA, and Package system gaps
are also defined within the RTM

The security design review gathers data to facilitate the The test approach defines the test phases and cycles that
identification of potential security risks associated with will be used to test the target solution
the target state. Note that an initial completion of the
document is done in the analyze phase, with the final
version due at end of test

30

Design Phase – What we get Plan Analyze Design Build Test Deploy

Operate
Initiate
By the end of the design phase, we
should have:

 A prototype of the application to demonstrate how it will work
 For custom solutions, design of common application classes and
components
 For custom solutions, a logical database design
 Design of the application configuration
 Functional designs for reports, interfaces, conversions, extensions,
forms and workflows that describe how these components will work
 Necessary development environments are ready
 End user organization, roles and jobs are defined
 Design for the delivery of training
 Definition of how the target solution will be supported in the
operating environment (both functionally and technically), gaps
between the current and target support models, and the plan to
close the gaps

31

Design Phase – What we do Plan Analyze Design Build Test Deploy

Operate
Initiate
Build a model or working application that demonstrates how
the product will look, act and feel, with the intent of
gaining stakeholder feedback. This process can be iterated
as part of the iterative approach, where applicable

Define how the target product will be supported in the
operational environment, including the roles needed to
support, the gaps between current and target state, and
the plan to move to target

Create the functional designs for each widget that
describe visually and textually how each widget (and the
overall product) will work and what it will do

32

Design Phase – What we create Plan Analyze Design Build Test Deploy

Operate
Initiate
The workforce transition plan defines the steps and
approach to move from the current organization (jobs,
roles, etc) to the target organization

The prototype is a mock-up or “alpha” version of the target
product, with the intent of demonstrating how the product
will look, act and feel

The role descriptions document defines the roles and
responsibilities that will exist in the target organization

The training plan defines the details of each training
approach / session so that training can be planned and
coordinated
33

Build Phase – What we get Plan Analyze Design Build Test Deploy

Operate
Initiate
By the end of the build phase, we
should have:

 A master configuration for the packaged software that can be
applied to build and test environments
 Technical designs for reports, interfaces, conversions, extensions,
forms and workflows that describe how these components will be
built
 Built, unit and assembly tested application components
 For custom builds, a physical database created from the logical
data definition
 Test planning complete, including build of test cycles, scenarios
and scripts
 Plans to staff the new organization as necessary
 Built training and communications materials
 Technical infrastructure and environments ready for test, training
and deploy

34

Build Phase – What we do Plan Analyze Design Build Test Deploy

Operate
Initiate
Create the detailed technical designs that describe how the
target solution will be built
Create physical database

Define the test cycles, scenarios and scripts that trace
Build the materials that will be used to support end user
back to each requirement to ensure that each requirement
training
is tested

Build the remaining environments that are needed for test
training and deployment Confirm that the build objects meet organizational
standards, and have been appropriately unit and assembly
tested

35

Build Phase – What we create Plan Analyze Design Build Test Deploy

Operate
Initiate
The knowledge management content is the information
needed by the supporting organizations (e.g., service desk,
functional support, technical support, etc) to meet
expected service levels

The test plan is comprised of the cycles, scenarios and test
scripts that will be used to ensure that the target product
supports requirements

Update of the communications plan established in the plan
phase
36

Test Phase – What we get Plan Analyze Design Build Test Deploy

Operate
Initiate
By the end of the test phase, we
should have:

 A validated target product that meets performance, security,
functional, desktop, and end user expectations
 An agreed to freeze on changes to application code
 Approved security design
 A conversion process that has been tested
 Completed runbooks
 Agreed to contingency plans
 Tested cutover plans
 Piloted training
 End users and stakeholders that are aware of the forthcoming
changes, and prepared to accept them

37

Test Phase – What we do Plan Analyze Design Build Test Deploy

Operate
Initiate
Prepare and test the cutover plans end to end prior to
actual cutover. Iterate until the cutover process is working
at an acceptable level

Pilot the training, make adjustments based on feedback,
and then deliver training as planned

Ensure that the target solution meets the desktop Confirm formal approval from the sponsor and key
requirements stakeholders that the target product is ready to be
deployed into the production environment

Freeze all changes to the application code until the
application is deployed. Once the application is deployed,
bugs will be prioritized, fixed and the application regression
tested. New functionality should wait for a new release

Execute mock conversion to test the end to end conversion
process prior to actual conversion. Iterate until conversion
process is working at an acceptable level

38

Test Phase – What we create Plan Analyze Design Build Test Deploy

Operate
Initiate
Final version of security design review

The cutover plan documents the steps, sequencing and The runbooks are a handbook that describe the overall
timing of the activities needed to migrate from the test technical architecture and operational considerations for
environment to the production environment an application, and are used by the technical support teams
39

Deploy Phase – What we get Plan Analyze Design Build Test Deploy

Operate
Initiate
At the end of the deploy phase, we
should know:

 Data converted into production environments
 Application code migrated to production environments
 End users trained and communicated to
 Target state (organization, processes and application)
rolled out as specified by requirements and delivery
approach
 Critical and high priority post deployment issues resolved
during warranty period
 Responsibility for operating and maintaining the target
state is transferred to the operating teams
 Completed project closure report

40

Deploy Phase – What we do Plan Analyze Design Build Test Deploy

Operate
Initiate
Move all involved application and technical components into
the production environment

Execute user support model by providing launch support for
the end users and when appropriate move to the operational
user support model

Deliver the training and communications necessary to make
stakeholders aware of the target product, and enabled to
operate successfully in the target environment, with the
target tools

Identify, prioritize and resolve issues during the
deployment period until the target environment has
reached a pre-defined level of stability

Formally transfer operating and maintenance responsibility
to the operating teams, disband the project team, stop
project funding

41

Deploy Phase – What we create Plan Analyze Design Build Test Deploy

Operate
Initiate
The user feedback report documents the results of user
interviews, focus groups, usability tests, and other
interactions with users throughout the project

The project closure report provides an overall wrap-up of The training evaluation summary records feedback from
the project. It documents key learnings, known open items, end users on training, to help the team identify where
overall project execution statistics, etc training works, and where it would benefit from
improvement

42

Agile Techniques

Operate

Initiate
Design Build
Agile Techniques – For each Sprint:
Design UI, process Review build
Review design Customer
Confirm scope flow, workflow, Do incremental with customer
output or data
with customer and approval of
of sprint make changes build and make
usage sprint
changes

 Within the context of the waterfall approach, some functions may
benefit from a more iterative design & build approach
 Common examples include application forms, configuration and
reports, but can apply to any functions that can be mostly built and
validated on a stand-alone basis
 These techniques are not a replacement for full Agile development.
Agile is a different type of SDLC that is not covered in this training
 Beware that iterative development has it‟s own pitfalls, including
potential for rework and cost and schedule over-runs

43

Operate Phase

Operate
Initiate
Entry into the operate phase represents official closure of
the project

 Project funding ends

 Project team and governance disbands in favor or
operating team and governance

 Project resources go onto other projects or activities

 The operational teams take ownership of the application
and supporting processes

44

SDLC Summary

 Waterfall approach, but iterate and overlap when reasonable and
helpful

 Not just for software – considers business processes,
organization and communication

 Toolbox approach, tailor, tailor, tailor

Are there any questions on the SDLC?

45

Case study #1

Refer to case study #1 handout

46

Next, let‟s look at project governance . . .





47

What is governance?
There are probably few terms that are used as freely,
but understood as poorly, as the term “governance”. We
LET „EM HANG
Judge Isaac Parker
aka “The Hanging Judge”
will continue the trend by using it freely. However, we
will try to make some sense of what it is and why it is
important - mostly so that you can impress your friends
and neighbors, but also so that you can understand how
you can use it to help your projects to be more successful

 One definition of governance: “Specifying the
decision rights and accountability framework to
encourage desirable behavior in the use of IT”

 We can simplify it further: “Defining who is He has decision authority

responsible for what and who can make which
The unfortunate accused
decisions”

48
They are accountable

Levels of governance
Our approach considers governance at the project
level, and cross-project (or portfolio) level

Portfolio  Decisions that cross
projects, such as
funding, resources and
dependencies

 Decisions that are local
Project 1 Project 2 Project 3 Project n to a project, such as
scope, design approach
and deliverable quality

49

Project Roles ACTION!

How are projects like movies? No, not the long hours and poor
reviews from the critics. Both rely on standard roles to help them
run smoothly. On any movie set everyone knows what the key grip
and gaffer are responsible for. Successful projects operate in the
same way, with standard roles and clear understanding of
responsibilities and decision making authority.

 Sponsor - Proposes and champions the project. Responsible for
the project‟s success

 Relationship Manager - Responsible for translating business
vision into solution, staffing, and delivering solution

 Project Lead – Responsible for delivery of project scope, on
time and within budget

 Functional Lead – Responsible for delivery of the functional
solution

 Technical Lead – Responsible for delivery of the technical
solution

 Change Management Lead – Responsible for organizational and
user adoption of the solution

Like Eddie Murphy in The Nutty Professor, an
50
individual can play more than one role on a project!

Project Escalation Paths
WE‟RE BEHIND
SCHEDULE?
WHY DIDN‟T
YOU TELL ME?!

Bosses tend to be happier when you don‟t surprise them,
especially if the surprise brings bad news. Every team
member should know what to do when they have a problem
that they cannot resolve themselves. A well defined process
to identify, escalate and resolve problems is an essential
part of how any project is governed

 The structure and number of
escalation levels is dependent upon the
size and complexity of the project and
Steering the organization, but typically want as
Committee
few as possible
Project Status
Meeting
 Team members should be encouraged
Team Status
Meeting(s) (and empowered) to resolve issues at
the local level, but should also know
where to get help when they need it

 The Project Lead is responsible for
Team Status Meeting(s)
facilitating the escalation process, but
every team member is responsible for
Review progress, deliverables, issues, decisions, risks, etc related to a specific team or subset of
the project

Team lead Team members Team members Team members Team members
identifying, resolving and escalating
As defined by the team leads and project lead
problems 51

Portfolio Governance
The IT Projects and Planning Committee is the “supreme court” for decisions
that impact the portfolio of projects. Business specific issues may still
require escalation through the business area, but items that are IT related
or have impact across the portfolio of projects can be escalated to this
council for final decisioning

AS CHIEF
DO YOU SMELL
I THINK IT JUSTICE, I
SOMETHING
WAS ALITO DECLARE IT
FUNNY?
WAS SCALIA

52

Gating I SURE HOPE
MY GATING
PAPERS ARE IN
ORDER . . .

Gating is part governance function and part quality
assurance. The intent of gating is to help apply our
standards (such as this delivery approach) and to bring
broad transparency to the solutions being built. It also
helps to support the concept of “phase containment”
whereby the problems from earlier phases do not have a
snowballing affect on later project phases

Funding Starts Funding Baselined Deployment Decision Funding Stops
Plan and Analyze
($100k – 250k)
Small Projects

Approval

Express Path
Establish ROM Estimate
Screening and Definition

Does Not Gate
Enhancement

Sprints

Operate
<$100k

Initiate Plan Analyze Design Build Test Deploy

Go/No-Go Decision
Planning Estimate

Baseline Estimate

Design Approval
Planning Phase
Major Projects

Build Approval
(over $250k or

Requirements
highly visible)

Approval

Approval

Full Path

There can be multiple paths through
Project Launch Gate Plan Gate Analyze Gate Design Review Gate Build Review Gate Go/No-Go Gate Project Close Gate gating depending upon the project
type, size and complexity. Two
typical paths are shown here
“Are we ready to “Can this project be “Are the “Do we know how we “Does the code meet “Does the product “Can the functionality
start spending money successful based on requirements clear, will build the product our coding meet the be supported
planning this work?” the plans?” agreed to and to support the standards?” requirements?” operationally?”
achievable?” requirements?” “Are we ready to
deploy into
production?

53

Gating Approvals  Gating is facilitated by the “Gating
Questionnaire”, a set of questions
Gating is run by the key organizational leads that are for each phase
impacted by and / or responsible for project outcomes.  The questions are aligned by the
The transparency from gating gives these organizational areas supported by the key
organizational leads who attend
leaders a chance to review solutions and raise concerns
gating
which in turn helps to increase the overall quality of our
 The project lead is responsible for
solutions preparing for project gates
 Gating manifests in physical signoff
to indicate approval by the gating
committee and project leads

PM010 - Gating Questionnaire
Portfolio Management Office (PMO) Illustrative
• Is the project scope clear, agreed to and achievable?
• Is the plan / approach for delivering the project clear and concise?
• Is the schedule clearly defined and achievable?

Architecture
• Is the solution architecture consistent with the scope and objectives of the project?
• Is the solution architecture consistent with Yale’s reference architecture standards?
• Does the plan include retirement of legacy systems where applicable?

Information Security
• Does the solution involve sensitive data?
• Are there any initial security concerns with the solution?

Infrastructure and Production Services
• Have the environments needed to support the development effort been identified?
• Have all infrastructure requirements been identified?
• Does the plan include relevant infrastructure tasks?

Deployment
• Are the stakeholders identified and engaged?
• Are the stakeholders expectations understood and considered?
• Does the plan consider necessary training and change management activities?
54

Governance Summary

 Project vs. portfolio governance

 Know who is responsible for what (team, roles, etc) and who can
make what decisions

 Know how to escalate issues and to get senior level support for
the project

 Gating

Are there any questions on Governance?

55

Let‟s look at project management
processes. . .




56

Think good project management skills
were important for this?
I BELIEVE THAT THIS NATION
SHOULD COMMIT ITSELF TO
ACHIEVING THE GOAL, BEFORE
THIS DECADE IS OUT, OF LANDING
A MAN ON THE MOON AND
RETURNING HIM SAFELY TO EARTH

On May 25, 1961, President John F. Kennedy
announced before a special joint session of
Congress the dramatic and ambitious goal of
sending an American to the Moon before
the end of the decade
ONE SMALL STEP
FOR (A) MAN, ONE
GIANT LEAP FOR
PROJECT
MANAGEMENT

On July 20, 1969, barely 8 years later,
Neil Armstrong became the first man to
set foot on the moon. Buzz Aldrin quickly
followed, while Mike “Hard Luck” Collins
waited patiently in the Command Module in
moon‟s orbit

This is actually a picture of Buzz Aldrin, not Neil Armstrong, whose 57
famous quote we‟ve destroyed for our own selfish purpose. Do you
know why there is not a clearer picture of Armstrong‟s first step?

PMBOK, or yet another silly acronym

We‟ve already talked about the balancing act that is project
management. The good news is that some very smart people
(no, not us) have thought a lot about this and have documented
(in ridiculous detail) just about everything you need to know
about managing projects. This wealth of information is lovingly
called the Project Management Body of Knowledge, or PMBOK
for short.

We will not attempt to reproduce PMBOK or try to make you all
PMP certified. But we will attempt to draw your attention to
some of the key concepts around PMBOK and how our delivery
approach supports them.

Even if you are not responsible for project or team
management, the tools and techniques within can almost
certainly help.

The Project Management Institute published the first Guide to Project Management
Body of Knowledge (PMBOK) as a white paper in 1987 in an attempt to document and
standardize generally accepted project management information and practice

PMBOK is an internationally recognized standard that provides the fundamentals of project management as they apply to a wide range 58
of projects (not specific to one industry or type of project) and is published by the Project Management Institute (PMI). PMI offers
a PMP (Project Management Professional) certification based on PMBOK. For more information, visit http://www.pmi.org

Project management knowledge areas
PMBOK thinks of the world in terms of “project management
processes” and “project management knowledge areas”. For our
purposes, we will focus on the following:

 Change control
 Issue and decision
management
 Scope management
 Schedule management
 Cost management
 Quality management
 Resource management
 Communications management
 Risk management
 Vendor management
59

Change control – how far is it from here I‟M DOUG. NICE TO
MEET YOU. WHOA,
HAVE YOU LOST

to there if I don‟t know where here is? WEIGHT??

Scope creep. Schedule slip. Cost overruns. Each can kill a project.
But how do you know your scope is creeping if you haven‟t agreed to
what it should be? The concept of change control starts with the
idea of setting a baseline. The baseline forms a common
understanding and agreement of what will be built (scope), when it
will be delivered (schedule) and how much it will cost. The sponsor,
RM and project lead must all agree to the baseline. Once agreement
is reached, material changes must follow a formal change control
process.

Project Lifecycle  Before planning starts, a rough order of
magnitude (ROM) estimate for scope,
Establish Baseline Execute
schedule and cost are established
Initiate

Plan Analyze Design/Build/Test/Deploy
 The ROM estimate is a “best guess” and
is not yet based on a firm definition of
scope & requirements
Identify changes to scope, schedule, cost
 At the end of the analyze phase, scope,
schedule and cost are baselined
Assess impact of changes Change
control  The baseline estimate is more than a best
process guess – it is based on a detailed
Submit for approval understanding of scope, requirements,
the target solution and the plan to get
If changes approved, update baseline
there
 Once the baseline is set, changes must
ROM Baseline follow a change control process 60
Estimate Estimate

Issue and decision management, recognizing and removing
barriers
Someone once said “difficult times make great leaders”, . . .
or “difficult leaders make great times”, . . . or something like
that. The point is, projects often face difficult times.
Barriers to progress should be expected. The best projects
know how to remove barriers or how to find creative ways
around or through them.

 Actively identify and aggressively manage issues and decisions
 Establish and manage an issue / decision log
 Make sure all team members know how to escalate
 Communicate resolutions to those who need to know
 Document resolutions so that you will remember what was decided (or so that
you don‟t need to keep resolving the same issues over and over again)
 Make it clear who is responsible for resolving each issue and decision, when a
resolution is needed, and the impact of not resolving
 Involve steering committee early

61

Scope management
Scope management is a core principle for a successful
project, but is often done poorly because it is harder to
measure than schedule and cost. A successful Sponsor and
Project Lead will find effective ways to document and
communicate scope so that all team members and
stakeholders are clear on what to expect

AFTER MEETING WITH HIS CLIENT, JIM WAS SURE
HE UNDERSTOOD THE SCOPE OF THE PROJECT

 Establish a baseline
 Consider not only what is in scope, but what is out of scope
 Write it down and get signoff
 Document assumptions
 Consider all areas that may represent work for the team, not just the functional scope. For
example, are there legacy systems that should be retired because of this project?
 Gain agreement on who can make scope decisions
 Understand the relative priority of each scope item

62

Schedule management

 Start with the end in mind (define target state and get agreement from sponsor and
stakeholders)
 Break large projects into phases
 Don‟t reinvent – look for packages or other working systems before starting to build from
scratch
 Build schedule with involvement from the folks that will lead and do the work
 Understand dependencies (both within the project, and external to the project)
 Understand critical path
 Build in contingency plans
63

Cost management
Unless you are literally rolling in money (we‟re looking at you,
Scrooge McDuck) most projects operate within a budget.



 Consider all costs – people, hardware, software, training, facilities, supplies, etc

 Understand who can make cost decisions

 Be clear as to whom is responsible for managing which costs

 Regularly review project financials, including planned vs. actual, estimate to complete and
projected variance

64

Quality management

Which car is
higher quality?

It depends on what the requirements were. If the nice little electric car meets its planned requirements, but the
ridiculously fast Bugatti Veyron does not meet the requirements for which it was intended (fuel efficiency,
perhaps?) then the electric car is of higher quality.

When it comes to projects, quality is not defined as “make it the best”. Quality is defined as meeting
requirements. Simple as that. There is no extra credit for exceeding requirements. Sure, it would be nice if the
shiny battery powered vehicle could top 250mph, but that is not what the Sponsor of this car has asked for, or
agreed to pay for.

 Follow proven methodology (duh!)
 Active participation from sponsor and stakeholders
 Define in advance what success looks like
 Project gating and phase end reviews (which help to encourage phase containment to catch
small problems before they become big)
 Be able to link requirements to testing

65

Resource management
I NEED FRANKLY MY DEAR,
RESOURCES I HOPE YOU HAVE
FOR MY COMPLETED A
PROJECT RESOURCE PLAN

If you are on a project that only requires one resource, then
our approach probably doesn‟t apply to you. However, a
project of size or complexity will require involvement from
multiple people to play multiple roles. Identifying the roles
and the people to fill them, as well as establishing a “team
feel” is an important part for any successful project.

 Keep resource plans up to date

 Co-locate teams whenever possible

 Build and foster team spirit

 Cross train team members

 Stretch team members with challenging assignments and the opportunity to learn new things

 Consider the training required and train the team together whenever possible

 Consider all resources needed, including functional, subject matter expert (SME), testing, desktop
technologists, including those who are part time.

 Gain agreement in advance from resource managers that the folks you need will be available when
you need them to be available

 And be sure to plan for non-people resources, like development and test environments 66

Communications & stakeholder management
OH, NOTHING. JUST
WANTED TO
DID YOU SAY MENTION THAT
Have you ever been impacted by a change, but were not told about SOMETHING? WALL COMING UP

it or involved in advance? We have all probably experienced this
in some fashion, and it usually doesn‟t feel very good. Successful
projects understand who the stakeholders are, what information
they want, and how and when to get it to them.

Project Stakeholders
Steering
Steering
Committee
Committee

Senior
Senior Clients & Users
Clients & Users
Management
Management

Academic &
Academic & Interdependent
Interdependent
Project
Project
Business Units
Business Units Projects
Projects

Information
Information Outside Groups
Outside Groups
Technology
Technology (e.g., vendors, etc)
(e.g., vendors, etc)

Team Members
Team Members

 Establish communications plan
COULD BETTER COMMUNICATION PREVENTED THIS
 Identify and engage all stakeholders CRASH?

 Understand the impact the project can have on the stakeholders and
the impact they can have on the project
 Don‟t make promises that cannot be fulfilled
 Focus groups, demos, pilots, town halls
 Special communications from the Sponsor
 Articles, web pages, newsletters A stakeholder is anyone
who is impacted by, or who 67
can impact, the project
 Listen, listen, listen

But even with perfect communication . . .
Homer reacts to the news that Springfield is being split into
two area codes

DON‟T FORGET THE
WHAT DO YOU MEAN? LEAFLETS THEY
WHAT REALLY BURNS ME
THEY RAN THOSE TV DROPPED FROM THE
UP IS THEY DIDN‟T GIVE NOT A SINGLE WORD OF
COMMERCIALS ABOUT SPACE SHUTTLE, AND
US ONE WORD OF WARNING . . .
IT, AND THAT BIG THE TWO WEEKS WE
WARNING
RADIO CAMPAIGN ALL SPENT AT AREA
CODE CAMP

. . . we cannot always guarantee the message
will be heard 68

Risk management
YOUR VENDOR
WILL DELIVER LATE
. . . BUT, YOU WILL
BE LUCKY IN LOVE

No, you don‟t need to be a fortune teller to deliver a successful project,
but it does help to be able to predict the inevitable “gotchya‟s” that can
derail any project. Risks are simply things that haven‟t yet occurred, but
may impact the project if they do. Successful projects are able to
identify risks, assess potential impacts, and take mitigation steps in
advance.

 Involve the whole project team, including stakeholders, in risk identification
and mitigation

 Develop and actively manage a risk plan

 Make the risks and mitigations plans known, and enlist help when needed

 Assign responsibilities to mitigate risks

 Be on the lookout for new, and realized, risks for the life of the project

As Poor Richard told us long ago, an ounce of
prevention is worth a pound of cure 69

Vendor management
Sometimes we work with a vendor because they sold us the product, other
times we need help or skills that we don‟t have available, and other times
we just want someone else to blame when things go wrong (oops, did we say
that one out loud?). Regardless of the reason for hiring a 3rd party to
assist, it is helpful to keep in mind some basic best practices.

 Plan early for knowledge transfer
 Form partnership – become one team with one goal and one plan
 Have vendor help to organize the team and plan
 Follow the same methodology
 Co-locate
 Understand and influence the contract
 Legal review of the contract
 Tie payments to acceptance when possible
 Look at fixed fee, but understand what it means to manage fixed fee work
 Have single point of contact
 Caveat emptor! 70

Project Management Processes Summary

 PMBOK is an excellent source for project management training
and best practices

 Good project management techniques can make things easier.
Really.

 The delivery approach has been built with the best practices for
project management in mind

Are there any questions on Project Management
Processes?

71

Case study #2

Refer to case study #2 handout

72

Odds and Ends

PMO SharePoint

Project SharePoint

Status reporting

Change controls

Gating tracker

73

PMO SharePoint
The PMO sharepoint is your one-stop-shop for information regarding the
delivery approach and management of the overall portfolio of projects
being delivered. It is located at https://projects.yale.edu

 Templates and sample deliverables
 Gating calendar
 Location for placing project status
reports
 Delivery approach placemat
 Helpful project management links
 Links to portfolio project SharePoint
sites
 Link to portfolio archive site
 And more!

74

Project SharePoint Sites
Each project has it‟s own SharePoint site. The site is created by the PMO
and can then be administered and tailored by the project. At the close of
the project, the projects deliverables are posted to the project team
archive site, and the project site is shut down.

Each site starts with:
 Location for project documents
 Change log
 Decision log
 Issue log
 Risk log
 Task log
 Team discussion
 Place to record project lead roles
 Links to deliverable templates the
project will use
 Other useful links
75

Status Reporting and Project Reviews
Projects create a status report each week that helps to articulate the
overall status, remaining work, and barriers to progress.

 Status is due by end of day each Thursday
 Posted to the PMO SharePoint
 Project leads report on the milestones, issues and
risks and provide graphics that are most relevant
to their project and their stakeholders
 Friday the PMO consolidates and reviews the
status reports
 Monday the IT Projects and Planning Committee
reviews the reports and acts on any prioritization
issues, cross project dependencies, or change
orders
 The PMO may schedule project reviews with teams
that require assistance during the week
Mon Tues Wed Thurs Fri

IT Projects Project Project Project Status
and Planning Reviews Reviews Status Due Reviewed
Committee 76

Yale waterfall delivery approach training deck

Yale waterfall delivery approach training deck

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Yale waterfall delivery approach training deck

Similar to Yale waterfall delivery approach training deck (20)

More from Yale University Careers

More from Yale University Careers (16)

Recently uploaded

Recently uploaded (20)

Yale waterfall delivery approach training deck