The Unconventional Guide to Project Failures (Part 1 of x)

About the Topic

Guides are usually for the purpose of providing instructions on how to reach a specific result; now that’s a totally different discussion whether result is favorable or not (positive or negative). Sometimes few unfavorable practices gets so frequent that it becomes a norm.

A Major cause that leads to project failures

There are many factors that effects and lead to IT project failures; there may be multiple perspectives and various business-oriented conditions involved, but one of those many factors is “frequent and routine changes in requirement specifications” during design phase.

If we drill down more into the root cause of why requirements keep changing during project execution phase it would not be difficult to get to conclusion that at many occasions adequate time was not spent in the initial planning (analysis) phase of project.

Usually complete system analysis is not done in planning phase, even project objectives are not defined completely, requirements are not well-documented and sometimes design/execution phase gets started without properly identifying or clarifying the scope; and technical team is asked to start with design/development with an unclear picture of what final product is expected from project. For technical team this situation is like a “moving target”

How to encounter this situation

Employ effective and efficient change control policies, procedures to ensure that project objectives can be achieved.

With traditional approach of project management like waterfall method, requirement changes needs to be properly analyzed before accepting, the impact of changes can be devastating for project and thus needs to be thought-out / analyzed in detail with stakeholders considering possible risks involved and needs to be communicated timely and effectively.

With adaptive approach like Agile or Scrum, changes can be accommodated in more flexible way since it’s an iterative process where requirement changes are mostly being handled in next sprint cycle.

Change Control process is not implemented to prevent change requests, but to ensure that proposed changes are properly discussed, analyzed impact and agreed before implementation. And no unnecessary changes are made, specially during execution/design phase.

The steps of Change Control process are:

1. Change Request or proposal
2. Identify and Analyze the Impact of proposed change
3. Decision to be made by Project Review Board / Project Manager about acceptable, defer or rejection of change request
4. Technical Team to Implement the change requested

All change requests should flow through Project Managers, another way is to review/approve/reject change requests is to form a Change Control Board (Project Review Board) but that may not be applicable in all situations.

The reason of highlighting this issue is most of the times, just because of irregular practices we tend to oversee the effects of poor change control management can bring to projects. A Lessons-Learned review meeting can help us in identification of various aspects that had impacted to possible project failures.

Experienced Project Managers often identify dealing with changes as a challenge, as in business-oriented situations change is inevitable.

Thanks,

Web Editor
SABIT SOLUTIONS