What makes an IT project successful?

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:

  1. Sometimes the success-criteria are not well specified by the customer. That makes it really hard to achieve them…
  2. 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?
  3. Complexity: The domain, number of involved systems, hardware, technologies, etc. is hard to understand, manage and control.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Bad technical decisions regarding tooling: Wrong IDE, version control system, build management, no wiki to document the goals / terminology / technical decisions / guidelines, etc.
Follow: twitter Share: twitter

JaB – Just another Blog

I am Ingmar.
I have been a professional software engineer now for 12 years.
I read this post and thought, it might be a good idea to have my own personal blog about my experiences…

A few more words about myself: Java is my preferred programming language, that’s what I have been using constantly throughout my career. Being involved in web projects, I have touched JavaScript as well. Visual Basic, C/C++, Ada, Assembler have (luckily) only been part of my student life.

I started off with standard web application development based on Servlets and JSPs, and Taglibs. Later, I helped a project team to refactor their existing web app towards Spring MVC and Freemarker. I did my fair bit of JavaScript, CSS and HTML development when I integrated that application into the SAP Netweaver Portal.

During the web service / SOA hype, I worked with Apache Axis and CXF, JAXB, XML Schema. I touched Complex Event Processing (CEP) during my work for a public funded research project and also worked with JBoss Drools.

Since 2011, I am working for hello2morrow, and we focus on developing tools that help developers and architects to achieve better quality. Sonargraph Architect is a static code analysis tool and can check automatically if the implementation matches the defined target architecture. I extended our SonarQube plugin, created the Jenkins plugin together with a colleague and have been part of the complete re-design resulting in Sonargraph 8.

Sonargraph 8 is an Eclipse RCP app, so I had to learn a lot about Eclipse, SWT and OSGi.
When I am not coding, I present our ideas at conferences (JAX, W-JAX, Jazoon, Devoxx) or different Java User Groups. It is always astonishing, how many people don’t use static code analysis and wonder, why they fall into the complexity trap over and over again. I find it astonishing, because those ideas about modularization, controlling coupling, avoiding cyclic dependencies are 20 years old…

 

 

Follow: twitter Share: twitter