Page Comparison

Discovery Phase:

February-March 2024

Research Phase:

March-April 2024

KNOWN

Things we are aware of and understand

• often but not always the same people building teams - procuring and hiring 

• sometimes accessing MAS support

• may be interacting with multiple procurement products, hiring services

• Product is rarely once and done - must be supported/maintained and updated

• the transition from capital to operating funds can impact maintenance/sustainment 

• Some clients they do not have knowledge and capacity to build new Agile teams

• contract renewal point - short term vs long term considerations can be bumpy

• Standing up Agile Teams is costly to business areas

• Not enough support in some areas for modernization, often people take a half approach

• In practice, business areas don't consider the entire life cycle of the product team when bringing in team resources (creates HR/Procurement Debt)

• short term focus (speed, urgency) - can have longer-term tradeoffs

• Procurement is slow and clients want to go as fast as possible (poor planning/lack of resource availability)

• some business areas may have questions about digital roles, sequencing of hires (early hires vs. full team), org design, team formation

• Misalignment right now between our services (no fee) and Procurement Services Branch (fee)

• Current free services also incentivize some behaviours - some not good. 

• Opportunity to build mobile agile teams we can deploy to mitigate and respond quickly to changing requirements

• Given pressure for delivery, people make decisions based on whatever is fastest, easiest, and/or least resource intensive to do. Which might not lead to a good decision. 

Things we are aware of but don't understand (research)

• We don't always have an understanding of budgets for others, this impacts services they can access

• What drives decisions: Budget spending urgency? Actual Solution need?

• How does the cost of a procurement/hiring process drive behaviour?

• Decisions seem to be made based on financial and delivery risk - also avoiding HR risk (easy to defer to contractors)

• People making decisions based on budget available

• People unsure or unaware of how long the product will in play, or if successful to allow permanent staffing

• Short-term resourcing may impact long-term sustainability of products

• People make decisions based on (sometimes unrealistic) timeline commitment for product delivery

• Do classification gaps exist that would favour procurement?

• "complicated" dynamics between contractors + employees

• Many business areas are extremely cost-conscious - may drive behaviour

• I suspect that a lot of Gov teams aren't used to managing a "software production" team and thus prefer to contract as needed for specific deliverable vs hiring digital talent permanently

• Digital talent = production. If a "buyer" doesn't have experience with a backlog approach, it may be hard to envision having full time staff (gotta keep everyone working)

• HMW uncover underlying motivations of folks making decisions

• Risk for union involvement for ongoing work positions not being filled.

• Commitment level of Sr Execs, ADM, DM etc,

• Hiring entire product team without long term work 

• Risk of people not wanting to use recruitment services, as this impacts budget when they can hire using their own resources. This may provoke shoddy practices and impact our image as an employer. 

• Contractors may not have insights into complexities unique to government

• Opportunity to connect to MAS for a more structured and planned approach to modernization and priority initiatives. 

• Budget cuts around April, election year ahead, lots of cost conscious decisions. 

• More flexibility with Procurement than recruitment when it comes to enforcing Agile teams and building products.

• is it intimidating to think about the longer term when this is all so NEW 

• what are the PERCEPTIONS vs REALITIES of sourcing talent?

• PSB don't charge us for their services. If we engage in cost recovery will they do the same?

UNKNOWN

What might people in our ecosystem know, that we don't

• Other SMEs - WLRS, PSFS, AG…

• DIO, MAS, BAT/Scrum Inc.

• DIO/OCG may know more on the amount of IT staff costs

• PSA - Workforce Planning

• IMIT Key Workstream strategy working group - bring evidence to ADM group about problems & opportunities - evidence for creating change

• What are the rules for hiring/creating a new position?

• Leaders who pioneered Digital Modernization/Transformation in BC Gov

• Higher level information about what may be coming down the pipeline that could impact hiring/procurement 

• Their own level of commitment and budget

• alignment with union - they would like to see more talent insourced (better balance)

• Ability to merge qualified lists to centralize and increase consistency for vendors and buying group across government; better corporate  intelligence on needs

Things we are unaware of and don't understand (risk, fear)

• Alternatives to the team-focused approach (is this a blind spot?)

• Do our cients want a more connected service?

• Bias towards certain technologies (e.g. OpenShift) creates procurement risk if those technologies are mandatory. Impacts choices/hiring longer term

• Union impacts for positions that are ongoing for more than 52 weeks/continuous nature

• Level of fear in new areas, often lots of new to agile folks or at the start of their modernization journey.

• If we and MAS both consulting services, how do we define the boundaries?

• Cost of Success - if this takes off, can we scale up to support?

• What is the comfortability of spending vs doing themselves. 

• Identifying which roles should generally be permanent employees, and which roles need not be.

• What is the employee and contractor experience in blended teams. Does that feel good or unequal?

• How can we move ( poach, hehe) contractors into permanent positions within?

Q4 will be a WIN if:

• Identify our "users" for this engagement, develop/identify a feedback/user group across BC gov

• Identify assumptions for connected service and validate with users (gov business areas), users provide us feedback on whether this is valuable or not

• Some sort of artefact to inform user's decisions (hiring vs. procurement) + debunk myths/misunderstanding

• Understand things we are aware but unknown, discover more unknowns to further explore 

• Define cost recovery model, and "cost" structure

In Q4 our work intersects with:

• e.g. any IM/IT strategy milestones we could inform?

• OKR around DO ability to support partners - does this help us rapidly resource for teams and sustain the capacity.

Q4 will be a FAIL if:

• We identify that people would be deterred from using our services if there is a cost implication

• We don't have a clear plan and vision for how Procurement and Hiring can work together (or not)

Important metrics or signals:

• how would we know, decide, prioritize - what's a signal that we're making things better?

• Our users can articulate their decisions (hiring vs. procurement)

• User engagement (IMBs, hiring/procurement managers) with the process

Assists ministries with investment cases, looks for alignment with digital principles and standards.

Hypothesis: Likely Funding is likely to intersect with org design, team formation (DTC).

Goal: alignment (e.g. clients get consistent advice), clear governance/ boundaries, healthy collaboration, efficiencies.

Risk: could too many “advisory services” teams doing similar work create confusion for clients?

DIO Digital Demo: Feb 22, 2024

StatusDiscovery outcomes:

• Discovery chat with Andrea Hill (Director of Digital Advisory Services) and Mackenzie Kitchen (Senior Digital Analyst) on May 14th

• Technically the DIO folk are Analysts, not Advisors

• Success metric = digital projects successfully funded

• They see all the funding cases and what folks are up to, aim to spot red flags with a supportive, light touch and connect folks to DO services (incl. ours)

• Typically folks have their minds made up when they reach the DIO (e.g. no org design advice)

• Working on: Digital Investment Assurance Framework to increase oversight and support post-funding

• Will be conducting Project Health Checks chaired by a DIO Analyst:

  1. progress, delivery, successes, value delivered

  2. money spent

  3. roadmap review

  4. anything project team wants to talk about

  5. rubric tiers: https://intranet.gov.bc.ca/assets/download/B3BDBB3395AC48C1A952D8D6D085DC70

• Governance/contacts: this creates a new point of contact: the responsible ED, program side. Very rarely may be an IT person. The framework sets down roles and responsibilities - MCIO, DIO, Ministry CFO (operational, capital, sustainment), program area ADM/project sponsor

• They have a goal of digitizing their service and making their data more visible, open to partnership and collaboration with us

• Note: 3 analysts supporting 12 ministries - tight capacity

• OPPORTUNITY: earlier intervention points with DO clients “how could we (relevant DO services) show up when there is a transformation-twinkle in the eye?” e.g. support before many decisions are locked in, to set up for success up for success

• OPPORTUNITY: how might DTC leverage DIO insights to predict demand on our services, e.g. number of clients/digital funding cases in play

• REQUEST: as we evolve our service, let DIO folk know so they can direct clients accordingly

Assists select priority partners toward rapid delivery.

Likely to intersect with org design, team formation.

Goal: alignment (e.g. clients get consistent advice), clear governance/ boundaries (do we help the same audiences, different ones, some overlap?), healthy collaboration and support for the hard work, sense of team-across-teams?

Risk: could too many “advisory services” teams doing similar work create confusion for clients?

MAS Digital Demo: Feb 8, 2024

Status (May 7)Discovery outcomes:

• Tess has had prelim async touchpoints with David King (Product Owner), and a lovely 1:1 with Gurkamal Sidhu (Scrum Master) Seeds have been planted - in the future let’s collectively sense if there are opportunities to do a more formal discovery around ways we could collaborate, support each other, and align overlappy elements of our servicesGurkamal Sidhu (Scrum Master)

• Seeds have been planted - ran out of time to conduct meaningful discovery, their strategy was also in flux

• Heather Remacle, Sr. Director, has since published some theory and a framework underpinning their work: Value - Align - Scale - Enable (VASE)

• David King has recently left the Product Owner role

Clients we support:

• SDPR - 25 digital talent hires

• AT Gen & JEDI  - 2  In progress via X Min

• MOH - 2 Hired talents via X Ministry

• CITZ - 34 Hired Talents via X ministry

• NRM ( 5 Ministries)  - 6  - Hired Talents via X ministry

• SPDR - 4 Hired Talents via X ministry

• TRAN - 2  Hired Talents via X ministry

• AEST - 1 Hired Talent via X Ministry

• PSA - Classification modernization - product development support + hire full team soon? 

• Job Profile approval to use. 

• Other IMIT Branches on Org design/Alignment, role development and transformation

• Applicants through outreach opportunities, such as BCIT Career fairs, clinics etc. 

• Candidates - Coaching and advice for applications & career development. 

• Clients looking for a TA initiative - 'Rapid Hire Program'

Clients we can’t support:

• GBAs who want to use the DT job profiles but do not fit into them

• Clients that have needs but timing of when we run our comps (driven by capacity and CI) don't align

• Clients that need more help with Job Description work rather than talent acquisitions. 

• Clients that would like to do it themselves but would like to understand best practices and/or access resources (i.e. can you share learning with me so I don't repeat mistakes)

• Who just need some additional support to expedite, but want to run their own.  - We often now provide advice.

• Clients who don't agree with our Service Agreement policy, i.e. can't commit to process or time commitments. 

• When we don't have resources to support their requests. i.e. Unable to run another competition .

• Clients who require IT roles, (Or general)  that fall outside of DT Roles. 

• With specific requirements for roles, that require a stand alone competition. 

• Who have larger requests. 

Clients we support:

• IMBs

• Ministry Procurement Shops

• Government Business Areas (direct interaction with Product Owners)

• Teams looking for digital talent for Agile projects

• GBA prepared to run a competition within the rules of procurement

• Key Clients: MOTI, CITZ, SDPR

• Other folks we've supported in the past: HLTH, FIN, EDUC

Clients we can’t support:

• Inadequate budget

• Not prepared to commit time to procurement competition

• Not a fit for our DM platforms

• Not building open-source web apps

• Low-value TWU/SWU opportunities (ROI too low - not worth the effort)

• Not ready to work in Agile (i.e., no full-time PO).

• Clients not doing custom dev (more for SWU)

• SWU/TWU both based on Agile Agreements.  That means that teams have to be working in Agile for contracts to work.

• to expedite, but want to run their own.  - We often now provide advice.

• Clients who don't agree with our Service Agreement policy, i.e. can't commit to process or time commitments. 

• When we don't have resources to support their requests. i.e. Unable to run another competition .

• Clients who require IT roles, (Or general)  that fall outside of DT Roles. 

• With specific requirements for roles, that require a stand alone competition. 

• Who have larger requests. 

Clients we support:

• IMBs

• Ministry Procurement Shops

• Government Business Areas (direct interaction with Product Owners)

• Teams looking for digital talent for Agile projects

• GBA prepared to run a competition within the rules of procurement

• Key Clients: MOTI, CITZ, SDPR

• Other folks we've supported in the past: HLTH, FIN, EDUC

Clients we can’t support:

• Inadequate budget

• Not prepared to commit time to procurement competition

• Not a fit for our DM platforms

• Not building open-source web apps

• Low-value TWU/SWU opportunities (ROI too low - not worth the effort)

• Not ready to work in Agile (i.e., no full-time PO).

• Clients not doing custom dev (more for SWU)

• SWU/TWU both based on Agile Agreements.  That means that teams have to be working in Agile for contracts to work.