Real Tools for Real People Project Management Real Tools for Real People Pam: By show of hands, how many are familiar with Project Management? Etc. Quick review of project management to get us started, Connie will describe the templates, DaveK will close with deeper dive areas and take us to the Q&A part. Lots of material … Also want to let you know that the materials are from the perspective of PMBOK and PMI, with a twist of Waterloo’isms …

Real Tools for Real People “A project is a temporary endeavor which creates a unique service, product or result.” - PMBOK Guide, 4th Edition Call from boss: The engine is broken. Can you find out what is wrong with it and fix it? Is this a project? Needs organization Project planning process produces schedules and budgets Can you schedule ‘fix it’ if you do not know what is wrong? There are at least two projects in the story. #watitis2012

Real Tools for Real People “A program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.” - PMBOK Guide, 4th Edition By grouping related projects into a program, an organization can coordinate the management of those projects. The program approach may help achieve decreased risk, economies of scale, and improved management. In addition to the work required to complete each individual project, the program also includes efforts like the program manager’s coordination and management activities. So, when you discover that you have more than one project, if there is a benefit to it, you can manage all the projects as a program. This should be done only when the program approach adds value. #watitis2012

Real Tools for Real People The Project Management Process includes initiating, high level project planning, detail project planning, executing and controlling, and closing process groups. Project management is not just a schedule or a bunch of documents. Challenge is to provide as much and as little project management as is necessary. The purpose of these methodologies are to provide a set of tools and templates to assist the Project Manager/Leader and Business Analysts or Functional Leads in reducing common risks associated with projects, and ensuring projects are executed more consistently. The information contained within the methodology should be adapted to individual projects, since each project is unique. - iterative - not linear #watitis2012

Real Tools for Real People Progressive elaboration is a term used in project management which means you learn more about the project’s characteristics as you progress through the project. Rolling wave planning uses progressive elaboration. Analogy: When you are in the attic with a flashlight, the objects closest to you are the most clear. As you move through the attic, things become clearer. Things further away are less focused. We add elaborate detail as we get closer to the targets. #watitis2012

Chavat’s Matrix Chavat’s Matrix of selecting light or heavy methodology (based on time and complexity) is a recommended guideline for determining how much structure should be used for a project #watitis2012

When thinking about how much “methodology” to use, also think about constraints like: time, cost, risk, scope, quality, risk, resources, customer satisfaction and any other factors that limit options. What effect will a change on one constraint have on another constraint? Will there be scope creep? Is there a need for change controls? Will there be time constraints? Are we worried about quality? Are there many risks involved? What about customer satisfaction? Is it important? How many stakeholders? Who is affected by this project? Think about this scenario: There is a tight deadline, people required to complete project activities have competing work priorities, and there is risk in not being able to a critical service without experienced, dedicated human resources. It may be that requests to add work and some great features that tie into strategic objectives are anticipated, potentially affecting the deadline. #watitis2012

Real Tools for Real People Connie starts here … #watitis2012

Real Tools http://ist.uwaterloo.ca/is/ Methodologies/ We will endeavor to go through all the templates in the Project Management Processes column, particularly focusing on the templates that are used more often. http://ist.uwaterloo.ca/is/ Methodologies/ Methodology_webChart.html #watitis2012

Program Charter Project Charter Why: Formally recognizes/establishes the existence of the program or project Authorizes program or project to spend money and commit resources Provides objectives and high-level requirements Identifies constraints and high-level risks Uncovers assumptions Links the projects or programs in the program to the ongoing work of the organization Recall the definition of a project – a temporary endeavor (i.e., beginning and an end!) which creates a unique service, product or result. The project charter recognizes or establishes the existence of the project through formal approval. …and the definition of program – group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually. The program charter captures the overall framework of the program. Assists in charting the program direction, high level scope, developing program deliverables and developing schedule requirements. The benefits listed in a program charter will be different than benefits listed in the project charter(s). Note: In terms of roles, a program manager is not necessarily a project manager. #watitis2012

Program Charter Project Charter When: Program Initiation Who: Key Stakeholders, Sponsor, Program Manager What: Problem statement, description, goals/ objectives, scope, critical success factors, assumptions, risks/issues, organization (including governance), funding, milestones, points of contact When: Project Initiation Who: Key Stakeholders, Sponsor, Project Manager What: High-level objectives, scope, constraints, assumptions, risks, dependencies, budget, timeline, strategy, roles & responsibilities, approval Program charter captures the overall framework of the program. The document assists in charting program direction and high level scope, and also assists with developing program deliverables and schedule requirements. Program overview contains problems statement, description, goals/objectives, scope, critical success factors, assumptions, risks/issues, structure, governance, stakeholders, roles & responsibilities #watitis2012

Program Charter? Project Charter? The critical patch update testing is done every year, lead by the same people. Waterloo needs to review a business process involving several departments. Waterloo needs to incorporate enterprise architecture to help align business strategy with IT. Major functional and technical changes are coming in the next release of the software. When should a program charter be used? #1 – charters not required … operational; refer to historic documents #2 – program charter required … efficiencies to be gained by grouping projects, not realized by individual projects #3 – program charter required … might be a tough one to answer if you don’t know what enterprise architecture is … set of projects to do system discovery and projects are managed via a program (for those of you who know what a portfolio is (outside of scope of presentation), the program may generate a portfolio #4 – project charter required. Especially where it is delivering new functionality. #watitis2012

Feasibility Study That’s a really amazing idea. Is it really possible? That seems like a great idea for a service. I don’t know what is involved. Do you? Does it make sense to do this project? Should we outsource this service? These are reasons for doing a feasibility study. Can you see how this document could save time, resources and money? What if we delved right into building or buying a product, and part way through the implementation you found out the solution just didn’t make sense for the University? #watitis2012

Business Case Sr. Management asks: Why should we do this project? What are the benefits? What are the costs? capture the reasoning for beginning a project in order to gain approval #watitis2012

Sometimes the governance model is included in the project/program charter or in the project management plan. Identifies the stakeholders and how they are involved. Example is for a governance model for CECA system. #watitis2012

High Level Project Timeline Connie typically uses this for a program or portfolio timeline, and where activities are specified on the template, projects would be specified. It gives an idea of what’s coming up and where we are, at a glance. These are easy to do in MS Visio. We had one at one time that had all our IS/enterprise systems projects on it with a 3-5 year timeline. As PMs, we love these charts. We plan to get to a day (next year, possibly) where we can have all these projects on some sort of dashboard, and then be able to drill into the details … #watitis2012

Project Management Plan Why: serves as an integration function records how the project is defined, planned, managed, and controlled This is the plan of all plans; it is the governance document for the project. It is used on medium or large projects. A project management plan is often confused for a schedule or timeline. It is not that. Recall earlier, when we described the PMBOK knowledge areas/constraints such as scope, risk, time, communication, human resource, quality, cost, integration … and “progressive elaboration” and rolling wave planning Pam referred to earlier? This document is a living document covering at least the ‘triple constraint/iron triangle’ constraints of scope, time and cost, and should be updated as things change through the project. The plan may be summary or detailed, depending on the size and complexity of the project. For large/complex projects, subsidiary plans add to this overall project plan … it is not a bunch of plans sewn together. Use the information in the project charter as input into the Project Management Plan. Feasibility studies and Business Cases may also be used, if applicable. #watitis2012

Project Management Plan When: High Level Project Planning (++) Who: Key Stakeholders, Sponsor, Project Manager What: Project management approach, scope, constraints, assumptions, milestones, schedule baseline, change control process, issues/request logging, plans for: deployment, communications, cost, procurement, scope, schedule, quality, risk, stakeholders, staffing, revision history Risk management efforts should be appropriate to the size and complexity of the project, as well as the experience and skill level of the project team. Planning for risk management answers the question of how much time should be spent on risk management based on the needs of the project. It also answers questions such as who will be involved and how the team will go about performing risk management. This type of information needs to be recorded about risks. We will talk about the risk register template and risk assessment and responses. Risks can be defined as threats, but they can also be defined as opportunities. An example of a risk opportunity may be to buy a greater quantity of something all at once (instead of as needed) to achieve deeper discounts. Another example may be to send a resource on training or bringing in a consultant with expertise. On large, properly managed projects where risk management has been an integral part of planning, the following occurs: There are no longer huge fires to put out every day – they were eliminated with risk response plans Risks are brought up in every meeting to be addressed before they happen If a risk event does occur, there is a plan in place to deal with it, meaning no more hectic meetings to develop a response #watitis2012

Project Management Plan Implementing a complex ERP solution involving most of the campus community, and involving significant cultural change. Implementing a new parking system. Minor technology upgrade to an ERP solution. Major functional changes to an ERP solution. #1 – yes; PM plan needed – communications plan would likely be documented in an Implementation Plan #2 – depends on how big the system is; maybe/maybe not; assuming project is not complex or has a long timeline (Chavat’s matrix), may not have a project management plan. Communications plan and stakeholder register would reside on their own. #3 – no #4 - yes #watitis2012

RF(x), where x=(I,P) (i.e., RFI or RFP) Procurement RF(x), where x=(I,P) (i.e., RFI or RFP) Procurement – RFP/RFI … contact Procurement early to help with your RFP/RFI. In IS, we typically help with gathering requirements and coordinating RFP efforts. Also check with CSS and networking regarding supported environments. #watitis2012

2 Requirement & Analysis Project Schedule: WBS Project Name 1 Initiation 1.1 Business Case 1.2 Evaluation & recommendations 1.3 Project Charter 1.4 Project Management Planning 1.5 Project Schedule 2 Requirement & Analysis 2.1 Gather Inssue/ Concern 2.1.1 Survey Results 2.1.2 Analyze the RT queue 2.1.3 analyze help emails 2.1.4 Presentation 2.1.5 Investigate the other systems 2.2 Focus Group 2.2.1 Selection of focus group 2.2.2 Kick off 2.2.3 Prototype review 2.2.4 Final review 2.3 Determine and document the reuirements 3 Design 3.1 Alternative graphical design 3.2 Prototype 3.3 Finalize functional design 4 Development 4.1 Technical Specification Document 4.2 Development & unit testing 5 Test 5.1 Functional Unit Testing 5.2 Quality check/ verification 5.3 Integration Testing/ UAT 6 Implementation 6.1 Communication to the users 6.2 User training & documentation 6.3 Initiate support & maintenance plan 6.4 System implementation/ Go-live 7 Post Implementation 7.1 Conduct survey of new system 7.1 Update file/ documents 7.3 Close project If there is time …. WBS is an input to the project schedule … recently added a new template for the WBS: A work breakdown structure (WBS) outlines the work that must be accomplished in the project, decomposes the work into smaller pieces of work and becomes the skeleton of the schedule. It must include activity name, activity number and individual accountable. The WBS is completed by the project team. The WBS won’t reflect dependencies… this is done next #watitis2012

Project Schedule WBS, Network diagram Activities; include project management activities Resources Dependencies Milestones (i.e. go/no go decisions) Baseline Who: Business Analyst(s), Project Lead(s), Developers, SMEs, Sponsor, Project Manager We mentioned the WBS; to develop a project schedule, you can also do a network diagram. That’s a good tool for documenting dependencies. The network diagram is out of scope for this presentation. I’ll announce it now: Coming soon to a methodology resource near you! Many different electronic tools for scheduling – Excel, Sharepoint lists, MS Project, etc. Milestones/decision points in a schedule are very important Include meetings and project management activities in your schedule … don’t sell PM activities short! (Oh, and project team is involved in planning & pm activities …) Kick off meeting – no slide #watitis2012

Implementation Plan Payroll moving from Finance to Human Resources Business process change involving IT changes Patch or tax updates Next on the list is the implementation plan. The implementation plan is used to document the transition or cut-over to the new system. It is not a schedule. It contains information about communications and training. Contains info about key messages such as when and who should deploy. Only for large projects with significant roll out training and communication impacts When to use a Implementation Plan? Yes No #watitis2012

Risk Register Rate the likelihood & seriousness Grade the likelihood & seriousness Rating for Likelihood and Seriousness for each risk L Rated as Low E Rated as Extreme (Used for Seriousness only) M Rated as Medium NA Not Assessed H Rated as High   In the project management plan, risk management was mentioned. This is the list of risks being managed and the information about how the risks are being managed. Yes, for larger more complex projects this document is required and risks should be assessed on a regular basis, especially right before a go live. On large, properly managed projects where risk management has been an integral part of planning, the following should occur: There are no longer huge fires to put out every day – they were eliminated with risk response plans Risks are brought up in every meeting to be addressed before they happen If a risk event does occur, there is a plan in place to deal with it, meaning no more hectic meetings to develop a response Some slides showing explaining the risk register … Grade: Combined effect of Likelihood/Seriousness   Seriousness Likelihood low medium high EXTREME N D C A B #watitis2012

Risk Register 3. Recommended actions 4. Changes #watitis2012 Recommended actions for grades of risk based on Likelihood/Seriousness Grade Risk mitigation actions A Mitigation actions, to reduce the likelihood and seriousness, to be identified and implemented as soon as the project commences as a priority. B Mitigation actions, to reduce the likelihood and seriousness, to be identified and appropriate actions implemented during project execution. C Mitigation actions, to reduce the likelihood and seriousness, to be identified and costed for possible action if funds permit. D To be noted – no action is needed unless grading increases over time N To be noted - no action is needed unless grading increases over time. Change to Grade since last assessment NEW New risk  Grading decreased — No change to Grade  Grading increased #watitis2012

Risk Register Risk Register: #watitis2012 <n> Id # Description of Risk (including any identified ‘triggers’) Impact on Project (Identify consequences ) Assessment of Likelihood Seriousness Grade (combined Likelihood and Seriousness)   Change Date of Review Mitigation Actions (Preventative or Contingency) Responsibility for mitigation action(s) Cost Timeline for mitigation action(s) <n> <describe the risk and any relevant triggers that may cause the risk to be realised.> <Describe the nature of the risk and the impact on the project if the risk is not mitigated or managed> <Change in Grade since last review> <Date of last review> <Specify planned mitigation strategies: Preventative (implement immediately) Contingency (implement if/when risk occurs).> <Specify who is responsible for undertaking each mitigation action(s)> <Specify timeframe for mitigation action(s) to be completed by> Risk Register: #watitis2012

Project Execution and Control While from the list of templates, it looks like most of the work is being done is planning, the bulk of the work actually occurs in Project Execution and Control. This is where the work occurs to deliver the product, service or result. Because so much is happening, communication is essential. You see many templates here that we’ve already discussed. The processes within this process group do not result in new document deliverables, but rather delivering the product, service or result. Constant monitoring and updates to previous documents will be required during this time. We have recently posted a template for an issues log. Honourable mentions for the process group documents are: logged issues/requests and changes, risk assessments and responses. It is also strongly recommended that projects have templates for status update meetings that clearly identify status, issues, and action items. The action items should have someone assigned to them. Attendees for each meeting should be listed and the date of the meeting. These minutes should be posted so they are accessible by all attendees and other possible stakeholders as well. A suggested template for a status update meeting is available. Managing Quality Control and Quality Assurance are often a big part of project execution and control. For example, for our ERP systems, we have programming standards, sign off controls and migration procedures to move customizations from development to test to production. Security, accessibility and if applicable, eCommerce principles/procedures would be applied. (E.g, running a security vulnerability scan on a web site, using achecker.ca to validate accessibility, etc.) You’ll see related templates to deliver quality on the Systems Development Life Cycle Methodology side of the web chart. It is strongly recommended that projects have templates for status update meetings that clearly identify status, issues, and action items. The action items should have someone assigned to them. Attendees for each meeting should be listed and the date of the meeting. These minutes should be posted so they are accessible by all attendees and other possible stakeholders as well. A suggested template for a status update meeting is available. Performance reports are more for Sr. Management/Sponsors to track the progress of the project against the plan. If the project is large enough to warrant a Project Management Plan, changes to scope, etc. can be documented in that plan and logged in the Revision History section during the execution of the project. Otherwise, changes to scope, etc. should be clearly documented in meeting minutes, etc. and accessible by Project Team members. #watitis2012

Project Closure A comment about the process group… Do you know of projects that never finish? When is a project complete? Oh, the project is done? Really? What lessons can the project share so we can build on the good and not repeat the bad? Why did the project get cancelled? Project closure is where the project is finished. A PM guru cites that this is one of the most ignored part of the project management process. The project is not complete when the final product scope is done; it is completed when closure is completed. This effort includes administrative activities such as collecting and finalizing all the paperwork needed to complete the project … client sign off; technical work to verify that the final product of the project is acceptable. It will also include any work needed to transfer the completed project to those who will use it and to solicit feedback from the stakeholders about the product and the project. If a project was started and was cancelled, it is very important to close the project. Imagine it starting up again a year or two later with a different team. Project closure is required! #watitis2012

Project Closure Why: confirms that all the requirements in the project have been met closes off any legal requirements (e.g., procurement, support model transitions, signoffs, etc.) creates records for similar future projects transition resources celebrate and communicate success #watitis2012

Project Closure When: Closure/Project Review Who: Project Manager, Business Analyst(s), SME(s), Sponsor, Project Lead(s), Developer What: comparison of objectives in charter/project management plan to final outcome, budget vs. actual costs, schedule vs. actual timeline, lessons learned, outstanding issues/tasks, transition to operations, recommendations for future projects, etc. The lessons learned can be captured in the project closure document, or separately in a lessons learned document. Templates for both are on the methodologies site. #watitis2012

Maintenance Plan Why: transitions development resources to maintenance/support resources closes off any legal requirements #watitis2012

Maintenance Plan When: Project Closure Who: Project Manager, Business Analyst(s), SME(s), Sponsor?, Project Lead(s), Developer(s) What: objectives, scope, infrastructure, roles & responsibilities, development & migration, standards, performance monitoring, issues tracking, system evolution #watitis2012

Satisfaction Assessment Is client satisfaction important for the project? The project delivered exactly what was asked for. Why is the product, service or result not being used? Optional … recommended for highly visible/large stakeholder group projects Can be delivered through surveys, focus group feedback sessions, etc. #watitis2012

Real Tools for Real People Green and Growing or Ripe and Rotting? - Kristin D. Russell , Secretary of Technology & CIO, State of Colorado Connie – I hope these tools are useful. We want these tools to be green and growing, so we need your feedback. If certain sections need to be added or don’t make sense in a template, let us know. Dave K Future areas of expansion/deeper dive for resources: More tools Knowledge areas (quality, risk, cost) Program management Portfolio management ITIL/EA integration Project Server #watitis2012

Real Tools for Real People Questions? IS-PM@lists.uwaterloo.ca http://ist.uwaterloo.ca/is/Methodologies/ Methodology_webChart.html Will be easier to find in WCMS: https://uwaterloo.ca/information-systems-technology/projects/project-resources #watitis2012