“First of all, the schedule comes from above. The timetable was not realistic in the first place. We’re trying to do this with undue haste. They don’t even try to find out in advance whether it’s realistic or not.”
The answer to the question in the title comes from deep within. Markku Pietilähas been in the software industry since 1987. Thirty years. His career began as an application advisor, after which Markku has held programming and planning positions in the financial sector and the Tax Administration, among others. For the past ten years, he has worked as an integration expert and architect.
“I plan, document and implement solutions, and coding is not too unfamiliar either.”
Defining and testing a software project – don’t compromise on these
Often, the software project goes wrong before it has even properly started. An impossible timetable is followed by a vague description of what is expected to get done in that time. In other words, the definition falls short.
“It’s a bad starting point, if an employee doesn’t know what the customer wants.”
It takes time to define a project, and it must be done properly, especially if the software projects are ordered from an external supplier who is unfamiliar with the customer’s business. According to Markku, this has not always been the case.
“I remember a time when coders and designers could be part of the business unit. There was no need to draw definite lines because the coders knew about the business, the people doing the business knew a little about technology, and everyone talked to each other. It is a different situation now.”
In addition to defining a project, another critical point is at the end of the project. Too often, semi-finished software is released into the world. This saves time and money during the testing phase, and the money is then spent fixing the messes after the launch.
We all know that it gets expensive when the systems do not work. Proper testing can reveal issues in time.
Currently, it is the tester’s market and testing is expensive. However, it would be worth the investment. We all know that it gets expensive when the systems do not work. Proper testing can reveal issues in time.
Don’t get too focused on the processes, remember integration
Unfortunately, the integration of systems is often not taken into account at the beginning of the project and is left to the last second. Markku remembers a project where they had to separately renew several different systems without knowing how to integrate them. He has also witnessed projects where the main focus is on Excel files and process flow charts, and the product and objective are forgotten altogether.
“Often, processes take precedence over the solution. We start thinking that if we follow the processes, everything will be fine. We’re left satisfied after following the process, but we haven’t actually understood what to do within the process.”
In a software project, the wise one is the one who asks stupid questions
Let’s stop complaining. How do you save the world from catastrophic software projects? Budget, timetable, definition – what should be done better?
“You need to ask stupid questions and find the people to answer them.”
The buyer does not need to understand the technology in depth. Instead, in addition to management, decision-making should involve a project worker who understands both technology and something about business.
Markku assures us that the buyer does not need to understand the technology in depth. Instead, in addition to management, decision-making should involve a project worker who understands both technology and something about business.
These things happen in every field of business: projects where budgets are doubled and tripled, and schedules are being stretched. Users are expressing unhappiness and news sites are sure to take advantage. Removing one single problem could solve all others.
“The biggest obstacle is money. If there is no money, something is always left undone.”