Table of contents
Research context
This protocol asks how long access provisioning takes for a new offshore developer and where the wait accumulates. The unit is one access request for one engineer and one tool, identified by the request record and the tool name. The study measures approval time, account creation time, first login, and the first successful use of the tool. It does not evaluate the engineer's skill or the quality of the access decision.
Set the scope to one client organization, one engineering lane, and one access catalog. Record the tools, the approvers, the identity provider, and the provisioning method at the start. If the access policy changes during the window, keep the earlier definition for the full sample or analyze the change as a separate period. A new approval step can look like a slower team when it is only a different rule.
Define the population as every access request for engineers who started in the lane during the window. The unit is the request, not the engineer, because one person can need many tools. A request that was cancelled remains in the sample with a cancellation reason. A request that was reopened after a denial is a new unit with a link to the original.
Record the tool category, the risk tier, the approver group, and the request channel. These strata matter because a production database and a documentation site carry different review expectations. Include requests made through chat, because those are often the slowest and the least visible. Test the unit definition on two recent onboarding records before collection begins. Use one category list for every request.
Define the request time as the moment the engineer or the manager submits a complete request, not the moment someone mentions a need. Define approval as the state that satisfies every required approver. Define account creation as the time the identity provider or tool shows the account. Define first successful use as the first recorded action that proves the engineer can perform the intended task.
Do not count an email that asks whether access is needed as a complete request. Do not count an account that exists but has no role as provisioned. A login that reaches an error page is not first successful use. Each definition should include one positive example and one boundary example so a second reviewer classifies the same record the same way. Write those examples in the protocol.
For each request, capture the engineer, tool, category, risk tier, requester, approver, request time, approval time, creation time, and first successful use. Add the number of reminders and the number of times the request was returned for missing information. Record whether the engineer was billed before access worked. Keep the timeline with the onboarding record so another reviewer can rebuild it.
Practical application
Also capture the onboarding start date and the first ticket that depended on the tool. These fields show whether the access delay actually blocked work or only sat open while the engineer did something else. If a ticket was reassigned because access was missing, record the reassignment and the time. A second reviewer should be able to see the work impact from the timeline.
Draw the sample from the access system and the onboarding roster rather than from a list of known delays. Record the export date, the filters, the row count, and the selection rule. Include requests from every tool category and every approver group so the result is not dominated by one easy path. If the roster is ordered by start date, include every engineer in the window. Do not sample only engineers who stayed past ninety days.
Collect timestamps from the systems as they existed on the observation date. If an approval happened in a meeting and was recorded later, use the recorded time and note the gap. Do not reconstruct a missing timestamp from memory. Note the collection date separately from the request date so the reader can see how much of the record has aged. Keep the raw export with the analysis file.
A useful additional measure is the share of requests that were complete on the first submission. A complete request names the tool, the role, the business purpose, and the manager. Record the missing fields and the time spent collecting them. That view separates an approver bottleneck from a requester-preparation problem. Show the missing fields beside the total wait.
Report the number of requests, the median approval time, the median creation time, and the median time to first successful use. Show the counts by tool category, risk tier, and approver group. Present the share of requests that waited more than one business day at any stage. Use the same denominator for every rate and show the number of requests with incomplete records. Show the raw times beside each median.
Inspect the slowest requests and describe which stage dominated without naming the engineer. A wait before approval may point to a missing manager or an unclear policy. A wait after approval may point to an identity provider or a tool owner who must create the role. Compare the result with the risk tier and the request channel. Report cancelled requests separately so their partial timelines do not distort the stages.
A useful additional view is the time from first login to first successful use. An account that can log in but cannot reach the required data is not provisioned for the work. Show the gap and the role or permission that was missing. That view helps the owner fix the access template rather than adding more approvers. Name the permission in the request record.
Operating controls
The review should separate a policy delay from an operational delay. A request that waits for a weekly access committee is a policy choice, while one that waits for a tool owner who forgot is an operational failure. Record the reason for each wait and the person who held the request. That split prevents the team from rewriting the policy when the real gap is a reminder or a backup owner. Keep the wait reason in the record.
The record cannot show whether the approver made a good decision or whether the engineer needed the access immediately. It can show only the request, approval, creation, and use times. A fast approval is not proof of good security, and a slow approval is not proof of neglect. The protocol also cannot capture access granted informally through a shared account, which is a separate control problem.
Access systems can omit requests made in chat, and identity providers can merge accounts in ways that hide a delay. A tool may have been usable before the account record was updated. Record those gaps and their treatment instead of dropping them silently. If the requester and approver are the same person, note the independence limitation and analyze that group separately. Keep the original request version with the sample.
A useful check is whether a new engineer can follow the access guide and predict which requests to make on day one. Ask the last two hires which request they missed and when they discovered it. That answer tests the guide, not the person. Update the onboarding pack with the missing request and the owner. A guide that assumes a manager knows every tool is incomplete.
Give the result to the access owner and the engineering lead and ask them to choose one observable change. The change might be a pre-approved role bundle, a named backup approver, a complete-request template, or a weekly provisioning review. Record the owner, the effective date, and the measure that will show whether the change worked. Avoid changing the approval policy and the tooling at the same time.
Repeat the protocol with the same definitions after the change and compare the same fields. If approval time fell but first successful use did not, the bottleneck may have moved to role assignment. If creation time fell but the engineer still could not work, the role template may be wrong. Close the review when the owner accepts the finding and the next cohort is scheduled.
The final view is the engineer's first-week calendar. Show how many hours were spent waiting, training, or doing work that did not need the missing tool. That context helps the owner see the cost of a slow request beyond the ticket age. Record the calendar view with the timeline. The measure is not how fast a ticket closed, but how soon the engineer could do the job.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.
Related research
What share of offshore pull requests need a second review round?