Shift in reasons for software project failure?

For decades software industry has created and evolved many engineering and management methodologies / models to address the problem of project failures. Where “Failure” is defined as deviation from set project objectives.

During various studies, various causes surfaced, ranging from Engineering Practices to Project Management (as stated above). A closer look reveals that earlier engineering practices were still maturing and organizations, and practices within organizations were at various level of maturities, resulting in varied success results, within organization as well as across industry.

After decades of study, incorporation of learnings and implementation of Best Practices, things have not improved to an extent, where it can be said that an optimum state has been accomplished. Over a period of time engineering practices have matured from process, and tools and techniques perspective. Many project management standards have emerged, implemented and practiced, resulting in almost a standardization of processes across industry. Yet, the capability to deliver the projects as per project’s set objectives varied.

Indeed, progress has been made; however, it looks like industry has reached a saturation point, and organizations across industry might be experiencing diminishing returns, or at least retarded returns on investment, when it comes to further investments in improvement of project management or engineering practices.

What it means is that there is more to it, which, has either been missed out or did not get required attention; may be unknowingly. We have to identify and investigate that “more”.

The resource capability improvement, external dependencies, customer’s equal participation and element of caution between customer and vendor are the other causes that could have been the bane behind these failures.

What should be done?

Over a period of time, the operating environment has evolved (as expected) and few interesting facts have emerged;

• Customers’ getting focused on outcomes of project
• Growing intolerance to defects, change requests, schedule slippages…anything that delays the outcome or gains, and spirals up the costs
• Elements of caution between vendor and customer
• Almost everyone has access to latest tools, technology, techniques, processes and methodologies to execute a software projects, and over a period of time these have also been standardized (to a great extent)
• The field of software engineering and management has evolved and stabilized to an extent where CMMi / ISO / ITIL…have become thresholds rather than differentiators
• The projects of strategic importance usually involve multiple vendors, thereby creating dependencies and challenges of synchronization and collaboration
• With less bench strengths and ever increasing pressure on margins, bench has thinned down even further
• Ever increasing pressure on budgets for readiness, morale etc.

With these challenges, the question arises, “What is that needs to change, either with customer or vendor, such that challenges can be addressed effectively?”

Very briefly,
Resource capability – self accountability and innovation culture - A maturity model driven through self-accountability, driven through innovation culture, is something that will propel personal development and shall also fuel organization’s growth. In a working environment it will be difficult to separate both, as those are interdependent for it to survive.

The point is, readiness can be enforced; however, development is self-driven. You do not require a “ready” workforce, rather you need a “developed” workforce, as only that workforce can drive the “right” work.

Acknowledge dependencies – you may plan for, can’t eradicate - In a project where multiple stakeholders are interacting and contributing towards success of project, it is normal to have dependencies. These dependencies play a crucial role in determining the success of the project. Invariably, many projects get delayed, or marred beyond recovery because of these dependencies
It would be an interesting study to know how many times vendors or internal IT teams failed to meet timelines, effort and / or cost estimates because of internal reason and those had no bearing either on customer or external dependencies or their active participation.

It is also interesting to note that despite of having various project execution methodologies projects still slip in want of dependencies. In this case the emphasis is more on external dependencies as internal dependencies can still be influenced or worked upon

Customer centricity, with customers’ self-realization - It is evident from above listed tasks or activities that a vendor is actually supplying functional, technical, program, and project management skills necessary to successfully convert the customer requirements into technical requirements and implementation of the same. However, at no point, all of that can be achieved without customer’s active participation.

May be it is little contentious; however, it has been observed that when a customer goes for a custom built car, cloth, house, ornaments, bike, furniture…etc., their participation is more and to an extent voluntary. Now, when it comes to software development, the participation reduces drastically. May be it is there in pockets, but then there are stories of success in pockets too. Again, may be it can’t be generalized; however, wherever there had been active participation from customers, the probability of failure had greatly been reduced, if not eliminated completely.

The point is, if active participation works in customer’s favor, why is it such a neglected area in software development?

Element of caution between customer and vendor – The fact of the matter is one may apply penalties on delays, quality, or pass on newly identified requirements as elaboration of requirements, at the end, it is going to hurt customer too. The reason being, vendor cannot resolve either customer’s internal or external dependencies beyond his control. These can only be resolved through customer’s active participation.

The quality is viewed in terms of deviation from functional and non-functional requirements of a project. In this case, if customer participation is lagging or is not sufficient, it is obvious that it will hurt the project objectives. It is true penalties may keep vendor honest to its terms; however, what provisions do customer have to keep maintain the same honesty? No, there is no need for such punitive clauses or provisions at both the ends, rather it is the thinking of shared accountability that will bring in results

To explore more on this, you may follow this link.