Partnership-based software development should replace project orientation

Preface & the dilemma

It doesn’t seem to make a difference in company or team sizes, the same dilemma usually arises quite early before the planning phase and then carries through to production.

So what to do to successfully move a project through its lifecycle? There doesn’t have to be a dilemma or disagreement. Software development is a very modern thing and modern should also be the mindset of how living software is created for customers.

Requirements wrongly communicated, domains not defined

Basically,?a project starts with an idea for a solution to a problem. Now requirements must be determined for it, so that these can be brought by appropriate technical side in the development department into an implementation form and naturally expenditure in the form of time and costs can be defined.

However, this rarely happens. And this is where the aforementioned dilemma begins. The customer naturally tries to keep costs as low as possible. From his point of view, the software service provider has the necessary competence to calculate and plan the project according to a simple briefing and, of course, to implement it in exactly the same way. The desire to hand over the responsibility to the expert at an early stage is great.

The problem: The software service provider simply does not have this expertise in the domain. It is also not his task to “bring it along”, but that of the person who deals with it in everyday life and already understands the problem.

“That’s why I have my service provider,“ or “That was discussed sufficiently on the phone,“ or “That wasn’t in the requirements, and we didn’t implement it either,“ are just a few negative examples of the lack of knowledge transfer and the friction points that arise before and during a project.

Definition of domains

For every project at least one domain prevails and that is the domain of the customer. The domain, often also called the business domain, fundamentally defines the requirements for the future solution. This includes user stories, technical terms and all sensitivities around the company or field of activity. This is also the part of the requirement that the customer can easily prepare in detail.?The important thing: The customer should not get technical, but stay in his domain and his thinking and explain the problem exactly as the customer and all his colleagues would understand it.?In this process, user stories are created that describe certain processes from the perspective of the later users.

The service provider should think his way into these user stories and understand them as an employee would. Under no circumstances should he fundamentally question these processes, because there are usually reasons why the processes were designed in this way. With the understanding gained, the software service provider can then begin its actual work - planning how the aforementioned user stories can be technically mapped. At this point, well-placed, value-added ideas by developers are welcome. At this point, the added value for the customer begins to emerge, as his processes can be represented more efficiently from a technical point of view than was traditionally possible.

Working together from the start and staying agile

The customer does not have that many options for simply presenting a complex topic from his domain to an external service provider. Although internal IT staff often take part in this planning process to provide support, it becomes clear time and again that this is where worlds collide.

It takes time. The solution is not to spend a lot of money and time on a requirements specification,?only to realize during development that you couldn’t think that far ahead in a live process. At the end of the project you will find that the solution deviates from the basic idea at the beginning and that is part of the process.

It is important to always be aware of what the requirements or user stories from the customer domain are and to evaluate and realign them at regular intervals, recurrently. The customer must be a part of the process during the entire development time and not the recipient of a “finished” solution at the end of a long period of time. The chance that the negative delta between delivery and expectation is painfully large is unfortunately too real. A development process takes place between at least two parties and should be considered as a joint working effort. Important: Neither customer nor service provider are “guests” in a project.

The chance that the negative delta between delivery and expectation is painfully large is unfortunately too real

Respond agilely to change

It often happens that analog processes from everyday life have to be digitized. Often, it is only during the project that it becomes clear that digital processes work in a fundamentally different way and that the user story needs to be rethought together.

Agile methods are excellent for keeping all participants up to date and including them in the interim results. Thus, every participant becomes aware of changes and the entire team is able to evaluate whether they are on the right track or whether changes in direction need to be made.

How do agile methods and classic fixed project planning fit together?

Not at all, they even repel each other and it is a guarantee for unnecessary dissatisfaction at the end of the project. To deliver a solution to satisfaction, the understanding of the process of “delivery” should be clarified first. A solution is not delivered.?The solution is introduced and continued in a living process that brings updates, features and fixes on a regular basis. A solution is created and implemented within the customer’s domain. Accordingly, the solution also participates in or is the basis of everyday life in many processes. We are not talking about a “one-time project”, but a living, growing software.

A solution is not delivered. The solution is introduced and continued in a living process.

And this is absolutely fundamental and should be clear to customers and service providers. Any form of fixed budgets in a project, be it the schedule or the financial resources, only gives the illusion of planning security. In this model, little is communicated and exchanged between the implementing and expecting parties during the development phase. The resulting pressure towards the end of the project can have fatal consequences for the solution.

Why does pressure arise with a fixed budget?

Even well-developed user stories harbor the potential for unforeseen problems. What if a problem can’t be solved the way it was thought? Or simply the visual idea of the solution was different on both sides. Deviations from the basic idea can arise very quickly.

Agile thinking is again important here. A basic idea, i.e. the customer’s requirement, is allowed to adapt during the course of the project.

It is recommended to keep the feedback loops as short and as frequent as possible.?The goal must be that participants are aware of the progress and the problems and can therefore also consciously intervene in a controlling manner. It is advisable to provide a usable “staging version” of the solution early on and to update it regularly so that the customer can compare his idea of the software with the actual state at an early stage.

The focus should always be on the best result, paving the way to it.?None of the participants knows at the beginning what the end will look like. The customer is an expert in his domain and the service provider is an expert in the technical implementation - but neither of them is a clairvoyant.

It is advisable to provide a usable “stage version” of the solution at an early stage and to update it regularly, so that the customer can compare his idea of the software with the actual state at an early stage.

A basic idea, i.e. the customer’s requirement, is allowed to adapt during the course of the project.

Partnership instead of demands

I recommend with conviction that?trust should be the top priority?in a joint project. If you go together as partners the way up to the finished solution and then together further, this represents a responsible task from the first day of the project. It is not about foreseeing as much as possible and packing it into a fixed framework, but it is about creating a framework for upcoming challenges and mastering them together. Problems are then not those of one or the other, but common problems that need to be solved.

Customer and service provider have a vision before the project and both should be able to identify with the solution from day one. Changes that arise during the project must be financially supported by the customer, because they are changes in the requirement for his solution. When this framework is created, the service provider must also confirm this trust and accordingly responsibly and committedly strive for the goal of qualitative completion. It must not be less then.

Conclusion

This is how a greenfield domain-driven solution with just an idea at the beginning can come to life after a longer development period. And only in this way can this solution later really solve the original problem and create additional added value.

Blame games, renegotiations or missed requirements should not be planned into a project from the beginning, but should give way to shared accountability and agile teamwork.

Don’t you agree?