Table of Contents
In our past article from the series on the IT vendor management, we spoke about where to find a reliable software vendor and how to structure a contract with a vendor. Today we’ll talk about one of the most intricate part of the project development aka the assembly of a project team and an efficient project kickoff.
When it comes to negotiation and project estimation, there might be several hidden rocks and challenges to be aware of in advance. In this article, we’ll walk you through the main steps of the process and will discuss the main things to keep in mind when discussing the team and the tech stack.
Evaluation of the project type and size
The first thing that SoftTeco does when a client approaches us with a project idea is evaluating the project type and size. For that, we use a project specification that is provided by the client – you can think of it as of an approximate project description. In case a client does not have a ready specification, we can help them assemble it by transforming the client’s thoughts, ideas, and visions into tangible deliverables.
It is also important to mention that SoftTeco pays extra attention to the client’s business goals and helps the client clearly define them so they serve as a base for further work. Judging by our experience, when the client first approaches a software vendor, they normally share their marketing and/or financial goals while business goals remain unclear or not so well-defined. Hence, it’s our responsibility to determine the business goals together with the client and help guide their vision of the product in the right direction.
Getting back to specifications, while each is different in terms of the contained details, it normally contains:
- The preferred goal of an application and what it has to accomplish, what business goals are to be met;
- Domain of the application (i.e. finances, healthcare, e-learning, etc.);
- Expected project duration (in hours) and the expected launch date.
By analyzing the specification, the team from the company’s side can get an idea of what kind of team is needed and how many hours will be spent on the project. Depending on the number of hours, we define the type of the project and its size. Based on that, we can also estimate the team size and the approximate composition of the team.
Definition and collection of user stories
The stage of business analysis and requirements gathering also includes the definition and assembly of user stories. Since we’ve already written an article on users stories and how they differ from use cases, we won’t go into much detail here. Let’s have a quick overview instead.
A user story is a brief description of an action that a user will perform while interacting with your product. User stories form a user journey – a path that a user will follow in order to achieve the needed result. An example of a user story is “I need to pay for my order online and directly from the app without being transferred to external services”.
The main role of user stories is to better understand user behavior on the app and what actions the user would want to take. In this way, you will ensure the product is user-focused and caters to users’ needs. Once user stories are defined, the team will then break them down into deliverables (tasks).
After studying the client’s specification and estimating the project, the software company typically provides a high-level project plan that features the main stages of work and the proposed team composition. As well, the project plan may feature the duration and deadlines (in case the client did not provide them) and the proposed tech stack, based on the requirements and needs.
Selection and approval of the tech stack
The choice of the right technology for your project significantly impacts the product success in the future. For instance, if you face an unexpected issue, it will be easier to resolve it if the technology is mature and has a big community that can provide help.
When it comes to choosing the tech stack, it often happens that a client and a development company may have different opinions on what technologies are best suited for the project. Some time ago, we’ve written an article on how to select a tech stack – you can read it in detail here. As for best practices, they are:
- See whether the technology is mature so there are enough software developers available;
- Do not trust buzzwords – double-check whether the technology is really suitable for your specific application;
- See whether there are any ready solutions available so you won’t have to design one from scratch;
- Consider the compatibility of technologies for better results (i.e. improved performance).
The main idea here is that both the client and the company need to clearly communicate their arguments for selecting certain technologies and choose the ones that will benefit the project the most.
Team assembly and the definition of the needed roles
Negotiations about the team composition are usually the most challenging ones due to a number of reasons. The best team composition may be out of the client’s budget or the client may not understand why certain roles are suggested. All these things are thoroughly discussed and it is vital to always keep the business goals in focus.
The software company first presents an approximate team composition to a client after receiving a project specification (that we discussed above). The proposed team composition is based on the project size and complexity as well as on the domain and recommended technologies. For example, if a client wishes to design a fintech application, a software team with an experience in this domain will be the first and most obvious choice.
The importance of a Product Owner role
When it comes to product development, it is important to understand that the software company brings the client’s ideas to life – but generation of these ideas and the final product vision falls on the shoulders of the client. Therefore, there should be an intermediary between the client and the team who will be responsible for guiding the client’s vision in the right direction, making decisions, and communicating client’s ideas to the team.
This person is usually the product owner or PO for short. Product owner works on the client side and, together with the development team, helps the client and/or stakeholders to make the right decision by analyzing project requirements.
The main idea that we wish to translate here is that it’s best for a product owner to work with the client and/or stakeholders in order to better understand what changes or decisions to implement in a product in order to achieve the client’s business goals. Of course, the development team can always suggest a solution or an idea but it will be the PO and/or the client to have the final say.
Main aspects to consider when negotiating the team structure
We’ve already stated how important it is for the client and the vendor to find common ground on the subject of team composition. Below we’d like to share several aspects to keep in mind that will help make the right decision in the most efficient way:
- If the recommended team does not fit the client’s budget, it is highly advisable to reduce the number of product features in order not to sacrifice the app’s quality by removing skilled developers;
- The vendor should explain every suggested role so the client understands what each person does and how they will contribute to the project;
- It is recommended to start the project with a relatively small team and then scale it up gradually – more on that below.
A kick-off call with the client
After the team and the tech stack are composed and the project is broken down into deliverables and milestones, the software vendor normally initiates a kick-off call with the client. The main goal of this call is to review the current plan in terms of deadlines, deliverables, sprints, etc. and to discuss any questions or concerns.
A kick-off call normally includes:
- Requiring accesses, discussing the task management system, and clarifying the report structure.
- Requiring accesses to the customer environments (Dev, Stage, Prod) and establishing a deadline. Also, assigning a DevOps engineer for the setup.
- Discussing timings for such activities as daily meetings, sprint planning, demo meetings, retrospective meetings, refinement sessions. All related information should be sent to the client in the meeting notes and added to the calendar.
- Setting the first spring planning – prior to that, it is important to already have tasks in the backlog and (if possible) an approximate plan for discussing with the client.
- Starting the deployment in case all accesses to the environments are granted.
Tasks to do outside the kickoff (for the development team)
The organization of a kickoff meeting may take some time so it’s natural that the development team starts working on other tasks in order to be fully prepared for the kickoff. These tasks may include:
- Organize a meeting with the dev team to discuss project architecture, delegate tasks, and assign roles;
- Describe tasks to do so they can later be imported to the client’s Jira;
- Investigate and clarify any issues that remain unresolved at this stage;
- Establish control over branches (i.e. where to implement updates and how);
- Connect Jira to the repository (if the repository is external);
- Start working with UX/UI designers (if needed);
- Start writing test documentation and test cases;
- Prepare all managerial documentation (project kickoff meeting, meeting notes structure, client reports);
- Prepare a project charter – a comprehensive document that describes the project in detail and states its main goals.
Hidden rocks to consider when starting a project
The development of a software project requires thorough planning and yet there still might be unexpected issues that happen after the project is launched. To minimize possible risks and help you navigate the complexity of the process, we list down the main issues to take care of in advance.
Provide access and all needed credentials before starting the project
One of the most frequent bottlenecks that we encounter when working with clients is the lack of access to the system or no credentials given in advance. So when the team starts working on a project (i.e. the start date as defined by the client and the team), it will simply not be able to do anything because no credentials or access were given. In this way, the client will be overbilling (according to the contract) but no work will be done – and there is no need to explain how negatively the situation will affect the project.
Gradual scale-up of the team
When the project is just starting, there is no need to kick it off with a big team. It’s usually more than enough to have just a technical lead, a project manager, and a technical QA for start. These people will:
- Ask questions to the client about the project;
- Write a detailed project specification;
- Create tasks according to this specification;
- Estimate project architecture and the app’s framework;
- Create tickets in Jira so developers can start work as soon as they board the project.
All these tasks require a certain amount of time. So to avoid overbilling from the client’s side and idling from the dev team’s side, it makes sense to start with a small group of people and then add more specialists as the project gets bigger and tasks get clarified.
Prepare all Jira tickets in advance
There is one thing that’s almost as bad as starting work with no credentials and that’s starting work with no clear tasks to do. This is why it’s essential to prepare all Jira tickets before kicking off the project so developers can immediately get down to work when they board the project.
Preparation of Jira tickets and their decomposition into technical tasks is the responsibility of the Product Owner and the tech lead so they need to work together on that.
Conclusion
The process of assembling a development team might be complex but if planned in advance, everything should go well and without any bottlenecks. Just keep in mind the tips discussed above and don’t forget to maintain transparent communication with the IT company and the team so you both stay on the same page and understand each other.
Comments