There are many different methods for planning a project, but for me there is only one approach that has truly proven itself.
We usually start a project because we want to achieve something nicer, better, more efficient, more convenient. We desire a state that goes beyond the current one, and we believe that for the sake of the desired goal we are willing to make serious sacrifices. We may even take on risks.
Usually, as long as the "project" stays at the level of wishes — that is, choosing what color the website should be, what font to use, and similar tasks — everything goes well. The client issues the tender or announces the kickoff meeting and chooses among the ever more beautiful offers. The mood is good; whoever wants to sell is kind, attentive, promises everything. Accordingly, the price is also quite high, but let's believe it, it's worth it.
And the client usually does believe that it was worth starting the project; they feel good about all the promises and the quality of the demo applications shown. The price is inserted into the budget, and the organization waits for everything to suddenly get better.
As the project progresses, the pressure grows for the solution to move closer to reality. How do we connect to system X, how do we solve in the off-the-shelf software something that we don't normally do that way. Of course, anything can be modified, it's only a matter of time and money. At the same time, customization is hard, and sentences like "that's not what we meant, that's not what you meant" become more and more frequent.
Clouds gather, meetings become more and more tense, and money and time keep running out.
The client did not know exactly what they wanted, just as the vendor did not foresee whether their solution, their method, would actually solve the problem the project was created for.
Both parties wanted something, but as the project progressed they were left only hoping, and later only with disappointment.
Of course at this point it is easiest to look for someone to blame, to bring out the contract, the minutes, the emails, but if we get to this stage, our chances of the project closing successfully are already minimal.
How should the project have started?
Let everything be written down and formulated precisely, sounds like the obvious answer. But for a number of reasons this never happens. It probably cannot even be expected.
- I usually say that at the start of every project we should already have all the information that we will only actually have by the end.
So what could be the solution, how do we do it?
Let's see how it can help in application development if we start the project in a "data-driven" way.
The essence of data-driven application development is that it does not start from wishes or possibilities, but from the current processes and data.
So we do not define the intended goal with the help of imagined or visually presented demos, but based on precise knowledge of how we currently operate.
For a more complex task, it helps a lot to prepare a plan, to get to know an existing system, to purchase appropriate external expertise. At the same time, without precise knowledge of how our organization, our software, our processes operate, we will never know exactly what is actually needed.
Nothing gives a more accurate picture of our current operations than our data.
The reverse is equally true: nothing will determine our future operations better than the structure of the data in our new system.
All this may sound strange to a decision-maker, and even the average employee only perceives, during their work, that they press a button, organize a meeting, send an email, enter a transaction into the central system, or insert a row into an Excel table.
Every process, every event generates data somewhere. And the data is tied to some participant in the process. The problem is that we expect the unification of processes — which necessarily also means channeling the data into a shared database — from a ready-made solution that supposedly knows everything, has very nice reports, and preferably has built-in artificial intelligence.
If we prepare the development plan, the project plan, in a data-driven way, then it cannot happen that some piece of data has nowhere to go. If every piece of data has a place, then it also cannot happen that some process is left out during planning. And if we have taken every process into account, there will be no participant who does not benefit from the results of the project.
Data-driven application development, therefore, starts with the precise mapping of our current data, processes and systems, and does not allow for any piece of data to be left out of consideration.
Suppose we keep track of our receivables in an Excel table. We mark the statuses with different colors, the amounts with numbers, and attach comments to them. What does it look like to transfer such a not-too-complicated business process into software?
The obvious solution seems to be to buy a ready-made "receivables management" piece of software. The project has a beginning and an end, the cost is easy to calculate, and since it is ready-made, we can start using it almost immediately.
At the same time, it may have too many features, or too few. Every user has to be registered, colleagues have to remember yet another separate password for yet another system, while our suppliers and issued invoices also have to be re-entered.
The other alternative is custom development.
The problem usually starts when we begin drawing screen designs. Where should the buttons and controls go, what menu system and icons should we use? Of course the data also has to go somewhere, but the programmer will create a table or two.
However, the following questions are not decided in the interface design:
- Which piece of data is mandatory?
- What type and length should each piece of data be?
- Which piece of data is unique?
- Which piece of data is the primary identifier of a record?
- Which pieces of data are foreign keys, i.e., strictly elements of a parameter table?
- What relationship exists in our case between the receivable, the supplier, the collector, the events created during the collection process, and the payments?
In data-driven application development, answering the above questions takes absolute priority. At the same time, it is interesting to observe that data determines not only the structure and operation of the interfaces, but — much more importantly — the process itself.
For example, if at the data model level we make the number of issued invoices unique, it will never be possible in the system to start more than one collection process for the same invoice. Not even if the program's interface — due to a programmer's mistake — allows it.
If in the data model the invoices and the collection events are placed in separate tables with a one-to-many relationship between them, then the interactions with the customer certainly won't end up in a single comment field; instead, the recording interface will be built historically, as a list, and the entire process will become easy to trace back.
The examples could go on and on — how much data-driven application development determines, and how drastically it reduces the risk of discrepancy between the software and the actual process. At the same time, from a well-built data model it is very easy to create even complex reports.
