Certified ProjectS : Initiation Certification Training

1. Certified ProjectS:Initiation Certification Training April 27, 2018

2. Overview Purpose: Practical walk through of project initiation phase and related certification documents to help you get your new projects on the road as cleanly and painlessly as possible Topics: • Initiation Phase • Developing a Project Charter • Developing a Certification Request

3. INITIATION PHASE Overview and Context

4. Introduction to Certified Projects • Authorized by Department of Information Technology Act as part of mandatory oversight responsibilities • Applies to executive branch agency IT projects meeting specified criteria • Required to undergo phased certifications as a result of appropriation or grant; • Subsequent to or interrelated with a previously certified project; • Cost equal to or greater than $100,000; OR • Deemed appropriate for certification by Secretary of DoIT • Applies regardless of funding source • Exceptions and waivers required for: • Combined certifications for two or more phases; • Certification waivers; • Technical Architecture Review waivers; AND • Independent Verification & Validation (IV&V) waivers TIP: Plan to meet requirements unless exception or waiver actually approved

5. Certification Phases & Artifacts • Agencies may also submit certification change request(s) related to: • Schedule • Budget • Scope

6. Initiation Phase • Critical, but often overlooked, project phase • Examples of Initiation Phase products: • Concept of operations • Alternatives analysis/feasibility study • Business case • Acquisition strategy • Market research • Governance structure • Communications strategy/plan • IV&V contract • Project management contract • Project management plan • Planning phase certification artifacts TIP: Well-executed Initiation Phase helps set up project for success by clarifying scope, expectations, realism TIP: Well-thought-out Initiation Phase products make subsequent certification requirements, and project planning and execution requirements, easier to meet

7. Closing thoughts… • Approach certification process as part of planning and executing a well-managed, successful project…not as a separate process or set of artifacts to be used solely to obtain certification • Schedule: • PCC 4th Wednesday of each month (with occasional exceptions) • DRAFT documents due to epmo@state.nm.us NLT COB 2nd Wednesday of month (or 2 weeks before PCC) • DoIT returns comments not later than following Tuesday • Agency FINAL documents due to epmo@state.nm.us NLT noon Thursday before PCC • Documents publicly posted Friday before PCC • Detailed schedule for year posted on DoIT website • For more information, refer to: http://www.doit.state.nm.us/oversight.html

8. Developing a project charter

9. Project Charter Basics Best Practices Common Administrative Errors Leaving DoIT logo on agency project charter (cover page, footer) Leaving template instructions in agency project charter Skipping sections Gratuitous content that doesn’t help focus scope and/or approach for project Copying charter done for another project Using wrong template Numbers don’t add up or are inconsistent between citations • Strive to be thorough, but also be concise • Keep in mind the purpose of a charter – the role it plays in project life cycle • Know your audience • Make content meaningful • Answer the questions!

10. Charter: cover page & table of contents Template Guidance Replace DoIT logo with agency logo or other art CIO is not business owner May add technology owner Original plan date = initiation certification date This is when you have version 1.0 Before that, think of drafts as 0.X Revision date depends on your project progression Ensure page numbers and section names correct Remove DoIT logo from footer Insert project name in header

11. Charter: project background Template Guidance 1.1Executive summary Introduce agency/program mission as it relates to project Briefly state how work supported/performed now Briefly identify issues driving new project Briefly state concept for project – e.g., new system, upgrade; procurement approach, if known; technology approach, if known TIP: Not re-justifying project funding. TIP: Avoid trying to state decisions not yet made or not based on analysis – e.g., regarding technology and architecture

12. Charter: project background (cont’d) Template Guidance 1.2Summary of foundation planning Specifically what work relevant to project planning has been completed? Think about project phases Initiation artifacts Planning artifacts TIP: Not a project history or description of future plans TIP: Identify discrete artifacts and/or tasks completed

13. Charter: project background (cont’d) Template Guidance 1.3Project certification requirements Mission critical: tie to agency mission Cost >$100K: state projected budget Customer impact: state what impact is Deemed appropriate: “Yes” will suffice Architecture review: “Yes”, unless you already have approved waiver TIP: If you do have a TARC waiver, enter approval date in “explanation” block

14. Charter: justification, objectives, impacts Template Guidance 2.1Agency justification Refer to agency strategic plan Mission Strategic goal Performance measure Don’t need a lot of content, but do need clear, accurate, relevant content TIP: Quote official agency plans or measures; don’t write narrative with your own interpretation TIP: Volume doesn’t improve value or relevance

15. Charter: justification, objectives, impacts (cont’d) Template Guidance 2.2Business objectives Should be traceable to: Section 1.1 – rationale for project Section 2.1 – agency justification Focus on targeted outcome, result or impacton business or clients/ citizens Think in terms of “why” Ensure objective is measurable TIP: Simply automating something or replacing a system doesn’t constitute a meaningful objective TIP: A short, strong set of objectives is much better than a long weak list TIP: List key objectives that shape project scope, priorities, approach TIP: Ensure quantified targets are meaningful

16. Charter: justification, objectives, impacts (cont’d) Template Guidance 2.3Technical objectives Should be traceable to: Section 1.1 – rationale for project Section 2.1 – agency justification Section 2.2 – business objectives Focus on targeted outcome, result or impacton business or clients/ citizens Think in terms of “why” Ensure objective is measurable See Business Objectives tips TIP: Don’t mix business and technical objectives TIP: Technology modernization is not an end in itself – must serve business purpose TIP: A project can be completed on time and within budget and still not meet objectives

17. Charter: justification, objectives, impacts (cont’d) Template Guidance 2.4Impact on organization Focus on elements that: Affect project definition, scope, approach Could affect project success End user: Will solution change end user interaction in any way? If so, what is high-level approach/concept for addressing this as part of project? Business processes: Do you need to change business processes to make solution/project successful? If so, what is high-level approach/concept for addressing this as part of project? IT operations and staffing: Will you be operating solution in house (e.g., technology, user support)? If so, do you need additional staff to make this work? Other: Are there other facets of your project/solution, beyond simple project execution, that might affect success? If so, what are they and how do you intend to address as part of project? TIP: You don’t have to describe a detailed solution to an issue or factor; just identify it and how you intend to include addressing it in project planning and execution TIP: Focus on key dimensions that might affect project success or failure

18. Charter: justification, objectives, impacts (cont’d) Template Guidance 2.5Transition to operations Same focus and tips as 2.4 Ops location & staffing: Where will solution operate? Who will staff? Data security & business continuity: Will solution handle sensitive data or have compliance requirements? What is business continuity requirement – how long can this solution be down? Maintenance strategy: Who do you plan will maintain system? Interoperability: Will the solution interface with other systems? If so, which? Record retention: State you will comply with State records requirements Consolidation strategy: Will this solution replace more than one existing solution? If so, which? TIP: Don’t use “the vendor will take care of it” as an answer.

19. Charter: project/product scope of work Template Guidance 3.1.1Project deliverables Table is an example of the project planning and management deliverables that might apply Use bulleted list of deliverables with minimal description (or simple table) Tailor description to your project – e.g., specifying what a contract will include Do not include descriptions of generic or industry-standard deliverables – e.g., project management plan Make list of KEY project deliverables for YOUR project Certification-related Contracts Other management plans TIP: Do NOT leave template table in your project charter TIP: Key deliverables will be used in subsequent sections of charter and of certification request – a good list makes all the difference

20. Charter: project/product scope of work (cont’d) Template Guidance 3.1.2Product deliverables Identify KEY product deliverables for YOUR project Quantity doesn’t improve content – more is not necessarily better Identify discrete deliverables, not tasks or work descriptions Remember to identify final solution Use bulleted list of deliverables with minimal description (or simple table) Think in terms of system development life cycle to identify key deliverables TIP: Do NOT leave the template table, as is, in your project charter TIP: Key deliverables will be used in subsequent sections of charter and of certification request – a good list makes all the difference TIP: Do NOT list every task or deliverable from your planned vendor contract(s) (unless they qualify as key product deliverables)

21. Charter: project/product scope of work (cont’d) Template Guidance 3. 2Success and quality metrics Relate to Section 2 content Agency justification Business objectives Technical objectives Measure outcomes, impacts, results – not simple project completion MUST be measurable TIP: A short list of meaningful metrics is more useful than a long list of gratuitous “metrics”

22. Charter: schedule estimate Template Guidance 4.0Schedule estimate Initial high-level schedule envisioned for project Present all key project and product deliverables (Section 3.1) Present all key milestones Certification gates Contract awards External deadlines Be realistic RFP timelines Contract timelines Federal or other external reviews Time required to perform work, including appropriate testing TIP: Present as a Gantt chart or pipeline chart, not as a table TIP: Ensure that schedule is READABLE within document

23. Charter: budget estimate Template Guidance 5.1Funding sources Information also will be used in certification request For each funding source: Fully identify appropriation and/or grant authorization State the accurate amount appropriated/granted Clearly state any restrictions associated with funding (e.g., use of funds, expiration date) If funding was reauthorized to extend expiration date, clearly indicate this and the associated source information 5.2Budget by major deliverable List project and product deliverables identified in Section 3.1 For each, list associated budget Information also will be used in certification request TIP: Include a TOTAL at the end of each table TIP: Ensure that amounts and totals are correct and that they are consistent throughout Charter and certification request

24. Charter: budget estimate (cont’d) Template Guidance 5.3Budget by project phase or certification phase Present budget by certification phase in a table Initiation Planning Implementation Closeout Ensure that numbers correspond to those in Section 5.2 If you are planning a multi-phase project (e.g., Phase I, II, III), present data in table by phase Phase I Initiation Planning Implementation Closeout Phase X Initiation Planning Implementation Closeout TIP: Include a TOTAL at the end of table TIP: Ensure that amounts and totals are correct and that they are consistent throughout Charter and certification request

25. Charter: project authority & organization Template Guidance 6.1Stakeholders Stakeholder = “an individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project” (PMI) Initial list of all key stakeholders Agency sponsors Executive steering committee members, if applicable Project manager Project team members, if known Users/user groups Contractors Be thorough, but not expected to be exhaustive at this stage Stake in project: brief statement of actual role as stakeholder

26. Charter: project authority & organization (cont’d) Template Guidance 6.2Project governance plan Briefly describe governance structure for project, taking into consideration: Executive sponsor Executive steering committee Advisory committee(s) Project team (PM, sub-teams) IV&V Also graphically depict governance structure and reporting lines TIP: Avoid duplicating roles – e.g., business owner and steering committee member – in separate boxes in graphic TIP: Ensure that IV&V reporting line is independent of project team TIP: Structure project team around actual work to be accomplished, not just as a box or series of boxes reflecting groups within organization TIP: Ensure PM actually has authority to lead project TIP: Avoid defining executive steering committee role as project management

27. Charter: project authority & organization (cont’d) Template Guidance 6.3Project manager Provide project manager name and contact information in table Briefly state project manager background as it relates to type and size of project being undertaken 6.4 Project team roles and responsibilities Correlate to governance structure in Section 6.2 Key individual roles – e.g., PM Team roles Clearly, concisely state role individual or team will play on project TIP: An individual’s name is not a “responsibility” or a “role” TIP: Consider work breakdown structure when defining team structure – tasks by life cycle phase, required skills, responsibilities

28. Charter: project authority & organization (cont’d) Template Guidance 6.5Project management methodology State the project management methodology you will use to plan and manage project, from inception through closeout May be Project Management Institute, Project Management Body of Knowledge standard May be agency-specific processes and tools May be vendor-supplied methodology and tools If desired, and if it directly influences selection of project management methodology, state system development life cycle methodology you anticipate using TIP: SDLC is not the same as project management methodology; waterfall is not a project management methodology, agile development is not a project management methodology – although there are corollary project management approaches for each TIP: Aspire to using consistent project management approaches, tools, methodologies, processes on multiple agency projects instead of treating each project as a unique instance

29. Charter: constraints Template Guidance 7.0 Constraints Constraint = any restriction that defines a project's limitations Identify key constraints that directly affect project Scope Schedule Budget/funding Approach (technology, acquisition) TIP: A short meaningful list is better than a long list of gratuitous factors TIP: Do not confuse assumptions with constraints TIP: List constraints that shape the project definition and/or approach – do not try to document an exhaustive list in the Charter

30. Charter: dependencies Template Guidance 8.0 Dependencies Identify key dependencies that directly affect project progress Certification External reviews Procurements Other projects or agency initiatives Hiring Be thorough and explicit Don’t skip critical elements TIP: Specify the dependency – e.g., contract X must be awarded by X date, before Y can begin

31. Charter: assumptions Template Guidance 9.0 Assumptions Assumption = “events or circumstances that are expected to occur during the project life-cycle” (PMI) Identify key assumptions that directly affect project Scope Schedule Budget/funding Approach (technology, acquisition) TIP: A short meaningful list is better than a long list of gratuitous factors TIP: Do not confuse assumptions with constraints TIP: List assumptions that shape the project definition and/or approach – do not try to document an exhaustive list in the Charter

32. Charter: significant risks and mitigation Template Guidance 10.0 Significant risks and mitigation Risk = “an uncertain event or condition that, if it occurs, has an effect on at least one project objective” (PMI) Identify key risks that significantly affect probability of project success, such as: Ability to meet critical compliance requirements, such as PCI DSS Use of new, high-risk technologies Solution complexity Do NOT list risks that really reflect general project management, such as: Availability of funding, unless there really is a risk that needed funds will not be appropriated or granted Project staff or contractor staff continuity, unless there is a specific condition that would make them unavailable Staying on schedule TIP: A short meaningful list is better than a long list of gratuitous risks TIP: List risks that shape the project definition and/or approach – do not try to document an exhaustive list in the Charter

33. Charter: executive communications plan Template Guidance 11.0 Communications plan for executive reporting Address executive-level governance described in Section 6.2 Executive sponsor Executive steering committee Advisory committee(s) Briefly state WHAT project team will report to executives, HOW they will report, HOW OFTEN they will report, and WHO is responsible TIP: Avoid relying solely on emailing written reports to executives TIP: Tie reporting frequency to project, taking into consideration mission criticality, timeline, risks, complexity TIP: Do not describe all project meetings, communications and/or project reporting here – just executive reporting

34. Charter: IV&V Template Guidance 12.0 IV&V IV&V required by beginning of planning phase Requires IV&V contract Must address planning, implementation and closeout phases Briefly describe planned IV&V approach for YOUR project What are critical elements for IV&V to review during planning? What are critical elements for IV&V to review during implementation? What will IV&V do for closeout? Do NOT simply copy table from template into your Charter TIP: Unless your project already has an approved waiver of the IV&V requirement, state an approach for IV&V TIP: If your project DOES have an approved IV&V waiver, indicate date waiver received DoIT approval TIP: Approach IV&V as independent expertise to help ensure project success – not just as a “box checking” requirement

35. Developing a certification request

36. Initiation Certification • Certification request form on DoIT website: http://www.doit.state.nm.us/oversight.html • Fill in form completely and accurately • Use information captured in Project Charter

37. Certification Request Project Governance Project Abstract Use Project Charter Executive Summary (Section 1.1) If well-written, that will address essential elements Planned start date: If agency has been working on project before certification, indicate real start date If no substantive work performed prior to certification, use planned PCC date Planned end date: use project end date stated in Charter Requested amount this certification: only request funds specifically required for initiation phase work Remaining appropriation not certified: appropriation amount minus amount you request to have certified for initiation TIP: Ensure that content matches Charter TIP: Ensure that amounts are correct – consistent with Charter, consistent with other tables in certification request, correct total • Project name: • Use official project name • Be consistent • Date: planned PCC date • Other agencies: list, if any others involved in project execution • Ensure executive sponsor, CIO/IT lead and project manager names match those in Charter

38. Certification Request Appropriation History Proposed Major Deliverables Use data from Charter Major project and product deliverables (Section 3.1) Budget by deliverable (Section 5.2) Due date (Section 4.0) Project phase (Section 5.3) Initiation Planning Implementation Closeout TIP: Ensure that content matches Charter TIP: Ensure that amounts are correct – consistent with Charter, consistent with other tables in certification request, correct total • Provide complete information for each appropriation and/or grant to be used for project • Information must correspond to information presented in Charter, Section 5.1 TIP: Include a TOTAL at the end of table

39. Certification Request Budget Budget (cont’d) TIP: Ensure that annual subtotals and overall total match other tables and amounts TIP: Ensure that line item subtotals match other tables and amounts TIP: Ensure that timing matches project schedule and major deliverables table Use data from Charter and from Proposed Major Deliverables table in certification request • Staff Internal: Include internal staff costs ONLY if they will be charged to project budget • Consulting Services: Use separate lines for each services contract (e.g., project manager, IV&V, solution implementation) • Hardware: If you will purchase hardware as discrete deliverable or separate from consulting services, include amounts here • Software: If you will purchase software as a discrete deliverable or separate from consulting services, include amounts here

40. Closing thoughts

41. How to Live with Certification • Approach certification as part of executing a well-planned project, not as an unrelated compliance requirement • Every project should have a charter • Every project should have a project management plan • Content required for certification should be readily available if planning work is being performed well • Don’t delay certification – integrate the deadlines and gates with project plan • Certification is generally not the “long pole in the tent” for projects, unless agency delays addressing requirements • Acquisition cycle is more often the effort that drives schedule and/or limits agency ability to move forward • Generally, certifying a project one phase at time is more manageable for agency, as well as complying with DoIT requirements • Myth – you must certify for implementation before you can award a solution contract

42. In Closing… • If you have questions… • Review content on DoIT website; • Speak with DoIT Office of the CIO team member assigned to your agency; and/or • Contact me directly – susan.pentecost@state.nm.us QUESTIONS or DISCUSSION?