1. Capacity building
Read this regardless of your procurement approach.
Goals
- To align various departments and facilitate future collaboration.
- To share basic knowledge of software procurement and development processes.
- To prioritize a new role: the product owner.
Actions
Reaching out to individuals and departments
Several individuals, departments and agencies need to build new skills and adapt their day to day role in order to effectively support software procurement: digital or IT; any number of direct service delivery departments (e.g. traffic and parking); procurement, budgeting or accounting; legal.
- Reach out to individuals in these different teams and begin discussing how they could contribute to future software procurement processes.
Building basic familiarity with software and software procurement
Everyone involved needs to be able to: asking the right questions, identify the right outcomes, and have a basic knowledge of the fundamental principles of modern software design.
- Read through this guide, as well as the additional resources in sections that you are responsible for. If you are the project manager, you should be an expert in the process, and answer questions for others.
- Look at past (software) procurement processes. How have they gone wrong? How have they been successful? Don’t speculate – actually ask users who use that product or who were involved with procuring it.
Training and designating product owners
The most important figure in an effective software procurement is the product owner (a.k.a. “project manager” or “business analyst”). This person shepherds the procurement process. They will be working across and independently from existing business units. They embed with a department (end users) and bring back specific requirements. They have analytical and design thinking skills.
- Hire or train one or more product owners.
Hosting workshops and finding champions
Capacity building should happen long before any given procurement starts.
- Host regular, city-wide workshops about the basics of procurement. Demystify the process. Emphasize the opportunities for acquiring better products and services, simplicity, efficiency, and creativity.
- Designate a procurement innovation lead (this could be a product owner) who can check in with department heads or business unit leaders and provide targeted assistance.
Common challenges
Departmental silos
Software procurement falls between existing business unit siloes (for example legal, IT, service delivery, budgeting and procurement). Who owns a process? Transitioning to cross-departmental protocols and standards requires process change management that is independent of the implicated departments.
Inadequate or obsolete job descriptions
There is no formal role or job description for a “product owner” – particularly one focused on software – in the public sector.
Insufficient time
Staff who could learn from and contribute to ongoing conversations about procurement process reform do not have the time to attend workshops and contribute, in addition to their daily job requirements.
Divergent or conflicting departmental agendas
These cause misalignment in priorities and friction before and during the software procurement and development process
Checklist
- Regular multi-departmental workshops and supporting materials
- Well-trained product owners
- Basic familiarity with software development methods across the organization
References
18F: Derisking Guide
https://derisking-guide.18f.gov/state-field-guide/
18F: A Day in the Life of an 18F Product Owner
https://18f.gsa.gov/2017/09/18/a-day-in-the-life-of-an-18f-product-owner/
Teaching Public Service in the Digital Age: The Digital Era Competencies