Top 4 Reasons Why Projects Fail, Part II

Top 4 Reasons Why Projects Fail, Part II Digineer

In Part I, last week, I laid out a general overview on why projects fail and looked at reason #1 in more detail. In Part II, we will look at reasons 2-4 in greater detail.

Is project success or failure solely the responsibility of the Project Manager? In my opinion, the answer is NO. This may surprise some but if we don’t have involvement, commitment, and bravery by sponsors of the project more than likely a project will fail. Furthermore, organizational leadership must create an environment that supports a project environment.

“Proper scope definition is critical to project success” this is not some quote from a great project manager, rather a text that is straight out of the Project Manager’s Book of Knowledge (PMBOK). It Is the responsibility of the project sponsor to set the scope expectations for a project. Driving to the fulfillment of expectations is the function of the project manager. Problems arise when expectations are not clear or informal. Conversely, if expectations and the method of managing them are too complex or rigid it becomes difficult to manage any requests for change.

Failure to set and manage expectations is certainly a major cause of project failure. The practical ones among us know that the reason being a project manager is difficult is that we really need to keep our project artifacts and techniques flexible enough so that we can produce predictable, professional results while at the same time accommodating any necessary change.

Reason number four for project failure is adequately identifying, documenting and tracking requirements. Using documentation requirements does not eliminate the need for formal, well-organized process for gathering requirements. Sometimes people believe that a one-page email with a wish list features is good enough. Not so much! The good news is that most project owners/sponsors believe that requirements need to be documented. Nailing requirement documents must be done very early in a project, wait till later and it’s too late. Ambiguity is good for no one thus you must clarify that ambiguity as quickly as possible.

There are various tools and techniques for defining requirements like codifying, progressive elaboration, interviewing, modeling and interviewing. You can use one or all these tools to help you to define your requirements.

Learn more about our Project Management techniques: sales@digineer.com

More from this author