Determining Scope
To begin let’s define what scope means as defined by the Project Management Institute:
Project Scope “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.” (Project Management Institute, )
Scope is one of the most important items to be defined in a project. It also needs to be one of the first. This is because without a proper knowledge of the scope of a project it is extremely hard to figure out and estimate all the details of the project. Without a proper scope it is impossible to identify and limit all the tasks involved in the development process. It also becomes impossible to estimate the overall cost of the project as a whole.
Scope Creep “refers to uncontrolled changes or continuous growth in a project’s scope.” (Scope Creep, n.d.)
Scope creep is one of the most painful points in systems development and for those who have been involved in the development process you have experienced just how painful it can be.
In order to avoid scope creep and create a project schedule that is as accurate as possible, scope has be identified, limited, and agreed upon by the major parties involved. The only way to effectively accomplish this is to develop and instantiate some form of process through which all projects can be moved when dealing with scope.
The Process
In my experience dealing with Project Managers, Scope, and Project Champions keeping scope under control requires a detailed process as well as acceptance of that process by all involved prior to the project kickoff. If everyone is made aware of and accepts the process and its procedures for dealing with scope, there is a higher chance of success when it comes to controlling scope and its tendency to creep as projects mature. This leads me to the first part of my process:
Procedure 1: Identifying Power Players
Before scope can be decided upon or controlled we need to have a clear picture of who has what power within the project and what that power allows them to do and dictate. With a well defined power hierarchy identified it will be much easier to know when and where you can say no and who you need to go to in order to have no communicated.
- The Power Payor: the ones ultimately paying for the new system
- The Power Management: the ones who are neither paying nor using the new system
- The Power Domain Expert: the one who knows all in regards to the business domain and/or the existing systems being replaced
- The Power Users: the ones who will actually be using the new system
Procedure 2: Identifying Business Domain(s)
It is extremely important that we understand the business domain(s) in which the information system will be built. Depending on the business domain(s), scope may be more difficult to determine and external experts may be required in order to accurately determine the scope of the system.
Procedure 3: Reviewing Existing System(s)
If there are existing systems which are to be replaced by the new system those systems can sometimes be a really good resource when it comes to determining the existing scope of the system. This will allow you to focus your attention to new scope that may be introduced due to the needs or changes in business which have inspired the development of the new system
Procedure 4: Interviewing Primary Users
It is important when determining scope that the primary users are located and interviewed in order to identify the requirements which they see as the most important or critical in their work. Ultimately it is the users of the system who we are building the system for, with the goal of improving their efficiency, effectiveness, and speed in their everyday work.
Procedure 5: Identifying Business Value
A thorough review of all requirements within scope should take place and business value should be identified and tied to each. By tying business value to each requirement we can potentially identify requirements in the scope which are superfluous or were inserted into the scope based on personal bias/desire.
Conclusion
No matter which procedure we are working through there is a good chance there will be discrepancies discovered, requirements that seem out of scope or superfluous, or requirements which smell of personal bias/desire. When we run into such cases we will need to figure out whether they are within scope or not and the best way to do this is to identify the power player who best fits the current phase and discuss the issues with them. These discussions may end up in negotiations so it is always a good idea to brush up on your negotiation skills.
In cases where a specific power player cannot be identified, it may be acceptable to gather a list of issues and obtain feedback from the entire power player group to come to a consensus on each issue.
Sources/References
1. Kendall, K.E. (2011). Systems Analysis and Design.
Pearson Education, Inc., publishing as Prentice Hall
2. Project Management Institute. (2008). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fourth Edition.
3. Scope Creep, (n.d.). In Wikipedia’s online encyclopedia
Retrieved from http://en.wikipedia.org/wiki/Scope_creep
MemoryTin 
Published by