Project Fail: Lessons learned from failed and abandoned projects as a Software Developer, Part 1

In life, and to be more specific, in any given software development project, nobody wants to fail. However, I shall let the famous words of Benjamin Franklin remind me and you as to why projects fail.

"If you fail to plan, you are planning to fail" ~ Benjamin Franklin.

So according to Benjamin Franklin, to fail is to have no plan. A lack of a plan increases the chances of failure every passing second. In this information overload era, planning means there is a level of intentionality that is applied towards a clear goal whose objectives are listed and broken down into tasks. These tasks are also listed in a hierarchy which is reflected in the weight of the objectives.

The time factor

From my experience, software projects that end up being abandoned or those that come to a failure point often have a "rush effect" to them. Usually because of this time factor, the discussion stage is usually full of common words/phrases like, "We don't have time" etc. Let me explain.

Let's create a scenario where Client A approaches a Software company and says they want a system in 1 month. The professional approach is to find out the software requirements and this means a discussion, even before money is in the picture. Client A then quickly tells the company that they are time bad but they have been referred to the said company because of their experience, especially in the area of delivering quality work in a fraction of the time.

At this point, the company caves into the pressure and they begin discussions on how much because of the tight deadline. However, from a professional standpoint, I have come to understand that the steps for a great project are usually 4, i.e. Discussion, Design, Development, and Deployment. Usually, successful software projects have core key elements of those above stages. I dare say successful software projects that go through that kind of cycle are usually maintainable.

Once the pressure sets in, the company begins to think of ways to speed up this project under the agreed budget and that's where the plans are thrown out of the window. Code snippets are pulled together from other projects, and internal prototypes that are not ready are promoted to full use because "the client must see something quick". This creates a domino effect which leads to Software engineers working throughout the night because of the "hot discussions had earlier" with the client. Even before the prototype is stable, the client has begun marketing their system and getting potential customers to sign up. Usually, at such a stage, the software is not fully tested and it can easily crash but that's all blinded by the adrenaline rush.

A few months down the road, the result is back-and-forth changes that were not in the scope originally, the software design has been changed over and over and there is no end in sight. The engineers begin to get frustrated because this "never-ending project" is beginning to affect their morale and sense of purpose. What began as a challenging point of growth quickly becomes something every Engineer loathes with uttermost disgust. Meetings are held to salvage what's left but at this point, the minds of the stakeholders have either shifted to a post-mortem kind of thing or just simply put the project back where it belongs, the shelf so that it can collect enough dust.

To be continued ....