Yale University Careers, profile picture
Uploaded byYale University Careers
PPTX, PDF2,378 views

Yale waterfall delivery approach training deck

The document outlines an IT project delivery training class, detailing its structure, objectives, and agenda. It discusses common pitfalls in project management, identifying key areas where projects often fail and the importance of best practices and project governance. Additionally, it emphasizes the significance of the Software Development Lifecycle (SDLC) and provides a detailed overview of the phases involved in successful project execution.

Embed presentation

Downloaded 59 times
IT Project Delivery Approach and how you can avoid sinking A training class prepared by the ITS PMO – June 2010 Special thanks to Jenny Greene (http://www.stellman-greene.com) for letting us borrow some of the concepts and graphics used within
Why are we here? To learn about the IT project delivery approach WELCOME CLASS! After this training you should: Be able to describe and use the basic structure of the IT project delivery approach Understand some of the best practices that help projects to be successful Know where to get more information and help when you need it Be better prepared to help your projects succeed!! 2
Today‟s agenda - Timing may be variable! Section Duration Start End Introductions 30 9:00 9:30 Opening 30 9:30 10:00 SDLC Placemat Orientation 10 10:00 10:10 Plan & Analyze 40 10:10 10:50 Break 10 10:50 11:00 Design/Build/Test/Deploy 45 11:00 11:45 Case Study I 20 11:45 12:05 Lunch 30 12:05 12:30 Case Study Feedback 15 12:30 12:45 Governance Overview 30 12:45 1:15 Processes Overview 30 1:15 1:45 Break, Case Study 60 1:45 2:45 Odds & Ends 15 2:45 3:00 3 Closing and Survey 15 3:00 3:30
Who are we? Before we begin, let‟s get to know each other Please tell us about:  Your department and role  Years at Yale  Previous experience / familiarity with project delivery methodologies  One interesting project experience you‟ve had 4
So, what is a project? Will deliver business and / or technical objectives in line with the University‟s strategic direction Runs for a defined period of time (has a start and end date) Has a budget Uses University resources 5
Work Categories All requested work can be categorized based on size or type Central A Major project, estimated at $250k or more funding, allocated by officers each year B Minor project, estimated between $50-$249k Client funded S Self funded request of any size Baseline C Small enhancement, estimated at less than $50k funding, pre- set each year M Maintenance and break/fix requests 6
What is a project delivery approach? Our approach includes:  Solution and business integration development lifecycle (SDLC) – What activities do I perform? – What deliverables do I create?  Project governance framework – Who is responsible for what? – How are decisions made for a project? Across all projects?  Project management Processes – How do I manage scope, schedule, cost, resources, quality, communications, risks and vendors? 7
What is project success? Project success occurs when we have:  A satisfied client (expectations met) Scope  Delivered the agreed objectives  Met an agreed budget ($, resources, etc)  Within an agreed time frame And, we‟ve done it all professionally and without killing the team Time Cost “Scope, Schedule, Cost” The “Golden Triangle” of Project Success 8 According to Gartner, approximately 60 – 70% of IT projects fail
Simply put, success is a balancing act YOU THINK THIS IS HARD? IN MY LAST JOB I MANAGED PROJECTS WITH MULTIPLE STAKEHOLDERS AND CONFLICTING PRIORITIES 9
Before we look at the approach, let‟s first examine why projects fail The bridge was nicknamed “Galloping Gertie” due to movement on windy days Not all failures are this easy to spot . . .  The Tacoma Narrows Bridge project failed before the first yard of concrete was poured  There was nothing wrong with the construction. Poor design and badly planned cost cutting in materials led to an unfortunate end  No human life was lost when the bridge collapsed on 11/7/1940, but Tubby the dog went down with his owners car when he refused to be removed 10
“This time it‟s different” There‟s an old saying about how there are a million ways to fail, but only one way to be right. When it comes to projects, nothing‟s further from the truth. Projects fail the same few ways over and over again. Don‟t go in the basement! Technology projects are a lot like cheesy horror movies. After you‟ve seen a few of them, you know that the first guy to leave the group is going to get an axe in his head. Projects are the same way. People keep making the same mistakes over and over, and it keeps getting their projects killed. 11
You know you‟re on a failed project when . . . JETSON, YOU‟RE A judge in 1964 said (and we paraphrase), “I FIRED!!!! don‟t know how to define pornography, but I know it when I see it.” And the same goes for failing projects - we can all spot a failing project when we see one. What does a failing project look like? You certainly know your project failed if it got aborted and everyone was laid off. But there are other, less obvious kinds of failure:  The project costs a lot more than it should  It takes a lot longer than anyone expected  The product doesn‟t do what it was supposed to  Nobody is happy about it Justice Potter Stewart‟s concurring opinion in Jacobellis v. Ohio: “I shall not 12 today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it.”
Sometimes failure seems normal Nobody sets out to fail, but for some reason people just accept that a lot of technology projects won‟t deliver on time, on budget with the expected scope intact. But talking about what causes failure makes people uncomfortable, because nobody wants to give or take that kind of criticism. A show of hands, please… We‟ve never met a single IT professional with more than a few years of experience who hasn‟t been on at least one failed project. Are there any here? 13
Four basic ways projects can fail There are plenty of ways that you can categorize failed projects. We like to think of them like this:  Things the product does (or doesn’t do) How your project doesn‟t quite meet the needs of the people you built it for  Things the team should have done Once in a while, it really is the team‟s fault  Things that could have been caught . . . but weren‟t until it was way too late  Things the boss does Classic management mistakes that can damage the project 14
Things the product does (or doesn‟t do) It seems pretty obvious that you should know what the software‟s supposed to do before you start building it... not that that stops us.  We only find serious problems after we‟ve built them into the product  Scope keeps changing and growi ng  No one is sure who gets to choose what the product does  90% done, with 90% left to go 15
Things the team should have done The team could have done the work more efficiently, if only we‟d taken the time to think it through.  Planning is not done thoroughly  Issues and risks are not identified and acted upon quickly enough  Dependencies are not understood  Expectations are not managed well 16
Things that could have been caught Which would you choose: a well built product that doesn‟t do what you need or a crappy one that‟s irritating to use and does?  Getting a few tech support people to “bang on the software” is not testing  Maybe we could‟ve caught that design problem before the code was built  Maybe we could‟ve caught that code problem before we went to test  Wishful thinking does not make an application run faster 17
Things the boss does Some problems start with senior managers, others start with key stakeholders, but they can all sink the project.  Over promising  Ignoring issues and risks  Artificial wall between the business and technology  Over simplifying 18
Brains are important too . .. HOW MANY TIMES A good approach is not a replacement DO I HAVE TO TELL for good judgment and sound skills. We YOU, IT‟S RIGHT TIGHTY, LEFTY could have the best tools in the world, LOOSEY but most of us still could not fix the space shuttle or perform surgery.  A sound approach is a good start, but we also need to be the owners of our own ability  Understanding how to use the tools and your own personal development path is probably the most important thing we would like you to learn today  The good news is that a standard, proven approach will help us to focus on the execution of the work and help us to better help each other Goober worked at Wally's Filling Station, which he 19 eventually purchased and became the proprietor
The talent is there… the delivery management‟s not Hoover Dam was finished two years early, and under budget. Technology projects are not so different that we can‟t engineer them just as well.  Our problems have, for the most part, been solved  Over and over and over again. Seriously.  We just have to stop ignoring the solutions The building of the Hoover Dam started in 1931 and finished in 1935, two years earlier than scheduled. And this is the reason chief 20 engineer of the project, Frank T. Crowe, was nicknamed “Hurry up”.
Ok, let‟s get to the good part Our approach encompasses three areas: Solution and business integration lifecycle (our SDLC) Project governance Project management processes Let’s start by reviewing the SDLC . . . 21
The Waterfall approach, or “how safe is your barrel”? Concept  The Waterfall Method was introduced by Winston Royce in 1970. It is the oldest and Requirements & Plan most widely used development approach  SDLC and Waterfall are not the same – Waterfall is one type of SDLC Design Solution AND MY  It involves a sequence of steps or stages, DRESS DIDN‟T EVEN GET output from one stage is input to the next WET Build and Unit Test Solution Parts  Stages can sometimes overlap, but there are very definite goals for each phase Integration Test and Customer Acceptance  Biggest drawback of the waterfall model is that revision (scope and design changes) can be difficult and costly if not managed Deploy properly Later we will talk about a concept called “Phase Containment” that helps to manage some of the drawbacks of waterfall 22 Winston W. Royce (1929–1995) was an American computer scientist, director at Lockheed Software Technology Center in Austin, TX, and one of the leaders in software development in the second half of the 20th century. He was the first who described the Waterfall model for software development
Phases Plan Analyze Design Build Test Deploy Operate Initiate Our implementation of the waterfall approach uses the following phases:  Initiate – Request a new project and get approval to allocate resources (and spend $$!)  Plan – Create project plan and define goals and expectations  Analyze – Confirm requirements for the product  Design – Detail the design of the product  Build – Create the product  Test – Validate that the product does what it is supposed to do  Deploy – Move the product into production  Operate – After the project is closed, run the product in production 23
Initiate Phase Plan Analyze Design Build Test Deploy Operate Initiate The project charter is the primary outcome of the Initiate phase. It prepares the project to officially launch, which means the project can begin to allocate resources and spend money.  Names sponsor, business relationship manager and project lead  Project purpose  Strategic fit  Success metrics  Known scope & requirements (high level)  Known stakeholders  Known risks & constraints  Project governance  Rough order of magnitude (ROM) schedule, resources and costs  Milestones, resources and costs for next phase (typically plan or plan and analyze) 24
Plan Phase – What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the plan phase, we should know:  What is in scope, what is out of scope  The high level requirements of the target state applications, processes and organization  The current state of the applications, processes and organization  The proposed target state of the applications, processes and organization  The steps needed to move from current state to target state  An approach for sourcing  Approaches for managing the projects scope, schedule, cost, resources, risk, quality and communications  Which deliverables the project will produce  Whether we will buy and / or build technology  Which package(s) will be used for technology that will be bought  The underlying technical infrastructure needed to support analysis and design  Who the stakeholders are and what is important to them  The potential impacts on the target organization  Who we need to communicate to, when, how, why and to say what  A draft plan, team and cost estimate on what it will take to move from current to target 25
Plan Phase – What we do Plan Analyze Design Build Test Deploy Operate Initiate Formally establish the project. Staff initial team members, begin project meetings, establish steering committee, create project status reports Document how the project will be organized and governed – consider who is responsible for each aspect of the project, how the team will be organized, what forums will be used to govern the project and who is on each forum Define the underlying technical architecture required to support the target application environment Define who needs to know what, when, how and why Assess the delivery approach and tailor it to the needs of the project. This includes phases, activities, deliverables, gating, sourcing, usage of vendors and other 3rd parties, etc 26
Plan Phase – What we create Plan Analyze Design Build Test Deploy Operate Initiate The solution blueprint contains a definition of the target state environment. This can include (but is not limited to) the application, infrastructure, process and organization target states. In addition, target training and the project delivery approach are documented here The stakeholder and organization impact analysis documents the stakeholders, their degree of influence on the project and how they will be impacted by the project. It also documents potential organizational impacts The project management plan documents the project scope, schedule & cost and how these items will be managed / governed 27
Analyze Phase – What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the analyze phase, we should know:  How the target state processes will work  The detailed requirements that the target state must support  Where there are gaps in how the vendor package(s) support the requirements  General approach for filling the gaps (e.g., custom mod, drop requirement, etc)  Use cases and the conceptual data model, for custom development  Identification of the RICEFW widgets that will be designed and built (RICEFW = Reports, Interfaces, Conversions, Extensions, Forms, Workflows)  High level designs to reflect how the requirements will be supported (where applicable and needed to determine RICEFW definition)  The approach that will be used to test that the target solution meets the requirements and does not have a negative impact on other systems or processes  The definition of, and the plan to build (where necessary) the technical infrastructure needed to support build, test and deploy  The approach that will be used to train users and other impacted parties on the target solution  Understanding of the current organization  Understanding of the impact of new processes and technologies on the organization, including roles, jobs, teams and performance measures  A baseline plan, team and cost estimate on what it will take to move from current to target 28
Analyze Phase – What we do Plan Analyze Design Build Test Deploy Operate Initiate Document the requirements that the target solution must support. Consider requirements across functional, technical and operational areas, as well as prioritization and potential phasing of requirements Reports, Interfaces, Conversions, Extensions, Forms, Workflows. Define the set of widgets that will be designed, built and tested. In some cases, a high level design will be needed to fully identify the widgets Consider and plan for any infrastructure components that need to be procured, built and / or configured. This should include your desktop infrastructure as well. Let‟s not forget about the managed desktop! For components of design & build that will be done in an iterative fashion (typically applies most easily to components that involve user interaction, such as process & form design) define the set of iterations that will be executed Document how the end users will be trained and educated on the usage of the target solution. Consider who needs to be trained, when they need to be trained, how they will receive training, what needs to be designed & built to support training 29
Analyze Phase – What we create Plan Analyze Design Build Test Deploy Operate Initiate The RTM documents each requirement of the target solution and facilitates traceability between requirements and associated test scripts. The RTM can also be uplaoded into a testing tool, such as SQA, and Package system gaps are also defined within the RTM The security design review gathers data to facilitate the The test approach defines the test phases and cycles that identification of potential security risks associated with will be used to test the target solution the target state. Note that an initial completion of the document is done in the analyze phase, with the final version due at end of test 30
Design Phase – What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the design phase, we should have:  A prototype of the application to demonstrate how it will work  For custom solutions, design of common application classes and components  For custom solutions, a logical database design  Design of the application configuration  Functional designs for reports, interfaces, conversions, extensions, forms and workflows that describe how these components will work  Necessary development environments are ready  End user organization, roles and jobs are defined  Design for the delivery of training  Definition of how the target solution will be supported in the operating environment (both functionally and technically), gaps between the current and target support models, and the plan to close the gaps 31
Design Phase – What we do Plan Analyze Design Build Test Deploy Operate Initiate Build a model or working application that demonstrates how the product will look, act and feel, with the intent of gaining stakeholder feedback. This process can be iterated as part of the iterative approach, where applicable Define how the target product will be supported in the operational environment, including the roles needed to support, the gaps between current and target state, and the plan to move to target Create the functional designs for each widget that describe visually and textually how each widget (and the overall product) will work and what it will do 32
Design Phase – What we create Plan Analyze Design Build Test Deploy Operate Initiate The workforce transition plan defines the steps and approach to move from the current organization (jobs, roles, etc) to the target organization The prototype is a mock-up or “alpha” version of the target product, with the intent of demonstrating how the product will look, act and feel The role descriptions document defines the roles and responsibilities that will exist in the target organization The training plan defines the details of each training approach / session so that training can be planned and coordinated 33
Build Phase – What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the build phase, we should have:  A master configuration for the packaged software that can be applied to build and test environments  Technical designs for reports, interfaces, conversions, extensions, forms and workflows that describe how these components will be built  Built, unit and assembly tested application components  For custom builds, a physical database created from the logical data definition  Test planning complete, including build of test cycles, scenarios and scripts  Plans to staff the new organization as necessary  Built training and communications materials  Technical infrastructure and environments ready for test, training and deploy 34
Build Phase – What we do Plan Analyze Design Build Test Deploy Operate Initiate Create the detailed technical designs that describe how the target solution will be built Create physical database Define the test cycles, scenarios and scripts that trace Build the materials that will be used to support end user back to each requirement to ensure that each requirement training is tested Build the remaining environments that are needed for test training and deployment Confirm that the build objects meet organizational standards, and have been appropriately unit and assembly tested 35
Build Phase – What we create Plan Analyze Design Build Test Deploy Operate Initiate The knowledge management content is the information needed by the supporting organizations (e.g., service desk, functional support, technical support, etc) to meet expected service levels The test plan is comprised of the cycles, scenarios and test scripts that will be used to ensure that the target product supports requirements Update of the communications plan established in the plan phase 36
Test Phase – What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the test phase, we should have:  A validated target product that meets performance, security, functional, desktop, and end user expectations  An agreed to freeze on changes to application code  Approved security design  A conversion process that has been tested  Completed runbooks  Agreed to contingency plans  Tested cutover plans  Piloted training  End users and stakeholders that are aware of the forthcoming changes, and prepared to accept them 37
Test Phase – What we do Plan Analyze Design Build Test Deploy Operate Initiate Prepare and test the cutover plans end to end prior to actual cutover. Iterate until the cutover process is working at an acceptable level Pilot the training, make adjustments based on feedback, and then deliver training as planned Ensure that the target solution meets the desktop Confirm formal approval from the sponsor and key requirements stakeholders that the target product is ready to be deployed into the production environment Freeze all changes to the application code until the application is deployed. Once the application is deployed, bugs will be prioritized, fixed and the application regression tested. New functionality should wait for a new release Execute mock conversion to test the end to end conversion process prior to actual conversion. Iterate until conversion process is working at an acceptable level 38
Test Phase – What we create Plan Analyze Design Build Test Deploy Operate Initiate Final version of security design review The cutover plan documents the steps, sequencing and The runbooks are a handbook that describe the overall timing of the activities needed to migrate from the test technical architecture and operational considerations for environment to the production environment an application, and are used by the technical support teams 39
Deploy Phase – What we get Plan Analyze Design Build Test Deploy Operate Initiate At the end of the deploy phase, we should know:  Data converted into production environments  Application code migrated to production environments  End users trained and communicated to  Target state (organization, processes and application) rolled out as specified by requirements and delivery approach  Critical and high priority post deployment issues resolved during warranty period  Responsibility for operating and maintaining the target state is transferred to the operating teams  Completed project closure report 40
Deploy Phase – What we do Plan Analyze Design Build Test Deploy Operate Initiate Move all involved application and technical components into the production environment Execute user support model by providing launch support for the end users and when appropriate move to the operational user support model Deliver the training and communications necessary to make stakeholders aware of the target product, and enabled to operate successfully in the target environment, with the target tools Identify, prioritize and resolve issues during the deployment period until the target environment has reached a pre-defined level of stability Formally transfer operating and maintenance responsibility to the operating teams, disband the project team, stop project funding 41
Deploy Phase – What we create Plan Analyze Design Build Test Deploy Operate Initiate The user feedback report documents the results of user interviews, focus groups, usability tests, and other interactions with users throughout the project The project closure report provides an overall wrap-up of The training evaluation summary records feedback from the project. It documents key learnings, known open items, end users on training, to help the team identify where overall project execution statistics, etc training works, and where it would benefit from improvement 42
Agile Techniques Operate Plan Analyze Design Build Test Deploy Initiate Design Build Agile Techniques – For each Sprint: Design UI, process Review build Review design Customer Confirm scope flow, workflow, Do incremental with customer output or data with customer and approval of of sprint make changes build and make usage sprint changes  Within the context of the waterfall approach, some functions may benefit from a more iterative design & build approach  Common examples include application forms, configuration and reports, but can apply to any functions that can be mostly built and validated on a stand-alone basis  These techniques are not a replacement for full Agile development. Agile is a different type of SDLC that is not covered in this training  Beware that iterative development has it‟s own pitfalls, including potential for rework and cost and schedule over-runs 43
Operate Phase Plan Analyze Design Build Test Deploy Operate Initiate Entry into the operate phase represents official closure of the project  Project funding ends  Project team and governance disbands in favor or operating team and governance  Project resources go onto other projects or activities  The operational teams take ownership of the application and supporting processes 44
SDLC Summary  Waterfall approach, but iterate and overlap when reasonable and helpful  Not just for software – considers business processes, organization and communication  Toolbox approach, tailor, tailor, tailor Are there any questions on the SDLC? 45
Case study #1 Refer to case study #1 handout 46
Next, let‟s look at project governance . . . Our approach encompasses three areas: Solution and business integration lifecycle (our SDLC) Project governance Project management processes 47
What is governance? There are probably few terms that are used as freely, but understood as poorly, as the term “governance”. We LET „EM HANG Judge Isaac Parker aka “The Hanging Judge” will continue the trend by using it freely. However, we will try to make some sense of what it is and why it is important - mostly so that you can impress your friends and neighbors, but also so that you can understand how you can use it to help your projects to be more successful  One definition of governance: “Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT”  We can simplify it further: “Defining who is He has decision authority responsible for what and who can make which The unfortunate accused decisions” 48 They are accountable
Levels of governance Our approach considers governance at the project level, and cross-project (or portfolio) level Portfolio  Decisions that cross projects, such as funding, resources and dependencies  Decisions that are local Project 1 Project 2 Project 3 Project n to a project, such as scope, design approach and deliverable quality 49
Project Roles ACTION! How are projects like movies? No, not the long hours and poor reviews from the critics. Both rely on standard roles to help them run smoothly. On any movie set everyone knows what the key grip and gaffer are responsible for. Successful projects operate in the same way, with standard roles and clear understanding of responsibilities and decision making authority.  Sponsor - Proposes and champions the project. Responsible for the project‟s success  Relationship Manager - Responsible for translating business vision into solution, staffing, and delivering solution  Project Lead – Responsible for delivery of project scope, on time and within budget  Functional Lead – Responsible for delivery of the functional solution  Technical Lead – Responsible for delivery of the technical solution  Change Management Lead – Responsible for organizational and user adoption of the solution Like Eddie Murphy in The Nutty Professor, an 50 individual can play more than one role on a project!
Project Escalation Paths WE‟RE BEHIND SCHEDULE? WHY DIDN‟T YOU TELL ME?! Bosses tend to be happier when you don‟t surprise them, especially if the surprise brings bad news. Every team member should know what to do when they have a problem that they cannot resolve themselves. A well defined process to identify, escalate and resolve problems is an essential part of how any project is governed  The structure and number of escalation levels is dependent upon the size and complexity of the project and Steering the organization, but typically want as Committee few as possible Project Status Meeting  Team members should be encouraged Team Status Meeting(s) (and empowered) to resolve issues at the local level, but should also know where to get help when they need it  The Project Lead is responsible for Team Status Meeting(s) facilitating the escalation process, but every team member is responsible for Review progress, deliverables, issues, decisions, risks, etc related to a specific team or subset of the project Team lead Team members Team members Team members Team members identifying, resolving and escalating As defined by the team leads and project lead problems 51
Portfolio Governance The IT Projects and Planning Committee is the “supreme court” for decisions that impact the portfolio of projects. Business specific issues may still require escalation through the business area, but items that are IT related or have impact across the portfolio of projects can be escalated to this council for final decisioning AS CHIEF DO YOU SMELL I THINK IT JUSTICE, I SOMETHING WAS ALITO DECLARE IT FUNNY? WAS SCALIA 52
Gating I SURE HOPE MY GATING PAPERS ARE IN ORDER . . . Gating is part governance function and part quality assurance. The intent of gating is to help apply our standards (such as this delivery approach) and to bring broad transparency to the solutions being built. It also helps to support the concept of “phase containment” whereby the problems from earlier phases do not have a snowballing affect on later project phases Funding Starts Funding Baselined Deployment Decision Funding Stops Plan and Analyze ($100k – 250k) Small Projects Approval Express Path Establish ROM Estimate Screening and Definition Does Not Gate Enhancement Sprints Operate <$100k Initiate Plan Analyze Design Build Test Deploy Go/No-Go Decision Planning Estimate Baseline Estimate Design Approval Planning Phase Major Projects Build Approval (over $250k or Requirements highly visible) Approval Approval Full Path There can be multiple paths through Project Launch Gate Plan Gate Analyze Gate Design Review Gate Build Review Gate Go/No-Go Gate Project Close Gate gating depending upon the project type, size and complexity. Two typical paths are shown here “Are we ready to “Can this project be “Are the “Do we know how we “Does the code meet “Does the product “Can the functionality start spending money successful based on requirements clear, will build the product our coding meet the be supported planning this work?” the plans?” agreed to and to support the standards?” requirements?” operationally?” achievable?” requirements?” “Are we ready to deploy into production? 53
Gating Approvals  Gating is facilitated by the “Gating Questionnaire”, a set of questions Gating is run by the key organizational leads that are for each phase impacted by and / or responsible for project outcomes.  The questions are aligned by the The transparency from gating gives these organizational areas supported by the key organizational leads who attend leaders a chance to review solutions and raise concerns gating which in turn helps to increase the overall quality of our  The project lead is responsible for solutions preparing for project gates  Gating manifests in physical signoff to indicate approval by the gating committee and project leads PM010 - Gating Questionnaire Portfolio Management Office (PMO) Illustrative • Is the project scope clear, agreed to and achievable? • Is the plan / approach for delivering the project clear and concise? • Is the schedule clearly defined and achievable? Architecture • Is the solution architecture consistent with the scope and objectives of the project? • Is the solution architecture consistent with Yale’s reference architecture standards? • Does the plan include retirement of legacy systems where applicable? Information Security • Does the solution involve sensitive data? • Are there any initial security concerns with the solution? Infrastructure and Production Services • Have the environments needed to support the development effort been identified? • Have all infrastructure requirements been identified? • Does the plan include relevant infrastructure tasks? Deployment • Are the stakeholders identified and engaged? • Are the stakeholders expectations understood and considered? • Does the plan consider necessary training and change management activities? 54
Governance Summary  Project vs. portfolio governance  Know who is responsible for what (team, roles, etc) and who can make what decisions  Know how to escalate issues and to get senior level support for the project  Gating Are there any questions on Governance? 55
Let‟s look at project management processes. . . Our approach encompasses three areas: Solution and business integration lifecycle (our SDLC) Project governance Project management processes 56
Think good project management skills were important for this? I BELIEVE THAT THIS NATION SHOULD COMMIT ITSELF TO ACHIEVING THE GOAL, BEFORE THIS DECADE IS OUT, OF LANDING A MAN ON THE MOON AND RETURNING HIM SAFELY TO EARTH On May 25, 1961, President John F. Kennedy announced before a special joint session of Congress the dramatic and ambitious goal of sending an American to the Moon before the end of the decade ONE SMALL STEP FOR (A) MAN, ONE GIANT LEAP FOR PROJECT MANAGEMENT On July 20, 1969, barely 8 years later, Neil Armstrong became the first man to set foot on the moon. Buzz Aldrin quickly followed, while Mike “Hard Luck” Collins waited patiently in the Command Module in moon‟s orbit This is actually a picture of Buzz Aldrin, not Neil Armstrong, whose 57 famous quote we‟ve destroyed for our own selfish purpose. Do you know why there is not a clearer picture of Armstrong‟s first step?
PMBOK, or yet another silly acronym We‟ve already talked about the balancing act that is project management. The good news is that some very smart people (no, not us) have thought a lot about this and have documented (in ridiculous detail) just about everything you need to know about managing projects. This wealth of information is lovingly called the Project Management Body of Knowledge, or PMBOK for short. We will not attempt to reproduce PMBOK or try to make you all PMP certified. But we will attempt to draw your attention to some of the key concepts around PMBOK and how our delivery approach supports them. Even if you are not responsible for project or team management, the tools and techniques within can almost certainly help. The Project Management Institute published the first Guide to Project Management Body of Knowledge (PMBOK) as a white paper in 1987 in an attempt to document and standardize generally accepted project management information and practice PMBOK is an internationally recognized standard that provides the fundamentals of project management as they apply to a wide range 58 of projects (not specific to one industry or type of project) and is published by the Project Management Institute (PMI). PMI offers a PMP (Project Management Professional) certification based on PMBOK. For more information, visit http://www.pmi.org
Project management knowledge areas PMBOK thinks of the world in terms of “project management processes” and “project management knowledge areas”. For our purposes, we will focus on the following:  Change control  Issue and decision management  Scope management  Schedule management  Cost management  Quality management  Resource management  Communications management  Risk management  Vendor management 59
Change control – how far is it from here I‟M DOUG. NICE TO MEET YOU. WHOA, HAVE YOU LOST to there if I don‟t know where here is? WEIGHT?? Scope creep. Schedule slip. Cost overruns. Each can kill a project. But how do you know your scope is creeping if you haven‟t agreed to what it should be? The concept of change control starts with the idea of setting a baseline. The baseline forms a common understanding and agreement of what will be built (scope), when it will be delivered (schedule) and how much it will cost. The sponsor, RM and project lead must all agree to the baseline. Once agreement is reached, material changes must follow a formal change control process. Project Lifecycle  Before planning starts, a rough order of magnitude (ROM) estimate for scope, Establish Baseline Execute schedule and cost are established Initiate Plan Analyze Design/Build/Test/Deploy  The ROM estimate is a “best guess” and is not yet based on a firm definition of scope & requirements Identify changes to scope, schedule, cost  At the end of the analyze phase, scope, schedule and cost are baselined Assess impact of changes Change control  The baseline estimate is more than a best process guess – it is based on a detailed Submit for approval understanding of scope, requirements, the target solution and the plan to get If changes approved, update baseline there  Once the baseline is set, changes must ROM Baseline follow a change control process 60 Estimate Estimate
Issue and decision management, recognizing and removing barriers Someone once said “difficult times make great leaders”, . . . or “difficult leaders make great times”, . . . or something like that. The point is, projects often face difficult times. Barriers to progress should be expected. The best projects know how to remove barriers or how to find creative ways around or through them.  Actively identify and aggressively manage issues and decisions  Establish and manage an issue / decision log  Make sure all team members know how to escalate  Communicate resolutions to those who need to know  Document resolutions so that you will remember what was decided (or so that you don‟t need to keep resolving the same issues over and over again)  Make it clear who is responsible for resolving each issue and decision, when a resolution is needed, and the impact of not resolving  Involve steering committee early 61
Scope management Scope management is a core principle for a successful project, but is often done poorly because it is harder to measure than schedule and cost. A successful Sponsor and Project Lead will find effective ways to document and communicate scope so that all team members and stakeholders are clear on what to expect AFTER MEETING WITH HIS CLIENT, JIM WAS SURE HE UNDERSTOOD THE SCOPE OF THE PROJECT  Establish a baseline  Consider not only what is in scope, but what is out of scope  Write it down and get signoff  Document assumptions  Consider all areas that may represent work for the team, not just the functional scope. For example, are there legacy systems that should be retired because of this project?  Gain agreement on who can make scope decisions  Understand the relative priority of each scope item 62
Schedule management  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 63
Cost management Unless you are literally rolling in money (we‟re looking at you, Scrooge McDuck) most projects operate within a budget.  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 64
Quality management Which car is higher quality? It depends on what the requirements were. If the nice little electric car meets its planned requirements, but the ridiculously fast Bugatti Veyron does not meet the requirements for which it was intended (fuel efficiency, perhaps?) then the electric car is of higher quality. When it comes to projects, quality is not defined as “make it the best”. Quality is defined as meeting requirements. Simple as that. There is no extra credit for exceeding requirements. Sure, it would be nice if the shiny battery powered vehicle could top 250mph, but that is not what the Sponsor of this car has asked for, or agreed to pay for.  Follow proven methodology (duh!)  Active participation from sponsor and stakeholders  Define in advance what success looks like  Project gating and phase end reviews (which help to encourage phase containment to catch small problems before they become big)  Be able to link requirements to testing 65
Resource management I NEED FRANKLY MY DEAR, RESOURCES I HOPE YOU HAVE FOR MY COMPLETED A PROJECT RESOURCE PLAN If you are on a project that only requires one resource, then our approach probably doesn‟t apply to you. However, a project of size or complexity will require involvement from multiple people to play multiple roles. Identifying the roles and the people to fill them, as well as establishing a “team feel” is an important part for any successful project.  Keep resource plans up to date  Co-locate teams whenever possible  Build and foster team spirit  Cross train team members  Stretch team members with challenging assignments and the opportunity to learn new things  Consider the training required and train the team together whenever possible  Consider all resources needed, including functional, subject matter expert (SME), testing, desktop technologists, including those who are part time.  Gain agreement in advance from resource managers that the folks you need will be available when you need them to be available  And be sure to plan for non-people resources, like development and test environments 66
Communications & stakeholder management OH, NOTHING. JUST WANTED TO DID YOU SAY MENTION THAT Have you ever been impacted by a change, but were not told about SOMETHING? WALL COMING UP it or involved in advance? We have all probably experienced this in some fashion, and it usually doesn‟t feel very good. Successful projects understand who the stakeholders are, what information they want, and how and when to get it to them. Project Stakeholders Steering Steering Committee Committee Senior Senior Clients & Users Clients & Users Management Management Academic & Academic & Interdependent Interdependent Project Project Business Units Business Units Projects Projects Information Information Outside Groups Outside Groups Technology Technology (e.g., vendors, etc) (e.g., vendors, etc) Team Members Team Members  Establish communications plan COULD BETTER COMMUNICATION PREVENTED THIS  Identify and engage all stakeholders CRASH?  Understand the impact the project can have on the stakeholders and the impact they can have on the project  Don‟t make promises that cannot be fulfilled  Focus groups, demos, pilots, town halls  Special communications from the Sponsor  Articles, web pages, newsletters A stakeholder is anyone who is impacted by, or who 67 can impact, the project  Listen, listen, listen
But even with perfect communication . . . Homer reacts to the news that Springfield is being split into two area codes DON‟T FORGET THE WHAT DO YOU MEAN? LEAFLETS THEY WHAT REALLY BURNS ME THEY RAN THOSE TV DROPPED FROM THE UP IS THEY DIDN‟T GIVE NOT A SINGLE WORD OF COMMERCIALS ABOUT SPACE SHUTTLE, AND US ONE WORD OF WARNING . . . IT, AND THAT BIG THE TWO WEEKS WE WARNING RADIO CAMPAIGN ALL SPENT AT AREA CODE CAMP . . . we cannot always guarantee the message will be heard 68
Risk management YOUR VENDOR WILL DELIVER LATE . . . BUT, YOU WILL BE LUCKY IN LOVE No, you don‟t need to be a fortune teller to deliver a successful project, but it does help to be able to predict the inevitable “gotchya‟s” that can derail any project. Risks are simply things that haven‟t yet occurred, but may impact the project if they do. Successful projects are able to identify risks, assess potential impacts, and take mitigation steps in advance.  Involve the whole project team, including stakeholders, in risk identification and mitigation  Develop and actively manage a risk plan  Make the risks and mitigations plans known, and enlist help when needed  Assign responsibilities to mitigate risks  Be on the lookout for new, and realized, risks for the life of the project As Poor Richard told us long ago, an ounce of prevention is worth a pound of cure 69
Vendor management Sometimes we work with a vendor because they sold us the product, other times we need help or skills that we don‟t have available, and other times we just want someone else to blame when things go wrong (oops, did we say that one out loud?). Regardless of the reason for hiring a 3rd party to assist, it is helpful to keep in mind some basic best practices.  Plan early for knowledge transfer  Form partnership – become one team with one goal and one plan  Have vendor help to organize the team and plan  Follow the same methodology  Co-locate  Understand and influence the contract  Legal review of the contract  Tie payments to acceptance when possible  Look at fixed fee, but understand what it means to manage fixed fee work  Have single point of contact  Caveat emptor! 70
Project Management Processes Summary  PMBOK is an excellent source for project management training and best practices  Good project management techniques can make things easier. Really.  The delivery approach has been built with the best practices for project management in mind Are there any questions on Project Management Processes? 71
Case study #2 Refer to case study #2 handout 72
Odds and Ends PMO SharePoint Project SharePoint Status reporting Change controls Gating tracker 73
PMO SharePoint The PMO sharepoint is your one-stop-shop for information regarding the delivery approach and management of the overall portfolio of projects being delivered. It is located at https://projects.yale.edu  Templates and sample deliverables  Gating calendar  Location for placing project status reports  Delivery approach placemat  Helpful project management links  Links to portfolio project SharePoint sites  Link to portfolio archive site  And more! 74
Project SharePoint Sites Each project has it‟s own SharePoint site. The site is created by the PMO and can then be administered and tailored by the project. At the close of the project, the projects deliverables are posted to the project team archive site, and the project site is shut down. Each site starts with:  Location for project documents  Change log  Decision log  Issue log  Risk log  Task log  Team discussion  Place to record project lead roles  Links to deliverable templates the project will use  Other useful links 75
Status Reporting and Project Reviews Projects create a status report each week that helps to articulate the overall status, remaining work, and barriers to progress.  Status is due by end of day each Thursday  Posted to the PMO SharePoint  Project leads report on the milestones, issues and risks and provide graphics that are most relevant to their project and their stakeholders  Friday the PMO consolidates and reviews the status reports  Monday the IT Projects and Planning Committee reviews the reports and acts on any prioritization issues, cross project dependencies, or change orders  The PMO may schedule project reviews with teams that require assistance during the week Mon Tues Wed Thurs Fri IT Projects Project Project Project Status and Planning Reviews Reviews Status Due Reviewed Committee 76
Change control process We discussed the concept of change control earlier. This page focuses on how to submit changes for approval  If impact is localized (e.g., does not require Project Lifecycle additional funding or resources, or has Establish Baseline Execute impact on other projects) then Initiate Plan Analyze Design/Build/Test/Deploy  Track on project SharePoint change log Identify changes to scope, schedule, cost  Review / approval from within project, Assess impact of changes Change control likely project steering committee process Submit for approval  If impact is not localized then If changes approved, update baseline  Track on project SharePoint and also ROM Estimate Baseline Estimate use the Change Control form  Review / approval from IT Projects and Planning Committee  RM, Sponsor and others can be present as appropriate 77
Gating tracker The 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 78
Want more info? https://projects.yale.edu 79
Comments, feedback, suggestions? HOW IS EDUCATION SUPPOSED TO MAKE ME FEEL SMARTER? BESIDES, EVERY TIME I LEARN SOMETHING NEW, IT PUSHES SOME OLD STUFF OUT OF MY BEST. CLASS. EVER BRAIN. REMEMBER WHEN I TOOK THAT HOME WINEMAKING COURSE, AND I FORGOT HOW TO DRIVE? 80
Thank you! 81

More Related Content

PDF
5 Ways SharePoint will Benefit your PMO
byKnowledge Management Associates, LLC
 
PDF
T359
byperformanceweb
 
PDF
How to Plan and Manage SharePoint Projects #hkspc
byDux Raymond Sy
 
PDF
T350
byguest287cb9
 
PDF
How to Effectively Plan, Execute and Control SharePoint Projects @ #SPSATL
byDux Raymond Sy
 
PDF
How to Effectively Plan, Execute and Control SharePoint Projects
byDux Raymond Sy
 
PPT
Managing Projects on SharePoint - Rich Blank - July 2010
byRich Blank
 
DOC
IT488_JaySexton_Week5GP
byJay T Sexton
 
5 Ways SharePoint will Benefit your PMO
byKnowledge Management Associates, LLC
 
T359
byperformanceweb
 
How to Plan and Manage SharePoint Projects #hkspc
byDux Raymond Sy
 
T350
byguest287cb9
 
How to Effectively Plan, Execute and Control SharePoint Projects @ #SPSATL
byDux Raymond Sy
 
How to Effectively Plan, Execute and Control SharePoint Projects
byDux Raymond Sy
 
Managing Projects on SharePoint - Rich Blank - July 2010
byRich Blank
 
IT488_JaySexton_Week5GP
byJay T Sexton
 

What's hot

PDF
How to Effectively Plan, Execute & Control SharePoint Projects
byDux Raymond Sy
 
PDF
OSPUG: How To Effectively Plan, Execute, Control SharePoint Projects
byDux Raymond Sy
 
PDF
How to Best Manage SP Projects #SPSNOLA
byDux Raymond Sy
 
PDF
Managing Enterprise Projects with Project Server 2010
byDux Raymond Sy
 
PDF
T356 Asmi
byperformanceweb
 
PDF
Leverage Project 2010 with SharePoint 2010 for Project Management Success
byDux Raymond Sy
 
PDF
How To Best Develop SharePoint Requirements #SPSNOLA
byDux Raymond Sy
 
PDF
Leverage Project 2010 w/ SharePoint 2010 for PM Success
byDux Raymond Sy
 
PDF
7 Ways to Leverage SP2010 for PM Success #PMIWDC
byDux Raymond Sy
 
PDF
Effectively Leverage Project 2010 w/ SharePoint 2010 for PM Success
byDux Raymond Sy
 
PDF
Leverage Project 2010 w/ SP2010 for PM Success @ SharePointFest Denver
byDux Raymond Sy
 
PDF
7 Ways to Leverage SharePoint 2010 for Project Management Success
byDux Raymond Sy
 
PDF
T353 Web
byperformanceweb
 
PDF
B310
byperformanceweb
 
PDF
SPSEMEA: Delivering SharePoint Success
byDux Raymond Sy
 
PPTX
How to effectively utilize project 2010 with share point 2010 mpugsemi_feb2012
byTimCermak
 
PPTX
What You Need to Know Before Upgrading SharePoint 2010
byPerficient, Inc.
 
PPTX
How to setup EVM within a PMO
byMichael Gowlett PMP, Prince 2 Practitioner
 
PDF
Delivering SharePoint Success: Why Collaboration is More Than Just Technology
byDux Raymond Sy
 
PDF
B303
byperformanceweb
 
How to Effectively Plan, Execute & Control SharePoint Projects
byDux Raymond Sy
 
OSPUG: How To Effectively Plan, Execute, Control SharePoint Projects
byDux Raymond Sy
 
How to Best Manage SP Projects #SPSNOLA
byDux Raymond Sy
 
Managing Enterprise Projects with Project Server 2010
byDux Raymond Sy
 
T356 Asmi
byperformanceweb
 
Leverage Project 2010 with SharePoint 2010 for Project Management Success
byDux Raymond Sy
 
How To Best Develop SharePoint Requirements #SPSNOLA
byDux Raymond Sy
 
Leverage Project 2010 w/ SharePoint 2010 for PM Success
byDux Raymond Sy
 
7 Ways to Leverage SP2010 for PM Success #PMIWDC
byDux Raymond Sy
 
Effectively Leverage Project 2010 w/ SharePoint 2010 for PM Success
byDux Raymond Sy
 
Leverage Project 2010 w/ SP2010 for PM Success @ SharePointFest Denver
byDux Raymond Sy
 
7 Ways to Leverage SharePoint 2010 for Project Management Success
byDux Raymond Sy
 
T353 Web
byperformanceweb
 
B310
byperformanceweb
 
SPSEMEA: Delivering SharePoint Success
byDux Raymond Sy
 
How to effectively utilize project 2010 with share point 2010 mpugsemi_feb2012
byTimCermak
 
What You Need to Know Before Upgrading SharePoint 2010
byPerficient, Inc.
 
How to setup EVM within a PMO
byMichael Gowlett PMP, Prince 2 Practitioner
 
Delivering SharePoint Success: Why Collaboration is More Than Just Technology
byDux Raymond Sy
 
B303
byperformanceweb
 

Viewers also liked

PDF
Challenging Aspects of Modern Project Management
byYamanta Raj Niroula, PMP
 
PPT
Ms Dynamics Sure Step 2010
byMohamed Aamer
 
PDF
Purchasing, Procurement, Vendor, Contract and RFP Process Management with Sha...
byOptimus BT
 
PPTX
Driving Business Value with Enterprise Social
byCreative Sharepoint
 
PPTX
2013 SharePoint Fest DC - Build a SharePoint Intake/Request List
byWes Preston
 
PDF
Recent ecm market developments from a share point of view q3
byMike Alsup
 
Challenging Aspects of Modern Project Management
byYamanta Raj Niroula, PMP
 
Ms Dynamics Sure Step 2010
byMohamed Aamer
 
Purchasing, Procurement, Vendor, Contract and RFP Process Management with Sha...
byOptimus BT
 
Driving Business Value with Enterprise Social
byCreative Sharepoint
 
2013 SharePoint Fest DC - Build a SharePoint Intake/Request List
byWes Preston
 
Recent ecm market developments from a share point of view q3
byMike Alsup
 

Similar to Yale waterfall delivery approach training deck

PDF
Why projects fail
byPonto GP
 
PPT
Why Do So Many Software Projects Fail?
byPhil Comelio
 
PPT
Spm unit 1
bysweetyammu
 
PDF
Project rescue fix it ot kill it
byJohn Cachat
 
PPT
01- Lecture 01 - Introduction to SPM.ppt
bySadiaMuqaddas
 
PPTX
Matinée PMI - Why so many technology projects failing
byPMI-Montréal
 
PPTX
The Project Management and Information Technology Context(1).pptx
byjayakodyjayakody
 
PPT
Software Engineering (Software size estimation).ppt
bysayedmujtabakazimi
 
PPT
2 Software-Project-VS-Other-types-of-Project.ppt
bylikipiki689
 
PPT
lecture8-190719030939.ppthjtyuiytiytiyti
byDharaniMani4
 
PPTX
Project Management System Architecture for Today
byIBRAHEEMMUHAMMADYAHA
 
PPT
1 2. project management
byakashsaini8
 
PPTX
Project Scheduling
byMSharmilaDeviITDEPT
 
PPT
Software Engineering (Project Scheduling)
byShudipPal
 
PDF
Managing international software projects interactively using scrum
byPeter Horsten
 
PDF
Overview Of Project Management - P&MSP2010 (2/11)
byEmanuele Della Valle
 
PDF
57086 01 introduction
byEngineering Department
 
PPT
223417 Diploma_Sem4_software_engg-chap-05.ppt
byDeepgaichor1
 
PPT
Ch5
byCristian Mureșan
 
PDF
Why Web Projects Fail
byRomae internet en content
 
Why projects fail
byPonto GP
 
Why Do So Many Software Projects Fail?
byPhil Comelio
 
Spm unit 1
bysweetyammu
 
Project rescue fix it ot kill it
byJohn Cachat
 
01- Lecture 01 - Introduction to SPM.ppt
bySadiaMuqaddas
 
Matinée PMI - Why so many technology projects failing
byPMI-Montréal
 
The Project Management and Information Technology Context(1).pptx
byjayakodyjayakody
 
Software Engineering (Software size estimation).ppt
bysayedmujtabakazimi
 
2 Software-Project-VS-Other-types-of-Project.ppt
bylikipiki689
 
lecture8-190719030939.ppthjtyuiytiytiyti
byDharaniMani4
 
Project Management System Architecture for Today
byIBRAHEEMMUHAMMADYAHA
 
1 2. project management
byakashsaini8
 
Project Scheduling
byMSharmilaDeviITDEPT
 
Software Engineering (Project Scheduling)
byShudipPal
 
Managing international software projects interactively using scrum
byPeter Horsten
 
Overview Of Project Management - P&MSP2010 (2/11)
byEmanuele Della Valle
 
57086 01 introduction
byEngineering Department
 
223417 Diploma_Sem4_software_engg-chap-05.ppt
byDeepgaichor1
 
Ch5
byCristian Mureșan
 
Why Web Projects Fail
byRomae internet en content
 

More from Yale University Careers

PPTX
Users group meeting 2012 july yale presentation v2
byYale University Careers
 
PPTX
Knowledge12 yale service management rapid maturity yale format
byYale University Careers
 
PPT
Introduction to the itsm program at yale why are we doing this august 2011
byYale University Careers
 
PPTX
Radcliffe rapid maturity through csi just yale slides
byYale University Careers
 
PPTX
Itsm knowledge roadmap ar updates
byYale University Careers
 
PPT
Request management lunch and learn v3
byYale University Careers
 
PPTX
Pecha-Kucha 2 Social Media Visibility- 20 slides-20 sec each
byYale University Careers
 
PPTX
Service lifecycle placemat v3
byYale University Careers
 
DOCX
Pecha-Kucha 2 script March 2014
byYale University Careers
 
PPTX
Using Social Media for Departments and Programs at Yale
byYale University Careers
 
PPTX
Using social media to increase organizational committment
byYale University Careers
 
PPTX
Knowledge hackathon
byYale University Careers
 
PPTX
Service management roadmap fy14 fy16
byYale University Careers
 
PPTX
Turn your skills into a career in IT
byYale University Careers
 
PPTX
Collaboration Landscape at Yale (C-level Executive presentation)
byYale University Careers
 
PPTX
Wit for orientation
byYale University Careers
 
Users group meeting 2012 july yale presentation v2
byYale University Careers
 
Knowledge12 yale service management rapid maturity yale format
byYale University Careers
 
Introduction to the itsm program at yale why are we doing this august 2011
byYale University Careers
 
Radcliffe rapid maturity through csi just yale slides
byYale University Careers
 
Itsm knowledge roadmap ar updates
byYale University Careers
 
Request management lunch and learn v3
byYale University Careers
 
Pecha-Kucha 2 Social Media Visibility- 20 slides-20 sec each
byYale University Careers
 
Service lifecycle placemat v3
byYale University Careers
 
Pecha-Kucha 2 script March 2014
byYale University Careers
 
Using Social Media for Departments and Programs at Yale
byYale University Careers
 
Using social media to increase organizational committment
byYale University Careers
 
Knowledge hackathon
byYale University Careers
 
Service management roadmap fy14 fy16
byYale University Careers
 
Turn your skills into a career in IT
byYale University Careers
 
Collaboration Landscape at Yale (C-level Executive presentation)
byYale University Careers
 
Wit for orientation
byYale University Careers
 

Recently uploaded

PDF
Enterprise Architecture Professional Journal Vol X November 2025.pdf
byDarryl_Carr
 
PDF
Humans cannot be transformed but we can help them - PLM Roadmap PDT Europe 20...
byJos Voskuil
 
PDF
Slide deck AI-powered engineering training program
byMIPLM
 
DOCX
7 Surprising Ways Metaverse Development Solutions Are Transforming Online Bus...
byRyan Wilson
 
PPTX
ActARion - The Future of Work with AI and Augmented Reality
byOrtwin Verreck
 
PDF
Where to Buy LinkedIn Accounts_ [12 Best Sites] (2).pdf
bydubivgplc4wloha4rxsm
 
PDF
How do I subscribe to Snapchat in usa 2025+_.pdf
bydubivgplc4wloha4rxsm
 
PDF
NeoBank Innovation Hackathon. On-Demand Events in San Francisco.
byTatianaSF.com
 
PDF
The Most Recommended Commerce Colleges of the Year in 2025.pdf
byEducationView
 
PDF
Getting ready for MTD – obligations, process and software
byFelixPerez547899
 
PDF
How to Buy, verified Apple pay Account.......pdf
bya32sop3orzibld4x34e4
 
PDF
ment.tech-Top 10 Digital Identity Wallet Development Companies 2026
byhirecorporate32
 
PDF
Lion One Corporate Presentation November 2025
byAdnet Communications
 
PPTX
Summaries of the 20 best business books of 2025.
byKevin Duncan
 
PDF
Investment Proposal (Business Plan) Electric Vehicle Charging Station in Lami...
byReyan Business Consultancy
 
DOCX
Trusted Top Site to Buy Verified PayPal Account Online Finance.docx
byCan I buy a verified Wise account?
 
PDF
Securiport Gambia - Border Solutions Security Group
bySecuriport Gambia
 
PDF
Joseph Heiman New Jersey - Passionate About Finance
byJoseph Heiman New Jersey
 
PPTX
Precautionary Landing Presentation Slide
bysamueledolce1997
 
PDF
Pre- 97 proposition to the parliamentary member
byHenry Tapper
 
Enterprise Architecture Professional Journal Vol X November 2025.pdf
byDarryl_Carr
 
Humans cannot be transformed but we can help them - PLM Roadmap PDT Europe 20...
byJos Voskuil
 
Slide deck AI-powered engineering training program
byMIPLM
 
7 Surprising Ways Metaverse Development Solutions Are Transforming Online Bus...
byRyan Wilson
 
ActARion - The Future of Work with AI and Augmented Reality
byOrtwin Verreck
 
Where to Buy LinkedIn Accounts_ [12 Best Sites] (2).pdf
bydubivgplc4wloha4rxsm
 
How do I subscribe to Snapchat in usa 2025+_.pdf
bydubivgplc4wloha4rxsm
 
NeoBank Innovation Hackathon. On-Demand Events in San Francisco.
byTatianaSF.com
 
The Most Recommended Commerce Colleges of the Year in 2025.pdf
byEducationView
 
Getting ready for MTD – obligations, process and software
byFelixPerez547899
 
How to Buy, verified Apple pay Account.......pdf
bya32sop3orzibld4x34e4
 
ment.tech-Top 10 Digital Identity Wallet Development Companies 2026
byhirecorporate32
 
Lion One Corporate Presentation November 2025
byAdnet Communications
 
Summaries of the 20 best business books of 2025.
byKevin Duncan
 
Investment Proposal (Business Plan) Electric Vehicle Charging Station in Lami...
byReyan Business Consultancy
 
Trusted Top Site to Buy Verified PayPal Account Online Finance.docx
byCan I buy a verified Wise account?
 
Securiport Gambia - Border Solutions Security Group
bySecuriport Gambia
 
Joseph Heiman New Jersey - Passionate About Finance
byJoseph Heiman New Jersey
 
Precautionary Landing Presentation Slide
bysamueledolce1997
 
Pre- 97 proposition to the parliamentary member
byHenry Tapper
 

Yale waterfall delivery approach training deck

  • 1.
    IT Project DeliveryApproach 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 wehere? To learn about the IT project delivery approach WELCOME CLASS! After this training you should: Be able to describe and use the basic structure of the IT project delivery approach Understand some of the best practices that help projects to be successful Know where to get more information and help when you need it Be better prepared to help your projects succeed!! 2
  • 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 3 Closing and Survey 15 3:00 3:30
  • 4.
    Who are we? Beforewe begin, let‟s get to know each other Please tell us about:  Your department and role  Years at Yale  Previous experience / familiarity with project delivery methodologies  One interesting project experience you‟ve had 4
  • 5.
    So, what isa project? Will deliver business and / or technical objectives in line with the University‟s strategic direction Runs for a defined period of time (has a start and end date) Has a budget Uses University resources 5
  • 6.
    Work Categories All requested work can be categorized based on size or type Central A Major project, estimated at $250k or more funding, allocated by officers each year B Minor project, estimated between $50-$249k Client funded S Self funded request of any size Baseline C Small enhancement, estimated at less than $50k funding, pre- set each year M Maintenance and break/fix requests 6
  • 7.
    What is aproject delivery approach? Our approach includes:  Solution and business integration development lifecycle (SDLC) – What activities do I perform? – What deliverables do I create?  Project governance framework – Who is responsible for what? – How are decisions made for a project? Across all projects?  Project management Processes – How do I manage scope, schedule, cost, resources, quality, communications, risks and vendors? 7
  • 8.
    What is projectsuccess? Project success occurs when we have:  A satisfied client (expectations met) Scope  Delivered the agreed objectives  Met an agreed budget ($, resources, etc)  Within an agreed time frame And, we‟ve done it all professionally and without killing the team Time Cost “Scope, Schedule, Cost” The “Golden Triangle” of Project Success 8 According to Gartner, approximately 60 – 70% of IT projects fail
  • 9.
    Simply put, successis a balancing act YOU THINK THIS IS HARD? IN MY LAST JOB I MANAGED PROJECTS WITH MULTIPLE STAKEHOLDERS AND CONFLICTING PRIORITIES 9
  • 10.
    Before we lookat the approach, let‟s first examine why projects fail The bridge was nicknamed “Galloping Gertie” due to movement on windy days Not all failures are this easy to spot . . .  The Tacoma Narrows Bridge project failed before the first yard of concrete was poured  There was nothing wrong with the construction. Poor design and badly planned cost cutting in materials led to an unfortunate end  No human life was lost when the bridge collapsed on 11/7/1940, but Tubby the dog went down with his owners car when he refused to be removed 10
  • 11.
    “This time it‟sdifferent” There‟s an old saying about how there are a million ways to fail, but only one way to be right. When it comes to projects, nothing‟s further from the truth. Projects fail the same few ways over and over again. Don‟t go in the basement! Technology projects are a lot like cheesy horror movies. After you‟ve seen a few of them, you know that the first guy to leave the group is going to get an axe in his head. Projects are the same way. People keep making the same mistakes over and over, and it keeps getting their projects killed. 11
  • 12.
    You know you‟reon a failed project when . . . JETSON, YOU‟RE A judge in 1964 said (and we paraphrase), “I FIRED!!!! don‟t know how to define pornography, but I know it when I see it.” And the same goes for failing projects - we can all spot a failing project when we see one. What does a failing project look like? You certainly know your project failed if it got aborted and everyone was laid off. But there are other, less obvious kinds of failure:  The project costs a lot more than it should  It takes a lot longer than anyone expected  The product doesn‟t do what it was supposed to  Nobody is happy about it Justice Potter Stewart‟s concurring opinion in Jacobellis v. Ohio: “I shall not 12 today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it.”
  • 13.
    Sometimes failure seemsnormal Nobody sets out to fail, but for some reason people just accept that a lot of technology projects won‟t deliver on time, on budget with the expected scope intact. But talking about what causes failure makes people uncomfortable, because nobody wants to give or take that kind of criticism. A show of hands, please… We‟ve never met a single IT professional with more than a few years of experience who hasn‟t been on at least one failed project. Are there any here? 13
  • 14.
    Four basic waysprojects can fail There are plenty of ways that you can categorize failed projects. We like to think of them like this:  Things the product does (or doesn’t do) How your project doesn‟t quite meet the needs of the people you built it for  Things the team should have done Once in a while, it really is the team‟s fault  Things that could have been caught . . . but weren‟t until it was way too late  Things the boss does Classic management mistakes that can damage the project 14
  • 15.
    Things the productdoes (or doesn‟t do) It seems pretty obvious that you should know what the software‟s supposed to do before you start building it... not that that stops us.  We only find serious problems after we‟ve built them into the product  Scope keeps changing and growi ng  No one is sure who gets to choose what the product does  90% done, with 90% left to go 15
  • 16.
    Things the teamshould have done The team could have done the work more efficiently, if only we‟d taken the time to think it through.  Planning is not done thoroughly  Issues and risks are not identified and acted upon quickly enough  Dependencies are not understood  Expectations are not managed well 16
  • 17.
    Things that couldhave been caught Which would you choose: a well built product that doesn‟t do what you need or a crappy one that‟s irritating to use and does?  Getting a few tech support people to “bang on the software” is not testing  Maybe we could‟ve caught that design problem before the code was built  Maybe we could‟ve caught that code problem before we went to test  Wishful thinking does not make an application run faster 17
  • 18.
    Things the bossdoes Some problems start with senior managers, others start with key stakeholders, but they can all sink the project.  Over promising  Ignoring issues and risks  Artificial wall between the business and technology  Over simplifying 18
  • 19.
    Brains are importanttoo . .. HOW MANY TIMES A good approach is not a replacement DO I HAVE TO TELL for good judgment and sound skills. We YOU, IT‟S RIGHT TIGHTY, LEFTY could have the best tools in the world, LOOSEY but most of us still could not fix the space shuttle or perform surgery.  A sound approach is a good start, but we also need to be the owners of our own ability  Understanding how to use the tools and your own personal development path is probably the most important thing we would like you to learn today  The good news is that a standard, proven approach will help us to focus on the execution of the work and help us to better help each other Goober worked at Wally's Filling Station, which he 19 eventually purchased and became the proprietor
  • 20.
    The talent isthere… the delivery management‟s not Hoover Dam was finished two years early, and under budget. Technology projects are not so different that we can‟t engineer them just as well.  Our problems have, for the most part, been solved  Over and over and over again. Seriously.  We just have to stop ignoring the solutions The building of the Hoover Dam started in 1931 and finished in 1935, two years earlier than scheduled. And this is the reason chief 20 engineer of the project, Frank T. Crowe, was nicknamed “Hurry up”.
  • 21.
    Ok, let‟s getto the good part Our approach encompasses three areas: Solution and business integration lifecycle (our SDLC) Project governance Project management processes Let’s start by reviewing the SDLC . . . 21
  • 22.
    The Waterfall approach,or “how safe is your barrel”? Concept  The Waterfall Method was introduced by Winston Royce in 1970. It is the oldest and Requirements & Plan most widely used development approach  SDLC and Waterfall are not the same – Waterfall is one type of SDLC Design Solution AND MY  It involves a sequence of steps or stages, DRESS DIDN‟T EVEN GET output from one stage is input to the next WET Build and Unit Test Solution Parts  Stages can sometimes overlap, but there are very definite goals for each phase Integration Test and Customer Acceptance  Biggest drawback of the waterfall model is that revision (scope and design changes) can be difficult and costly if not managed Deploy properly Later we will talk about a concept called “Phase Containment” that helps to manage some of the drawbacks of waterfall 22 Winston W. Royce (1929–1995) was an American computer scientist, director at Lockheed Software Technology Center in Austin, TX, and one of the leaders in software development in the second half of the 20th century. He was the first who described the Waterfall model for software development
  • 23.
    Phases Plan Analyze Design Build Test Deploy Operate Initiate Our implementation of the waterfall approach uses the following phases:  Initiate – Request a new project and get approval to allocate resources (and spend $$!)  Plan – Create project plan and define goals and expectations  Analyze – Confirm requirements for the product  Design – Detail the design of the product  Build – Create the product  Test – Validate that the product does what it is supposed to do  Deploy – Move the product into production  Operate – After the project is closed, run the product in production 23
  • 24.
    Initiate Phase Plan Analyze Design Build Test Deploy Operate Initiate The project charter is the primary outcome of the Initiate phase. It prepares the project to officially launch, which means the project can begin to allocate resources and spend money.  Names sponsor, business relationship manager and project lead  Project purpose  Strategic fit  Success metrics  Known scope & requirements (high level)  Known stakeholders  Known risks & constraints  Project governance  Rough order of magnitude (ROM) schedule, resources and costs  Milestones, resources and costs for next phase (typically plan or plan and analyze) 24
  • 25.
    Plan Phase –What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the plan phase, we should know:  What is in scope, what is out of scope  The high level requirements of the target state applications, processes and organization  The current state of the applications, processes and organization  The proposed target state of the applications, processes and organization  The steps needed to move from current state to target state  An approach for sourcing  Approaches for managing the projects scope, schedule, cost, resources, risk, quality and communications  Which deliverables the project will produce  Whether we will buy and / or build technology  Which package(s) will be used for technology that will be bought  The underlying technical infrastructure needed to support analysis and design  Who the stakeholders are and what is important to them  The potential impacts on the target organization  Who we need to communicate to, when, how, why and to say what  A draft plan, team and cost estimate on what it will take to move from current to target 25
  • 26.
    Plan Phase –What we do Plan Analyze Design Build Test Deploy Operate Initiate Formally establish the project. Staff initial team members, begin project meetings, establish steering committee, create project status reports Document how the project will be organized and governed – consider who is responsible for each aspect of the project, how the team will be organized, what forums will be used to govern the project and who is on each forum Define the underlying technical architecture required to support the target application environment Define who needs to know what, when, how and why Assess the delivery approach and tailor it to the needs of the project. This includes phases, activities, deliverables, gating, sourcing, usage of vendors and other 3rd parties, etc 26
  • 27.
    Plan Phase –What we create Plan Analyze Design Build Test Deploy Operate Initiate The solution blueprint contains a definition of the target state environment. This can include (but is not limited to) the application, infrastructure, process and organization target states. In addition, target training and the project delivery approach are documented here The stakeholder and organization impact analysis documents the stakeholders, their degree of influence on the project and how they will be impacted by the project. It also documents potential organizational impacts The project management plan documents the project scope, schedule & cost and how these items will be managed / governed 27
  • 28.
    Analyze Phase –What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the analyze phase, we should know:  How the target state processes will work  The detailed requirements that the target state must support  Where there are gaps in how the vendor package(s) support the requirements  General approach for filling the gaps (e.g., custom mod, drop requirement, etc)  Use cases and the conceptual data model, for custom development  Identification of the RICEFW widgets that will be designed and built (RICEFW = Reports, Interfaces, Conversions, Extensions, Forms, Workflows)  High level designs to reflect how the requirements will be supported (where applicable and needed to determine RICEFW definition)  The approach that will be used to test that the target solution meets the requirements and does not have a negative impact on other systems or processes  The definition of, and the plan to build (where necessary) the technical infrastructure needed to support build, test and deploy  The approach that will be used to train users and other impacted parties on the target solution  Understanding of the current organization  Understanding of the impact of new processes and technologies on the organization, including roles, jobs, teams and performance measures  A baseline plan, team and cost estimate on what it will take to move from current to target 28
  • 29.
    Analyze Phase –What we do Plan Analyze Design Build Test Deploy Operate Initiate Document the requirements that the target solution must support. Consider requirements across functional, technical and operational areas, as well as prioritization and potential phasing of requirements Reports, Interfaces, Conversions, Extensions, Forms, Workflows. Define the set of widgets that will be designed, built and tested. In some cases, a high level design will be needed to fully identify the widgets Consider and plan for any infrastructure components that need to be procured, built and / or configured. This should include your desktop infrastructure as well. Let‟s not forget about the managed desktop! For components of design & build that will be done in an iterative fashion (typically applies most easily to components that involve user interaction, such as process & form design) define the set of iterations that will be executed Document how the end users will be trained and educated on the usage of the target solution. Consider who needs to be trained, when they need to be trained, how they will receive training, what needs to be designed & built to support training 29
  • 30.
    Analyze Phase –What we create Plan Analyze Design Build Test Deploy Operate Initiate The RTM documents each requirement of the target solution and facilitates traceability between requirements and associated test scripts. The RTM can also be uplaoded into a testing tool, such as SQA, and Package system gaps are also defined within the RTM The security design review gathers data to facilitate the The test approach defines the test phases and cycles that identification of potential security risks associated with will be used to test the target solution the target state. Note that an initial completion of the document is done in the analyze phase, with the final version due at end of test 30
  • 31.
    Design Phase –What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the design phase, we should have:  A prototype of the application to demonstrate how it will work  For custom solutions, design of common application classes and components  For custom solutions, a logical database design  Design of the application configuration  Functional designs for reports, interfaces, conversions, extensions, forms and workflows that describe how these components will work  Necessary development environments are ready  End user organization, roles and jobs are defined  Design for the delivery of training  Definition of how the target solution will be supported in the operating environment (both functionally and technically), gaps between the current and target support models, and the plan to close the gaps 31
  • 32.
    Design Phase –What we do Plan Analyze Design Build Test Deploy Operate Initiate Build a model or working application that demonstrates how the product will look, act and feel, with the intent of gaining stakeholder feedback. This process can be iterated as part of the iterative approach, where applicable Define how the target product will be supported in the operational environment, including the roles needed to support, the gaps between current and target state, and the plan to move to target Create the functional designs for each widget that describe visually and textually how each widget (and the overall product) will work and what it will do 32
  • 33.
    Design Phase –What we create Plan Analyze Design Build Test Deploy Operate Initiate The workforce transition plan defines the steps and approach to move from the current organization (jobs, roles, etc) to the target organization The prototype is a mock-up or “alpha” version of the target product, with the intent of demonstrating how the product will look, act and feel The role descriptions document defines the roles and responsibilities that will exist in the target organization The training plan defines the details of each training approach / session so that training can be planned and coordinated 33
  • 34.
    Build Phase –What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the build phase, we should have:  A master configuration for the packaged software that can be applied to build and test environments  Technical designs for reports, interfaces, conversions, extensions, forms and workflows that describe how these components will be built  Built, unit and assembly tested application components  For custom builds, a physical database created from the logical data definition  Test planning complete, including build of test cycles, scenarios and scripts  Plans to staff the new organization as necessary  Built training and communications materials  Technical infrastructure and environments ready for test, training and deploy 34
  • 35.
    Build Phase –What we do Plan Analyze Design Build Test Deploy Operate Initiate Create the detailed technical designs that describe how the target solution will be built Create physical database Define the test cycles, scenarios and scripts that trace Build the materials that will be used to support end user back to each requirement to ensure that each requirement training is tested Build the remaining environments that are needed for test training and deployment Confirm that the build objects meet organizational standards, and have been appropriately unit and assembly tested 35
  • 36.
    Build Phase –What we create Plan Analyze Design Build Test Deploy Operate Initiate The knowledge management content is the information needed by the supporting organizations (e.g., service desk, functional support, technical support, etc) to meet expected service levels The test plan is comprised of the cycles, scenarios and test scripts that will be used to ensure that the target product supports requirements Update of the communications plan established in the plan phase 36
  • 37.
    Test Phase –What we get Plan Analyze Design Build Test Deploy Operate Initiate By the end of the test phase, we should have:  A validated target product that meets performance, security, functional, desktop, and end user expectations  An agreed to freeze on changes to application code  Approved security design  A conversion process that has been tested  Completed runbooks  Agreed to contingency plans  Tested cutover plans  Piloted training  End users and stakeholders that are aware of the forthcoming changes, and prepared to accept them 37
  • 38.
    Test Phase –What we do Plan Analyze Design Build Test Deploy Operate Initiate Prepare and test the cutover plans end to end prior to actual cutover. Iterate until the cutover process is working at an acceptable level Pilot the training, make adjustments based on feedback, and then deliver training as planned Ensure that the target solution meets the desktop Confirm formal approval from the sponsor and key requirements stakeholders that the target product is ready to be deployed into the production environment Freeze all changes to the application code until the application is deployed. Once the application is deployed, bugs will be prioritized, fixed and the application regression tested. New functionality should wait for a new release Execute mock conversion to test the end to end conversion process prior to actual conversion. Iterate until conversion process is working at an acceptable level 38
  • 39.
    Test Phase –What we create Plan Analyze Design Build Test Deploy Operate Initiate Final version of security design review The cutover plan documents the steps, sequencing and The runbooks are a handbook that describe the overall timing of the activities needed to migrate from the test technical architecture and operational considerations for environment to the production environment an application, and are used by the technical support teams 39
  • 40.
    Deploy Phase –What we get Plan Analyze Design Build Test Deploy Operate Initiate At the end of the deploy phase, we should know:  Data converted into production environments  Application code migrated to production environments  End users trained and communicated to  Target state (organization, processes and application) rolled out as specified by requirements and delivery approach  Critical and high priority post deployment issues resolved during warranty period  Responsibility for operating and maintaining the target state is transferred to the operating teams  Completed project closure report 40
  • 41.
    Deploy Phase –What we do Plan Analyze Design Build Test Deploy Operate Initiate Move all involved application and technical components into the production environment Execute user support model by providing launch support for the end users and when appropriate move to the operational user support model Deliver the training and communications necessary to make stakeholders aware of the target product, and enabled to operate successfully in the target environment, with the target tools Identify, prioritize and resolve issues during the deployment period until the target environment has reached a pre-defined level of stability Formally transfer operating and maintenance responsibility to the operating teams, disband the project team, stop project funding 41
  • 42.
    Deploy Phase –What we create Plan Analyze Design Build Test Deploy Operate Initiate The user feedback report documents the results of user interviews, focus groups, usability tests, and other interactions with users throughout the project The project closure report provides an overall wrap-up of The training evaluation summary records feedback from the project. It documents key learnings, known open items, end users on training, to help the team identify where overall project execution statistics, etc training works, and where it would benefit from improvement 42
  • 43.
    Agile Techniques Operate Plan Analyze Design Build Test Deploy Initiate Design Build Agile Techniques – For each Sprint: Design UI, process Review build Review design Customer Confirm scope flow, workflow, Do incremental with customer output or data with customer and approval of of sprint make changes build and make usage sprint changes  Within the context of the waterfall approach, some functions may benefit from a more iterative design & build approach  Common examples include application forms, configuration and reports, but can apply to any functions that can be mostly built and validated on a stand-alone basis  These techniques are not a replacement for full Agile development. Agile is a different type of SDLC that is not covered in this training  Beware that iterative development has it‟s own pitfalls, including potential for rework and cost and schedule over-runs 43
  • 44.
    Operate Phase Plan Analyze Design Build Test Deploy Operate Initiate Entry into the operate phase represents official closure of the project  Project funding ends  Project team and governance disbands in favor or operating team and governance  Project resources go onto other projects or activities  The operational teams take ownership of the application and supporting processes 44
  • 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? 45
  • 46.
    Case study #1 Refer to case study #1 handout 46
  • 47.
    Next, let‟s lookat project governance . . . Our approach encompasses three areas: Solution and business integration lifecycle (our SDLC) Project governance Project management processes 47
  • 48.
    What is governance? Thereare probably few terms that are used as freely, but understood as poorly, as the term “governance”. We LET „EM HANG Judge Isaac Parker aka “The Hanging Judge” will continue the trend by using it freely. However, we will try to make some sense of what it is and why it is important - mostly so that you can impress your friends and neighbors, but also so that you can understand how you can use it to help your projects to be more successful  One definition of governance: “Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT”  We can simplify it further: “Defining who is He has decision authority responsible for what and who can make which The unfortunate accused decisions” 48 They are accountable
  • 49.
    Levels of governance Ourapproach considers governance at the project level, and cross-project (or portfolio) level Portfolio  Decisions that cross projects, such as funding, resources and dependencies  Decisions that are local Project 1 Project 2 Project 3 Project n to a project, such as scope, design approach and deliverable quality 49
  • 50.
    Project Roles ACTION! How are projects like movies? No, not the long hours and poor reviews from the critics. Both rely on standard roles to help them run smoothly. On any movie set everyone knows what the key grip and gaffer are responsible for. Successful projects operate in the same way, with standard roles and clear understanding of responsibilities and decision making authority.  Sponsor - Proposes and champions the project. Responsible for the project‟s success  Relationship Manager - Responsible for translating business vision into solution, staffing, and delivering solution  Project Lead – Responsible for delivery of project scope, on time and within budget  Functional Lead – Responsible for delivery of the functional solution  Technical Lead – Responsible for delivery of the technical solution  Change Management Lead – Responsible for organizational and user adoption of the solution Like Eddie Murphy in The Nutty Professor, an 50 individual can play more than one role on a project!
  • 51.
    Project Escalation Paths WE‟RE BEHIND SCHEDULE? WHY DIDN‟T YOU TELL ME?! Bosses tend to be happier when you don‟t surprise them, especially if the surprise brings bad news. Every team member should know what to do when they have a problem that they cannot resolve themselves. A well defined process to identify, escalate and resolve problems is an essential part of how any project is governed  The structure and number of escalation levels is dependent upon the size and complexity of the project and Steering the organization, but typically want as Committee few as possible Project Status Meeting  Team members should be encouraged Team Status Meeting(s) (and empowered) to resolve issues at the local level, but should also know where to get help when they need it  The Project Lead is responsible for Team Status Meeting(s) facilitating the escalation process, but every team member is responsible for Review progress, deliverables, issues, decisions, risks, etc related to a specific team or subset of the project Team lead Team members Team members Team members Team members identifying, resolving and escalating As defined by the team leads and project lead problems 51
  • 52.
    Portfolio Governance The ITProjects and Planning Committee is the “supreme court” for decisions that impact the portfolio of projects. Business specific issues may still require escalation through the business area, but items that are IT related or have impact across the portfolio of projects can be escalated to this council for final decisioning AS CHIEF DO YOU SMELL I THINK IT JUSTICE, I SOMETHING WAS ALITO DECLARE IT FUNNY? WAS SCALIA 52
  • 53.
    Gating I SURE HOPE MY GATING PAPERS ARE IN ORDER . . . Gating is part governance function and part quality assurance. The intent of gating is to help apply our standards (such as this delivery approach) and to bring broad transparency to the solutions being built. It also helps to support the concept of “phase containment” whereby the problems from earlier phases do not have a snowballing affect on later project phases Funding Starts Funding Baselined Deployment Decision Funding Stops Plan and Analyze ($100k – 250k) Small Projects Approval Express Path Establish ROM Estimate Screening and Definition Does Not Gate Enhancement Sprints Operate <$100k Initiate Plan Analyze Design Build Test Deploy Go/No-Go Decision Planning Estimate Baseline Estimate Design Approval Planning Phase Major Projects Build Approval (over $250k or Requirements highly visible) Approval Approval Full Path There can be multiple paths through Project Launch Gate Plan Gate Analyze Gate Design Review Gate Build Review Gate Go/No-Go Gate Project Close Gate gating depending upon the project type, size and complexity. Two typical paths are shown here “Are we ready to “Can this project be “Are the “Do we know how we “Does the code meet “Does the product “Can the functionality start spending money successful based on requirements clear, will build the product our coding meet the be supported planning this work?” the plans?” agreed to and to support the standards?” requirements?” operationally?” achievable?” requirements?” “Are we ready to deploy into production? 53
  • 54.
    Gating Approvals  Gating is facilitated by the “Gating Questionnaire”, a set of questions Gating is run by the key organizational leads that are for each phase impacted by and / or responsible for project outcomes.  The questions are aligned by the The transparency from gating gives these organizational areas supported by the key organizational leads who attend leaders a chance to review solutions and raise concerns gating which in turn helps to increase the overall quality of our  The project lead is responsible for solutions preparing for project gates  Gating manifests in physical signoff to indicate approval by the gating committee and project leads PM010 - Gating Questionnaire Portfolio Management Office (PMO) Illustrative • Is the project scope clear, agreed to and achievable? • Is the plan / approach for delivering the project clear and concise? • Is the schedule clearly defined and achievable? Architecture • Is the solution architecture consistent with the scope and objectives of the project? • Is the solution architecture consistent with Yale’s reference architecture standards? • Does the plan include retirement of legacy systems where applicable? Information Security • Does the solution involve sensitive data? • Are there any initial security concerns with the solution? Infrastructure and Production Services • Have the environments needed to support the development effort been identified? • Have all infrastructure requirements been identified? • Does the plan include relevant infrastructure tasks? Deployment • Are the stakeholders identified and engaged? • Are the stakeholders expectations understood and considered? • Does the plan consider necessary training and change management activities? 54
  • 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? 55
  • 56.
    Let‟s look atproject management processes. . . Our approach encompasses three areas: Solution and business integration lifecycle (our SDLC) Project governance Project management processes 56
  • 57.
    Think good projectmanagement skills were important for this? I BELIEVE THAT THIS NATION SHOULD COMMIT ITSELF TO ACHIEVING THE GOAL, BEFORE THIS DECADE IS OUT, OF LANDING A MAN ON THE MOON AND RETURNING HIM SAFELY TO EARTH On May 25, 1961, President John F. Kennedy announced before a special joint session of Congress the dramatic and ambitious goal of sending an American to the Moon before the end of the decade ONE SMALL STEP FOR (A) MAN, ONE GIANT LEAP FOR PROJECT MANAGEMENT On July 20, 1969, barely 8 years later, Neil Armstrong became the first man to set foot on the moon. Buzz Aldrin quickly followed, while Mike “Hard Luck” Collins waited patiently in the Command Module in moon‟s orbit This is actually a picture of Buzz Aldrin, not Neil Armstrong, whose 57 famous quote we‟ve destroyed for our own selfish purpose. Do you know why there is not a clearer picture of Armstrong‟s first step?
  • 58.
    PMBOK, or yetanother silly acronym We‟ve already talked about the balancing act that is project management. The good news is that some very smart people (no, not us) have thought a lot about this and have documented (in ridiculous detail) just about everything you need to know about managing projects. This wealth of information is lovingly called the Project Management Body of Knowledge, or PMBOK for short. We will not attempt to reproduce PMBOK or try to make you all PMP certified. But we will attempt to draw your attention to some of the key concepts around PMBOK and how our delivery approach supports them. Even if you are not responsible for project or team management, the tools and techniques within can almost certainly help. The Project Management Institute published the first Guide to Project Management Body of Knowledge (PMBOK) as a white paper in 1987 in an attempt to document and standardize generally accepted project management information and practice PMBOK is an internationally recognized standard that provides the fundamentals of project management as they apply to a wide range 58 of projects (not specific to one industry or type of project) and is published by the Project Management Institute (PMI). PMI offers a PMP (Project Management Professional) certification based on PMBOK. For more information, visit http://www.pmi.org
  • 59.
    Project management knowledgeareas PMBOK thinks of the world in terms of “project management processes” and “project management knowledge areas”. For our purposes, we will focus on the following:  Change control  Issue and decision management  Scope management  Schedule management  Cost management  Quality management  Resource management  Communications management  Risk management  Vendor management 59
  • 60.
    Change control –how far is it from here I‟M DOUG. NICE TO MEET YOU. WHOA, HAVE YOU LOST to there if I don‟t know where here is? WEIGHT?? Scope creep. Schedule slip. Cost overruns. Each can kill a project. But how do you know your scope is creeping if you haven‟t agreed to what it should be? The concept of change control starts with the idea of setting a baseline. The baseline forms a common understanding and agreement of what will be built (scope), when it will be delivered (schedule) and how much it will cost. The sponsor, RM and project lead must all agree to the baseline. Once agreement is reached, material changes must follow a formal change control process. Project Lifecycle  Before planning starts, a rough order of magnitude (ROM) estimate for scope, Establish Baseline Execute schedule and cost are established Initiate Plan Analyze Design/Build/Test/Deploy  The ROM estimate is a “best guess” and is not yet based on a firm definition of scope & requirements Identify changes to scope, schedule, cost  At the end of the analyze phase, scope, schedule and cost are baselined Assess impact of changes Change control  The baseline estimate is more than a best process guess – it is based on a detailed Submit for approval understanding of scope, requirements, the target solution and the plan to get If changes approved, update baseline there  Once the baseline is set, changes must ROM Baseline follow a change control process 60 Estimate Estimate
  • 61.
    Issue and decisionmanagement, recognizing and removing barriers Someone once said “difficult times make great leaders”, . . . or “difficult leaders make great times”, . . . or something like that. The point is, projects often face difficult times. Barriers to progress should be expected. The best projects know how to remove barriers or how to find creative ways around or through them.  Actively identify and aggressively manage issues and decisions  Establish and manage an issue / decision log  Make sure all team members know how to escalate  Communicate resolutions to those who need to know  Document resolutions so that you will remember what was decided (or so that you don‟t need to keep resolving the same issues over and over again)  Make it clear who is responsible for resolving each issue and decision, when a resolution is needed, and the impact of not resolving  Involve steering committee early 61
  • 62.
    Scope management Scope managementis a core principle for a successful project, but is often done poorly because it is harder to measure than schedule and cost. A successful Sponsor and Project Lead will find effective ways to document and communicate scope so that all team members and stakeholders are clear on what to expect AFTER MEETING WITH HIS CLIENT, JIM WAS SURE HE UNDERSTOOD THE SCOPE OF THE PROJECT  Establish a baseline  Consider not only what is in scope, but what is out of scope  Write it down and get signoff  Document assumptions  Consider all areas that may represent work for the team, not just the functional scope. For example, are there legacy systems that should be retired because of this project?  Gain agreement on who can make scope decisions  Understand the relative priority of each scope item 62
  • 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 63
  • 64.
    Cost management Unless youare literally rolling in money (we‟re looking at you, Scrooge McDuck) most projects operate within a budget.  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 64
  • 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 65
  • 66.
    Resource management I NEED FRANKLY MY DEAR, RESOURCES I HOPE YOU HAVE FOR MY COMPLETED A PROJECT RESOURCE PLAN If you are on a project that only requires one resource, then our approach probably doesn‟t apply to you. However, a project of size or complexity will require involvement from multiple people to play multiple roles. Identifying the roles and the people to fill them, as well as establishing a “team feel” is an important part for any successful project.  Keep resource plans up to date  Co-locate teams whenever possible  Build and foster team spirit  Cross train team members  Stretch team members with challenging assignments and the opportunity to learn new things  Consider the training required and train the team together whenever possible  Consider all resources needed, including functional, subject matter expert (SME), testing, desktop technologists, including those who are part time.  Gain agreement in advance from resource managers that the folks you need will be available when you need them to be available  And be sure to plan for non-people resources, like development and test environments 66
  • 67.
    Communications & stakeholdermanagement OH, NOTHING. JUST WANTED TO DID YOU SAY MENTION THAT Have you ever been impacted by a change, but were not told about SOMETHING? WALL COMING UP it or involved in advance? We have all probably experienced this in some fashion, and it usually doesn‟t feel very good. Successful projects understand who the stakeholders are, what information they want, and how and when to get it to them. Project Stakeholders Steering Steering Committee Committee Senior Senior Clients & Users Clients & Users Management Management Academic & Academic & Interdependent Interdependent Project Project Business Units Business Units Projects Projects Information Information Outside Groups Outside Groups Technology Technology (e.g., vendors, etc) (e.g., vendors, etc) Team Members Team Members  Establish communications plan COULD BETTER COMMUNICATION PREVENTED THIS  Identify and engage all stakeholders CRASH?  Understand the impact the project can have on the stakeholders and the impact they can have on the project  Don‟t make promises that cannot be fulfilled  Focus groups, demos, pilots, town halls  Special communications from the Sponsor  Articles, web pages, newsletters A stakeholder is anyone who is impacted by, or who 67 can impact, the project  Listen, listen, listen
  • 68.
    But even withperfect communication . . . Homer reacts to the news that Springfield is being split into two area codes DON‟T FORGET THE WHAT DO YOU MEAN? LEAFLETS THEY WHAT REALLY BURNS ME THEY RAN THOSE TV DROPPED FROM THE UP IS THEY DIDN‟T GIVE NOT A SINGLE WORD OF COMMERCIALS ABOUT SPACE SHUTTLE, AND US ONE WORD OF WARNING . . . IT, AND THAT BIG THE TWO WEEKS WE WARNING RADIO CAMPAIGN ALL SPENT AT AREA CODE CAMP . . . we cannot always guarantee the message will be heard 68
  • 69.
    Risk management YOUR VENDOR WILL DELIVER LATE . . . BUT, YOU WILL BE LUCKY IN LOVE No, you don‟t need to be a fortune teller to deliver a successful project, but it does help to be able to predict the inevitable “gotchya‟s” that can derail any project. Risks are simply things that haven‟t yet occurred, but may impact the project if they do. Successful projects are able to identify risks, assess potential impacts, and take mitigation steps in advance.  Involve the whole project team, including stakeholders, in risk identification and mitigation  Develop and actively manage a risk plan  Make the risks and mitigations plans known, and enlist help when needed  Assign responsibilities to mitigate risks  Be on the lookout for new, and realized, risks for the life of the project As Poor Richard told us long ago, an ounce of prevention is worth a pound of cure 69
  • 70.
    Vendor management Sometimes wework with a vendor because they sold us the product, other times we need help or skills that we don‟t have available, and other times we just want someone else to blame when things go wrong (oops, did we say that one out loud?). Regardless of the reason for hiring a 3rd party to assist, it is helpful to keep in mind some basic best practices.  Plan early for knowledge transfer  Form partnership – become one team with one goal and one plan  Have vendor help to organize the team and plan  Follow the same methodology  Co-locate  Understand and influence the contract  Legal review of the contract  Tie payments to acceptance when possible  Look at fixed fee, but understand what it means to manage fixed fee work  Have single point of contact  Caveat emptor! 70
  • 71.
    Project Management ProcessesSummary  PMBOK is an excellent source for project management training and best practices  Good project management techniques can make things easier. Really.  The delivery approach has been built with the best practices for project management in mind Are there any questions on Project Management Processes? 71
  • 72.
    Case study #2 Refer to case study #2 handout 72
  • 73.
    Odds and Ends PMO SharePoint Project SharePoint Status reporting Change controls Gating tracker 73
  • 74.
    PMO SharePoint The PMOsharepoint is your one-stop-shop for information regarding the delivery approach and management of the overall portfolio of projects being delivered. It is located at https://projects.yale.edu  Templates and sample deliverables  Gating calendar  Location for placing project status reports  Delivery approach placemat  Helpful project management links  Links to portfolio project SharePoint sites  Link to portfolio archive site  And more! 74
  • 75.
    Project SharePoint Sites Eachproject has it‟s own SharePoint site. The site is created by the PMO and can then be administered and tailored by the project. At the close of the project, the projects deliverables are posted to the project team archive site, and the project site is shut down. Each site starts with:  Location for project documents  Change log  Decision log  Issue log  Risk log  Task log  Team discussion  Place to record project lead roles  Links to deliverable templates the project will use  Other useful links 75
  • 76.
    Status Reporting andProject Reviews Projects create a status report each week that helps to articulate the overall status, remaining work, and barriers to progress.  Status is due by end of day each Thursday  Posted to the PMO SharePoint  Project leads report on the milestones, issues and risks and provide graphics that are most relevant to their project and their stakeholders  Friday the PMO consolidates and reviews the status reports  Monday the IT Projects and Planning Committee reviews the reports and acts on any prioritization issues, cross project dependencies, or change orders  The PMO may schedule project reviews with teams that require assistance during the week Mon Tues Wed Thurs Fri IT Projects Project Project Project Status and Planning Reviews Reviews Status Due Reviewed Committee 76
  • 77.
    Change control process Wediscussed the concept of change control earlier. This page focuses on how to submit changes for approval  If impact is localized (e.g., does not require Project Lifecycle additional funding or resources, or has Establish Baseline Execute impact on other projects) then Initiate Plan Analyze Design/Build/Test/Deploy  Track on project SharePoint change log Identify changes to scope, schedule, cost  Review / approval from within project, Assess impact of changes Change control likely project steering committee process Submit for approval  If impact is not localized then If changes approved, update baseline  Track on project SharePoint and also ROM Estimate Baseline Estimate use the Change Control form  Review / approval from IT Projects and Planning Committee  RM, Sponsor and others can be present as appropriate 77
  • 78.
    Gating tracker The projectgating 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 78
  • 79.
    Want more info? https://projects.yale.edu 79
  • 80.
    Comments, feedback, suggestions? HOW IS EDUCATION SUPPOSED TO MAKE ME FEEL SMARTER? BESIDES, EVERY TIME I LEARN SOMETHING NEW, IT PUSHES SOME OLD STUFF OUT OF MY BEST. CLASS. EVER BRAIN. REMEMBER WHEN I TOOK THAT HOME WINEMAKING COURSE, AND I FORGOT HOW TO DRIVE? 80
  • 81.