Need more developers but have second thoughts about outsourcing?
Being uncertain is absolutely normal, especially if you’ve never worked with a software development agency before.
We provide companies with senior tech talent and product development expertise to build world-class software. Let's talk about how we can help you.
Contact usAs a software development services vendor, we understand the importance of transparency. And we believe it’s our responsibility to inform you about every step of the process and help you achieve your business goals.
Here at Relevant, we are convinced that client onboarding is essential. Here’s why.
As a software development company that prioritizes quality over everything else, we want to make sure that our cooperation with clients goes as smoothly and efficiently as possible. Our developers aren’t just freelancers with zero accountability. They are acting as an extension of your team, a business partner if you will. That’s why the relationships for us are extremely important.
As a client, you’ll probably have many questions. Onboarding is the best time to clarify everything, from the legal issues to the number of video calls per week. Having a well-defined yet flexible client onboarding process helps us ensure that our partnership is off to a great start.
In this article, we will talk about the process at Relevant Software and tell you more about how we onboard clients in our company.
Table of Contents
There’s no industry standard as to what a client onboarding process should look like, but for more than years of serving clients all over the world, we came up with our own approach. Here’s how it looks.
Let’s talk about every step in detail.
So what happens after we sign a Master Service Agreement (MSA)? First of all, we take care of the legal matters by signing SOW. It’s an important addition to MSA, another formal agreement between a company and a client that specifies all the details about the product or service to be delivered. In other words, SOW is a contract that will define the procedural terms and conditions of our business relationship.
SOW covers the following aspects:
The goal of SOW is to prevent any disagreements and misunderstandings between the parties. Dealing with all these questions early in the process gives both sides peace of mind and sets the whole thing up for success.
Requirement workshop is a collaborative event of key project stakeholders, the goal of which is to discover, validate, prioritize, and agree on the project requirements. We typically organize such workshops with our business analyst, project manager, and designer.
A typical workshop takes around 2-3 hours and the goal is to draw mockups and write project documentation. The next step is project re-estimation, which provides a more accurate timeline and resource estimation based on the prepared documentation and design.
At this point, we’re almost ready to start coding, but there are a few more things we need to take care of.
An artifact in software development refers to any project-related thing created by people involved in the process. First, a dedicated project manager develops a list of all the required artifacts that must be produced by different team members and then puts everything on a shared Google Drive for everyone to view and share.
Here are some of the typical artifacts, which are essential for every project.
Project Charter. It’s a statement of objectives in a project. This statement also sets out detailed project goals, roles and responsibilities, identifies the main stakeholders and the level of authority of a project manager.
RACI Matrix. RACI stands for Responsible, Accountable, Consulted, and Informed. It’s a linear responsibility chart that maps out every task, milestone or decision, as well as the roles of each person involved.
Change Request register. This is a file where we are tracking requests from any stakeholder. It usually consists of request number, date added, request description, field to implement (FE/BE/BA/PM/DevOps), who requested, and the requested due date.
Gantt chart. It’s a bar chart with project work breakdown structure (WBS), start and end date for each work.
Project roadmap. It’s a high-level strategic overview of the key project elements. It should include objectives, resources, deliverables, milestones, and planned timeline.
Release plan. In contrast to project roadmap, this is a simple scheme of task-level project details presented on a timeline. A project plan is used for assigning responsibilities and track progress.
Risks register. It looks like two tables with a list of all possible risks, both negative and positive. Risk register also includes qualitative and quantitative analysis and various action plans to be executed in case things go wrong.
User stories. It’s an informal description of one or more features of a software system. We can’t give an exact estimate until the full scope is described by our Business Analyst.
Here at Relevant, we use an Agile approach to software development, and to keep track of the process, we use Jira. It’s an issue tracking – slash – project management tool used for task management and reporting. We use it to visualize the progress and plan a working process for our team.
Before the beginning of the work, a Project Manager must conduct risk identification and evaluation session with all team members, preferably with a customer, too. As a result of this session, we should have two Risks matrixes in a project folder ‒ positive and negative.
The better the plan, the easier the execution. Our next steps involve spelling out a detailed project roadmap in a Gantt chart with dependencies and creating a step-by-step release plan. It’s going to be super helpful for the entire duration of the project.
Effective communication during the development process is key. We agree on all the details, such as the frequency of interactions (daily standups, weekly/monthly meetings), preferred communication channels (Slack, Skype, Google Hangouts), and the availability (if we’re in different time zones).
This stage doesn’t require a client’s contribution but it’s an essential part of project planning and it’s critical for the success of the project. Our DevOps team creates CI/CD pipeline diagram, system description, and instructions for developers. We’re also setting up the environment and building the architecture of the project.
Depending on the amount of documentation we’ve managed to gather and the complexity of the project, it can take anything from one day to a couple of weeks. In the latter case, onboarding becomes “Sprint 0”, but that’s a highly unlikely scenario. Typically, onboarding doesn’t take more than a week.
We still have an onboarding process, which includes the following steps:
This is pretty much it when it comes to our client onboarding process. We’ve been developing and documenting it since 2013 to provide our clients with the swiftest and smoothest onboarding experience.
Ready to create your product with a Relevant team? Get in touch with our expert and get your free consultation.
Businesses integrating AI into their workflows could unlock a transformative 40% boost in workforce productivity…
No one dreams of studying regulatory documents all day. Yet, for financial institutions, that’s exactly…
Do you face obstacles in keeping up with the rising costs of farming while maintaining…
