How much influence does not have a detailed scope when working on it? Can a bad scope be a cause of a failed project? Saving Changes...
Sort By:
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Jorge,
yes, absolutely.
Often scope problems are root causes for troubled projects.
But a detailed scope could be bad too, if there are too many changes along the road. Sometimes not all details can be found upfront, but need to be developed during the project. Or in a long project, scope details that were written down a year ago are no longer true (because the world changed, the team has more knowledge, new technologies are available etc).
In my experience, establishing a win-win relationship between project and requestor and
(1) being able to fix as much of the scope as early as you can
(2) while being able to change it if deemed necessary by both
is a good way forward.
Some say fix it as late as possible, that is not my opinion if (2) works.
The key is: do not only look on scope, but regard the context with stakeholder engagement.
A poorly defined scope can absolutely cause a project failure. Some claim that 90% of project failures are due to missed requirements. Whether you believe the 90% or not, it is still a large number. Critical requirements are part of the scope, and there are many examples about how missed requirements resulted in a failed outcome.
Many times in my career, I have worked on products where the designer only understood part of the scope, such as a business system that was efficient at storing data, but lacked a user interface that could find the right data once stored. Since the designer had no concept of operations for the product, it failed to meet the user requirements and required a separate system to catalog everything in the main system. Not long after an extremely expensive implementation, it was replaced by an all new (and also extremely expensive) system. Saving Changes...
Poor scope or requirements management is definitely a common cause of project failure as without this, you end up building the "wrong" product, service or result to achieve the expected outcomes.
poorly defined scope is one of our top processes for standard risk evaluations before each project. We speak from experience: in international projects, maybe because of contract language unfamiliarity, the project supplier (us) almost always gets the short end of the stick. In that regard, I agree wholeheartedly with Keith. We never had a project failure because of it, but only because now we do perform that analysis. And of course it depends on what is defined as project failure. Not so long ago, we abandoned a multi million dollar potential contract because of that analysis, where the Customer was not able to define scope to our liking, in the context of a fixed price contract. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Key points to take into account are: 1-"not have a detailed scope". You will have a scope with the amount of detail you can based on the available information you have. This is well proved by Barry Bohem when creating "Cone of Uncertainty". 2-"bad scope". What "bad" means? Mainly based on point 1. Saving Changes...
