Yale waterfall delivery approach training deck
-
Upload
yale-university -
Category
Business
-
view
762 -
download
0
description
Transcript of 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
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.
Plan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
Initiate
Operate
26
Plan Phase – What we do Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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!
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Plan Analyze Design Test DeployBuild
Initiate
OperatePlan Analyze Design Test DeployBuild
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
Project management processes
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
Project management processes
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
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
Establish a baseline
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
Document assumptions
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
Establish a baseline
Document assumptions
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!
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
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!