Software projects not only need engagement from a development team, but also from the client. A client should be ready to devote his time for planning, analyzing and discussing the product roadmap. Let’s see, what kind of engagement on the client’s side is needed to run a successful application development process.
Hiring a development team
A client should take time to hammer out many of the aspects of a product before the project starts. First of all, he has to look for a good software provider. If he doesn’t have any internal programming resources already, he needs to spend some time looking for the right provider. He probably browses the internet and searches his own network asking colleagues for recommendations. Finding the best delivery partner can be time-consuming and needs a lot of effort. And that’s only the first step.
Legalities and a product brief
Once you’ve found a perfect development partner, the next step is to hammer out all the legalities and sign a contract. It also needs an effort on the client’s site. You need to determine the project scope, define the application’s features, and describe the expected result. There are some materials, description, and briefs to be prepared to get an accurate cost estimate and to allow the IT team to understand how the application should work and what features it must cover.
“In Espeo, we know exactly what information is needed to get a full understanding of our client’s goals and business needs” said software consulting director Dominik Zyskowski. “The most important thing is the vision of the project and the features that the application must address. We must very clearly understand what goals the application should bring for its end users,” he added.
Defining application scope and estimate
Clients describe their vision in many different ways. Some of them compare their idea to some tools that already exist on the market and have similar features. “It’s very common for clients to say, ‘I would like to build an app similar to X.’ For us, it’s a nice way to get the first feeling of a solution that is to be built. In the second stage, we ask additional questions to get a more detailed understanding of an idea and its full range,” said Zyskowski.
Some clients already have examples of the mock-ups or even sketches of their preliminary idea. They prepare information about the business value and show how it should be supported by the future product.
It is very helpful for both sites to agree on as much detail as possible before a project start. But without a technology background and project experience, it’s not easy for many clients to define the detailed product vision. We can easily understand that. That’s why we offer our clients Product Design Workshops as the first step of work on the application. Such workshops clarify all product details in its technology and business aspects. We advise on features to be chosen for an MVP, define usability that meets target groups needs, and prepare an application prototype which very often is necessary to convince investors/sponsors to support a project.
“We spend a few days together discussing the vision of the project about the features of some use cases about the business itself. So there is a moment in which the client should teach us about his vision should convey to us as much information as possible here in order for us to understand the project and to estimate it.” said Dominik. “So that’s a lot of effort and our clients really need to allocate some time to determine all the details and the common point of view relevant the product and its vision.”
“We need to ask a lot of questions to digest the information that we learned and come back with followup questions. We engage clients in this somewhat intensive process. While it sometimes takes quite a long time, the finished product will be sound. In order to get professional service, you’ll have to set aside time to get everything right.” Dominik explained.
Once you decide on taking the product design workshop, here’s what you should expect. So, in case of meeting with one person which represents the whole company, he should be well prepared. He must have knowledge both from the business and technology side. It is really important if the person is meeting us only alone in person or if it’s a kind of company project where there are more stakeholders.
Understanding all sides of the project and achieving all the knowledge needed could be very time-consuming. “The whole team needs to meet together in the same room for a few hours, clearly defining the future product functionality cannot be overestimated,” Dominik noted.
Product owner role
We work in scrum methodology, so we have to choose a person who will be responsible for the whole project. Usually, we do not allocate the product owner on our side. Dominik said, “Scrum assumes that there is a development team, but there is also a role of a product owner who is in charge of deciding which features are in the system.” He has to have almost absolute knowledge about the product and answer any questions about how the features should be implemented and what it should do. The product owner is able to respond to all questions about product, system and also business background,” Dominik said “It is better for the clients to have a person on their side who has a very strong industry background and great understanding of client’s business niche. Working as a delivery team we can perfectly recommend on technology, UX and many other aspects but at the beginning, we need to acquire the domain knowledge from client’s business.”
A Product owner must answer questions that arise even several times a day. He needs to respond quickly enough not to block our work. In order to avoid sending a single question, we organize so-called backlog groomings or backlog refinements. These are meetings where the goal is to explain the backlog to the team and discuss with the development team all the upcoming tasks trying to find out all these questions before we start the implementation of a given feature. This kind of meeting usually lasts much longer at the beginning of the project and then we keep these meetings regularly every week or every two weeks depends on the length of the sprint just to refine the next stories on the list. This way can be on the right track with all client’s needs with the minimum effort from the client’s side to run the project on time and budget.
“The great example here is our project for The Guardian. The company has a dedicated business owner on its side who takes care of the business – the roadmap for the system in terms of business discusses with us about priorities and features. All the process is led by Slack – both sites are this way very responsive and the communication is smooth and quick. We run together planning sessions and so-called groomings to set up what should be done in the next sprints,” said Dominik.
Client’s engagement as a success factor
Of course, there are clients who do not want to engage so much in the project. They just want to write down specification then want the software provider to learn and understand their business enough to ask all the questions that appear during the development process.
“We try to discourage clients from that kind of approach, but if there is still a need on client’s side to pass us product owner role, we try to adjust and prepare for the role as much as we can. Then we only need a contact person on the company’s side to decide about the next step of the project,” said Dominik. This kind of project management is exposed to some risk as our product owner though best preparations cannot always understand full business context.
That is why we always try to encourage our clients to consider this team spirit type of arrangement and be ready for some serious involvement on their site.