I have worked in a number of projects in the last couple of years, unfortunately I only consider a few of them successful… First of all, what means „successful“?
My definition is: „The project has been completed on time and budget and the customer is happy with the result.“
There are methodic, organizational, technical and social reasons for failures. Here are my 10 favorites:
- Sometimes the success-criteria are not well specified by the customer. That makes it really hard to achieve them…
- Most projects are not off-the-shelf: There are new technologies that need to be mastered, the use cases are not yet clear, the team members have never worked together in the same constellation before. How can you meet deadlines and budget constraints if you don’t have a solid reference for your estimations?
- Complexity: The domain, number of involved systems, hardware, technologies, etc. is hard to understand, manage and control.
- Even with solid planning and a lot of requirements engineering, the customer might figure out half-time that the priorities changed and other use cases need to be implemented. That obviously makes the initial estimations obsolete. It is unlikely that the initial budget will be sufficient.
- Agile methodologies to the rescue? Also short release cycles and quick customer feedback don’t guarantee the correct outcome, if there is no solid roadmap and no frequent adjustment of the goals. I often have the feeling that „agile“ is mis-understood as „no process“, „no planning“, „just coding“. But if done right, it has the same stages as old-school waterfall, just more iterations to align frequently with the customer.
- Project management is no picnic. As a project manager you need good nerves and excellent communication skills to control the egos of the team members. Software engineers are not famous for being socializing experts. Creating a productive atmosphere of joy and energy is essential.
- Software engineers like „toys“ aka new technologies. If there is a new framework that sounds promising, it has to be integrated into the project. Many times, there is no solid evaluation process. If there is no honest answer to the questions „How does the project / product benefits from technology X?“, „What are the other two best alternatives?“, don’t use it.
- Quality is not a defined goal, speed of development has top priority. But if no time is spent to refactor and restructure code, to remove duplication, etc, the speed of development will sooner than later slow down considerably.
- No architecture management resulting in a lack of modularization. If dependencies within the software are not controlled the project will most probably end up in the big ball of mud. If you then discover that a framework is not as promising as it seemed, you cannot easily ditch it, because of all the references to it.
- Bad technical decisions regarding tooling: Wrong IDE, version control system, build management, no wiki to document the goals / terminology / technical decisions / guidelines, etc.