IT Project Scoping 2.0

Transcription

1 The NYS Forum IT Procurement Workgroup Presents: IT Project Scoping 2.0 November 15, :00-3:30 pm (12:30 pm Check-In) Dell NYC Office 2 Penn Plaza, 18th floor, NY, New York IT Procurement Workgroup

2 1:00 PM Welcome and kickoff, overview IT Project Scoping 2.0 Agenda 1:15 PM Project Scoping Best Practices Richard Green, Director of Service Delivery at New York State Technology Enterprise Corporation (NYSTEC) 1:45 PM NYS ITS Project Scoping from an IT Procurement Perspective Joel Lombardi, Director, Procurement and Contract Support 2:00 PM NYC DoITT Project Scoping - The New York City Template Rachel Laiserin, Associate Commissioner, Procurement & Vendor Management and Guy Oliveri, Director of IT Procurement Administration 2:15 PM Recharge Break 2:30 PM Panel Discussion and Q&A with the audience Joel Lombardi, Rachel Laiserin, Guy Oliveri, Richard Green, Meg Collins 3:30 PM Session end IT Procurement Workgroup

3 The NYS Forum, Inc. Project Scoping Best Practices Richard Green Director of Service Delivery New York State Technology Enterprise Corporation - NYSTEC IT Procurement Workgroup

4

5 Presentation Content Presentation objectives Definitions Challenges Consequences Overcoming challenges IT Procurement Workgroup

6 Presentation Objectives Demystify the term scope Understand the relationship between scope and requirements Appreciate the challenges of defining scope Understand the possible consequences of failing to define scope adequately Absorb some ideas for overcoming the challenges of define scope (the Best Practices part ) IT Procurement Workgroup

7 Definitions IT Procurement Workgroup

8 Scope Dictionary Definition Scope: the extent of the area or subject matter that something deals with or to which it is relevant. Extent (1): The area covered by something. Synonyms: area, size, expanse, length, stretch, range, scope, compass Extent (2): The size or scale of something. Synonyms: size, dimensions, magnitude, measurements Presenting Workgroup IT Procurement Workgroup

9 Scope PMI Definition Scope refers to the detailed set of deliverables or features of a project. These deliverables are derived from a project s requirements. PMBOK defines Project Scope as the The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions. Presenting Workgroup IT Procurement Workgroup

10 Scope & Requirements Scope Work that needs to be accomplished Deliverables Requirements Presenting Workgroup IT Procurement Workgroup

11 Scope & RFP Requirements Deliverables Project Scope Technical Solution/Product Scope What we want the system/solution to do (and how we want it to do it) Business Requirements Business Rules Functional Requirements Non Functional Requirements Work that needs to be accomplished What we want them to do once under contract Contractor Requirements Presenting Workgroup IT Procurement Workgroup

12 Scope & Project Results Deliverables Project Scope Technical Solution/Product Scope Working Software Work that needs to be accomplished - Training - Data Conversion - Knowledge Transfer - Implementation in the Production Environment!! Presenting Workgroup IT Procurement Workgroup

13 Challenges IT Procurement Workgroup

14

15 How long is a piece of string? Used as a response to a question such as "How long will it take?" or "How big is it?" when the length or size is unknown, infinite, or variable. (colloquial, often humorous)

16 Boiling the Ocean To attempt something that is way too ambitious, effectively impossible. An idea too broad in scope to accomplish. (Urban Dictionary)

17 Scope: Build something to get from Point A to Point B Point B Point A Presenting Workgroup IT Procurement Workgroup

18 What the vendor thought we wanted Presenting Workgroup IT Procurement Workgroup

19 What the budget allowed for Presenting Workgroup IT Procurement Workgroup

20 What the timeline allowed for Presenting Workgroup IT Procurement Workgroup

21 What the users wanted Presenting Workgroup IT Procurement Workgroup

22 Consequences IT Procurement Workgroup

23

24

25 Presenting Workgroup IT Procurement Workgroup

26 Examples from personal experience Agency 1 Multiple requirements efforts over many years No high-level definition of scope/objectives Still no solution Agency 2 Decision to exclude requirements matrix in favor of narrative description Contract awarded but termination of project mutually agreed Agency now attempting to develop solution in-house Agency 3 Failure to adequately define security requirements Contract awarded but vendor failed to meet security standards = contract terminated Re-bid required = pain, delays, waste of money Presenting Workgroup IT Procurement Workgroup

27 Overcoming the Challenges IT Procurement Workgroup

28 Boundaries Presenting Workgroup IT Procurement Workgroup

29 The #1 Dilemma Too much detail vs. Not enough detail Presenting Workgroup IT Procurement Workgroup

30 Not all details are created equal Certain details can have a disproportionate impact Example: where will the project staff work? Presenting Workgroup IT Procurement Workgroup

31 Scope Management Agile vs. Traditional Agile principles that relate the most to scope management: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Simplicity the art of maximizing the amount of work not done is essential. Presenting Workgroup IT Procurement Workgroup

32 Scope Management - Traditional Identify and document complete scope at the beginning when least informed. Scope Management - Agile Requirements gathered throughout the project as knowledge of customer needs & project realities grows.

33 Scope Management - Traditional Identify and document complete scope at the beginning when least informed. Change after the requirements phase viewed as negative. Scope Management - Agile Requirements gathered throughout the project as knowledge of customer needs & project realities grows. Change viewed as positive. Changes late in the project are often the most valuable changes.

34 Scope Management - Traditional Identify and document complete scope at the beginning when least informed. Change after the requirements phase viewed as negative. Scope Management - Agile Requirements gathered throughout the project as knowledge of customer needs & project realities grows. Change viewed as positive. Changes late in the project are often the most valuable changes. Rigid control and discouragement of changes after sign off on requirements. Change management inherent. Opportunity to include new requirements with every sprint. Product owner determines the value and priority of new requirements.

35 Scope Management - Traditional The cost of change increases over time, ability to make changes decreases. Scope Management - Agile Fix resources and schedule initially. High priority features push out the lowestpriority features. Iterative development allows for changes with each new sprint.

36 Scope Management - Traditional The cost of change increases over time, ability to make changes decreases. Scope Management - Agile Fix resources and schedule initially. High priority features push out the lowestpriority features. Iterative development allows for changes with each new sprint. Scope bloat (unnecessary features) included out of fear of mid-project change. Scope determined by considering which features directly support vision & goals. Most valuable features created first to guarantee their inclusion. Less valuable features might never be created.

37 Characteristics of Agile that Generate Success Effectively breaks a big project down into small chunks Realistic about not knowing exactly what you re going to need ahead of time Better accommodates changing requirements (typical RFP cycle = at least 12 months) Change viewed as positive Presenting Workgroup IT Procurement Workgroup

38 Written Communication vs. Interactive Verbal Communication Written Communication: Possibility of miscommunication No instantaneous feedback (Handwriting: 5-20 wpm, Average professional typist: wpm) Interactive Verbal Communication: Greater exchange of information Instantaneous feedback (Audiobooks are recommended to be words per minute) Presenting Workgroup IT Procurement Workgroup

39 Opportunities for Clarifying Scope Within Existing Procurement Processes RFI Vendor roundtable and/or vendor demos Bidder conference Q&A process Amendment process Clarifying scope once under contract: Discussion, natural back and forth Negotiation Change orders Amendments Presenting Workgroup IT Procurement Workgroup

40 Conclusions IT Procurement Workgroup

41 Your proposal is innovative. Unfortunately we won t be able to use it because we ve never done something like this before.

42

43 Presenter Richard Green Ph IT Procurement Workgroup

44 Project Scoping NYS Forum/NYC IT Procurement Work Group November 16, 2018

45 November 16, Case Studies Scope Responsibility Acceptance

46 November 16, Scope Overcoming Vagueness A problem of contradictions: Comparing across vendors Controlling costs Room for Creativity Vs. Certainty and Predictability Case Study vague scope results in wildly disproportionate vendor responses

47 November 16, Responsibility Overcoming Vagueness Failure to prescribe exact roles may lead to finger pointing and project delays Trying to prepare for the unknown at the start of a project Death by Gantt chart Delays do not help Case Study Failure to properly prescribe responsibility can lead to project failure and millions of dollars in losses for both parties

48 November 16, Acceptance Overcoming Vagueness Failure to prescribe a realistic acceptance criteria in detail may lead to disputes Circumvention of prescribed process will not help payment State (lack of) responsiveness and delay as a cost driver Skipping through project timelines as a cautionary tale Case Study Failure to properly communicate acceptance or rejection, and prescribe an appropriate mechanism for such, may lead to contract cancellation or de-scoping.

49

50 Project Scoping NYS Forum/NYC IT Procurement Work Group November 15, 2018 Department of Information Technology & Telecommunications (DoITT) 50

51 Successful project scoping requires Clearly identified Business Owner Time commitment from subject matter experts Advance planning Procurement timelines need to be considered in the early stages of project development Market research Understand what the market offers and what similar organizations are doing Good project governance Organization wide project intake and governance process with required documentation (e.g. Project Charter) leads to scope development 51

52 Project Charter - leads to good project scope Background Business need Project goals & objectives Project description Elevator statements High level scope Out of scope Tradeoffs Resources/Schedule/Scope/Quality Stakeholder identification Project team roles and responsibilities 52

53 Building Project Scope Project Charter Funding Request Solicitation Scope Contract Statement of Work Detailed Requirements 53

54 Citywide Contracts AGENCY SUBMITS AGENCY SUBMITS REQUEST DOCUMENT(S) TO DOITT OVERSIGHT APPROVAL SERVICE REQUEST TO DOITT OVERSIGHT APPROVAL DOITT SENDS AGENCY REQUEST TO CONTRACTORS DOITT/AGENCY HOLD CONTRACTOR Q&A CONTRACT REQUEST DOCUMENT BUSINESS NEEDS DOCUMENT REQUEST FOR SERVICES WRITTEN ANSWERS TO CONTRACTORS CONTRACTOR PREPARES TASK ORDER CONTRACTOR ASSIGNMENT NOTIFICATION FINAL EVALUATION COMMITTEE SELECTION EVALUATION COMMITTEE SELECTION / PRESENTATION CONTRACTORS SUBMIT PROPOSALS TASK ORDER CONTRACTOR PROPOSALS TASK ORDER REVIEW/ NEGOTIATION OVERSIGHT APPROVAL TRANSMITTAL AND T.O. TO COMPTROLLER TASK ORDER FILING CONTRACTOR BEGINS WORK USER AGENCY FMS ENTRY

55 How DoITT Helps City Agencies Guiding Preliminary Documents are Required Contract Request Document (CRD) Business Need Document (BND) Template Request for Services (RFS) DoITT RFS Reviews 55

56 Guiding Preliminary Documents - CRD Objectives what problem are you solving? List of Critical Business Requirements List of Major Tasks, Milestones, Deliverables Schedule Project Team and Needed Resources Budget/Funding Market Research

57 Guiding Preliminary Documents - BND Alignment with Citywide Goals Key Management Information (compliance with policies, strategic plans, etc.) Benefits to the City Description of Solution and Evaluation of Rejected Alternatives Dependencies Development Methodology Enterprise Architecture, Disaster Recovery, etc.

58 Template Request for Services (RFS) Scope/Objectives Business Justification Business Requirements Technical Requirements Project Timeline Project Organization Services Required of Contractor Selection Process and Timeline Proposal Template

59 DoITT RFS Reviews Technical Review Enterprise Architecture IT Security Project Management Infrastructure Legal Review Procurement Review OMB Review

60 1:00 PM Welcome and kickoff, overview IT Project Scoping 2.0 Agenda 1:15 PM Project Scoping Best Practices Richard Green, Director of Service Delivery at New York State Technology Enterprise Corporation (NYSTEC) 1:45 PM NYS ITS Project Scoping from an IT Procurement Perspective Joel Lombardi, Director, Procurement and Contract Support 2:00 PM NYC DoITT Project Scoping - The New York City Template Rachel Laiserin, Associate Commissioner, Procurement & Vendor Management and Guy Oliveri, Director of IT Procurement Administration 2:15 PM Recharge Break 2:30 PM Panel Discussion and Q&A with the audience Joel Lombardi, Rachel Laiserin, Guy Oliveri, Richard Green, Meg Collins 3:30 PM Session end IT Procurement Workgroup

61 Panel Discussion Richard Green, Director of Service Delivery, NYSTEC Joel Lombardi, Director, Procurement and Contract Support, NYS ITS Rachel Laiserin, Associate Commissioner, Procurement & Vendor Management, NYC DoITT Guy Oliveri, Director of IT Procurement Administration, NYC DoITT Meg Collins, Senior Managing Partner, Gartner Consulting IT Procurement Workgroup