Why is it (not) good to learn?
- Have more questions?
April 11, 2023
There are many different ways to plan a project, but for me there is only one approach that really works.
When we embark on a project, we usually do it because we want to achieve something nicer, better, more efficient, more convenient. We long for a state beyond the present and believe that we are willing to make serious sacrifices to achieve it. We even take risks.
Usually, as long as the "project" is at the level of desires, i.e. choosing what colour to make the website, what font to use and similar tasks, everything goes well. The client puts out a tender or announces a kickoff meeting and chooses from the best bids. The atmosphere is good, the person who wants to sell is nice, attentive, promises everything. The price is accordingly high, but believe me, it's worth it.
And the customer usually believes that the project was worth the effort, feeling good about the promises made and the quality of the demo applications presented. The price is included in the budget, and the organisation expects everything to get better.
As the project moves forward, the need to bring the solution closer to reality becomes more pressing. How to connect to system x, how to solve in out-of-the-box software what we don't do the way we do it. Of course everything can be modified, it's just a matter of time and money. However, customisation is difficult and phrases like "we didn't think what you thought" are becoming more and more common.
The clouds are gathering, meetings are getting tenser, and money and time are running out.
The client was not clear about exactly what he wanted, just as the supplier could not foresee whether his solution, his method, would solve the problem that led to the project.
Both parties wanted something, but as the project progresses, they only hope, and later they are left with disappointment.
Of course, the easiest thing to do at this point is to find the person responsible, to get the contract, the minutes, the emails, but if you get this far, your chances of a successful project are minimal.
Let everything be precisely written down and formulated, is the obvious answer. But for a number of reasons, this never happens. It is probably never expected.
Let's look at how starting a project in a "data-driven" way can help with application development.
The essence of data-driven application development is that it does not start from desires and possibilities, but from actual processes and data.
So the target is not set using imaginary or visualised demos, but based on an accurate understanding of how you are currently working.
For a more complex task, it helps to have a plan, to know a ready-made system and to buy the right external skills. However, without knowing exactly how your organisation, software and processes work, you will never know exactly what you need.
And nothing gives a more accurate picture of our current operations than our data.
The reverse is also true, nothing will define our future operations more than the structure of the data in our new system.
All this may sound strange to a decision maker and the average employee may only perceive their job as pressing a button, organising a meeting, sending an email, entering a transaction into the central system or inserting a row into an excel sheet.
Every process, every event generates data somewhere. And the data is linked to an actor in the process. The problem is that we expect the unification of processes - which necessarily means putting the data into a common database - from a ready-made solution that does everything, has very nice reports and preferably has built-in artificial intelligence.
If you prepare your development or project plan in a data-driven way, there is no risk that there will be no room for any of the data. If there is room for all the data, it is not possible for a process to be left out of the design. And if all processes have been taken into account, there will be no stakeholder who will not benefit from the results of the project.
Let's assume that we keep a record of our receivables in an excel sheet. The statuses are indicated by different colours, the amounts by numbers and the corresponding notes. How does it look like to translate such a not too complicated business process into a software?
An obvious solution seems to be to buy a ready-made "receivables management" software. The project has a beginning and an end, the cost is predictable and because it is ready, we can start using it almost immediately.
However, it may have too many features or too few. All users have to register, colleagues have to remember a password for multiple systems, while suppliers and invoices issued have to be re-recorded.
Another alternative is custom development.
Usually, the problem starts when we start drawing screenshots. Where to put buttons, controls, what menu system, icons to use? Of course, the data will have to be put somewhere, but the programmer will create a table or two.
For example, if the number of invoices issued is made unique at the data model level, it is never possible to start several recovery processes for the same invoice in the system. Even if the program interface allows it, by programmer error.
If in the data model the invoices and the collection events are placed in separate tables and there are several links between them, then the interactions with the customer will certainly not be placed in a comment field, but the recording interface will be structured historically like a list and the whole process will be easily traceable.
The examples could go on and on about what data-driven application development can determine and how drastically it can reduce the risk of mismatch between software and the real process. However it is very easy to produce even complex reports from a well-built data model.
Sharing:
Book an appointment for a free 30-minute consultation, where we will give you a deeper insight into how we can create a customized integrated system for you in less than 10 weeks!
© 2023 Enrol Consulting Kft. All rights reserved.
EN 
HU