In outsourced software development, you as a customer probably don't understand the expected degree of your direct involvement in the project. Some may imagine that the customer's role is simply to hand a list of requirements over and then pay for the results.
Although, in the waterfall development methodology, the expected contribution applies. In reality, almost all IT teams have taken an agile approach and thus expect customers to cooperate with the development team almost daily to ensure that the end result not only meets customer expectations but also finds the market fit.
Developing software in a black box in 99.9% of cases is a recipe for a disaster and an overblown IT budget.
This article aims to outline the optimal problem-solving process between you and an IT contractor. After delivering 50+ high-loaded advanced solutions, we have come up with explicit recommendations to collaboratively deliver viable products with a smooth development process.
Crucial participation milestones
There are several milestones where customer participation can be crucial for the project. Let's mention all of them, highlighting the exact customer's role and responsibilities required for each milestone.
Determining the project's scope of work
How it goes: At the beginning of a project, the team defines the project's scope of work. They describe the functionality they'll be building and the stages of the development process.
Also, this phase is about setting tasks. The project is split into several parts. Each part has a specific set of features. Large tasks are broken down into smaller ones and distributed over iterations (sprints). This allows product development to be more flexible: depending on intermediate results, the team can change the priority of tasks.
The customer's role: Your participation in planning is vital because only you can prioritize epics and tasks to meet your business needs. A project manager will help you with the description of each task with user stories and acceptance criteria.
Normally, you will be given access to the project environment software (Jira), where tasks are described and tracked. Also, you will have a template for a task to develop a feature or describe a bug.
To make task writing easier and faster, you can create a separate document describing recurring cases. For example: "We've received feedback from numerous end-users that they would like to be able to perform X functionality. And my product owner has prepared a new user flow."
Compiling a roadmap
How it goes: A roadmap defines the functionality that needs to be built and breaks it down by time intervals with specified deadlines. It is important to understand that this is a flexible tool, so deadlines and lists of functions can change depending on the team's pace, user requirements, and other external factors.
The customer's role: You will need to approve any alterations and additions to the roadmap. So the team may need to contact you often. Make sure that you agree on the time when you're available for quotations and requests. Alternatively, appoint someone to handle communications with the development team.
Prioritizing tasks
How it goes: When the team plans a sprint, they prioritize tasks: critical, high, medium, and low. Features get prioritized, too. For example, killer features are a high priority, while functions like “it would be great to do it, but it is unclear whether anyone will use it” are low.
In addition to the main functionality, a project also features writing autotests, solving technical debt problems, writing technical documentation, and bug fixing. In planning and prioritizing, all of these aspects must be considered.
The customer's role: You need to make sure that the team understands the project's priorities correctly. Feel free to check their prioritization in the task tracking environment, ask questions, and communicate concerns if you have any.
Planning sprints
How it goes: Sprints are one- or two-week-long development iterations. Sprint-based work allows seeing continuous progress and painlessly changing the project's direction if needed. It also helps identify a problem early on and set deadlines.
The customer's role: Each sprint is planned by the whole team, including you. However, it is important to remember that you are not the one setting deadlines for the completion of tasks. The programmers set deadlines for the completion of tasks, the testers set deadlines for testing, and the PM sets deadlines for deployment or demonstration.
Normally, all tasks are divided into small subtasks (not more than 2 hours) and are estimated based on spent time. Depending on the duration of the sprint, the total number of hours is calculated, and based on the estimates, you can understand how many tasks each developer can take on in a sprint.
Tasks are defined for a sprint once, and it is better not to change them during an iteration. An exception is when there are critical bugs. However, no one on the team should ask developers to do something without a task created in the project environment. Only in extreme situations (during emergencies in the product environment), tasks can be created with a delay. For example, a developer has already begun to work on an identified problem, while a formal task is being created for this at the same time.
You should have access to all the relevant project information: discussions, project structure, priorities, reports, and plans. Documentation is necessary: it helps prevent miscommunication and avoid wasting time on asking questions. All documents will be available to project participants depending on their roles and unavailable for anyone else: in Jira, in Confluence, in a wiki, or in the repository.
Demonstrating results
How it goes: A demo is a demonstration of the team's intermediate result. Demos can be held every sprint or as often as needed. This is another way to monitor the progress of the team. The main purpose of a demo is to show what the team managed to accomplish during a sprint and to understand whether the execution meets the ultimate requirements.
The customer's role: During demos, you are expected to provide constructive feedback. This feedback should be documented and translated into tasks. It is not recommended to criticize the team during demos because being criticized can demotivate them.
After the presentation, you will be expected to go through all the tasks completed in the sprint and formally accept them in the task tracking environment.
Also, demos can feature analysis of the past sprint. The point is to see what was good in it, what problems occurred, and how the problems could have been or can be solved.
Note that, in the early stages, demos will normally expose bugs. It's okay because it shows that the team is working on the product. To reduce the number of bugs, you can add a QA specialist to the team and create autotests.
Accepting tasks
You are the one who ultimately accepts all the tasks. You check the team's progress by testing the software they've developed. The acceptance process helps you see whether the team is performing as expected.
You will be expected to accept tasks regularly. It is advisable to review the scope of completed tasks every day or at least at the end of each sprint before planning. Based on formal acceptance, the team can move unfinished work (or work that needs revision) to the next sprint. It is important to understand that, without your acceptance, a task cannot be marked as done, so the team won't be able to complete the sprint.
Reporting problems and solving them
Projects with no problems do not exist. Reporting problems honestly and openly is the key to success. Only if problems are reported openly, it's possible to stabilize the project in a timely manner and move on. Problems can be very different, ranging from a situation where you feel uncomfortable with a specific team member to a situation where deadlines are missed.
Most of the problems are solved by communication.
Team composition problems
If you are uncomfortable working either with the whole team or with its individual members, you need to discuss this with the project manager and decide how to eliminate the discomfort or replace the team member.
If the team member in question is the project manager (if you think he or she is incompetent or you just don't like him or her), you should contact your contractor's top management directly.
Performance problems
If the team performs poorly or does not provide the results that you expected, you need to turn to the project manager and the team lead. Tell them that you are not satisfied with the performance and explain what exactly isn't right.
It is an absolute no-no to hush problems up. If you remain silent during demos, the team thinks that everything is okay, and in the meantime, the gap between expectations and reality grows.
There are cases where there is a lot of functionality to develop, but there is little time, so the deadlines are not satisfactory. If the team gives you adequate reasons why development cannot be sped up, listen to them. If the arguments seem far-fetched to you, work out the details until you are sure that the team is doing their best and moving as fast as possible.
Even if the team additionally works at night and on weekends, it will not improve the situation. On the contrary, it will only make it worse. Later, after intensive overworking, the team's productivity will drop, and so will the quality of the product.
It's important to remember that you need to share your emotions, but at the same time, your feedback should remain constructive, and you should actively participate in problem-solving. Also, remember that, according to professional etiquette, it's recommended to refrain from personal comments about the members of the team you're working with.
If you've reported a problem to the team and offered solutions, but nothing changes, you should also contact the top management directly.
Remember that the team has no intention of harming you, ripping you off, or multiplying bugs. A good contractor always tries to make products that solve your business problems and help you gain profit.
Conclusion
If you outsource software development and fully rely on the team to make all the decisions without your involvement, there's a big risk that the final product will be different from what you imagine. That's why it's advisable to be actively engaged in development. The customer's role is not only to accept results but also to guide the team, address their concerns, and make sure that they're doing things the way they should.
Active involvement is to ensure that the customer and the contractor are continuously working together on the common goal: to make a product that will be competitive and successful.
Latest articles here
