Micro-Acquisition Pilot Business Case
Proposal: A pilot to simplify micro-procurement of open source code at ESDC
Sponsoring Branch(es): IITB-SABR & CFOB-Asset Management Policy and Procurement
Contents
- Contents
- Business Need Definition
- Summary of Objectives
- Rough order of magnitude
- Stakeholders
- Consultations/Collaboration
- Benefits
- Benefit 1: Increase the number of IITB teams that work in the open
- Benefit 2: Increased re-use of code (Using open standards and solutions)
- Benefit 3: Improve diversity in GC IT contracting
- Benefit 4: Increase the knowledge of new software/tools by IITB employees
- Benefit 5: Reduced burden on ESDC Contracting Officers
- Measuring Success
- Risks
- Communications
- Annexes
Business Need Definition
Problem
Many advancements have been made to modernize IT Procurement at ESDC, such as Capacity on Demand. However, when it comes to coding, development and working in the open, there are still procurement challenges that exist.
In the GC, procured code is often proprietary licensed and as a result reduces the ability to re-use existing investments.
Startups and freelancers with the latest technology expertise can face barriers in accessing GC contracts. Many small and medium enterprises find that standing offers and supply arrangements can be “ cumbersome to use and difficult to qualify for”. They also seem to “disproportionately favour suppliers located in the National Capital Region”1. In a 2017 survey, 95% of Small and Medium Enterprises (SMEs) did not view the GC as a buyer2. Whereas large companies have teams of people whose sole job is to submit bids for GC contracts, many startups do not. Some of Canada’s top developer talent exists in those SMEs and ESDC is missing out on that developer talent.
As well, although procurement processes at ESDC are becoming streamlined, getting external help for small pieces of ad-hoc development work (say to fix a bug or to build a small prototype) still takes weeks. In the world of open source software, where the code is freely available to anyone to fix and access immediately, and where IT is moving towards a DevOps/agile way of working (where changes to IT systems can, and should, be made daily. See IITB’s Target IT Solution Delivery Model for more), it is necessary to have a procurement process that can move equally as fast.
Additionally, while micro-procurement contracts are low dollar value3 and low risk, they take up a lot of time of procurement officers, whose expertise is needed for complex and high-risk procurements.
Proposal
Put in place a pilot and platform at ESDC for micro-procurement of software. This pilot would be spearheaded by a partnership between IITB and CFOB and would run for one year All work would be unclassified, and the contracts would be for a set amount. The scope for the pilot is limited to ESDC only; only ESDC employees will be able to post opportunities. Details of the Design Elements and the Processes can be found below.
ESDC is a natural fit to run this pilot and will benefit greatly from it because of the strong link with the ESDC mandate to “improve the standard of living and quality of life for all Canadians. We do this by promoting a labour force that is highly skilled. We also promote an efficient and inclusive labour market.“ This initiative, in addition to benefiting ESDC, will also create new opportunities for SMEs throughout Canada.
At ESDC there are 54 OSS products known to be in use and at least 90 web applications at ESDC which contain OSS elements. But this micro-procurement pilot is not only for products already using open source code. Internal and proprietary products could make use of the micro-procurement pilot as well (e.g., for powershell scripts to deploy infrastructure). The procured code would simply be made available to the GC under an open source software licence that allows for code re-use.
If this pilot is deemed to be successful, a formal project could be initiated to scale up to a broader, more permanent service within ESDC (see more on this in section Measuring Success). It is also possible that the micro-procurement of software could be scaled up to the GC level.
Rationale/Background
The connection between Procurement, IT and business transformation is noted in the Canadian Digital Operations Strategic Plan 2018-2022 which says that “If modern technology is an essential enabler for digital government, procurement modernization is an equally essential enabler of modern technology.”, and by Gartner who recently released their Procurement in 2020 and Beyond report. In this report they recommend shifting the ownership for low and mid-tier purchases away from corporate procurement teams so that those teams can focus primarily on strategic, high value, high-risk purchases4.
The GC also has recommended changing the way low dollar value (LDV) procurements are done. The 2020 Red Tape Reduction Report recommended establishing “a fast track process for service contracts under $10,000”. And the Office of the Procurement Ombudsman identified that there is a high risk that the “procurement does not allow for innovation” when using Standing Offers for low dollar value procurement in their Low Dollar Value Contracting report (based on information gathered during an interdepartmental risk assessment workshop).
Private industry has been doing low dollar value purchases of code, including bug bounty initiatives (where developers are encouraged to find bugs in software and are paid to fix them).
The BC government has had a great deal of success with the BCDevExchange ‘Code with Us’ program. This program has since expanded in scope (to contracts up to $70K) and evolved into the Digital Marketplace platform.
The US government has a simplified process for all micro-purchases which, among other things, encourages their Deputy Heads to delegate authority for micro-purchasing. Many groups within the US government have experimented with using this process to purchase open source code including the IT Modernization CoE, the Department of Veterans’ Affairs, and 18F.
In addition to having the precedent of the pilot GC Developers Exchange from 2017 (more in Annex D), the recommendations and guidance from the red tape reduction report and the Office of the Procurement Ombudsman, policy cover exists when it comes to LDV procurement.
The procurement policy team at Treasury Board Secretariat have advised that there is nothing in the current policy instruments that prevents establishing a simplified process for LDV purchases. In the Office of the Procurement Ombudsman’s LDV report, they advised that “The regulatory and policy framework for federal contracting allows federal organizations the flexibility to develop their own frameworks to govern LDV contracting.”
Furthermore, it is government policy to use Acquisition Cards to buy and/or pay for goods and services within the level of procurement authority delegated to the Department whenever it is economical and feasible to do so. Acquisition Cards provide a convenient, less cumbersome way to buy and pay for low dollar value, low risk goods and services. They facilitate and simplify the procurement process for managers and employees, while streamlining the payment process for suppliers and departmental accounting units.
Consequence of Inaction
The consequences of not moving forward with this pilot include:
-
Missed opportunity for ESDC to contribute towards a skilled labour workforce during a time where large number of Canadians have lost their employment
-
Lack of agility to address IT solution fixes and improvements in a timely manner.
-
Lack of access to developer talent
-
Procurement officers are kept busy with low risk LDV procurements
-
Continued dependence on large waterfall IT procurements
-
Missed opportunities for quick wins
Summary of Objectives
This 1-year pilot will gain empirical evidence in order to validate the following hypothesis:
If low dollar value5 procurement of code was simplified for both ESDC teams and suppliers, would we achieve the following objectives:
- Increased participation and access to developers who wouldn’t normally bid on GC IT contracts
- Increased working in the open within ESDC
- Reduced workload burden on ESDC procurement officers by allowing them to focus on more complex procurements
- Increased ESDC capabilities around agile including breaking work up into smaller chunks which drive high software delivery and organizational performance
Policy Alignment
At the GC level, this pilot is aligned with the GC Digital Standards, the Digital Operations Strategic Plan (2018-22), the Minister of Digital Government’s mandate letter and the Digital Nations Charter (Canada is a signatory).
This pilot is also aligned with Beyond2020 which includes ‘Agile’ as an area of focus and includes ‘Embrace uncertainty and learn through experimentation’ as an action item. Details on alignment can be found in the Benefits section.
Within ESDC, this pilot is aligned with ESDC’s Departmental Plan 2019-2020 intent to “continue to pursue innovation and experimentation to learn from the successes and failures that come from testing new and different approaches to policy development, program design, and service delivery”6. There is also alignment with the practices related to procurement in ESDC’s OSS Management Framework.
CFOB review
The design of this pilot and related processes will be done to ensure alignment with Treasury Board’s Directive on Payments and ESDC’s Acquisition Card Policy. CFOB has reviewed contracting policy and acquisition card policy and has found no issues with the proposed approach of the micro-procurement pilot.
There is no requirement to post the opportunities on GETS, therefore, for the purpose of the pilot the opportunities will only be posted to the Micro-Acquisitions website, in addition to possible other locations where the opportunities will be advertised.
For the purposes of the pilot, none of the contract delivery locations will be in Comprehensive Land Claim Agreement (CLCA) areas.
CFOB has reviewed the Policy on Decision Making in Limiting Contractor Liability in Crown Procurement Contracts and given the nature of open source software and the value of the requirements, the risk is determined to be low. Therefore, we will remain silent on the issue of indemnification of the Crown in resulting contract clauses.
IITB review
The Micro-Acquisitions website where opportunities are posted will be thoroughly tested to ensure GC accessibility requirements are met. Any emails sent to suppliers will only include text or files which are accessible.
The Micro-Acquisitions website will be hosted on GitHub Pages and all code received from suppliers will be pulled into either GitHub or GitLab repositories (both of which are approved technical bricks).
All code received from suppliers will be Quality Assurance tested using automated tools (to check for accessibility, security etc.).
Suppliers will not need security clearance as all work was unclassified and virtual.
Rough order of magnitude
Cost of planning and technology delivery
The total estimated cost of planning and technology delivery is $96K*.
Costs for the planning and technology delivery include a non-salary cost of $15 for a domain registration as well as salary costs of approx. $96K from both the CFOB team and the IITB team (using existing FTEs). Details in the following table:
Team | Total employees | Total Estimated level of effort (days) | Estimated cost* | Details |
---|---|---|---|---|
Salary | ||||
CFOB: Procurement specialists | 3 | 31 | $15K | Process design, IP experts, payment experts |
IITB: Technical team | 3 | 158 | $81K | Developers, designers, open source experts, UX, project lead |
Total Salary | 5 | 178 | $96K | |
Non-Salary | ||||
IITB: Technical team | N/A | N/A | $0.015K | Domain name registration |
Total Non-Salary | N/A | N/A | $0.015K | |
TOTAL COSTS FOR PLANNING AND TECHNOLOGY DELIVERY | $96K |
* For salary costs, EBP and non-salary costs related to salary are not included
Cost of operation (1-year pilot)
The total estimated cost of operation for the 1-year pilot is $210K*.
The non-salary costs for the operation of the 1 year pilot include an estimated $50K fund within IITB as seed funding to do micro-procurements as well as to ensure rapid payment of micro-procurements done by teams outside of IITB (eliminating delays related to budget transfers).
The salary costs related to the operations of this pilot will include both technical and functional support. This includes but is not limited to: review of all micro-procurement opportunity text (submitted by those in the GC who want to set up contracts), submitted source code, website monitoring and addressing any bugs. This work would be done by Innovation Information and Technology Branch (IITB) staff.
In addition, there will be auditing, and monitoring work and general procurement support required. This work would be done by Chief Financial Officer Branch staff. Further details on the proposed Roles and Responsibilities can be found in Section 9.0. As such, ESDC SAL requirements for the operation of the micro-procurement pilot are as follows:
Team | Total employees | Level of effort (days) | Estimated cost | Details |
---|---|---|---|---|
Salary | ||||
CFOB: Procurement specialists | 2 | 7 | $3K | Procurement innovation team (auditing and reporting, process refinement, answers to sticky procurement questions from suppliers) |
IITB: Technical team | 4 | 305 | $147K | Developers, open source experts |
Total Salary | $150K | |||
Non-Salary | ||||
IITB: Technical team | N/A | N/A | $50K | Seed funding for procurements as well as to enable cost management (while waiting for budget transfers from other teams) |
Total non-Salary | N/A | N/A | $50K | |
TOTAL COST OF OPERATION (ONE YEAR PILOT) | $200K |
* For salary costs, EBP and non-salary costs related to salary are not included
Further details of the activities and roles and responsibilities can be found in the Stakeholder section.
Potential Source(s) of Funds
IITB-SABR and CFOB will leverage their existing employees to run the pilot.
The $50K will be sourced through the P0 Business Case exercise however, it is not a mandatory expense to ensure the success of the Micro-Procurement pilot.
ROM duration Range
An estimated timeline for the planning and development phase as well as the one year the pilot is operational is as follows:
Q3 2020: Planning and Technology Delivery
Q1 2021: Pilot Launch
Q4 2021: Pilot Complete
Stakeholders
Stakeholders will be involved in both Phase 1: planning and technology delivery as well as Phase 2: pilot operations. The roles and involvement of stakeholders is outlined below.
Legend:
R: Responsible
A: Accountable
C: Consulted
I: Informed
Phase 1: Planning and Technology Delivery
IT Strategy Team | CFOB Procurement | Clients | Suppliers | IITB Procurement Team | OSME (PSPC) | IP CoE (ESDC) | ESDC OSS Framework Team | Legal (PSPC) | |
---|---|---|---|---|---|---|---|---|---|
Finalize and obtain approvals to go forward with the pilot | A/R | A/R | C | I | I | ||||
Produce procurement and payment processes | R | A/C* | C | C | C | ||||
Produce high-level system architecture | A/R | C | C | ||||||
Design (technical components) | A/R | C | C | ||||||
Build (the technical components) | A/R | I | I | ||||||
Testing | A/R | C | C | C? | C | C | I | ||
Complete SA&A and obtain ATO (*only if required) | A/R | I | I | ||||||
Produce procedures for suppliers | A/R | C | C | C | |||||
Produce procedures for clients and ESDC procurement/financial personnel (checklists, FAQ, contract splitting) | A/R | C | C | C | |||||
Produce communication plan | A/R | C | I | C | |||||
Write and get approval on process and contract terms and conditions | I | A/R | C | C** | |||||
Identify and/or add licence terms | A/R | C | C | C | |||||
Communication activities | A/R | C | I | I | I | C | I | ||
Produce audit and reporting process | C | A/R | C |
*For this item, the accounts payable team could also be included.
**Might not need to go for full legal review if standard clauses are used.
Phase 2: Pilot Operations
IT Strategy Team | CFOB Procurement | Clients | Suppliers | Branch Financial Teams | OSME (PSPC) | IP CoE (ESDC) | ESDC OSS Framework Team | Legal (PSPC) | |
---|---|---|---|---|---|---|---|---|---|
Pre-contractual phase | |||||||||
Develop the opportunity text using template (problem to be solved, evaluation criteria, acceptance criteria, start date, contract value) | C | C | A/R | ||||||
PIF created and signed by section 32 Mgr | A/R | ||||||||
Opportunity text and PIF sent to Financial Team (FPS if in IITB) | A/R | ||||||||
Commit funds in SAP | I | A/R | |||||||
Contractual phase | |||||||||
Prepare the translation of the opportunity text | A/R | ||||||||
Post the opportunity on the Micro-procurement platform | R | A | |||||||
Share the opportunity via social media and other channels | R | A/R | I | I | C | ||||
Manage the solicitation process (technical authority to answer technical questions) | R | C | A/R | ||||||
Close the opportunity at the close date | A/R | I | |||||||
Evaluate proposals and document the evaluation | C | I | A/R | I | |||||
Select the winning supplier | C | I | A/R | ||||||
Winning supplier is notified and they agree to the generic terms and conditions | I | A/R | I | ||||||
Post a notification announcing the winning supplier | R/C | A/R | |||||||
Debrief unsuccessful suppliers (as required) | I | I | A/R | I | |||||
Contract Administration Phase | |||||||||
Supplier works in the open on an open repository | A | R | |||||||
Monitor work of contractor (in open) respond to supplier questions and receive contract deliverables | I | A/R | I | ||||||
Report any procurements problems to the contracting officer | I | C | A/R | I | |||||
Resolve any contractual issues (if required) | C | A/R | I | ||||||
Report any issues with supporting tools (website, GitHub etc.) | C | I | A/R | ||||||
Resolve any issues with supporting tools (website) | A/R | I | C | ||||||
Supplier delivers the code (via a pull request on an open repository) | I | I | A/R | ||||||
Assess the delivered code against acceptance criteria | C | A/R | |||||||
Assess the delivered code against automated QA checks (e.g. security) | I | A/R | |||||||
Determine that the goods and services received are in accordance with the contract | C | A/R | |||||||
Pull request is approved and merged | I | A/R | I | ||||||
Post-Contractual Phase | |||||||||
Supplier sends invoice to FPS mailbox | A/R | ||||||||
FPS team sends entrusted email for signature (section 34 approval) | R | A/R | |||||||
Approved invoice is entered in SAP | A/R | ||||||||
Supplier is contacted for payment info and card doc is created in SAP | I | I | A/R | ||||||
Funds are delivered to supplier using credit card (by FPS credit card holders) | I | I | A/R | ||||||
Pilot mid-point and close out | |||||||||
Audit of contracts issued via the micro-procurement pilot | C/I | A/R | C | I | |||||
Mid-point and close-out pilot report (to assess against success criteria and lessons learned) | A/R | C | C | C | C | C | I |
Consultations/Collaboration
This initiative is being co-sponsored by the Innovation Information and Technology Branch (IITB) and the Chief Financial Officer Branch (CFOB) at ESDC. IT modernization depends on procurement modernization. IT can’t work in an agile or DevOps way if procurement processes still follow waterfall. Likewise, procurement can develop agile procurement practices but if IT doesn’t work that way then nothing is gained.
Wide collaboration is a requirement of GC Digital Standards. As such, collaboration on this initiative is already underway between ESDC, PSPC and TBS will continue through design and development. Collaboration has also included discussions with other governments. As part of the design process, collaboration will also include potential suppliers.
Details of these collaborations (in addition to the collaboration between the IT strategy Team and the CFOB Procurement Innovation team) are as follows:
Organization | Branch/Committee | Date of Consultation | Discussion and recommendation |
---|---|---|---|
GC/TBS | Procurement policy team | July 8, 2020 | Procurement team advised there is nothing in the current policy suite prevents establishing micro-procurement for OSS. |
GC/PSPC/OSME | Supplier engagement team | July 15, 2020 | OSME shared data from supplier surveys, offered to review the business case, and ultimately documentation and T&Cs for understandability |
GC/PSPC | Contract simplification team | June 9, 2020 | Supportive. Recommended connecting ADM |
GC/PSPC/OSME | 15 Day Expedited Payment Initiative | June 25, 2020 | Supportive. Discussed whether the 15 day Expedited Payment initiative could be used for this initiative (if not using acquisition cards). |
GC/TBS | Canadian Digital Service | ongoing | CDS were originally looking to take on the GC Developers Exchange but have other priorities. They are supportive of ESDC moving this forward and have offered to support. Collaboration with CDS is ongoing. |
GC/TBS | Talent Cloud team | June 18, 2020 | TC team are supportive of this initiative. If our focus was on HR, there would be alignment and an opportunity to use their platform. Alignment does exist when it comes to facilitating Indigenous peoples’ participation. TC team are currently working on an Indigenous Portal. Agreement to stay connected. |
GC/ESDC | Electronic Procurement System project team | June 3, 2020 | All procurements via the new EPS (when it goes live) will be those from PSPC standing offers and supply arrangements. EPS is therefore out of scope. |
BC government | BC Developers Exchange team | Sept. 23, 2020 | BC advised that their code for the Digital marketplace is open source and encouraged re-use of the code. They mentioned that the Yukon and QC governments are also interested in starting their own Digital marketplaces for code. |
Benefits
Benefit 1: Increase the number of IITB teams that work in the open
Aligns with:
Policy and Directive on Service and Digital (Use open standards and open source software first, All source code must be released under an appropriate open source software license), Digital Standards (Work in the open by default), Directive on Open Government (Maximize the release of open data and open information)
Assumptions:
Suppliers will not have access to GC networks or devices. Suppliers will only have access to work on code that is available on public repositories.
Details of the pilot and lessons learned will be shared openly beyond ESDC’s walls, the system will be developed with open source tools.
Details:
Movement of IT work to the open is happening in the GC (e.g. Justice Canada’s recent posting of their COVID office scheduling app to GitHub), but this move is happening slowly. As part of the pilot, those posting contracts must be willing to work in the open because the suppliers will not have access to GC devices or networks. This could function as a nudge to move more of ESDC’s code into the open.
A core component of this initiative is the micro-procurement interface will be open by design and built using open source tools. By providing teams with a tool based upon open source usage, this initiative would begin shifting culture and processes toward open by design.
Benefit 2: Increased re-use of code (Using open standards and solutions)
Aligns with: GC Digital Standards, DOSP, Digital Nations Charter
Assumptions:
All code purchased via the micro-procurement pilot would be licensed as open source, solutions purchased via this pilot will be documented on the Open Resource Exchange.
Details:
By requiring that all code procured via this pilot be licensed as open source, and by simplifying the procurement process to obtain this code, the use of open source code in ESDC could increase.
Given that this pilot is focused around leveraging industry leading public source code sharing services, the solutions will heavily leverage open standards (rather than closed proprietary systems), and the solutions will be publicly available. In doing so all departments will have access to the code and will be able to re-use it rather than procuring code themselves (saving the GC time and money).
Benefit 3: Improve diversity in GC IT contracting
Aligns with: Digital Nations Charter (open markets)
Assumptions:
Communications and marketing will be done to ensure that new supplier groups are reached and aware of is new procurement platform
Details:
As mentioned above 95% of SMEs surveyed in 2017 do not see the GC as a buyer. Through a simplified and expedited process that reduces the barriers that these organizations (including startups) and freelancers face, and a targeted communications strategy (to diverse businesses such as those that are Black, Woman owned, visible minority, youth and Indigenous led), this pilot is expected to increase access to IT talent that the GC is currently missing out on.
Benefit 4: Increase the knowledge of new software/tools by IITB employees
Aligns with: Digital Standards (deliver better services)
Assumptions: IITB employees will be encouraged to embrace open source solutions
Details:
Strategic procurement of open source code can bring knowledge into IT teams that is not currently there. Suppliers will be contracted to solve problems and when they turn over the open source code, ESDC IT teams will be able to learn from suppliers in almost a train the trainer sort of way. This would enable IITB to build capacity in-house and embed modern tools and practices within IITB teams. Further, contributions to GC open source projects, or open source projects being leveraged by the GC, has the potential to be leveraged as a recruitment tool for IITB.
Benefit 5: Reduced burden on ESDC Contracting Officers
Aligns with: the Acquisition Card Policy
Assumptions:
Simplified process will be possible so that IITB employees can draft requirements with minimal or no involvement by ESDC procurement and facilitate payment via acquisition card
Details:
Traditional contracting methods require the involvement of an ESDC Contracting Officer with Contracting Authority in order to put a contract in place. Developing a simplified process for sourcing open source code with a template approach will allow IITB employees to procure and pay for services without the involvement of ESDC procurement. Given that ESDC contracting officers are already inundated with contracting requests, particularly now due to Covid-19 and the safe re-opening of Service Canada Centres, having IITB employees able to carry out low dollar value, low complexity sourcing on their own will be advantageous to both CFOB procurement and IITB.
Measuring Success
During the pilot, success will be measured and adjustments made. Some success metrics could include: number of opportunities posted, number of proposals received, number of contracts awarded, number of suppliers who apply, percentage of contracts awarded to suppliers who have never worked for the government, percentage of suppliers who are part of ‘diversity’ groups.
Return on Investment calculations could also be included as a measure (e.g. time saved doing a micro-procurement vs. the existing process).
A detailed performance measurement plan will be developed during the planning and design phase of the pilot and the KPIs will be refined at that time (as such they may change from the ones mentioned above).
If deemed to be successful at the end of year 1, the pilot would move from beta/alpha to a full product/service. With proven success, a central agency may be interested in taking this on and this service could be expanded to other departments.
Risks
Risk | Proposed Mitigations |
---|---|
Contract Splitting |
|
Concerns from PIPSC about outsourcing |
|
Lack of use due to teams being unused to working in an agile way and creating small iterative work packages |
|
Code could be submitted that includes malware |
|
Potential for increased risk of favouritism and/or of communication with the suppliers/bidders during the process |
|
Communications
Following approval of the pilot, a detailed communications plan will be developed.
Some initial thinking around communication activities includes the following:
-
Communications activities should ensure that diverse suppliers are aware of the micro-procurement pilot (e.g. Indigenous business organizations, women-led IT businesses, students).
-
Communication activities will be targeted at suppliers as well as clients within ESDC.
-
Communications activities targeted towards suppliers could include:
-
advertising on Buy and Sell (e.g. posting a news item)
-
posting an issue on the old GCDevEx repository
-
creating a twitter feed for ESDC micro-procurement opportunities.
-
-
Communications activities targeted towards ESDC could include:
-
a presentation at the IITB showcase
-
a message in the IITB newsletter
-
a message in the CFOB newsletter
-
Other communications pathways will be added to the communication plan as the project unfolds.
Annexes
Annex A: Proposed Design Elements
Opportunities
-
All opportunities must be $10K or less including tax
-
All opportunities are for open source code (licensed for reuse)
-
All work is unclassified
-
All work is for a set value (no bidding)
Platform
- All code will be saved to an open repository
Reporting
-
Capability must exist to report on all procurements made via the micro-procurement platform
-
Total $ amount awarded; Total contracts completed
-
List of all completed contracts and the $ value of each contract
-
Summary of suppliers who have bid on/won contracts by demographic information: diversity, geographic location/Indigenous territory, bid on GC contracts before?
Suppliers
-
Must be able to search for opportunities based on keywords (e.g. python, R, JavaScript)
-
Must have a checklist to follow when responding to an opportunity
Documentation
-
A copy of all documentation elements automatically saved to a SharePoint site (e.g. opportunity web page converted to .docx)
-
Opportunity text
-
Proof of supplier agreement to the generic process and contract Terms and Conditions
-
GC Team’s responses to the ‘union’ questions (e.g. no internal capacity exists)
-
All suppliers responses to the opportunity
-
Rationale for choosing selected supplier
Annex B: Proposed Process
Contract process
-
The ESDC client (any ESDC employee) writes up the opportunity using a template. Proposed elements that make up the template are in Annex C.
-
The opportunity text is reviewed by the IT Strategy team and CFOB.
-
The IT Strategy team posts the English and French opportunity to the Micro-Acquisitions website
-
Interested suppliers can ask questions about the opportunity and the questions and answers will be posted openly (e.g., on the website). Q&As will be bilingual.
-
Interested suppliers submit their response to the opportunity (via email?) and provide written acceptance of any terms and conditions (e.g., related to Intellectual Property).
-
The ESDC client and IT Strategy Team assesses the proposals against the assessment criteria and selects the winning supplier
-
The client advises the winning supplier and verifies they are still interested
-
If yes, documentation is saved to the SharePoint site and work begins. Selected supplier is asked to provide some demographic information (voluntary and assuming the privacy team agrees)
-
If no, the client selects the supplier who came in second (so long as they meet the evaluation criteria), advises the winning supplier and verifies that they are still interested.
-
-
The winning supplier is posted on the website. Unsuccessful suppliers are provided with a mechanism to learn more about why they were not selected.
Completion of work and acceptance process
-
Supplier works in the open on an open repository of their choosing (such as GitHub)
-
Supplier is in contact with the ESDC client if they have questions while they are working
-
Supplier creates a Pull Request(s) on the open repository for the final code and runs the code through automated tools (e.g. for security, accessibility etc.)
-
Code is assessed by the ESDC client, and the IT Strategy team to ensure it meets the acceptance criteria
-
If Code meets the acceptance criteria and passes all tests, the Pull Request is approved by the client and the code is merged into the open repository.
Payment process
-
Suppliers will be paid via credit card (directly or via PayPal)
-
The FPS team within the Innovation and Information Technology Branch (IITB) will be the team to process all micro-procurement payments for ESDC clients
-
ESDC clients outside of IITB who wish to procure code via the micro-procurement process will transfer funds to IITB via a budget transfer. Approval is being sought for a fund within IITB which could be used to pay suppliers in advance of budget transfers being complete.
Annex C: Draft Opportunity template fields
-
Opportunity title
-
Opportunity teaser (short, punchy description for the website)
-
Opportunity description (what is the problem that needs to be solved – written in plain language)
-
Link to GitHub repository (where the code will be stored)
-
Required skills (keywords such as: JavaScript, Python etc.)
-
Acceptance criteria (What criteria will the code need to meet to be accepted. what would indicate that the code has solved the problem as stated in the opportunity. Note all acceptance criteria must include some standard language around the QA tests that the code would need to pass)
-
$ Value of this contract (this is a fixed price)
-
Evaluation criteria (How the GC team will determine the winning bid. All evaluation criteria should include standard language. Details to be developed.)
-
Opportunity contact information (name/email address)
-
Project name (links to project details. There could be many contracts associated to a single project)
Note: the Office of Small and Medium Enterprise (PSPC) strongly recommends having a checklist for suppliers to use to make sure they have completed all the steps necessary when submitting their proposal. They also recommend having a plain language description available to all suppliers of how the procurement process will unfold.
Annex D: The GC Developers Exchange
The GC Developers Exchange (GCDevEx) was originally launched in 2017 by PCO in partnership with TBS and PSPC. It was a website to facilitate micro-procurement in the GC. All contract opportunities were for open source code and had a value of $10K or less. Suppliers did not need security clearance as all work was unclassified and virtual. One of the main goals of the GC Developers Exchange was to distribute GC contract dollars to those who might not normally get them (e.g., students, small companies, those not in the National Capital Region). The initiative used code forked from the BC Developers Exchange’s Code with Us platform, a similar micro-procurement initiative.
The GCDevEx pilot created many lessons learned including:
-
Departmental procurement teams needs to be engaged early on in the design work
-
A simplified back-end procurement and payment process is required (not just a front-end to connect suppliers with the GC and vice versa)
-
The GC isn’t used to working in an agile iterative way when it comes to IT
-
Suppliers need to be able to respond to opportunities in 2hrs or less for a $10K contract. Any more time than that makes it not worth their while
-
Resources are required to provide support to those posting opportunities as well as to suppliers
-
Multiple contracts need to be run through the pilot in order to have enough data to determine success.
The GCDevEx pilot went offline after one year due to resourcing issues and after being unsuccessful in getting the PCO procurement folks onboard to develop a simplified process.
-
see http://opo-boa.gc.ca/rapports-reports/2017-2018/index-eng.html ↩
-
see https://www150.statcan.gc.ca/n1/daily-quotidien/181116/dq181116c-eng.htm ↩
-
Low Dollar Value is defined within PSPC’s Supply Manual as contracts where the value is $25K or less for goods or $40K or less for services ↩
-
Gartner’s Procurement in 2020 and Beyond report ↩
-
Low dollar value procurements are those that are <$25K for goods or <$40K for services ↩
-
ESDC departmental plan 2019-2020, page 11: https://www.canada.ca/en/employment-social-development/corporate/reports/departmental-plan/2019-2020.html ↩