The model's $185 US blended project rate and 50% gross-margin target allow $185 × (1 - 0.50) = $92.50 of delivery cost per sold labor hour. Start your project retrospective questions with that distinction between an allowance and actual cost. Then use the completed work to choose a specific improvement for the next job.
I'd keep the meeting short by having its owners prepare the records first. The discussion should decide what changes, not become the first attempt to reconcile the time entries. A completed cutover doesn't establish that the commercial result or the desk handoff is complete.
Prepare the Scope and Cost Comparison
The project owner brings the approved quote and the delivered scope, with accepted changes identified separately. Keep unfinished work visible. A successful go-live can coexist with documentation or remediation still assigned to the project.
Finance reconciles revenue and direct delivery cost on the same basis. Gross margin means revenue less the matching direct cost, divided by revenue. Include the applicable payroll burden and don't substitute the $185 selling price for the cost of an engineer hour.
The $92.50 calculation is an allowance per sold hour, not proof of what delivery consumed. Compare the relevant actual cost with the allowance before declaring the work profitable at the target. If the price or scope changed, keep that changed basis explicit.
Have staff complete the time record for work performed, including effort the business won't bill. MSP Mastery cohost Nick argues for recording actual project time while the business makes the billing decision. His distinction keeps an invoice concession from removing useful delivery evidence.
Ask for an Answer Someone Can Act On
Assign the evidence for each question before inviting the review group. The delivery engineer shouldn't have to reconstruct every commercial decision. Keep the conversation on something its responsible owner can change.
| Retrospective Question | Who Prepares the Answer | Decision to Make |
|---|---|---|
| Did the result match the approved scope? | Project owner, using scope and acceptance records | Assign unfinished work or resolve a remaining disagreement |
| Where did effort differ from the estimate? | Estimator and finance reviewer, using planned and recorded work | Identify the assumption requiring investigation or correction |
| What discovery changed the work? | Delivery engineer, using the discovery record | Decide whether an earlier check belongs in preparation |
| Was changed scope approved before execution? | Project owner, using the client decision record | Repair the approval process without inventing past authorization |
| Can the desk support the delivered service? | Service lead, using a representative support task | Assign missing access, documentation, or instruction |
| What will the next comparable job do differently? | Review leader, using the findings above | Name the action owner and where the change will be used |
An explanation needs evidence. If the notes don't establish why a phase took longer, assign an investigation instead of choosing a convenient cause. A wait for client approval and technical rework call for different corrections.
Skip the transformation language. Record the assumption that failed and the person who will change the working method. The next estimator needs an instruction they can use, not another paragraph about improving collaboration.
Keep Discoveries and Approval Gaps Distinct
Establish what was known when the estimate was prepared. Some work may have required investigation before its full scope could be defined. Check whether that uncertainty was visible to the client and whether later decisions followed the agreed change process.
For a hypothetical migration that reveals remediation during preparation, inspect when the need was raised and what the client accepted. An overrun isn't automatic evidence of poor engineering. It also isn't automatic permission to add a charge.
Mike Psenka recommends identifying new scope and cost during delivery and discussing them with the customer while the work is underway. That is his vendor project-control advice about avoiding a late surprise bill. A retrospective can check for that conversation but can't supply a missing client approval afterward.
Assign the correction to the responsibility it changes. An estimator may need a discovery question, while the project owner may need a clearer approval route. Don't turn both findings into a general allowance added to every future quote.
Check the Desk and the Intended User
Have the service lead attempt a relevant support task using the handoff record. If the desk needs the project engineer's memory to proceed, identify the missing material and assign it. The client shouldn't discover an internal handoff gap when asking for help.
Ray J. Green describes treating a project as done when the intended customer is using a good result, including knowing about and being able to use an internal tool. That is his operating criterion. Use it to ask an adoption question alongside the technical acceptance check.
Keep the agreed commercial boundary visible. An internal review doesn't make additional training or project remediation part of managed support. Route any new commitment through the appropriate scope decision.
Paul Green recommends contacting a client after a project has had time to settle and asking about rough edges. That is practitioner follow-up advice. Choose the timing from the actual work rather than treating the internal meeting as evidence that the client has no further concerns.
Make the Change Available to the Next Project
Choose the most useful improvement the evidence supports and name its destination. An estimating change belongs in the estimating record under its owner. A technical change needs its procedure owner to update and validate the method.
Meeting notes are not a deployment method. Have the reviewer confirm that the next person doing the job can find and use the change. If it needs a larger decision first, assign that decision rather than marking the lesson complete.
When the board opens on Monday morning, which assignment or preparation step will the review have changed? Put that action where the next project owner will encounter it. Check its use on comparable work before assessing whether it helped.
A better result alone doesn't prove the change caused it. Compare the relevant task and conditions with the assumption you meant to improve. Keep remaining uncertainty with the finding instead of claiming success from a higher margin alone.
For the next completed project, have its owner prepare the scope and cost evidence. Assign the people who can answer the questions before scheduling the review. Finish with an owned improvement and every remaining client action still assigned.
mspoutpost.com/articles/project-retrospective-questions-that-improve-the-next-job
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.