Previously, we have written posts about how clients ensure successful web projects. In short, failed web projects can be avoided through proper preparation, you can read more about this here.
But sometimes you find yourself in projects that do not go as expected, then it is important to know what can be done about the problems that have arisen. In this post, we discuss the biggest and most common problems that can arise during web projects and how these problems can be solved.
There are usually two reasons why web projects fail. One is that the scope grows, which is called scope creep, while the other is recurring delays. Mostly it is a combination of both that makes web projects delayed and more expensive than expected.
Here below we discuss these two problems and their solutions.
Problem: Scope creep
Scope creep is a common problem in web projects, which means that the scope of the project becomes larger than expected during the course of the project. Usually this is because the requirements specification is not detailed enough from the start. Instead of writing a detailed requirements specification, only the intended web solution has been formulated through general explanations.
It is common to expect that details can be specified during the course of the project. Which results in suppliers underestimating the scope of the project and thus falling short of the original estimate. Of course, not all the small details can be determined before the project starts, but most of it should be specified and anchored even before development begins.
But what solutions are there if the project has already started and the scope is growing?
Solution
Take control of the project by specifying the interface as well as every function and other details together with the supplier. It is important to also specify non-functional requirements such as performance, security and technical search optimization. Download our white paper and learn more about which non-functional requirements are important – här.
In addition, it is important to ensure that everything is documented, that the supplier has read this documentation and that you agree on what is to be done. A new schedule with clear milestones and deadlines is then requested. The new structure and schedule will hopefully mean that the remaining time of the project will not result in any more surprises.
At this stage, it is also important to discuss the chosen web technology. This is because changes in the requirements specification can also mean that the basic structure of the web solution changes. A website can become a web system and vice versa, which can lead to the chosen web technology no longer fitting the web solution and therefore being incorrect.
Keep your fingers crossed that this is not the case as this can involve rebuilding, which can result in both more expensive and delayed web projects. However, there is a fairly small risk of this since major changes to the requirements specification are required for it to be that wrong.
Problem: Recurring delays
The second common problem that can arise during web projects is recurring delays. Usually they are related to previous problems, that is, the requirements specification is not detailed enough. However, it is of course possible that there is a clear requirements specification and that delays occur despite this.
Delays will happen, but if delays occur repeatedly, this should be seen as a warning sign. At this stage, you should question what the delays are due to. If they are due to illness or an optimistic supplier, it is positive, while if it is due to difficulties in the development work, there are significantly bigger problems.
Solution
If the recurring delays are due to suppliers missing milestones and deadlines, the supplier most likely has an incorrect time estimate. This is due to various reasons, for example, that the developers are not experienced enough and therefore keep a low pace or cannot estimate work.
Generally it is a combination of these two and in such cases it is important to take the supplier’s estimate into account. Then try to calculate how long deliveries have taken in the past in comparison to the supplier’s estimate, then take this into account in future schedules. If the delays are due to the supplier’s lack of competence, you should of course never pay more than agreed.
When developing web systems, what we in the industry call “coding in circles” sometimes happens. This means that the web system has bugs and when you solve one bug, another one appears. This becomes a negative spiral, bugs will continue to be discovered and only increase in number. If this happens, you have a bigger problem, because it is a sign that the source code is messy. In some cases, this can mean that the source code has to be scrapped and reworked, which is of course never desirable.
If you suspect that the source code is messy and may need to be scrapped, it is best to have another party review the source code. It is then important that the original supplier shares the source code, however, you can expect that they may be contradictory.
After the review, you should get an idea of what can be saved and what needs to be rebuilt. In this phase, we also recommend ending the project with the deficient supplier, however, source code that can be reused should always be saved.
At the same time, it is important to be patient before deciding to involve a new party to review the code. Remember that it is common for web systems to have many bugs during ongoing work. But if you clearly notice that several old bugs are recurring and the vendor is not meeting deadlines, then it is probably due to poor source code.
Summary
In summary, there are two common problems that arise during web projects. One is scope creep, which means that a project becomes larger than expected due to an insufficient requirement specification. While the other is recurring delays, which can be due to various reasons such as an optimistic vendor, inexperienced developers, or an incorrect time estimate.
If scope creep occurs in your project, it can usually be resolved by taking control of the project. You can do this by specifying the interface as well as every function and other details together with the vendor. In addition, the choice of technology should be discussed at this stage, as changes in the requirements specification may also mean that the basic structure of the web solution changes.
The problem of recurring delays can be connected to other problems such as scope creep or changes in the requirements specification. In such cases, it is always important to take into account the supplier’s time estimate. However, if recurring delays continue to occur, there is a risk that the original source code is messy and needs to be reworked. In such a case, the source code must be reviewed by an external party.