A software R&D service company often carries out projects in which software engineers work at customers’ premises. It is usually called onsite work. This approach is typical for projects requiring regular communication with customer business units, developers, and project managers on the client’s side or specific hardware or software that cannot be (efficiently) accessed from the provider’s office.
In this article series, I would like to consider the peculiarities of onsite work and the risks it holds for both customers and contractors, as well as some of the methods that we use at Auriga to mitigate these risks.
Communications
When cooperating onsite, engineers have to interact much more often with various customer representatives—business users, product owners, project managers, and other developers on the client’s side—through personal communications, phone calls, online messenger sessions, and emails. At the same time, engineers have more autonomy when interacting with the customer and making decisions, which certainly contributes to the development of their communication skills. However, it may also cause problems. Multiple meetings with the client may obviously reduce engineers’ available time for coding. Is this problem related to a project risk that can be leveled out?
Well, we can hardly reduce the number of meetings with the customer if our engineers share knowledge onsite and the project is aligned with the customer’s processes. Moreover, our company’s many years of experience show that when the requirements are more detailed, we conduct more intermediate demos, and we receive more frequent customer feedback, we receive fewer comments at the end of the project. Therefore, our project managers always stimulate additional communications between engineers and customers.
Save the tip: Set the time for communication while planning (or write a communication plan). Choose a specific person (a Product Owner or a Project Manager) who will help contractors find the necessary information or connect with the right experts in the company. Set the meeting schedule and a range of employees to attend them. Familiarize engineers with the escalation system in your company.
Why is it important? Communication makes life easier, reveals potential problems in the early stages, and as a result, helps to achieve a quality product on time and with fewer defects.
Business Requirements
Another onsite support peculiarity is that the initial business requirements are usually formulated too generally, with no specifics or technical details that would help accurately estimate labor costs and schedule the project. At the start of such projects, the lack of clarity does not seem to be a big problem, as engineers are going to stay in the customer’s office and can therefore later discuss their questions and clarify the requirements at any time.
Although this, to some extent, may be convenient for the customer, this convenience is associated with a real risk of changing (complicating) the requirements and delaying the delivery deadlines of the entire project. Our company has completed many onsite projects for clients from different industries, and we have developed a set of processes and practices that allow you to manage this risk:
- When planning a project, we usually put in extra time to clarify and detail the requirements and prepare technical requirements documentation. The resulting document describes the requirements from the software developers’ point of view; it should be agreed with the client during the initial development phase.
- After all meetings with the customer representatives to discuss technical requirements, their changes, comments, and improvements, we prepare protocols and send them to all project participants.
- Some customers do not have much experience in establishing detailed project requirements. In such cases, our experts can demonstrate the best examples of technical requirements descriptions written earlier for other successful projects.
Save the tip: Document business requirements in advance, either by yourself or with specialists, or ask the contractor’s engineers to prepare the documents for you.
Why is it important? On the one hand, this allows you to reduce the time taken to establish detailed technical requirements, and on the other, it helps you describe the requirements to engineers in a clearer and more understandable way.
In the next part, I will consider such onsite project features as following the customer’s software development processes and using the customer’s IT infrastructure and equipment. Please stay tuned to the Auriga blog!
