Collaboration with agency partners
At the VDZ Tech Summit 2021, we talked about the problems that can arise when working with agency partners and how to avoid them in advance. In this article, we summarize the topic in detail.
What is the problem when working with agency partners?
Since our founding in 2010, we have repeatedly been approached by customers who are more than dissatisfied with their previous agency partners: The communication does not work as expected, the cooperation is completely different from what was promised in the purchasing process, the project is way over budget and the end of the project is not in sight, or the agency ends the cooperation with the customer for its own reasons.
Such and other circumstances have often crossed our path. That is why we give potential customers various recommendations to keep their independence already from the first meetings.
From our project experience, we have the one or other tip to avoid pitfalls even before the beginning of the cooperation.
Everything related to the project should be owned by the customer
There are many reasons for changing agencies in web projects, which is why we believe it is always worth thinking about what will happen in the event of a change even before the cooperation begins.
Hosting
Sometimes the customer wants or needs to quickly change the agency service provider. If the previous agency alone has all the contacts and access to the hosting platform, however, then in most cases it doesn't happen quickly. In addition to the service provider change, the website also has to be moved to a new hosting, which on the one hand can cause technical difficulties and on the other hand costs time and money.
Instead, we recommend specialized hosting offers, establish contact if necessary, and insist that the customer and hosting service provider sign the contract directly with each other. As a digital agency, we can still take care of the administration and support, and the customer always has everything with them. If there is a change of agency in the future, only the access data is exchanged - the website can stay where it is.
Ticketing system
For us as an agency that has been remote since its inception, the written documentation of tasks in tickets has been enormously important from the very beginning. Over the years, it has proven over and over again how helpful it is to be able to look up old tasks and issues - staff changes, no memory is perfect, why did we do it that way back in the day?
Ticketing systems like Jira have long been common to plan, implement and document tasks. In the past, typical agency customers didn't have a ticket system, so it was obvious that the agency would create a project in the agency's own ticketing system. We also still have existing customers where this is the case. For new projects, however, we recommend a company-owned ticketing system that is completely in the hands of the customer. For example, a Jira instance can be used, which is free of charge for up to 10 users.
Version control
As a Drupal agency we build complex websites, so we are constantly dealing with code. That code should be versioned is something few need to be convinced of. Versioned code contains important details about the project history, ideally you can find out when, by whom and why a certain line of code was written that way.
We have often experienced that only the current code status is handed over to the end customer when the agency changes, so here is the very clear recommendation: the complete versioned code should belong to the customer, for example via a company-owned Github repository. We and many other agencies additionally use ticket IDs of the ticketing system used for their code versioning, so that in addition to a short description of why a line of code exists via the ticket ID in the ticketing system, a new agency can also understand why this line exists. This shows why code history and ticketing system should remain with the customer.
Communication is everything
When looking for a new agency partner, a customer often first reaches a specialized sales team that paints a perfect picture of future cooperation. We often hear of such cases when customers opt for a large agency because of the size of their own company or the scope of the project. Once the contract is agreed, another team comes into play: the development team, which often consists of junior developers who may be located in inconvenient time zones or are often replaced. Specialists like those in the sales team only get to see customers occasionally. The risk is then very high that the project runs over the deadline, budget has to be added several times and yet there is no end in sight.
Such a problem can be solved by getting to know the project team as a customer during the purchasing process or by trying out the collaboration with a small project.
Requirements workshops for testing
It is completely normal to go into a project with great enthusiasm and optimism at the beginning, but with time it can happen that the cooperation does not harmonize so well after all.
That is why we recommend testing the cooperation with a small project. Requirements workshops are a good way to do this: Even if the customers think that the requirements are already absolutely complete and clearly stated, there are still many questions and need for advice. What is developed in a requirements workshop is handed over to the customer in such a way that it can also be used further if the cooperation with us is not continued for any reason.If it is already determined in the requirements workshop that we cannot work together well, the collaboration can be terminated without much pain on either side.
Ten stakeholder in every meeting?
It is not uncommon for initial meetings and workshops to be attended by an unmanageable number of potentially involved people. This drags out discussions and wastes a lot of time: Some participants are only physically present, but immersed in their e-mails. In our view, this is one of the biggest mistakes you can make. For an effective meeting culture, you need a responsible person who gathers all the necessary information before meetings, prepares it, and also does this during the project. We work with the Scrum framework and prefer to call this person Project Owner or Product Owner.
Project Owner
A Project Owner should be able to take the side of the customer and becomes part of the Scrum team. We recommend that this role is taken on the customer side, as this is where the relevant requirements are managed and this guarantees a very close collaboration between the agency and the customer. The Project Owner role pulls the necessary information internally within the company or brings in subject matter experts for one-on-one meetings with the agency team as needed.
Many companies make the mistake of handing over the task of organizing the project to a person who already has a lot of responsibility and does not have the necessary time. However, if the project is to turn out well, this position is a full-time job (which can also be done part-time as long as the person has no other time-consuming responsibilities).
Putting requirements in writing
Requirements change during the course of a project, so you can come to terms with that before you even start. Complex web projects consist of many requirements that are difficult to keep track of. Therefore, it is extremely important to record requirements in writing. At the beginning, this can be kept as simple as possible. For this, we recommend the principle of user stories: "As <role>, I want <goal/desire> to <benefit>".
Mutual sympathy more important than price
A favorable hourly rate may be tempting, but it does not always mean a favorable project progress. On the contrary, if work is slow or customer requirements and wishes are not understood, it will still be expensive.
The likelihood that a project will have a successful outcome, despite all the variables, is much higher if the collaboration is based on mutual sympathy and congruent values. What we consider for ourselves as an agency before each project, we also recommend to the customers to consider: Can we imagine to work out something new in cooperation and to invest many intensive working hours for the project?
Photos by Xavi Cabrera on Unsplash
