Top Tips to Improve Project Delivery in a Remote World

‘Bees’ – World leaders in collective decision-making

It’s (almost) never a technology problem. It’s a communication problem!

As Technology consultants, we see many different ways of working, use a huge range of tools and meet all the Myers Briggs personality types.

Regardless of the project’s complexity, from a simple Risk dashboard to a complex low-latency Trading platform, I found that the reason for most delays is never about the technology itself but the poor communication between the people involved.

Since remote or hybrid working is the new normal, it’s never been more important to focus on great communication.

From my observations of what works from in-person to fully remote, here are the top 5 tips to improve project delivery with “minimum” effort:

Tip 1 – Create an ‘outstanding’ onboarding Wiki

Me:Can someone help me set up my Dev environment please?”

Everybody: 🙉

Back in the day, the answer would have been “RTFM Seb”, and that was it.

If you have never heard of the term RTFM, it simply means ‘Read The Freaking Manual.
An expression that was often used in Computer science circles to describe that the answer is easily found in the manual.

Nowadays, you’ll be lucky if there is a Manual in the first place.


In most places, although there is a Wiki to help new joiners get started, those guides are often out of date, imprecise and littered with jargon opaque to new starters.


An easy solution is to write an onboarding guide making the assumption that the reader knows absolutely nothing about the internal system and jargon. Avoid using acronyms and ambiguous terms.

Also, give the new joiner the remit to correct any mistake and clarify any ambiguity so that the next person finds it even easier to get started with the project.


  1. New joiner is getting productive faster
  2. Self-assisted, so not bothering others for trivial matters
  3. Painless experience for new joiner

Tip 2 – Create a ‘definition of done’ for your development process

Product Owner: Is this task Done?

Me: Well, it is Done but not released in Production.

Product Owner: When will it be Done, Done? 🎯


Although the shared goal is to ship a specific feature to customers, each team member is a specialist and is appraised on the completion of their specific tasks. I stopped counting the number of times a feature went back and forth from development to testing with the “It works on my machine” reason to close a ticket.


Does “Done” mean ‘I finished implementing the feature’ or does it also include Documentation, Unit tests, Integration Tests, Deployment to UAT, to Production?

Define and agree as a Team on what the definition of ‘Done’ should be. Write it down in your process section and make sure that the Team adheres to it.


  1. Stop wasting time
  2. Share a common understanding
  3. Avoid blame culture

Tip 3 – Create an Agenda for every meeting

Product Owner: Can you demo the latest release?

Me: 😱

In a very panicky way, I will type in my login details incorrectly a couple of times while on a screen share. I’ll have no script and no story to tell. After finally login in, I will discover that the environment is not working as expected. The demo comes across as uninspiring and unprofessional.


Most people find meetings a power drain. The main reason is that we join too many meetings where the objectives are not clear and attendees are ill-prepared so they run way longer than they should. (I mean you are probably reading this article while in a meeting 🙈).

Better still, ask yourself if the meeting needs to happen in the first place.


“No agenda, no attendance” is the motto at Gitlab when it comes to meetings.

I like this motto for a couple of reasons – First, you know what’s expected as an attendee and can prepare accordingly. Second, you can prevent Mindless Accept Syndrome (MAS), an involuntary reflex in which a person accepts a meeting invitation without even thinking why. To learn more about MAS, I suggest the excellent Ted Talk from David Grady.

The best way to get meetings to run efficiently is to add an agenda and set expectations for the attendees.


  1. Gather the right people in the room
  2. Give a chance for attendees to prepare
  3. Stop wasting time

Tip 4 – Record your meetings and publish them

Me: Sorry, I couldn’t make the meeting, anything I should be aware of?

Everyone: Nope, all good. 👍🏼

Product Owner (later in the week): This is not what I asked and I made it very clear during the Team meeting.

Me: 😡


We all have conflicts with life priorities and other business responsibilities, which means we can’t (and shouldn’t) make all the meetings we are invited to.


The solution here is to record every Team video call and publish them on the Team Wiki. Additionally, I strongly suggest using a transcription service like or Avoma. With the advances in machine learning, these tools are getting really accurate nowadays.


  1. More flexibility with scheduling
  2. Audit record of what has been said
  3. Repository of past conversations for absentees and new joiners

Tip 5 – Stop using ambiguous language

Me: Do you think we should write a blog post about collaboration?

Hannah: I definitely would! 😇

Me: Ehh, am I doing it, or are you doing it? 🤔

If you are not from the UK but have lived here for a while, the below will sound very familiar:

What the British sayWhat the British meanWhat others understand
Very interestingThat is clearly nonsenseThey are impressed


We live in a multi-cultural world with colleagues scattered all over the globe, the majority with another primary language and sometimes no cultural reference.


Try to use short sentences, eliminate ambiguous words, avoid adverbs and cut acronyms and jargon.

Also, try to limit the usage of idioms. (and yes, the irony of using the word idiom is not lost on me)


  1. Stop wasting time
  2. Share common understanding
  3. Set clear expectations

I’m hoping this article resonated with you and gives you some ideas on how to improve your communication.

If you want to dig deeper into the topic, I suggest reading the Effective & responsible communication guidelines from Gitlab.

Until next time…