Of course, projects always start with the customer's needs - what the business is looking for with the digital solution. Depending on the project and the client's situation, the discussion about the appropriate solution may initially be at a very abstract level, when starting to open up what kind of process is being pursued. The customer may also have a predefined solution idea. However, the need for scalability of certain processes and other corresponding functionality needs may not necessarily be well documented in the finished requirements definition, even if they have already been considered when the specification was drafted, because from the perspective of the drafter they are easily taken for granted.
However, business needs are often much easier to meet and implement when things are considered in terms of business needs, rather than just a ready-made spec. Similarly, in the AI era, there is a move towards the business and code needing to be much closer together as the length of iterations decreases, meaning that any potential mismatch between needs and implementation becomes more of a challenge.
Projects, where the software requirements specifications and design documents are so polished, with pictures, that the programmer is left with no gaps to fill in how the software should work are rare. If software development and maintenance is intermittent, without a continuous design and testing team, the success of the development relies heavily on the developer's understanding. While general knowledge can often get you a long way, the need to understand the business, at least at a basic level, usually arises fairly quickly.
At Fluentia, we always aim and strive to build a comprehensive picture of the problem the customer is facing - what business and personal roles are affected and what moving parts are involved. These may include user numbers and related recurring trends such as working hours. We clarify the idea of what the target state of the project is and how the activities on the customer's site will change as a result of the solution. Which things will be made easier, which parts of the processes will be fully automated, which areas will require more work or attention to enable benefits in other areas.
Other, quite significant issues may also arise in the discussions, which may take the project in a different direction than originally thought. These may include the size of the project. What initially appeared to be a huge development project may work better when broken down into smaller chunks. Without careful discussion and clarification of the business need, the supplier will not be able to evaluate and, if necessary, challenge the way the idea was conceived. This risks blindly going for something that solves the problem but causes problems in, for example, surrounding businesses, and the project may be stretched, for example by retrospectively re-adjusting the whole to the real overall business needs.
Another important issue is to address the functionalities requested by the client and to form a common vision on how to prioritise and sequence them in the project. Again, it is important to dare to challenge the client's plan and suggest alternative activities. Some functionalities should be done before others. Some should be implemented on a smaller scale first and user experience gathered. Some features should be deferred to a later stage to keep the project size and budget within reasonable limits.
As a digital solutions provider and technology partner, it is meaningful also for us that the solutions we produce are genuinely geared towards improving the efficiency and growth of our customers' businesses. Let's act with purpose, as we like to say.
The developers' business knowledge and understanding is not only reflected in better technological implementation, but also in a shared vision of what is being done between the customer and the supplier. This enables the developer to better get to the heart of why certain things are done in a certain way. This may lead to more efficient ways of implementation, which in turn leads to better business processes.
In some configurations, of course, it is enough for the programmer to do only the programming side, and developers with less experience are naturally more dependent on the spec, but in every project the interpretation of the spec into software has to be done. When it's done by a skilled, business-speaking developer, the customer can, at best, get something much better than they originally ordered. A shared long-term vision for the development of business solutions between the customer and the technology partner also provides an excellent framework for a long-term, productive and trusting partnership.
If you're looking for software developers who understand your business and can help you achieve your digital goals, get in touch!
