1️⃣ How we work with our clients
We don’t have a typical client-consultant relationship. Instead, we work as one team—specifically, one agile team.
Here's what this looks like:
Here are the mechanisms that support this way of working:
- Channels of communication
- Collaboration tool to build a transparent, common backlog
- Duration of our work sprints
- Routines
- Weekly 30’ check-ins to discuss the backlog, review deliverables and resolve impediments.
- Retrospectives. These are our strategic tune-ups, scheduled after each project phase or significant milestone. These sessions are a collaborative forum where both sides—client and team—engage in a transparent exchange about what's excelling and what requires fine-tuning, from workflow to deliverables. It's about proactive improvement, not just reflection. By addressing these insights in real-time, we ensure continuous advancement and on-the-spot course correction for stellar outcomes.
We prioritise real-time communication for our mixed project teams, including both client and REBORRN members. Therefore, we'll align with our clients' preferred tools, like Slack or Microsoft Teams. If the client lacks a platform, we're ready to extend an invitation to ours or utilise immediate messaging solutions like WhatsApp. Our aim is to steer clear of email, which often hampers the swift and informal dialogue that is crucial for our collaboration.
We are adaptable and will seamlessly integrate with our client's preferred tool, whether that's Notion, Asana, Trello, Microsoft Teams, or any other platform. In the absence of a preferred tool, we will extend an invitation to utilise our systems. Regardless of the platform chosen, it will serve as the foundation for creating a comprehensive and detailed backlog, accessible for review by both the client and our team at any time. We usually use a simple Kanban board to visualise this backlog.
We also need a space for our files to “live”. That could be Google Drive or OneDrive.
We usually prefer weekly ones, but depending on the duration of the project, this may change.
One of the most important elements in our ways of working with our clients is our pre-defined routines. We usually set up:
2️⃣ Internal project Kick-off meeting
To ensure that the above principles are clear and are successfully put into practice, we ensure that we have a thorough kick-off meeting in every project.
A project kick-off meeting is an internal first meeting with the project team and is separate from the kick-off meeting with have with the client. This meeting is the time to establish common goals and the project's purpose.
A good project kick-off meeting sets the course for successful and smooth collaboration.
Getting everyone on the same page and off to a great start is critical for the success of any engagement. It's a jumping-off point for the assigned REBORRN team, where all its members should come away from this first meeting with a clear understanding of their roles, the project's sole purpose for both REBORRN and the client, and the desired impact the team wants to create.
Our kick-off is an opportunity to orient the team to work at hand and establish common project goals and check-ins. We recommend the following flow to facilitate consistency in internal kick-off projects. The project lead uses this template:
3️⃣ How we off-board ourselves
We are an impact-first company. This means we seek engagements that are meaningful, not merely to perpetuate our relationship with clients for the sake of more fees.
We achieve this by making ourselves obsolete and then off-boarding. While every engagement is different, this is usually achieved through two main strategies:
- Working as One Team: We integrate fully with our clients, sharing everything openly, as explained here.
- Training Our Clients: We ensure our clients can continue our work independently. For example, in a Team Effectiveness project, if we help a team transition to agile ways of working, we train enough team members in agile methodology to sustain our role.
Curious to understand more? Here is a case study that describes how we made ourselves obsolete in a project with G4S:
