There are two major ways to cooperate with a software or hardware development company: a dedicated team or a fixed-cost project.
The dedicated team model suggests that your scope and project duration might change. Therefore, the total cost of the project will depend on the tasks you assign to the team, and you pay for the time engineers needed to accomplish these tasks.
The fixed-cost project means that you have all the requirements defined before starting the work, and you negotiate the total cost of, for instance, developing a product.
In this article we will explain when it’s more reasonable to go with a dedicated team model, how it might look, pros and cons, and how you can make this model more (and less) effective.
How do you know if the dedicated team model will work for you?
You might be a startup, an established business or a digital agency — it doesn’t make a difference; the dedicated team might work equally well for you. The first more important criterion is which type of project you have.
A dedicated team is a right choice when you have a big project, several projects or a huge pool of tasks; when you don’t have a clear vision of future project deliverables; and when you know that many requirements will be revealed during the discovery phase and R&D tasks. You know that the scope and timeline for this project might change, but the quality should stay on the same level.
The second benchmark for choosing a dedicated team is your staffing needs. This type works when you have your own development team that you’re going to extend, you have an in-house project manager (PM) and you need an engineering team, you need a PM and a team, or you need an engineer with very specific expertise.
The third point is your budget. It’s very important not to be limited to a strict budget.
There also might be a situation when you may consider switching from a fixed-cost project to a dedicated team. This makes sense when you have been working with a vendor for a certain period of time, so you know how the team works and estimates different tasks; the members have been shown to meet promised timelines; and you are satisfied with the quality level and trust your vendor.
On the other side, this is not a one-size-fits-all model. The dedicated team is not the right choice when one of the following is true: you don’t trust your vendor, your budget is limited, or the project is small. It's also not a good fit when your project plan is ready and very detailed, deadlines are defined, quality is a secondary priority for you, and you know that no changes to the scope might occur.
How might your dedicated team look?
Depending on how well you know the development process and what your staffing needs are, you might consider hiring only engineers or a team with a PM.
When you hire only one or more engineers,
- you should clearly understand the development process,
- you are responsible for creating a task backlog,
- you will keep track of the work progress, and
- you should keep track of proper communication.
When you hire a team with a PM,
- you might have significantly lower understanding of the development process,
- you will communicate only with the vendor’s PM, and
- the vendor’s PM will do all team management and keep track of the team lifecycle.
What are the pros and cons of a dedicated team model?
There will always be advantages and disadvantages no matter which cooperation model you choose. The dedicated team model offers you the highest flexibility for changes to planning and task priority, but, at the same time, you take responsibility for the communications and risks.
The vendor also faces the pros and cons on its end, so you both always should negotiate to reach a win-win scenario.
How to get the most and least effective collaboration
So, when you’ve decided on a dedicated team, there are a few things that will help you be more effective in this cooperation.
The first thing is your previous experience with dedicated teams or your understanding of the software development process. This will improve project management significantly.
If your previous experience with software development was positive, this is a plus. The negative experience might cause a lack of trust in your vendor, leading to micromanagement and applying a process that helped fix issues last time, even if it’s not relevant.
Second, especially when it’s a hardware project, you would benefit from having a highly skilled PM on your side, and you can predict the future impact of your engineering decisions (e.g., if you cut expenses now, you will end up with higher costs later).
Other things impacting effectiveness are experience in interviewing tech staff, treating your dedicated team as your in-house team, visiting the dedicated team (preferably before starting the project), and motivating the team.
Motivation influences performance a lot, and, with higher motivation, your team can do better than usual. So, here is what you can do to keep it at a high level:
- have a development process established,
- share a clear responsibility matrix,
- identify the goals,
- don’t use outdated technology stack,
- assign challenging engineering tasks,
- require very high-quality standards,
- swap staff responsibility from time to time to decrease instances of being “bored”.
Some of your actions might also make your team less effective, so we recommend avoiding the following tips.
Don’t work on tasks backlog. The team may often be unloaded and, after a certain time, become bored. Then, team members might ask to leave the project.
Always rush deliveries. Teams will burn out quicker, especially if everybody understands that the rush has no purpose and always happens for no reason.
Frequently introduce changes that completely cancel previous work. The team might treat new tasks as something that there is no reason to perform properly as they will be changed or removed anyway.
Сommunicate with engineers unprofessionally, e.g. public conflicts, blaming, bullying. The team loses motivation, and any project-related activities are associated with something bad.
Do not try to understand the development process. You should have a basic understanding of how the software is created; otherwise, the project management will become messy.
Treat your dedicated and in-house teams differently. This might cause the customer’s in-house team not to feel accountable. Any issue might be recorded under the dedicated team.
Summary
The dedicated team is a really effective cooperation model and brings a lot of advantages, for example, you can select a team or apply any staff changes and be flexible with your project. However, prior to choosing this model, you’d better check whether the goals and needs of your project correspond.
We recommend always aiming for a win-win situation with your vendor. This can be achieved when you have a professional PM, know the process, maintain a backlog, plan deliveries, and communicate properly and your vendor provides a strong team, proper expertise, and transparent reports.
Contact us if you have some project idea in mind.
