powerobjects: Managing Project Scope
To be or not to be…. That is a scope question.
Have you ever been on a project and been faced with the decision of whether something should be part of the project or not? Often times, people see this as a single decision or perhaps more commonly, maybe two.
Many Project Managers assert that there are several decisions you should make when defining whether something is a part of project scope. The value of asking these questions is that they reduce the chances of scope creep, help harden your project documentation, and help you include key decision makers in changes to the project.
Let’s walk through this process to see what it looks like! (Reference the diagram below).
Obviously, the starting point is that there is ambiguity around whether something is included in the current project scope.
Your first decision is to define if it is indeed in the existing project scope or not. Typically, you would refer to the Statement of Work, Project Charter, or other organizational scope document. If you’re unable to resolve this question by referencing one or multiple project documents, then you may need to revisit your documentation as it may lack the detail to adequately define and help manage scope now and moving forward. Identifying this issue early in a project will help mitigate one of the most common issues, which is “scope creep.” Often the most common cause of scope creep is that scope was not well defined and documented at the beginning of a project.
If the proposed item is defined as not being in scope, then you need to determine if you should increase the current project scope to include it. This is the most common path for project changes, and results in either a project scope change, or pushing the item to a later date or dropping it entirely.
If the proposed item is within scope, your next decision should be if it is worth including in the existing project NOW.
Typically, this question is not asked as a part of the process. Usually once an item is defined as being within scope, it is immediately assumed that it is included in current scope without any real vetting of the impact or value of the addition.
Asking this question has some key benefits. The first benefit is that it helps you understand where this item came from and why it changed. If it is a something that was missed, then it may highlight that there could be more items like this now or in the future. If this was a change, then there is the possibility it may change again which means you need to understand now so you can plan appropriately. All too often project scope expands because changes are included without effectively defining the extent those changes will have on an entire project and not just on a specific project item.
The other benefit of asking this question is that you engage key stakeholders in defining whether something should be in the current project. As a part of this process, you must clearly define the value of these items. This will aide in the later steps of getting more resources or time to complete the work if it is added to the current project.
If it is worth including now, then the follow-up question should be if you could adjust or cut current scope or just add it in. This is another question that is rarely asked, but can help mitigate change orders that increase cost, project duration, and needed resources. Sometimes project or organization constraints force the question of one item taking the place of another instead of just adding it in. Projects can sometimes grow exponentially in scope and end up being nearly two or three times what was initially planned. This results in significant cost and duration increases that are perceived as poor project or program management when the true root cause was poor project scoping at the beginning of the project.
If you determine that is it not worth including now, then you should move that item to a later phase, put it onto the backlog, or move it to another project. Often this is for items that will change again or items whose scope you’re unable to adequately define now. In most cases, items that are pushed out usually change significantly or end up being dropped all together. One key advantage of asking this question beyond managing scope is that you engage the business on the value of adding something to the project scope.
When you follow this process you ensure that you have tried your hardest to mitigate scope creep, have determined if everything in scope is ‘value added,’ as well as making sure all stakeholders are aware of how and why project scope changed along with any changes in budget, duration, and resources.
Looking for more helpful guides to Dynamics 365? Be sure to subscribe to our blog!
Happy Dynamics 365’ing!
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|powerobjects: Do I Really Need a Project Manager for My ERP Project?||Blog bot||Dynamics CRM: Blogs||0||21.03.2018 01:13|
|powerobjects: Why Project Managers are Using Dynamics 365 for Project Service Automation||Blog bot||Dynamics CRM: Blogs||0||28.12.2017 00:15|
|emeadaxsupport: Intercompany time postings incomplete at transaction voucher level when project date differs from the day posted||Blog bot||DAX Blogs||0||19.08.2013 19:11|
|Опции темы||Поиск в этой теме|