JJSSWW

Updated September 2026: in September 2019 I came back from vacation hoping a teammate would now lead a difficult opportunity, only to learn he had sent the first version and handed it back to me. The remaining work turned out to be a couple of slides. I have rewritten it into advice on picking up a half-finished deck from a colleague.

From my emails, I saw a teammate had been assigned to the opportunity while I was away, and I hoped he would front it from now on. When I asked, he said he had only been brought in to send the initial version; the rest was mine. For a moment I was furious. Then I asked about the status and pending actions, and found only a couple of slides remained, some of which I already had material for.

What should you ask when you pick up someone's work?

• What version was sent, to whom, and what feedback came back.
• What is still pending, with owners and dates.
• Any commitments made to the client or onsite team in your absence.
• Where the latest files are.

Ten minutes with these questions, before reacting to the news, usually shows the job is smaller than it first feels, as it did for me.

How do you handle disappointment about getting the work back?

Acknowledge it privately and move on quickly. Your colleague probably had no say either. The fastest way out of a difficult opportunity is to finish it well, not to resist taking it back.

How do you avoid duplicating what was done?

Start from the version that was sent, not your pre-leave draft. Changes made in your absence may not be obvious. Compare the two versions if needed, and confirm with the onsite team that the sent version is the current baseline.

How do you finish quickly?

Reuse related slides you already have, confirm the remaining changes in one short call, and set a closure date. Tell everyone involved that you are back and own the work, so requests come to you rather than to the colleague who covered.

Should you ask for the opportunity to move to someone else?

Only if the remaining work is large and you have other commitments. For a couple of slides, finishing it yourself is quicker and earns goodwill. Save the request to move for work that genuinely does not fit your allocation.

Keep reading

• Returning From Leave While Working From Home
• Delivering the Out-of-the-Box Slides Onsite Wants
• An Out-of-Office Message That Protects Your Leave

Updated September 2026: in July 2019, after I explained to my manager why some review comments did not fit the storyline, he revealed the real reason behind his escalation: the offshore lead had called him privately to say I had ignored his comments. I have rewritten it into advice on handling complaints that reach you through your manager.

I gave my manager my reasons: some comments depended on the onsite team, and some slides did not fit the storyline the onsite team had set. At first he insisted all comments be addressed that day. When he accepted the comments were irrelevant, he explained why he had escalated. After the call, the offshore delivery lead had phoned him directly and said I had not addressed any of his comments or found the slides he needed.

Why do people complain through your manager?

Sometimes to avoid a direct conflict, sometimes to put pressure on, and sometimes because they believe the manager is the right channel. Whatever the reason, it means your side has not been heard yet, and the complaint arrives without context.

How should you respond to your manager?

Calmly and with specifics, as I did: which comments were addressed, which depended on others, which conflicted with the agreed storyline. Ask your manager what exactly was said, so you respond to the actual complaint rather than a summary of it.

Should you confront the person who complained?

Talk to them, but do not confront. A short conversation, "I understand you had concerns about the comments; can we go through them together?", often resolves more than an exchange through managers. It also signals that you would prefer issues raised directly next time.

How do you prevent it happening again?

• Keep a comment tracker and share it after every review.
• Confirm in writing which comments were deferred and why.
• Ask reviewers to raise disagreements with you first, before escalating.

What should your manager do?

Ideally, hear your side before escalating. If that did not happen, it is reasonable to ask, calmly, that in future they check with you first. Most managers agree once they have seen how much context the original complaint left out.

Keep reading

• Returning From Leave While Working From Home
• Calibrating Your Manager's Estimates for New Work
• Quality-Checking an RFP Response at Short Notice

Updated September 2026: this 2019 post described starting an opportunity with a delivery contact I had not worked with before, beginning with the questionnaire to send to the client, which he reviewed and added to. I have rewritten it into a guide to writing a good client questionnaire at the start of a proposal.

The first step on every opportunity was a questionnaire to the client, and I had a ready-made set. I shared the first draft with the new delivery contact, who was happy with it and added a couple of questions. He was calm, in control and supportive when needed, which made the start easy.

Why does the questionnaire matter so much?

Because the answers set the scope, assumptions and price of everything that follows. Questions not asked become assumptions, and assumptions become disputes later. A good questionnaire is the cheapest risk reduction in the whole proposal.

What should a client questionnaire cover?

• Scope: processes, locations, users and systems in scope, and what is explicitly out.
• Current state: existing systems, versions, integrations and known pain points.
• Volumes: transactions, records, users and growth expectations.
• Constraints: timelines, budgets, compliance and technology preferences.
• Decision process: who evaluates, the criteria and the dates.

How do you keep it manageable for the client?

Prioritise. Clients answer twenty sharp questions far better than eighty generic ones. Group questions by topic, number them, and explain briefly why the less obvious ones matter. Remove anything already answered in the RFP.

How should you use a standard questionnaire?

As a starting point. Tailor it to the client's industry and the RFP, and let the delivery team add questions from their experience, as my new colleague did. A reused questionnaire that has not been tailored tells the client you did not read their document.

When should the questionnaire go out?

As early as the RFP rules allow. Many RFPs set a deadline for clarification questions, sometimes within the first week. Missing it means working on assumptions for the whole response, so put the question deadline in the plan on day one.

What if answers do not come back in time?

Document the assumptions you will make for each unanswered question and include them in the proposal. It protects both sides and often prompts the client to answer the questions that matter.

Keep reading

• Quality-Checking an RFP Response at Short Notice
• Delivering the Out-of-the-Box Slides Onsite Wants
• Picking Up a Half-Finished Deck From a Colleague

Updated September 2026: in 2019, drained after a tight-deadline proposal, I was asked at the end of the day to "QA" a short-turnaround RFP response with minimal scope, then heard nothing until I chased my manager at lunch the next day. I have rewritten it into a checklist for quality-checking an RFP response at short notice.

My manager had let me rest after a draining deadline. Then, as everyone was leaving, he asked me to look at a short-turnaround RFP with "minimal scope to QA". I agreed and left. The next morning brought no email or details, and only when I reminded him at lunch did the work start moving. Short-notice QA requests often arrive like that: vague, late and urgent.

What does QA of an RFP response involve?

Checking that the response answers every question the client asked, is consistent throughout, and contains no errors that could cost the deal. It is not rewriting the solution. Agree that boundary at the start, or "QA" quietly becomes co-authoring.

What should you ask before starting?

• The RFP document itself and the submission deadline.
• Who owns the response and who can approve changes.
• Whether you are checking content, format, compliance or all three.
• When your comments are due back.

What should a QA checklist cover?

• Compliance: every RFP question answered, in the required order and format, within page or word limits.
• Consistency: the same numbers, names, timelines and team sizes across all sections.
• Client details: the correct client name everywhere, with no leftovers from a previous proposal.
• Commercials: figures matching between the pricing sheet and the narrative.
• Presentation: headings, numbering, fonts and table formatting.

How do you give QA feedback efficiently?

Group comments by severity: must fix, should fix and optional. Use comments in the document rather than long emails, and give a one-line summary at the top. The response owner should be able to decide in minutes what to act on.

What if the details do not arrive?

Chase early, as I eventually did. With a short turnaround, half a day lost waiting is a large share of the time available. A quick morning message, "Ready to start the QA; please share the RFP and draft", avoids the lunchtime surprise.

Keep reading

• Writing a Client Questionnaire at the Start of an RFP
• Returning From Leave While Working From Home
• Copied In to Assist, Now Treated as the Owner?