Welcome to our fourth news blog from Lakeshore Operations GmbH.
We have implemented many software projects in the past few years. Yes, we also made mistakes.
In this blog, we want to list the 7 biggest mistakes of our software projects that we have experienced. These lists are certainly not universal. It rather describes our view and should help you to avoid similar mistakes.
1. Spent too much time for planning the software projects
What is this statement? Too much planning? What nonsense?
In our opinion, there are big mistakes here. For many software projects, we have made intensive plans. We have written many project descriptions. The potential customer has created a corresponding specification for a lot of money. The result was almost always the same.
The information never corresponded to the result of the software. During the implementation, changes and new requirements were added over and over again, which upset the original planning.
In the beginning is the idea of how processes can be automated or shortened. With this idea, however, it is impossible to design a working solution on paper. Here you have to design different solutions and test how the customer responds and then make appropriate adjustments. A complete comprehensive planning is more of a hindrance here, as it was often planned past the customer.
We will certainly go into another blog on how to plan software from our point of view so you get into the implementation faster.
2. Too little communication with the developers
In our opinion, this is one of the main reasons for the failure of software projects.
I remember well a union project that wanted to build a membership database. That’s already many years ago. The union had specified a comprehensive requirements specification.
There was a project meeting every two months where the developer demonstrated his progress. After six months, the programmer gave up. The former level of development was not useful, so it had to start again from scratch.
The example may be very crass. But only if the state of development will be regularly exchanged and the programmer is given a direction for the coming week, he will know what he should do. Only in this way, the temporal progress can really be controlled.
3. Fixed price projects
At this point, certainly the spirits argue.
Fixed price projects are only possible if the requirements have actually been formulated in detail in concrete terms. Since it is hardly possible to describe such a detailed software project in such detail, the contractors will always install extensive safety buffers. If it comes to a change in the course of implementation, it will certainly be more expensive, unless you can exchange functionalities against each other.
Of course we are offering also fix price project, because a lot of our customer asking us. We are now of the opinion that projects that are billed according to actual expenditure, with a fair contractor are overall much cheaper.
4. Test phase planned too short
Many will agree with us on this point. In our estimation, the test phase always takes longer than planned. Until a prototype is permanently transferred to a productive environment, it requires a whole series of tests. In tests, however, failures are rarely considered. Many see the tests only as a formality, where small errors are corrected.
In the test phase, real end users are often involved first, who then come around with other ideas or find that the new process does not work that way. With such a major change, you'll often need major programming and the whole project will take much longer.
5. Programming by Freelancer
Freelancers are a very important component for software developing. They are virtually anytime and meanwhile comfortably engage on the internet.
It becomes problematic when freelancers develop the software completely on their own. What happens if changes are made later or there are bugs in the software? Are the freelancers still available? We've seen several times that a freelancer who wrote software for us just stopped working as a programmer. So, it was completely unclear how it goes on here.
The use of Freelancer is always meaningful, if these are integrated into an existing software team and the support and subsequent developments can be continued seamlessly.
6. Rights of use are not clearly regulated
Copyrights or the rights to use software are always a sensitive issue. It should therefore be clearly regulated beforehand which party has the following rights to the software.
If this is not regulated, the parties will certainly have different opinions in the end. We therefore strongly recommend that every software contract in a paragraph clearly regulates the rights of the individual contracting parties to this software.
7. Missing documentation
Documentation is a tiresome topic. Again, many will agree.
A software system is constantly evolving. Programming will be continued over time by various developers. Without sufficient documentation of the source code, the development can later become a nightmare.
In quality control, a customer should always take a look at the source code even if he does not understand it. The decisive factor here is whether the programmer has adequately documented his own source code.
We're sure to get even closer to our 7 points in future blogs and hope you can avoid similar mistakes as much as possible in the future.
Exciting for you!
The Lakeshore Operations GmbH is a software house, which was founded in 2016 to support companies in the digitization processes. We can draw on more than 20 years of experience. With IT experts from Rostock and Hamburg as well as programmers from Poland, Lakeshore Operations GmbH has a powerful team to support large or small companies in their IT or software projects.
Which way do you want to go?
Have you decided to bring your company up to date with digital progress? Do you want to find the right solutions so that you can shorten your work processes? Then you are exactly right here.
This will enable you to overtake your competitors and secure a place in the market. It is not the big one who eats the little one, but the fast one who eats the slow ones.
We wish you much success!
Jürgen Möller & Gunnar Bock