Index:

1.1 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.3 1.4 1.5 1.5.1 1.5.2 1.5.3 1.6 1.6.1 1.6.2 1.7 1.8 Introduction Best practice for scope requirement collect project requirement define the scope create Work Break Down Structure verify the scope the Get Feedback monitor and control the scope How should the project manager deal with scope creep? Controlling project scope Manager project scope granular scoping accurate time capturing milestone reconciliation Improve project success with better scope management problem with project scope capturing project scope conclusion References

1.1 Introduction
The Project Management Institute Project Management Book of Knowledge (PMBOK) defines product scope as the features and functions that are to be included in a product or service. It defines project scope as the work that must be done to deliver a product with the specified features and functions. Project scope management is defined as the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. The scope definition section details the process of developing a detailed description of the project and its deliverables. The scope is the most

important element to understand about any project. Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully . All planning and allocation of resources are anchored to this understanding. In the other
word the scope management plan establishes how scope management will be carried out in the project. It serves as guidance for scope process and formats and defines the roles and responsibilities for stakeholders in those processes. It is not the detailed requirements information, but instead explains how that information will be captured, expressed, and modified (if or when necessary).

The scope management plan includes descriptions of required documents (e.g., functional requirements, technical requirements, and change control forms). Although the approaches to scope management may vary, some of the elements are consistent. The scope management plan should express how and where scope will be definitively captured and how and when it may be modified. The plan may go into detail about how the requirements and scope will evolve (through team processes, expert assessment, or otherwise) or may simply identify a single team member with go-to responsibility for all scope issues. Because it is integrated with other baseline issues (including cost, schedule, and risk), the scope management plan should be coordinated with any management plans that have been developed for those areas. The scope for this project was defined through a comprehensive requirements collection process. First, a thorough analysis was performed on the companys current software applications based on employee and user feedback. From this information, the project team developed the project requirements documentation, the requirements management plan, and the requirements traceability matrix for what the new software application must accomplish. The project description and deliverables were developed based on the requirements collection process and input from subject matter experts in software design, technical support, programming and business applications. This process of expert judgment provided feedback on the most effective ways to meet the original requirements of providing a new software platform from which the company can improve its financial tracking and internal financial processes.

1.2 Best Practices for Scope Management

The knowledge area of Scope Management is all about making sure that the project includes only the work required to complete the project successfully. To be effective at scope management, you must learn to control what is and what is not in the scope of the project. Below are some of the best practices for successful scope management. 1. 2. 3. 4. 5. Collect Project Requirements Define the Scope Create a Work Breakdown Structure Verify the Scope and Get Feedback Monitor and Control the Scope

1.2.1 collect project requirements The ability to define and then effectively control the scope of a project depends a lot on the goals and requirements of the project. For this reason, you need to gather the necessary information up front, before you ever start the project. By clearly understanding the needs of the stakeholders and the capabilities and constraints of your resources, you have a higher chance to succeed. The easiest way to collect the project requirements is to perform interviews with the key stakeholders. Ask questions about their views of the finished product, the deliverables they expect to receive, and the schedule of the project. Once you have the information you need, you may want to create a Scope Management Plan to define the processes that will be followed in defining scope, documenting scope, verifying and accepting scope, and managing change requests. 1.2.2 Define the scope The scope of a project typically consists of a set of deliverables, an assigned budget, and an expected closure time. The previously collected project requirements will help you define the scope. Be sure to write down exactly what the project will entail and what it will not entail. Any amount of variation in the scope of the project can affect the project schedule, budget, and ultimately the success of the project. Getting a clear and concise definition of the scope will help you manage changes as they occur. With a clear scope definition, you can simply ask the question, "Does this change fall within the scope of the project?" If the answer is yes, then vet and approve the change. If the answer is no, then put a pin it and save it for another time or project. 1.2.3 Create a Work Break Down Structure A work breakdown structure or WBS is a graphical representation of the hierarchy of the project. The WBS forces the project team to think through all levels of the

project and identify the major tasks that need to be performed for the project to be completed on time. By starting with the end objective and then successively subdividing it into manageable steps or components in terms of size, duration, and responsibility, the WBS provides a high level view of the entire project. Furthermore, the framework makes planning and controlling the scope of the project much easier since you have a graphical chart to reference point for the tasks and subtasks needed for each phase of the project. As a general rule of thumb, no task within the WBS should be less than 8 hours or more than 80 hours. 1.2.4 Verify the scope and Get Feedback Because projects are expected to meet strict deadlines, verifying the scope of the project is critical before and during the project cycle. Scope verification can be done after each major task or phase is completed or if it is a smaller project, after the project has been completed. To verify the scope, meet with the project customer or stakeholder and get him/her to formally accept the project deliverables. This includes getting a written acceptance of the deliverables and requesting feedback on the work performed. Getting feedback from the customer is an excellent way for you to improve processes and make sure the customer is happy with your work and the status of the project. The most important thing here is to communicate well and often. Verifying the scope and getting feedback will help you focus on customer acceptance, quality control, and verifying that work performed meets the definition of the scope of the project. 1.2.5 Monitor and control the scope Now that the Scope has been clearly defined, a work breakdown structure has been organised, and the customer has formally accepted the scope of the project, it is time to actually manage and control the scope to avoid scope creep. Scope creep refers to the incremental expansion of the scope of the project, which may include and introduce more requirements that may not have been a part of the initial planning phases, but add costs and time to the original project. To effectively monitor and control the scope of the project, make sure you have an established process for managing change requests. Any and all requests should be vetted and approved before they get introduced into the project. The budget and schedule of the project should also be altered to reflect the new changes. These changes should get a formal sign-off from the customer or key stakeholder before proceeding. It is important that you closely monitor and control the scope to avoid disgruntled customers, higher than expected costs, and projects that aren't completed on time.

1.3 How Should the Project Manager Deal with Scope Creep?
Scope creep has always been the bane of traditional project managers, as requirements continue to change in response to customer business needs, changes in the industry, changes in technology, and things that were learned during the development process. Every project has (or should have) a set of deliverables, an assigned budget, and an expected closure time. There are agreed upon requirements and tasks to complete prior to the closure of project. These constitute the scope of the project. Any amount of variation in the scope of project can affect the schedule, budget and in turn the success of project. Scoping is the separation between what is included in and what is excluded from project. Scope creep occurs when the line is moved, usually outwards. Thus what was excluded is now included, making a project in most cases larger. According to the PMBOK Version 4, scope creep is defined as adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided. In the past, we have participated (not as a project lead or a project manager) in a number of projects that failed due to scope creep. I could not find any formal statistics to refer to, however, I've noted that majority of those projects failed due some form of scope creep. Note that the PMBOK considers a project as failed anytime it is over budget or does not meet the predetermined schedule deadline. Scope creep can originate from:

Poor implementation of change control. Incomplete gathering of requirements before the beginning of project execution. Insufficient involvement of critical stakeholders (including the customer). Lack of support from the executive sponsor.

Scope creep can be classified as:

Technical Scope Creep Business Scope Creep

The technical scope creep can show up when the project team wants to please the customer and is not able to reject the customer's request for a change in the requirements during project execution. Gold-plating is another reason which can cause technical scope creep. In this case, the project team (or development/design

team) adds additional features and functionality that are not part of original requirements in order to please the customer. The business scope creep occurs due to external forces that may be beyond the control of project manager. An example might be the continual changes in market trends, which makes previously defined requirements now obsolete. One can avoid scope creep by managing the scope of project effectively. There are a number of ways to control or avoid scope creep:

Involve the customer and/or the end users early in the project. Thoroughly analyse and gather requirements during the initial stages of the project. Introduce a Change Control Board (CCB) team that would evaluate the risk of implementing the changes. Make sure to involve critical stakeholders throughout the project phases (especially during the planning phase). Avoid gold-plating and gain the ability to refuse changes in requirements with proper reasons and support. In extreme cases, stop the project so that new additional requirements can be properly scoped and integrated rather than tacked on.

Two additional points need to be made here: We need to be careful not to confuse scope creep with progressive elaboration. According to the PMBOK Version 3, progressive elaboration means developing the product in steps, and continuing by increments. For example, during early strategic planning, when information is less defined, work packages may be decomposed to the milestone level. As more is known about the upcoming events in the near term they can be decomposed into activities Secondly, note that the idea of scope creep has evolved in SCRUM. The product catalogue (scope) is dynamic and it changes throughout the software product development life cycle as long as the customer feels that those changes add value to the project and accepts the responsibility for them. At the same time, every attempt is made to make sure that scope within each SCRUM sprint is strictly enforced. This evolution of scope creep in SCRUM does represent some interesting problems, which are beyond the scope of this article.

1.4 Controlling Project Scope

The most common reason for software project failure is not failure to control budget or schedule, but failure to control requirements, either at the outset or during the build phase. Software projects are unlike those that deliver a tangible product such as a building, a bridge, or a dam. These projects receive much more attention during the

planning phase and tend to be controlled with much more rigour than are software projects. You'll never hear of a plan to build a 20,000 square foot shoe store ballooning into a project to build a 10 acre shopping mall! Yet that's exactly what happens to a lot of software projects. They start off with one objective in mind but after the last stakeholder has added his or her wish list they bear no resemblance to the original vision. I call this dispersion of focused effort "ocean boiling." It's not an original term, but I think it fits this situation perfectly. Attempts to boil the ocean will expend a great deal of heat without changing the sea state. Attempts to deliver an extensive wish list of software features will spend a great deal of cash without changing the business. Failure to maintain a narrow focus on the original objective of the project leads to overruns of both schedule and budget. I'm using the original budget and schedule here as we frequently see projects which have their budget and schedule changed during the course of the project, using the appropriate change management processes labelled as cost overruns and late deliveries based on their deviation from the original plan. Clearly, whether these projects are "on budget" and "on schedule" is a debatable point. The real point here is that a certain degree of deviation from the original budget and schedule is acceptable, but when the scope of a project experiences a significant increase budget and schedule are sure to increase beyond what all stakeholders will find acceptable. Think how many times you've read or heard about overruns on government projects in the media. The media rarely mentions whether these "overruns" are the result of approved change requests; their only point of reference is the originally announced schedule and budget and anything more is an overrun. You may not be working on a government project, but it is still important to curtail project scope for the organisation you are working for. This article is not meant to be a comprehensive course on scope management, merely to offer a few helpful tips that will help you avoid managing a project that is perceived by your stakeholders to overrun budget and schedule. Those of you who haven't invested in project management certification should take a good PMP course or other PMP exam preparation training product and get certified. Doing so will give you all the tools and techniques you'll need to manage your project's scope. In the meantime, here a few tips you can start using right away. Don't take the entire burden of curtailing project scope upon yourself. You share responsibility for this with your project's executive sponsor and you won't be able to control scope growth without their help. You need their help with the Change Control Board (CCB) when senior stakeholders come to you with additions to project scope, which they believe have merit. It is up to you to verify their business case and provide an accurate cost estimate and it is up to the executive sponsor and CCB to reject the change. You'll help with this decision if you can manage to provide an accurate estimate of the additional time and money that the change would cost. A finish date beyond what the organisation finds acceptable or a budget increase beyond the organisation's ability to pay will help the sponsor and CCB make the right decision.

Be as specific as possible in the Project Charter, preliminary Scope Statement, or Statement of Work (SOW) as possible. The Project Charter and preliminary Scope Statement will constitute the blueprints for the final product. Research usage of the software well before finalising these documents so that all the potential users, customers, or partners of the tool are consulted and their requirements captured. These documents should then become the benchmarks of your project's scope. New requirements that don't support the original intent should be discouraged. Features or functions which would better support the original concept should be given serious consideration. Ones that add significantly to the original scope should not. I regard a request to support a new category of users, or market, to the scope as examples of requests for changes that are not appropriate. Additions to the software system which are unacceptable to your project may be ideal candidates for the next project. Software systems are never static; they are constantly changing and evolving so they should have a process for capturing new features or fixes for the next system release. Ensure that your project has a direct connection between its change management system and the production change management system. Changes that would add too much to the scope of the current project, but that are otherwise supported by a sound business case should be assigned to the production feature pool. This approach has two advantages: it doesn't lose sight of the value-add feature being requested and it isn't an outright rejection of the requested change. Don't forget that the cost of the project must include project management activities such as project communications, meetings, workshops and other management functions. Your organisation may already have a well defined management methodology which you are expected to follow, otherwise you should be managing it using the best practices in the industry (the Project Management Body of Knowledge, or PMBOK 4th Edition describes these very well). Make certain that the work that you plan to do to manage the project is captured in the Project Charter and/or preliminary Scope Statement. Requests for additional work should be treated the same way as other requests to expand the scope. A Statement of Work (SOW) will usually accompany an RFP or RFQ when work is being done by a vendor for a client. The SOW will usually be much more precise and detailed in its description of the work to be done, but not always. Make sure that the SOW you're working from is detailed and includes a description of the project management functions and artifacts you will be responsible for. Duties, meetings, reports, and communications that were not identified in the SOW should be addressed through change requests. Change requests which would significantly alter the scope of the project should not be an issue. If it does become an issue, it will be the customer's issue providing you have a well prepared SOW. Verify that you can deliver the scope of the project as it has been defined for the budget allocated to the project and in the time given. This will probably be relatively easy when the project is similar to ones routinely undertaken by your organisation, or

for smaller projects. More thought should be given to the project approach when tackling a very large complex project for the first time. Pilot projects and prototypes can be used to learn more about the cost and effort necessary to deliver the project. They will also prove the estimation techniques you have used, or suggest corrections to them when they prove to be inadequate. The work of these projects should never be wasted. The pilot should deliver a subset of functions for the planned system and the prototype should be a base that the project can be built on. Build the pilot or prototype into the overall project plan as the first phase. Review the feasibility of the project after this phase is over and re-calibrates your estimating methods if necessary. Your first line of defence against budget and schedule overruns on a software project is a well drafted Project Charter and/or preliminary Scope Statement. These documents don't have to contain a great deal of detail, that's not their purpose, but do have to contain a description of the system's functionality at a high level. Don't try to make the documents detailed, but do make them precise. Next, make sure you've got all the right stakeholders and capture clear, concise requirements. Use a pilot project to prove your approach or a build a prototype to prove the technology. In both cases you should re-calibrate your estimation technique if necessary and ensure that you have the right schedule and budget for the project. Your last line of defence is your executive sponsor. The sponsor should be making the right calls on the proposed changes. Proposed changes that would increase the budget beyond the organisation's ability to pay or extend the schedule beyond the time the organisation can afford to wait should be rejected. You can help by providing an accurate estimate of the cost of the change and the potential impact on the schedule. One last piece of advice: whenever the scope of your project is changed, make very certain that the new budget and schedule baselines are well communicated, then use them as your new baseline.

1.5 Managing project scope

Assume that the scope and budget are set, the team knows what they're delivering, and everyone is ready to begin. You're confident that hours have been allocated appropriately, but you also know how easy it is for scope to slip away from you - you need to keep a good handle on this project to ensure the team doesn't squander their hours and push the project over budget. In this article, I'll review some solid tactics you can employ to progressively manage your project budget and maintain total visibility from beginning to end. 1.5.1 Granular Scoping The first tool in your arsenal of budget management needs to be rolled out before the project is even approved for commencement. It's what I refer to as granular scoping, and it means that the budget should be allocated to each resource at a task level. In other words, don't estimate required hours in large lump sums - when you are going

through the initial scoping exercise, ensure hours are broken down into as much detail as much as possible. This will allow you to subsequently assign and manage project hours in smaller steps, which will inherently provide you with greater control and transparency as your team consumes their allocated hours. The ultimate advantage is greater visibility regarding how long each project task actually takes. This information will be invaluable to you as you estimate future projects with similar tasks. 1.5.2 Accurate Time Capture It amazes me to learn of interactive agencies that still are not capturing project hours through some sort of time sheeting system. There is no chance a project manager will have success in measuring project profitability with any comprehension if each resource isn't recording hours spent on specific projects. Ideally, resources will log how much time is used on each project task (back to granularity), so that you will understand exactly what areas of the project are most time consuming. This information will allow you to compare estimates against actuals, refining your scoping methodology by making corrections moving forward. 1.5.3 Milestone Reconciliation If you've executed the first two recommendations, you'll also be able to complete this one - providing you with absolute clarity and opportunity to recover from potential pitfalls as you move through the project life-cycle. Reconciliation is an exercise during which you analyse project completion (how much work has been done) in comparison to work effort (how may hours have been used). If you have broken down the scope and hour allocations in a detailed way, and hours are being recorded by each project resource, you will be able to reconcile at key points in the project to identify if you are over or under budget before the project is completed. If you know you are over budget early on, you may be able to take action and correct this trend before it's too late to make a difference. Project reconciliations also present an opportunity for you to share accurate information related to scope and budget with your client. A client that understands how much effort goes into a project, and how the team is working to remain within budget, will be more amenable to paying for legitimate overages. As a project manager, your most critical responsibility to the organisation you work for will be scope management - it directly affects the bottom line, contributes to corporate success, client satisfaction, and professional achievement. While this task may seem overwhelming, it is within reach if you can breakdown work effort and measure profitability as you move through the project. Ultimately, agility will provide you with options - and understanding where your budget is at each stage of a project will allow you to react and manage project scope successfully.

1.6 Improve Project Success with Better Scope Management

The Project Management Institute Project Management Body of Knowledge (PMBOK) defines product scope as the features and functions that are to be included in a product or service. It defines project scope as the work that must be done to deliver a product with the specified features and functions. Project scope management is defined as the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. 1.6.1 problem with project scope The Project Management Institute Project Management Body of Knowledge (PMBOK) defines product scope as the features and functions that are to be included in a product or service. It defines project scope as the work that must be done to deliver a product with the specified features and functions. Project scope management is defined as the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. 1.6.2 Capturing Project Scope The defence against all these problems is to clearly define the project's scope at the beginning. Once defined then validate that scope with all the key stakeholders, getting their buy in and consensus on the scope before charging ahead. Some tools and techniques useful in capturing the project scope are:

Define the project need Identify key stakeholders Identify project drivers Develop operational concepts Identify external interfaces

Define the project need When scoping the project it very important to define the need for the project. Mistakes are made here because most of us define implementation rather than the need. Buying a car is an implementation but getting from point A to point B is the need. Implementation can change based on the need but the need should remain unchanged. Over time the implementation can be taking a bus based on various factors such as cost or available resources but the need remains the same (getting from point A to point B)

If the need changes over time, you might not know what is really needed and you cannot build a product to meet a moving target. Identify the stakeholders The PMBOK defines stakeholders as: "individuals and organisations who are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or successful project completion". The aim of inclusiveness makes the identification of stakeholders important; excluding an important stakeholder can undermine the process. No hard or fast rules exist to tell us whom to involve and how. What we do know is that stakeholder involvement is context-specific; what works in one situation may not be appropriate in another. Stakeholders in a project can include people those who:

Buy it Sell it Use it Train others to use it Design it Develop it Test it Market it Maintain it Expect to profit from it.

Identify project drivers Organisations are driven by many outside influences, e.g., regulations, standards, laws, and other considerations. A major driver for many organisations is the set of existing equipment, software, or processes. Other drivers include security and safety concerns. Depending on your type of business you may be affected by an overabundance of regulations from external organisations. Develop operational concepts Operational concepts bridge the gap between product scope and formal requirements. The operational concepts are plain-language descriptions of user product/system interactions in the life of your product for both nominal and off-nominal conditions. How will it be used, manufactured, tested, installed, maintained, stored, and decommissioned? Operational concepts may be use cases, operation plans, scenarios, or other methods of uncovering gaps in knowledge and scope.

Many great products start with an intuitive operational concept. High-level operational concepts will help in the creation of the project scope. In the beginning, there may be several alternatives the project could select to meet the project need. In fact, the operational concept may exist before the need statement. Scenarios allow different operational ideas to be explored. Then the feasibility of each scenario is examined and more ideas are explored. A needs statement can be written after the scenarios capture the true need. The operational concept, like all other parts described above, is iterative. A single alternative must be selected and reflected in the project scope to ensure that key stakeholders share the vision before requirement capture begins. Identify external interface Serious problems arise at interfaces. The project is particularly vulnerable to interfaces with other products over which you have no control. External interfaces fall into two broad categories:

User (usually a human being) and Everything else

User external interfaces include buttons, levers, handles, straps, warning bells, safety labels, and displayed information. Non-user external interfaces include command, data, operating system, computer system, and existing equipment used with your product. There are several external interface considerations that should be made prior to writing requirements, including the need to interface with a non-standard product, lack of interface documentation, and the risk of changes to products out of your control with which yours must interface. All of this information is vital to the project's risk assessment and change management processes. There are different classes of interfaces you must consider: First, there are fixed interfaces that are well known and unchangeable. Second, there may be existing interfaces that can be changed, either to save money, or because that interface is being updated. The third type of external interface is one that does not currently exist. In both the second and third cases, negotiation must be completed and agreed to as part of the process.

1.7 Conclusion
Projects, like business, often fail because they are not properly managed. Scope Creep is a major aspect of project failure. This can be mitigated by following simple procedures such as having a scope document that all the stakeholders agree on and on having a change management plans if there are supposed to be modifications to it. Manage scope and make your project a part of the successful thirty percent. Project scope management is defined as the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. If the scope is not managed correctly it may lead to an unsuccessful project. This article deals with problems with scope and tools and techniques useful in capturing the project scope. The main points of this assignment can be summarized as follows: Scope creep doesnt exist in agile projects, because scope is expected to change. Scope management in agile is primarily a function of rolling wave planning and the management of the product backlog. Scope is defined and redefined using five different levels of planning that take the team from the broad vision down to what team members plan to complete today. WBSs are not created per se; instead, release/quarterly plans and iteration plans serve to break down the work into smaller work packages, referred to as features and tasks. Scope is verified by the customer, who is responsible for accepting or rejecting the features completed each iteration. Scope is controlled through the use of the backlog, rolling wave planning, and the protection of the iteration.

1.8 References
Project Management: A systems approach to planning, scheduling and controlling, Harold Kerzner, John Wiley & Sons, 1997 ISBN 0471288357 Effective Project Management, 2nd Edition, Robert K. Wysocki, Robert Beck, David B. Crane, John Wiley & Sons, 2000 ISBN 0471360287 http://www.projectmanagementdocs.com/templates/scope-management-plan.html http://www.projectsmart.co.uk/scope-management.html http://media.techtarget.com/searchSoftwareQuality/downloads/Software_Project_Manager_ Agility_CH05.pdf http://www.preparepm.com/notes/scope.html http://my.safaribooksonline.com/book/software-engineering-and-development/projectmanagement/9781933890524/program-scope-management/program_scope_managem