Effective Requirements Collection for Successful Procurement

Efficiently collecting and articulating requirements is crucial in the procurement process. Clear, measurable, and strategic requirements help ensure successful acquisition planning and project delivery. This involves describing system functionalities, considering unique jurisdictional requirements, and being mindful of associated costs. Engaging skilled business analysts, maintaining clarity in requirements articulation, and aligning with development approaches like Waterfall or Agile are key considerations for a successful procurement strategy.

• Requirements Collection
• Procurement Process
• Clear Articulation
• Strategic Planning
• Cost Considerations

ren_gri Follow

Uploaded on Oct 11, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. IIS Procurement Webinar Series Week 2: Requirements Collection and Statement of Work (SOW) Paul Klintworth, CDC Marcey Propp, PHII Consultant Presenter name/date

2. Recap Week 1 and Q&A 2

3. Acquisition planning: collect requirements Acquisition planning Solicitation Pre-award/Award Develop solicitation document Assemble acquisition team Develop evaluation criteria Conduct market research Publish solicitation/Q&A Develop project budget Document SOW/PWS Collect requirements Evaluate responses Negotiate contract Award contract 3

4. Requirements guidelines Labor and time intensive step, but so vital take the time to articulate what you need! Requirements should be described in a way that are independent of technology and/or applications. Requirements should be clear and concise so that all workgroup participants can understand them. Requirements should be measurable for evaluation (testing) purposes. Recommendation: Requirements can be collected in advance of issuing the solicitation. 4

5. Requirements description Describe the needed functionality of a system. Recommendation: Include people within/outside your organization who understand the need and can think strategically. Consider strategic requirements based on pending legislation, upcoming initiatives, shared services, etc. Provide a description of what the system needs to capture, perform and display but not how. Answer the question of, What must/should the system do in support of task/activity X? 5

6. Requirements collection: considerations Clearly defined requirements particularly those that are unique to your jurisdiction are indispensable to achieving your programmatic goals. Note whether specific requirements are mandatory or optional/ nice to have in the document. A skilled business analyst can be indispensable in facilitating the requirements process. Be careful not to adopt another jurisdiction s requirements without thorough review. Be sure your articulation of requirements matches the style of services you wish to acquire using a Waterfall or Agile development approach. 6

7. Every requirement has a cost How many 9 s? 99.999%: 5 minutes 15 seconds, or less downtime in a year 99.99%: 52 minutes 32 seconds 99.9%: 8 hours 46 minutes 7

8. Requirements collection: getting started Tools* IIS Functional Model IIS Baseline Requirements Traceability Matrix (RTM) IIS Functional Model Assessment IT Services Worksheet (service expectations) Recommendation: Identify requirements relevant to your jurisdiction, above and beyond the IIS Baseline RTM. Questions Do we have our requirements well-defined and documented? Have we reviewed any of our own prior requirements documentation? Have we asked CDC, AIRA or other jurisdictions for samples? Does our intended procurement process have a specific format or template we must use for documenting our requirements? Who would ideally be involved in requirements gathering? In validating the requirements? *Additional tools can be found in the PHII IIS Procurement Toolkit located at: https://phii.org/course/iis-procurement-toolkit/ 8

9. Acquisition planning: document SOW/PWS Acquisition planning Solicitation Pre-award/Award Develop solicitation document Assemble Acquisition Team Develop evaluation criteria Conduct market research Publish Solicitation/Q&A Develop Project Budget Document SOW/PWS Collect Requirements Evaluate responses Negotiate contract Award contract 9

10. Document SOW/PWS: considerations The centerpiece of a solicitation document. Performance Work Statement (PWS), Statement of Work (SOW) or Statement of Objectives (SOO) Documenting your needs as requirements drives what is being solicited Defines the criteria for acceptance Defines your responsibilities and those of your contractor Documenting requirements is your primary responsibility! Requires significant attention, thought and time The key to good documentation is precision and completeness Recommendation: Be as specific and clear as possible in terms of your service expectations. 10

11. Which to use? Statement of Objectives (SOO) Focuses on overall objectives rather than specific requirements Least prescriptive, encouraging maximum flexibility in solution offered Performance Work Statement (PWS) Description of the requirements with greater emphasis on what is to be done rather than how it is to be done Best used when project is well defined but want some flexibility in how requirements are met by a vendor Statement of Work (SOW) Detailed description of what specifically is to be accomplished by the vendor in measurable terms, often stipulating how the work should proceed Because the jurisdiction is more prescriptive in how to do the work, it may also bear more responsibility for any project failures 11

12. Putting it all together: the SOW I. Background and need: provides a high-level overview of the context for the procurement, including information on your IIS program. I. Procurement objectives: brief and concrete statement of what you want achieved, including the desired benefits to your program. I. Scope of Work: describes the services from the perspective of the bidder; that is, what is it you need the bidder to do, both at a fairly high level and in terms of major activities. I. Technical requirements (primarily for software procurements): defines the functional and non- functional (e.g., security, usability, scalability) requirements for the system. 12

13. Putting it all together: the SOW (contd) V. Services to be delivered/contractor performance requirements: specifies the tasks you want the contractor to perform and services to be delivered. V. Hosting requirements: specifies any requirements for hosting the IIS, with vendor or in the cloud. V. Schedule: provides the timeframes within which the services and deliverables are provided. V. Reporting: specifies how and when you want the successful bidder to report both progress on the requirements or deliverables and on expenditures. V. Other special considerations V. Attachments/References/Appendices 13

14. Service Level Agreements (SLAs) Tool IT services worksheet Recommendation: Apply the same principles of precision, clarity and understanding of what s reasonable/affordable and realistic. Considerations A key document that should be required in the solicitation Defines the level of service and terms with your vendor, central IT, and/or program Can impact pricing depending on the level of service and terms required Included as part of the contract at time of award 14

15. Has your jurisdiction documented or planned to document your requirements? What tools are you using/planning to use? 15

16. Upcoming webinars March 7th: Solicitation phase March 14th: Pre-award/Award phase Join our next session on March 7th. Send your questions to iis@phii.org. 16