10 Signs When Projects Are Doomed to Failure
10 Signs When Projects Are Doomed to Failure
Is your agile project in danger of failing? These signs could indicate that it is, like team members discussing the poor project state, and minimal project progress.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
Are you working on a project, that runs badly? Have you ever asked yourself if your project is doomed to failure? In this blog, I will list 10 signs, that may help you to find out.
Let me quickly tell you, who I am: I am working as an IT freelancer/consultant in the area of Java(TM) Enterprise Applications since 2000 and I must admit, that besides some successful projects, I also had to experience a few project failures. From that experience, I proclaim that it would have been possible for the decision makers to save a lot of money by stopping/restarting the projects earlier – they just should have been more aware of the signs themselves or they should not have been ignoring them for a too long time. Anyway, I would like to share my personal experiences in this area and of course I am interested in feedback about similar situations, that you have been going through…
Sign 1: The team members are talking way too much about the bad state of the project or private things instead of working on their tasks.
Obvious reason for this sign is demotivation. Common reasons for demotivation are:
- the bad state of project itself
- their boss / project leader doesn’t take their worries and advices seriously
- or the boss does recognize the advices, but he is afraid of communicating them further to his superior.
Sign 2: The progress of the project is only minimal over a significant period of time.
There can be many reasons for this sign. In one project, we had the problem, that the business analysts were not able to provide enough concise requirements to keep the developers busy. Their main problems were, that either the analysis took too long or that the decision makers were not making their decisions fast enough. Another problem we once had was that the team members had to do too many administrative tasks like reporting or attending working groups in which the process should be optimized.
But even worse, such administrative improvements are absolutely no guarantee, that the project can really be saved. The key point is, that the administrative stuff might only be a side issue but it is not necessarily the main one: Thus it is crucial to reveal, name and tackle the realproblems of the project. These might be technical problems concerning the general architecture or some special sub-components of the system. Or it might be the way, how business requirements are specified and handed over to the IT, or even a mixture of both. But anyway, if the project leaders do not (want to) see or tackle the real problems – maybe because of political issues – then your project is in real danger!
Sign 3: Your “common sense” tells you, that this project can never be completed in a way that fulfills the customer’s expectations.
Assuming you and your colleagues are not complete newcomers and that you do at least have a few years of experience within IT-Projects, ask your “common sense”. Consider all the problems that your project is facing, ask what would REALLY have to be done to solve these problems. Finally ask, if you believe, that the management will really accept all these changes. If the answer is no, this sign clearly applies to your project, especially if most of your colleagues come to the same result!
Sign 4: There is too much politics involved in the project
One problem might be, that there are stakeholders from different departments pursuing different goals. This can either lead to delayed important decisions or that bad compromises are being made. These bad compromises can in turn lead to more complex requirements and even bad architecture (“architecture driven by management”).
Another frequent and important issue is when departments play the “who raises the red flag first” game. Then the concerned project leaders don’t communicate the real state of their project part to the management over a longer period of time. Such “sugarcoating” information is a high risk, especially if the situation doesn’t improve or even gets worse. This will inevitably lead to a point in time, where all the facts will come up at same time – causing a “Big-Bang” – and the extreme danger, that the management will be too angry and/or shocked to let the project continue.
Sign 5: An external consultant in a central role pursuits his own or his company’s interests more than the customer’s interests.
Sign 6: An external consultant in a central role is a “dazzler” (in german: “Blender”)
Such consultants have an extremely convincing appearance – they could sell you almost anything! But team members often have a good feeling, if this appearance is really backed by solid knowledge. If not – and the project leader doesn’t recognize (or want to recognize) this early enough – that consultant can lead the project into a disaster.
Sign 7: The production date has already been postponed more than once and you still cannot determine a realistic new final date.
Sign 8: (Technical): The team(s) develop(s) a generic system but especially the customization / configuration is so complex, that it won’t be maintainable once it is in production.
Sign 9: (Technical): The performance of the system is unacceptable when caching is turned off.
In one of my projects, the performance of the backend was so poor, that the application was unusable – even if there was only one single user on it. One main reason for the poor performance was that too many separate SQL queries were sent to the database in one single frontend request (because no sql-joins were used – yes. I was shocked, too!). Instead of repairing the obvious mistakes in the ER-Model and the SQL queries, the responsible team decided to start using caches. The caches solved the problem partly, at least when the caches were filled after the initial frontend requests. But nevertheless, those initial requests were unacceptably slow. The conclusion is, that poor design – no matter in which layer – will remain a latent risk for the whole project.
Sign 10: The software development process was chaotic from the very beginning and it was not possible to introduce a standard process in the meantime.
One aspect of this is, that developers got hired too early and thus they needed to start implementing – although not even a minimum of requirements engineering was done beforehand. So the team started to develop something, that they guessed what might approximately be what business may need. Project leaders seem to tend to call this an “agile” approach, but of course this is at least a huge misunderstanding of “agile software development.”
Another aspect might be, that if several teams are involved, there are no common code quality guidelines and so code quality and quality assurance happens by accident (or not at all). If this problem cannot be solved by the project leaders very soon and the coverage of automated tests remains low throughout the whole development phase, the need for manual testing will rise so high, that it overtakes the potential efforts for the automated tests by far.
Well, maybe you find more signs, but I think, if most of these signs apply to your project, you should be prepared, that the “judgement day” will come – sooner or later. Good luck!
Published at DZone with permission of Stephan Bauer , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.