Case Scenarios for Retainer Work

Support (Minor Features and Bug Fixes)

Range varies from changes to content, header and footer elements, navigation changes, to slightly larger changes, such as new architectural changes, front-end layouts, or troubleshooting existing functionality.

1. Client submits request
2. PM reviews ticketing guidelines
3. PM approaches developer for estimate
4. Developer must factor in any onboarding time (local development environment, cloning files and code, setting up, reading build documentation, etc.)
5. Client reviews and approves estimate
6. Developer performs task, barring contingencies:
7. Developer will notify PM of any obstacles or issues that arise during development, offer options
8. PM will reassess and ask for new estimate, may need to submit to client for further approval
9. Process loops back to Step 5, Developer performs task
10. Developer reviews ticket response QC
11. PM reviews work
12. PM submits work for client review
13. Client approves push to production

Support (Major Features)

E.g. “I want a new page layout or add a different index of content types” instagram API breaking changes, starts at 5h tasking and up.

1. Cause for work arrives (client wants a new feature, page layout, architectural change/enhancement).
2. PM reviews ticketing guidelines.
3. PM approaches developer for estimate.
4. If a designer needs to be involved, this sub-routine can be modified ad hoc to reflect their participation
5. Developer must factor in any onboarding time (local development environment, cloning files and code, setting up, reading build documentation, etc.
6. Developer should ask for a second opinion with teammate or director for possible courses of action
7. Enough time should be allotted and billed for this process and counted against the retainer.
8. Client reviews and approves the estimate, or requests a different approach, and requests new estimate.
9. Developer performs task.
10. Developer reviews ticket response QC.
11. PM reviews work.
12. PM submits work for client review.
13. Client approves push to production.

Retainer Work: End-of-Life Updates

E.g. a web service we use stops working, with or without warning.

1. Developer reviews changes to web service.
2. PMs are notified of changes.
3. PMs notify affected client(s).
4. Developer submits estimate.
5. Client reviews estimate, makes decision.
6. PM determines whether this goes to retainer or a new PO.
7. PM assigned task to developer best suited for the task.
8. Developer performs task.
9. Client approves push to production.