Team members involved in hopeless projects become dejected, stressed, and overworked. Are there any silver linings to working on a doomed project? This article argues that there are. When you and your teammates are stretched to your limits, you can learn a lot about each other, your managers, and what it takes to make a successful product.
The exciting book Death March by Edward Yourdon shows the main issues that can lead a project to a hopeless state. In spite of obvious and predictable mistakes, we still hear about many hopeless projects, agile or not. People involved in such projects cannot enjoy their work and project teams despair. Are there any advantages to being on a hopeless team? I believe there are.
So let me share with you a story about my experience being a member of a hopeless project team and the advantages of this situation.
During two years our project met almost all problems described in Death March and made its way from “Mission Impossible” to “Ugly” (counterclockwise).
Stage “Mission Impossible” (belief in the team power and in reaching impossible goals in the name of the team and the company): Our team was developing a very interesting and extreme e-commerce project. The team could bear all management whims and believed in the great future of the project.
This phase lasted for about six months until the date of “The Great Release,” when we had to deliver a new, redesigned version of the software. The whole team worked without any rest during a one-month sprint and we finished the release with a difficult night update. That night about eighty bugs were fixed and verified by six teammates, developers and testers. We felt as if we had reached the top of a huge mountain, but it cost a piece of overall enthusiasm.
Stage “Kamikaze” (everyone understands that failure is inevitable but the project is worth it to participate): After a retrospective glance at “The Great Release,” the first results of inaccurate planning became visible to the team. One by one, people became more pessimistic but continued to work hard. In spite of previous unsuccessful (quality-wise) releases, top managers kept on creating impossible deadlines and vague requirements and asking us to work overtime. But we made a mistake and mutely accepted the situation, and overtime became a normal situation. It lasted almost a year.
Stage “Suicide” (no chance of success for the project, the team feels miserable and has no inspiration to work): After a period of endless overtime work, the project team was involved in the development of a super urgent subproject. The timeline was unreal: only several weeks for development process, including deployment and quality assurance. Every member of the team knew the product would not be delivered on time. We expressed our fears about the incredibly short period of development phase, but managers pretended to be deaf.
Stage “Ugly” (manager tries to reach the project goals by sacrificing professional and personal interests of the team members): Of course, the team missed the deadline. In addition to the fact that our inspiration had absolutely run out, the super urgent subproject did not achieve commercial success. We continued to work under pressing deadlines and a growing number of tasks that had not been appropriately estimated by the team due to lack of time and unclear requirements. Managers did not try to cheer us up. They asked us to release something that would be called “a new version,” but we could only deliver something that looked like a trash can full of unpleasant defects.
Turning from subjective impressions to objective facts, the following characteristics of the project stages should be mentioned:
- Mission Impossible:Stand-up meetings are regular but not very productive. Not all team members understand the principles of agile methodology. People are ready to participate in retrospective meetings and discuss positive and negative moments of development process.
- Kamikaze:Stand-up meetings are too long (up to thirty minutes). Not all people are involved in active discussion. Therefore, the ScrumMaster and the project team make a decision to hold separate stand-up meetings for the mobile application group and the server-side group. Separating by architectural layer leads to a lack of communication and loss of crucial communication. People do not wish to report problems during retrospective meeting because the proposals of the previous meetings have not been taken into account.
- Suicide:Scrum meetings are not well organized. They are too long because of the increasing number of issues and unplanned discussions. Retrospective meetings have vanished.
- Ugly: The two teams are joined together again. Scrum meetings are not productive. Overtime and pressure exhaust the team.
Are There Any Advantages to Being on a Hopeless Team?
Though I am convinced that a person cannot work on a hopeless project for an unlimited amount of time, I made several conclusions that can be useful to every member of a hopeless team.
You can discover many things on a hopeless project:
- Your personal “breaking point” in extreme conditions
- How different people react on long-term overtime
- How time pressure can lead productivity and quality to zero
- How people can lose their tempers looking at demotivated coworkers
- If managers don’t react at the first signs of problems, they will not react properly on more complex and difficult problems
- Projects cannot be successful if management sacrifices quality
- The team will not be able to deliver the product of appropriate quality on time if there are no clear requirements
Can a project team resist being in a hopeless situation? In my opinion, yes and no. Hypothetically, a team can decline the mandate that they must work overtime and might make managers reconsider a deadline. However, the reality is that there are always people with fears or high loyalty. These circumstances can force them to work in abnormal conditions for an extremely long time. From this point of view, it is better to follow the advice of the author of Death March: It is better to leave the project and make different plans for the future.
User Comments
Reminds me of a story my friend Rick tells. Seems he was on a trans-oceanic flight when the passenger seated next to him died, mid-flight. There were no empty seats on the plane and no where to move the body, so they just covered up the deceased passenger. Rick says there was one advantage to the situation -- he got two meals.
Maryna's story sounds to me like a terrible personal price to pay for some meager project learnings.
A bit like saying a major car crash is a learning experience, because then you find out how high your pain threshold is, and what hospital food tastes like.
It may be well be true, but the experience is very definitely NOT worth the price.
Sounds like an interesting book. :-)
Have to agree on both counts though. 1) It is possible to learn something positive from any situation. And 2) Some experiences just aren't worth the cost of what you learn so better to leave the project and make different plans.
This just further convinces me ( not that I needed any :-) ) that managers, any managers (project or functional) that operate on a zero-sum game mode (http://glossary.usip.org/resource/win-win-versus-zero-sum) should not be the roles they hold.
Maryna, that's for this article. IT was a good read. :-)
Hi Maryna,
Thank you for sharing your observations and thoughts. I liked reading your section at the end both at the personal level as well as the management level. Unfortunately for me, I've yet to see the management layer in organizations that go through this vicious cycle make any real change going forward. They often fall into the mindset of, "we did what we had to do" without realizing the negative consequences until their talent base walks out the door. Thank you again for sharing as it was interesting to see your experiences.
Thank you a lot for all the comments and for your attention to this important problem.
Unfortunately, it is very difficult to catch the signs of the problem from inside of a project.