I always enjoy hearing stories about the last computer software project. It ranks right up there with politics, religions and martial problems as to who was at fault. Definitely a problem if the process and project are not managed carefully.

I was once hired to assess why a software project had missed its fourth deadline in the last year. The project was well over budget, a year plus late and most everyone pointing the finger at someone else. The stress level was now impacting the executive management team as each senior manager was supporting their direct report as if there was a need to add more fuel to the fire. The project continued to slip and fall further and further behind, and some management started questioning the original project requirements and wondering how things got this way.

My background: I started with computers in 1967 with a computer program class at Andover Institute of Business (used to be on Congress Street in Portland, ME). I spent the next 20 years deeply engulfed with everything to do with computer hardware and software systems. Over the next 2 decades I witnessed constant battles between management over the project aspect of what was needed, why was it needed and why was it going to take so long and cost so much. Sound familiar? Same questions are still being asked today. If and when these matters were resolved, often with the answer being we don’t have any choice but to do this became the major down fall to many projects: the project team itself.

Often the causes appear to be poor documentation, training, planning, busy end-users, the technical guru’s not being technical enough or not business enough, but what they really mean is the project team didn’t do what was needed.

That was the situation with my contract. Everyone was to blame, but nobody was responsible. The stress level within the departments involved was mirrored with their anger and distrust for one another. Their hard work and long hours had failed to achieve results as planned and they knew all eyes in the company were on them. Their career advancement opportunities were fading fast at that company.

The actual root cause of project dilemmas, in most situations, can be traced back to the original project team. The primary issues turn out to be: knowledge and experience, and the ability to work together, communicate, make decisions, negotiate, problem solve and re-plan. Similar to why businesses fail to achieve their true potential.

The negative impact of poor project planning drains the energy level of even the noblest of employees. Enthusiasm, important as it is, can’t survive under a structure of poor planning. Remember we seldom plan to fail, we fail to continually plan and re-plan. It takes courage and conviction to re-plan. It takes a combination of leadership (knowing where you’re going and rallying the forces) and management (being able to control the complexities and human behavior to muster the forces) to make progress on implementing common goals.

If the impact of failed software projects had the same impact as not meeting other business goals, how would things be different? Sounds like software projects should be treated like all other business projects.