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

http://www.stellman-greene.com/

2

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

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!!

WELCOME CLASS!

3

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

Closing and Survey 15 3:00 3:30

4

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

5

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

6

Work CategoriesAll requested work can be categorized based on size or type

A

B

C

M

S

Major project, estimated at $250k or more

Minor project, estimated between $50-$249k

Self funded request of any size

Small enhancement, estimated at less than $50k

Maintenance and break/fix requests

Baseline funding, pre-

set each year

Central funding,

allocated by officers each

year

Client funded

7

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?

What is a project delivery approach?

Our approach includes:

8

What is project success?

The “Golden Triangle” of Project Success

Scope

Time Cost

Project success occurs when we have:

A satisfied client (expectations met)

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

“Scope, Schedule, Cost”

According to Gartner, approximately 60 – 70% of IT

projects fail

9

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

10

Before we look at the approach, let’s first examine why projects fail

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

The bridge was nicknamed “Galloping Gertie” due to movement on windy

days

11

There’s an old saying about how there are a millionways to fail, but only one way to be right. When itcomes 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.

“This time it’s different”

12

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

You know you’re on a failed project when . . .

Justice Potter Stewart’s concurring opinion in Jacobellis v. Ohio: “I shall not 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.”

A judge in 1964 said (and we paraphrase), “I 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:

JETSON, YOU’RE

FIRED!!!!

13

Nobody sets out to fail, but for some reason peoplejust 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 ortake 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?

Sometimes failure seems normal

14

There are plenty of ways that you can categorizefailed 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 doneOnce 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 doesClassic management mistakes that can damage the project

Four basic ways projects can fail

15

Things the product does (or doesn’t do)It seems pretty obvious that youshould know what the software’ssupposed to do before you startbuilding it... not that that stopsus.

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

Scope keeps changing and

growingNo one is sure who gets to choose

what the product does90% done, with 90% left to go

16

Things the team should have doneThe 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

17

Things that could have been caughtWhich would you choose: a well builtproduct 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

18

Things the boss doesSome 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

19

Brains are important too . ..

A good approach is not a replacement for good judgment and sound skills. We could have the best tools in the world, 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

HOW MANY TIMES DO I HAVE TO TELL

YOU, IT’S RIGHT TIGHTY, LEFTY

LOOSEY

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

20

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 engineer of the project, Frank T. Crowe, was nicknamed “Hurry up”.

21

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

22

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

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

The Waterfall Method was introduced by Winston Royce in 1970. It is the oldest and most widely used development approach

SDLC and Waterfall are not the same – Waterfall is one type of SDLC

It involves a sequence of steps or stages, output from one stage is input to the next

Stages can sometimes overlap, but there are very definite goals for each phase

Biggest drawback of the waterfall model is that revision (scope and design changes) can be difficult and costly if not managed properly

Concept

Requirements & Plan

Design Solution

Build and Unit Test Solution Parts

Integration Test and Customer

Acceptance

Deploy

AND MY DRESS DIDN’T EVEN GET WET

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

of waterfall

23

Phases

Plan Analyze Design Test DeployBuild

Initiate

Operate

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

Our implementation of the waterfall approach uses the following phases:

24

Initiate Phase

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)

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.


Initiate

OperatePlan Analyze Design Test DeployBuild

Initiate

Operate

25

Plan Phase – What we getBy 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


Initiate


Initiate

Operate

26

Plan Phase – What we do Plan Analyze Design Test DeployBuild

Initiate


Initiate

Operate

Formally establish the project. Staff initial team members, begin project meetings, establish steering

committee, create project status reports

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

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

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

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

27

Plan Phase – What we create Plan Analyze Design Test DeployBuild

Initiate


Initiate

Operate

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 project management plan documents the project scope, schedule & cost and how these items will be

managed / governed

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

28

Analyze Phase – What we getBy 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


Initiate


Initiate

Operate

29

Analyze Phase – What we doDocument 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

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

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

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

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!


Initiate


Initiate

Operate

30

The security design review gathers data to facilitate the identification of potential security risks associated with 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

Analyze Phase – What we create

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 test approach defines the test phases and cycles that will be used to test the target solution


Initiate


Initiate

Operate

31

Design Phase – What we getBy 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


Initiate


Initiate

Operate

32

Design Phase – What we doBuild 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

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

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


Initiate


Initiate

Operate

33

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

Design Phase – What we create

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

coordinated

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


Initiate


Initiate

Operate

The workforce transition plan defines the steps and approach to move from the current organization (jobs,

roles, etc) to the target organization

34

Build Phase – What we getBy 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


Initiate


Initiate

Operate

35

Build Phase – What we do

Create the detailed technical designs that describe how the target solution will be built

Define the test cycles, scenarios and scripts that trace back to each requirement to ensure that each

requirement is tested

Build the remaining environments that are needed for test training and deployment

Build the materials that will be used to support end user training


Initiate


Initiate

Operate

Confirm that the build objects meet organizational standards, and have been appropriately unit and

assembly tested

Create physical database

36Update of the communications plan established in the

plan phase

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

product supports requirements

Build Phase – What we create

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


Initiate


Initiate

Operate

37

Test Phase – What we getBy 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


Initiate


Initiate

Operate

38

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

Test Phase – What we do

Ensure that the target solution meets the desktop requirements

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


Initiate


Initiate

Operate

Confirm formal approval from the sponsor and key 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

39The runbooks are a handbook that describe the overall technical architecture and operational considerations

for an application, and are used by the technical support teams

The cutover plan documents the steps, sequencing and timing of the activities needed to migrate from the test

environment to the production environment

Final version of security design review

Test Phase – What we create Plan Analyze Design Test DeployBuild

Initiate


Initiate

Operate

40

Deploy Phase – What we getAt 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


Initiate


Initiate

Operate

41

Deploy Phase – What we do

Move all involved application and technical components into the production environment

Formally transfer operating and maintenance responsibility to the operating teams, disband the

project team, stop project funding

Identify, prioritize and resolve issues during the deployment period until the target environment has

reached a pre-defined level of stability

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

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


Initiate


Initiate

Operate

42

The project closure report provides an overall wrap-up of the project. It documents key learnings, known open

items, overall project execution statistics, etc

Deploy Phase – What we create

The training evaluation summary records feedback from end users on training, to help the team identify

where training works, and where it would benefit from improvement

The user feedback report documents the results of user interviews, focus groups, usability tests, and other

interactions with users throughout the project


Initiate


Initiate

Operate

43

Design Build

Agile Techniques

Agile Techniques – For each Sprint:

Confirm scope of sprint

Review build with customer

and make changes

Design UI, process flow, workflow, output or data

usage

Review design with customer and

make changes

Do incremental build

Customer approval of

sprint

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


Initiate


Initiate

Operate

44

Operate Phase

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

Entry into the operate phase represents official closure of the project


Initiate


Initiate

Operate

45

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?

46

Case study #1

Refer to case study #1 handout

47

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

Our approach encompasses three areas:Solution and business integration lifecycle (our SDLC)

Project governance


48

What is governance?

There are probably few terms that are used as freely, but understood as poorly, as the term “governance”. We 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 responsible for what and who can make which decisions”

Judge Isaac Parkeraka “The Hanging

Judge”

He has decision authority

They are accountable

LET ‘EM HANG

The unfortunate accused

49

Levels of governance

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

Portfolio

Project 1 Project 2 Project 3 Project n

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

Decisions that are local to a project, such as scope, design approach and deliverable quality

50

Project Roles

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 individual can play more than one role on a

project!

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.

ACTION!

51

Project Escalation Paths

The structure and number of escalation levels is dependent upon the size and complexity of the project and the organization, but typically want as few as possible

Team members should be encouraged (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 facilitating the escalation process, but every team member is responsible for identifying, resolving and escalating problems

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

Team Status Meeting(s)

Project Status Meeting

Steering Committee

Com

munic

atio

ns

Issues, d

ecision

s, risks

Team Status Meeting(s)Review progress, deliverables, issues, decisions, risks, etc related to a specific team or subset of

the project

As defined by the team leads and project lead

Team members Team members Team members Team membersTeam lead

WE’RE BEHIND SCHEDULE? WHY DIDN’T

YOU TELL ME?!

52

Portfolio Governance

DO YOU SMELL SOMETHING

FUNNY?

I THINK IT WAS ALITO

AS CHIEF JUSTICE, I

DECLARE IT WAS SCALIA

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

53

Gating I SURE HOPE MY GATING

PAPERS ARE IN ORDER . . .

Express Path

Full Path

Plan Analyze Design Build Test DeployInitiate

Scre

enin

g an

d D

efini

tion

Esta

blis

h RO

M E

stim

ate

Maj

or P

roje

cts

(ove

r $25

0k o

r hi

ghly

vis

ible

)Sm

all P

roje

cts

($10

0k –

250

k)

Funding Starts Funding StopsFunding Baselined Deployment Decision

Plan

ning

Pha

se

Appr

oval

Plan

and

Ana

lyze

Ap

prov

al

Requ

irem

ents

Ap

prov

alBa

selin

e Es

timat

e

Go/

No-

Go

Dec

isio

n

Ope

rate

Des

ign

Appr

oval

Build

App

rova

l

Plan

ning

Esti

mat

e

Plan Gate

“Can this project be successful based on

the plans?”

Analyze Gate

“Are the requirements clear,

agreed to and achievable?”

Design Review Gate

“Do we know how we will build the product

to support the requirements?”

Go/No-Go Gate

“Does the product meet the

requirements?”“Are we ready to

deploy into production?

Build Review Gate

“Does the code meet our coding

standards?”

Project Close Gate

“Can the functionality be

supported operationally?”

Project Launch Gate

“Are we ready to start spending money planning this work?”

Enha

ncem

ent

<$10

0kD

oes

Not

Gat

e

Sprints

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

There can be multiple paths through gating depending upon the project type, size and complexity. Two typical paths are shown here

54

Gating Approvals Gating is facilitated by the

“Gating Questionnaire”, a set of questions for each phase

The questions are aligned by the areas supported by the key organizational leads who attend gating

The project lead is responsible for preparing for project gates

Gating manifests in physical signoff to indicate approval by the gating committee and project leads

Gating is run by the key organizational leads that are impacted by and / or responsible for project outcomes. The transparency from gating gives these organizational leaders a chance to review solutions and raise concerns which in turn helps to increase the overall quality of our solutions

Portfolio Management Office (PMO)

• 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?

I nformation Security

• Does the solution involve sensitive data?

• Are there any initial security concerns with the solution?

I nfrastructure 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?

I llustrative

PM010 - Gating Questionnaire

55

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?

56

Let’s look at project management processes. . .

Our approach encompasses three areas:Solution and business integration lifecycle (our SDLC)

Project governance


57

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

ONE SMALL STEP FOR (A) MAN, ONE GIANT LEAP FOR

PROJECT MANAGEMENT

This is actually a picture of Buzz Aldrin, not Neil Armstrong, whose 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?

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

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

58

PMBOK, or yet another silly acronym

PMBOK is an internationally recognized standard that provides the fundamentals of project management as they apply to a wide range 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

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

http://www.pmi.org/

59

Project management knowledge areasPMBOK 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

60

Change control – how far is it from here to there if I don’t know where here is?

I’M DOUG. NICE TO MEET YOU. WHOA,

HAVE YOU LOST WEIGHT??

Initiate

Baseline Estimate

ROM Estimate

Before planning starts, a rough order of magnitude (ROM) estimate for scope, schedule and cost are established

The ROM estimate is a “best guess” and is not yet based on a firm definition of scope & requirements

At the end of the analyze phase, scope, schedule and cost are baselined

The baseline estimate is more than a best guess – it is based on a detailed understanding of scope, requirements, the target solution and the plan to get there

Once the baseline is set, changes must follow a change control process

Project Lifecycle

ExecuteEstablish Baseline

Submit for approval

Identify changes to scope, schedule, cost

Assess impact of changes Change control process

Plan Analyze Design/Build/Test/Deploy

If changes approved, update baseline

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.

61

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

62

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

63

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

64

Cost management



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

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

65

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

66

Resource management FRANKLY MY DEAR, I HOPE YOU HAVE

COMPLETED A RESOURCE PLAN

I NEED RESOURCES

FOR MY PROJECT

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

67

Communications & stakeholder management

DID YOU SAY SOMETHING?

OH, NOTHING. JUST WANTED TO MENTION THAT WALL COMING

UPHave you ever been impacted by a change, but were not told about 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.

ProjectProjectAcademic & Business UnitsAcademic &

Business Units

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

(e.g., vendors, etc)

Team MembersTeam Members

I nformation Technology

I nformation Technology

Steering CommitteeSteering

Committee

Clients & UsersClients & UsersSenior Management

Senior Management

I nterdependent Projects

I nterdependent Projects

Establish communications plan

Identify and engage all stakeholders

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

Listen, listen, listenA stakeholder is anyone who is impacted by, or who can impact, the project

Project Stakeholders

COULD BETTER COMMUNICATION PREVENTED THIS CRASH?

68

WHAT REALLY BURNS ME UP IS THEY DIDN’T GIVE

US ONE WORD OF WARNING

WHAT DO YOU MEAN? THEY RAN THOSE TV

COMMERCIALS ABOUT IT, AND THAT BIG RADIO

CAMPAIGN

DON’T FORGET THE LEAFLETS THEY

DROPPED FROM THE SPACE SHUTTLE, AND

THE TWO WEEKS WE ALL SPENT AT AREA CODE

CAMP

NOT A SINGLE WORD OF WARNING . . .

But even with perfect communication . . .

Homer reacts to the news that Springfield is being split into two area codes

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

69

Risk management

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

YOUR VENDOR WILL DELIVER LATE . . . BUT, YOU WILL BE

LUCKY IN LOVE

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

70

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!

71

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?

72

Case study #2

Refer to case study #2 handout

73

Odds and Ends

PMO SharePoint

Project SharePoint

Status reporting

Change controls

Gating tracker

74

PMO SharePointThe 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!

https://projects.yale.edu/

75

Project SharePoint SitesEach 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

76

Status Reporting and Project ReviewsProjects 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 and

Planning Committee

ProjectStatus Due

Status Reviewed

Project Reviews

Project Reviews

77

Change control processWe discussed the concept of change control earlier. This page focuses on how to submit changes for approval

Initiate

Baseline Estimate

ROM Estimate

Project Lifecycle

ExecuteEstablish Baseline

Submit f or approval

I dentif y changes to scope, schedule, cost

Assess impact of changes Change control process

Plan Analyze Design/ Build/ Test/ Deploy

I f changes approved, update baseline

If impact is localized (e.g., does not require additional funding or resources, or has impact on other projects) then

Track on project SharePoint change log

Review / approval from within project, likely project steering committee

If impact is not localized then

Track on project SharePoint and also use the Change Control form

Review / approval from IT Projects and Planning Committee

RM, Sponsor and others can be present as appropriate

78

Gating trackerThe project gating tracker (PM010) is used to facilitate the gating process for each project.

Each project creates a PM010 for the project, using the template on the PMO sharepoint site

PM010 contains a tab for each phase (or gate), and each tab has a set of questions that help to facilitate the gate

The project team is responsible for completing and distributing the gating questions prior to each gate

The PMO completes the “action items” and “gating outcome” sections for each gate

The PM010 document follows the project from start to end, and is the source for gating information for the entire life of the project

79

Want more info?

https://projects.yale.edu

https://projects.yale.edu/

80

Comments, feedback, suggestions?

BEST. CLASS. EVER

HOW IS EDUCATION SUPPOSED TO MAKE ME FEEL SMARTER? BESIDES, EVERY TIME I LEARN SOMETHING NEW, IT PUSHES SOME OLD STUFF OUT OF MY

BRAIN. REMEMBER WHEN I TOOK THAT HOME WINEMAKING

COURSE, AND I FORGOT HOW TO DRIVE?

81

Thank you!

yale waterfall delivery approach training deck

Business

failed project

project costs

project delivery methodologies

project delivery approachand

failing projects

project governance framework

project management processes

typecentral amajor project