Management Bug: Undefined Project Scope
Management Bug: Undefined Project Scope
A MngtBug is a problem, cause or impact in a human manager’s decision which produces an incorrect or unexpected result. Every other week we share a little bit of our knowledge base on social media and our newsletter. This week’s MngtBug is…
Have you ever seen this MngtBug? How did you solve it?
Share your story!
Description
This week’s “Undefined Project Scope” is one of the main origins for problems on project management.
There are 2 main points of view:
Sponsor View: Projects start with a high-level idea that has been defined and proposed in business terms, not project terms. Sponsors are focused on their customers and competitors, and do not think in terms of “scope,” much less in terms of “scope management.” Likewise, sponsors are typically not familiar with the concept of project charters, which explains why project managers usually create them. Sponsors rarely think that their scope is undefined, and they expect others to quickly match their level of understanding. They have been planning and thinking about their business needs, sometimes for months or years, and expect project teams to get up to speed fast.
Project View: The high-level scope is best documented in a project charter and expanded in the scope statement. These high-level views are not sufficient for understanding scope until a decomposed deliverable-based work breakdown structure (WBS) is created. Without the detail of a full WBS, a gap in understanding will exist. If the high-level scope is not clarified further with a detailed and validated requirements analysis, then the gap grows wider.
- Unclear initial scope. The Sales Commission project has an unclear scope definition. Mary did not decompose the scope enough, and the requirements analysis was superficially done. Both of these elements contributed to an undefined scope.
- Lack of detailed scope. The team felt pressured into not articulating the scope in detail, often a pitfall of software package installation. Bob focused on the interfaces, which paradoxically opened the door to expanding the scope to include a web page, something clearly out of scope.
- Poor communication. Mary did not do an effective job of communicating scope, particularly that the G/L interfaces were out of scope.
If a project skips detailed decomposition and requirements analysis, the scope remains ambiguous. In our experience, the ambiguity is then addressed by design and development teams in one of two inappropriate ways: 1) the team interprets the requirements and builds what it thinks is right, or 2) the team clarifies the scope by eliciting requirements directly from stakeholders and subject matter experts (SMEs). The chances for misinterpretation and expansion of scope are high in these cases.
- Bill and Allison appeared to build what they thought was best, not what was in scope.
- Bob and Chris worked together in an unmanaged way, and the Flash component was added for personal reasons and not because it addressed a business need.
Recommendations
- A clear, well-managed scope is a key element to successful projects. Sponsors can contribute to clear scope by developing their own charters. Our idea of the charter is a short document that contains mainly the business need, the project vision, and high-level features in and out of scope. These are all items that executives should be able to articulate on their own.
- Scope statements should include both features in and out of scope. A robust WBS that decomposes deliverables into work packages is a must. The decomposed deliverables form the basis for beginning detailed requirements analysis.
- Business analysts can contribute to clear scope with effective requirements elicitation and by analyzing and documenting clear, complete, and concise requirements. This takes time, of course, and the project team needs to plan for the time and be firm about it in the project schedule.
- The project manager needs to work with the sponsor to either negotiate a later delivery date for the project or reduce its scope when the date is fixed.
- To help clarify the scope early in the project, the systems analyst could have used scope models and diagrams, such as Business Process Models and Use Case Diagrams. They provide a visual aid to clarify scope, leading to a more effective sharing of “mental models” with stakeholders.
Summary: Whether the scope is initially unclear or it stays vague as a project unfolds if the product scope and its underlying requirements are not clear and precise, it is a “breeding ground” for scope creep. (thank you to https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675)
Known Associates
This MngtBug has been mentioned in relation to a number of MngtFixes such as…
“Customer Needs Elicitation”,
“Customer Requirements Definition”,
“Project Management Templates Definition and Implementation”,
“Project Management Training”,
“Project Planning Implementation”,
and of course “Project Scope Definition and Update”!
Call to action
What about you? What do you want more or less of on this newsletter?
Do you have other suggestions?
Share your thoughts on email to newsletter@humanmngt.com!
We would love to know more about your feedback and stories to feature them on this newsletter so that we can learn, share and grow together!
Feel free to share this newsletter with your friends and colleagues.
If you liked it, there is a good chance they will like it too!
Have a nice week and remember…
Human Managers should strive to be humans while managing and be managed as humans!
