.jpg)
The Power of Adept Distributed Teams in Outsourcing: A Guide to Operational Excellence
Discover the benefits of adept distributed teams in outsourcing. Enhance operational excellence, reduce HR risks, and optimize your business operations.
guidance to teams that are planning to combine remote work and outsourcing with traditional employment situations
The world has changed more in the past five years than ever before, and much of that change is work related.
More people are working from home and want to continue doing so. More companies are struggling to fill open positions than ever before. Which means there’s a greater demand than ever before for outsourced and freelance services.
This handbook has been created to provide guidance to teams that are planning to combine remote work and outsourcing with traditional employment situations.
As a long time, provider of outsourced and remote working solutions, our team is uniquely able to provide insight into the best way to manage the process and get the results you want.
When teams are geographically dispersed, it is more important than ever to have documented processes and predictable workflows. When everyone knows the process, it’s easier to ensure that the right steps are taken in the right order, and to keep projects and deliverables on track.
Every team is unique, and every project will have its own time, budget, and work product requirements. However, many years of handling outsourced development requests from various internal and external clients have allowed us to create an effective process that can be applied to most situations.
While these processes and workflow recommendations can be adapted, it’s strongly suggested that they be included in the process in some form.
Setting S.M.A.R.T. goals for the short, medium, and long term is one of the best ways to measure progress and keep your team on track. Goals should be Specific, Measurable, Achievable, Relevant, and Time-Bound. They should be written down, and they should be communicated to all team members.
Remember that while setting and attaining goals is an important part of planning, there will always be unforeseen events and changes, so make sure you build some flexibility in too.
Teams, especially those that are geographically remote from each other, perform better when they understand how small daily tasks and seemingly insignificant milestones connect to the big picture.
When you are creating project plans, communicate the big picture with all the milestones, deliverables, tasks, and activities defined and listed to your team. Seeing how each small task affects the whole project when it is completed correctly and on time will increase motivation and buy in to the plan.
Every step, no matter how small, makes a difference in the grand scheme of things, and your employees, freelancers and subcontractors should be aware of that impact.
While scheduling project meetings, measuring progress, and adjusting course if necessary is critical to project success, doing these things too frequently is counterproductive. Your team will spend more time talking about progress than making it happen.
It’s better to divide projects into shorter cycles of about two weeks, which are long enough to check significant work off the to do list, but not so long that it’s not possible to make changes if necessary.
The length of each cycle could vary based on your business and project requirements, but it should be measured in weeks rather than days (too short) or months (too long.)
Include some time between each cycle in your planning, to allow for a feedback loop. This will allow all team members to report progress and problems, and to analyze and develop solutions. This is also a common practice in well-known project management methodologies like Scrum.
Individual teams may choose to have informal meetings at shorter intervals, and you should share information with team and project leaders in as close to real time as possible. Which will allow you to spread general project meetings out further.
As your project progresses, you will find that new requests, additions, and some degree of scope creep find their way into the process. It’s important to understand that you cannot take action on every request or piece of feedback. Review these periodically, and decide which ones are important to the success of the project.
Don’t allow yourself to be caught up in a backlog that won’t move your project forward.
Teams work best when everyone knows who is responsible for which elements of the project. Defining those roles and responsibilities starts by designating a project owner, who will define the process, set the project brief and timeline, and drive the project towards completion.
Once the project owner has been defined and appointed, they should work to appoint individuals who are responsible for specific project related issues and tasks. In this case, a flat hierarchy is not effective. Everyone needs to know who makes the decisions and sets the goals.
The general rule for planning successful projects is that the smaller you can break tasks down, the better you will be able to manage the project and measure success.
Every deliverable and milestone should be broken down into individual tasks, and each of those should be divided into sub tasks and issues. This makes it easy to see where potential problems might occur and allows you to quickly change plans and reassign resources.
While projects should be carefully planned and meticulously documented, real progress is measured in work product. As changes are made, designs are completed and problems are solved, they can be marked as complete. Be sure to mark completed tasks, subtasks, and issues off on your project plan and schedule, so you can maintain an accurate record of your progress.
As your team works towards completing the project, it’s important to keep a record of what has already been achieved. Changelogs allow your team to track their own progress on their tasks and ensure that there is clear communication about that progress.
Changelogs can be shared with the team and can also be used to document added value that is created during the course of the project.
Share changelogs and other updates with the whole team too. It’s important to celebrate collective successes and ensure that even geographically remote teams continue to work towards common goals.
User stories, issues and tasks are all ways to communicate a problem and the desired solution to your team. When tasks and issues are clearly defined, and the solution is described, it is much easier for the team member responsible for that issue to define what is required and deliver that desired result.
Keep your issues and tasks simple, clear and to the point. This should be a set of instructions about how to solve a problem. Which is why you should usually write issues and tasks after the project plan has been mapped out, and the solutions have been brainstormed and finalized.
User experience features and functionality should all be discussed before creating the project plan, and breaking it into milestones, tasks, and issues. Discuss these with the high level project team, decide on solutions, and then communicate those solutions in your issues and tasks. Ideally, issues and tasks should focus on implementing solutions – not developing them.
Once your team gets the project plan and their instructions, their primary goal should be executing the decisions and solutions that have already been decided.
Very often, the perfect user story you create at the beginning of a project won’t be the same as the one you write at the end. Along the way, you will find that your assumptions change, that you get unexpected feedback and that people want different things than you assumed when you started.
This is to be expected. There are several approaches recommended to approach this, but often, it’s best to think of your perfect user story as a living document.
Over time, it will change, evolve, and grow. You will add new tasks, features and functions to your to do list as the project progresses. This is a normal part of the process, so consider which user requests will enhance the project and which will not and adjust your backlog tasks accordingly.
Most teams use project management tools to track, measure and share information. Some, like Asana, are largely to do lists. Others, like Trello, are a little more graphically. The tools you choose to use don’t matter as much as how you use them.
In fact, if you use them correctly and consistently, even something as basic as a shared Google Sheet and your Outlook Calendar could be effective project management tools. Here’s what you should be focused on.
Communication is central to the success of any project. However, there are different types of information.
Primary or master documentation including endpoints and architecture should be kept separate to day to day communication. A changelog should be kept and updated whenever appropriate, but you should also use issue level comments to track specific comments, questions or suggestions.
Communication should always be recorded, and you should avoid any one on one emails or conversations. If it’s not recorded in the project documentation in writing in some way, it will not be taken into account.
In the project management world, tasks and issues that will impact the success and trajectory of the project as a whole are deemed to be “on the critical path.” These tasks must be completed on time, or they will delay or derail the rest of the project.
While it is sometimes very easy to determine which items are critical, it can be harder to assign a priority weighting to other tasks. In that case, you should consider three important things:
Each of these can be assigned a weighting factor, which is usually a number, exponent or size. For ease of use, number scales work just fine. So, assign each one of these factors a number between zero and 10, with zero being completely unimportant and 10 being critical. The higher the resulting number, the higher up the priority list the task should be.
The BWA model (business, weight, ambition) that we have just outlined can be used to determine which tasks can be outsourced.
Tasks and issues with lower rankings could be considered non-core tasks and are probably easy to outsource. Tasks with higher rankings should be handled in house or outsourced to specialist contractors where they require specialist skills.
The chart below illustrates this graphically.
#1 High ambition and/or Business priority. These are the tasks you do care about and shouldn’t outsource at all. These tasks usually have the risk of knowledge transfer outside of your core team.
#2 Tasks that have high business priority but not high technical expertise requirements (i.e., UI-related, bug fixes, integrations) can be outsourced efficiently and still contain all security, knowledge, and IPR requirements.
#3 Sometimes tasks have low ambition and business priority. Quite often these tasks are not actually needed.
Every project team will have some level of fluidity. Team members will come and go, you may use freelancers and outsource some aspects of the project. It is critical that all of their work is stored in a central location that is secure and easy for project admin to access.
Repositories of code and work product should always be managed in house, and you should always have complete control of everything stored there. This means you can make staffing and outsourcing changes, when necessary, without worrying about losing important chunks of your project.
We prefer Access Keys (SSH) over username/password credentials, and of course, when there is a change to the team structure, security and access changes should be made immediately.
Most development happens on the engineer’s local host (Local Web Development Environment), and many teams choose to use a unified cloud-based DB which makes setting up the environment a little faster. This also ensures that the team uses the same datasets and structures. However, this is a personal preference that should be decided by the team.
We recommend using these types of environmental setup:
The initial setup allows fast development and testing. We prefer a shared test DB which the whole team uses. This helps with testing and issue reporting case when multiple engineers are working on the same tasks, or when tasks have a direct correlation.
This environment is used for review and testing each implementation in a near-production environment. Engineers can make pull requests (which are approved by the issue owner), or merge directly based on the team workflow and preference.
When the review is done and tested, it can be deployed to production. This should be done by the core team, and you should not allow access for the outsourcing company for this stage.
We use three-phase quality assurance, which is focused on manual testing.
It goes without saying that all the credentials, admin rights, and access control should be handled by the core team. Which allows only required access to the services (for example DB).
We recommend that teams use mockup data in local and staging environments, and if needed test the data internally with the production data before deploying.
During the BWA model security (and IPR) concerns can be easily identified which leads to secure outsourcing with minimal risks.
We can adapt your existing staging process environment (local setups or cloud-based). Our experts are also more than happy to help to get the virtual development setup running.
Here’s example of cloud-based DB setup. Basic setup meets GDPR and most of the high-security requirements, yet still, be the most efficient way to handle non-core tasks (see BWA model).
.jpg)
Unified cloud-based DB simplifies development and testing and ensures that data points and procedures are constantly updated and available for all the team members. Which means the benefits easily outweigh the effort required for the first setup.
With 3000+ professionals on board, we’re ready to assist you with full-cycle development.
.jpg)
.jpg)