Welcome to the BPR Tutorial Series

Home - Bookstore - Tutorials - Best Practices

Send this page to a friend

header21.gif (4805 bytes)

 

New Series - Effective Project Planning and Startup

Module 2: The Importance of Scope and Objectives

This is the first tutorial in a series dedicated to project planning and startup.  Module 1 introduced the project plan.  Module 2 discusses the importance of scope and setting clear objectives.  Module 3 provides considerations for your project team membership.  Module 4 examines the effective use of consultants.  Module 5 addresses your project approach and methodology.  Module 6 summarizes the importance of effective planning and provides tips for successful planning.  This tutorial series is taken from Prosci's Project Planning Toolkit which includes a complete project plan template.

Email this page to a friend

 

Defining the project scope

The project scope is the boundary that tells where the project begins and ends. Throughout the charter of the project and discussions about the business problems and opportunities, you may feel that everyone is viewing the project the same. However, many times there is confusion about what falls inside the boundary of this specific project and what does not. Developing a solid project scope and socializing it with your project team, sponsors and key stakeholders is critical. Research with 327 project improvement teams showed that clearly defining scope and objectives was in the top-3 most important start-up activities.

A common mistake made by project teams is to define their project scope only in general terms. This lack of definition causes managers and key stakeholders throughout the organization to make assumptions related to their own processes or systems falling inside or outside of the scope of the project. Then later, after significant work has been completed by the project team, some managers are surprised to learn that their assumptions were not correct, resulting in problems for the project team. Other project teams report problems with "scope creep" as their project gradually takes on more and more work.

This tutorial provides guidelines and examples for establishing your project scope in a way that will minimize these problems.

 

A process perspective

It is helpful to define the scope first from a "process" perspective, clearly stating where the process begins and where it ends. Although your scope will include organizational and technical components, a process perspective provides the best and most focused definition of what is changing and what is not changing. It will also help you avoid miscommunications that can occur when a particular system or organization is the focus of the change (i.e. what inside the organization will be changing).

Example

The process to be redesigned begins with the receipt of an order and ends with the completed order received by the customer.

Defining the scope clearly helps the team focus on what the project is about, and also speeds the learning and design phases. A process orientation also helps avoid scope creep that is possible when scope is only defined based on organizations or systems. Once you have defined the scope based on the business processes, you can then add the scope definition of organizations and systems based on these processes.

To help you define your scope, answer the following questions:

  • What processes are included in the scope of our project? What processes are NOT included in the scope of our project? Where does each process begin and where does each process end?

  • What systems used in these processses are included in the scope? What systems used in these processes are NOT included in the scope?  Note: some legacy systems may be out of scope because of the embedded investment in these systems, or because the systems are used by other organizations that are not in the scope of the project.

  • What organizations involved in these processes are included in the scope? What organizations involved in these processes are NOT included in the scope?

Optional: you may also want to state if the project includes process design, process and systems design, or process, systems, and job role design if you know this information at this stage of the project.

Example

The process includes the work processes and systems required to fill the order. The process does not include the manufacturing activities required to make the product, or the billing process.

Organizations involved include order processing, logistics and shipping. Organizations not involved include manufacturing and accounting.

The current personal computers and LAN architecture are part of the project scope. The database server and database application are also included. The customer contact software is not part of the project scope.

 

You are writing this scope section to avoid surprises and clarify assumptions. Clearly setting expectations is important for you and the project stakeholders. Draw a high-level diagram of the current processes and illustrate the process scope boundaries with a dashed line. People learn differently and pictures often raise questions that are overlooked when you use only words to describe the project scope.

Review the project description and scope statement with the project team members and project sponsors (key business leaders for the project).

 

Establishing project objectives and conditions of satisfaction

Many project teams can describe their general objectives, but fail when it comes defining what success looks like. Moreover, they often miss the opportunity to discuss and negotiate these conditions of satisfaction with their customers and stakeholders. Objectives that include general statements like:

  • increase customer satisfaction
  • reduce costs
  • increase revenue
  • reduce employee turnover

are important as a general direction, but they lack specifics and the ability to measure success. It is critical to include two additional elements to your objectives: by how much and when. "By how much" is the specific numeric goal that you are aiming for. "When" is the time frame that this goal will be reached. Both of theses elements constitute how success will be measured, and become an agreement between the project team and the stakeholders as the conditions of satisfaction for each objective.

Example

The project objective is to totally redesign the order taking and fulfillment processes and systems to increase customer satisfaction and reduce operational costs. Conditions of satisfaction include:

  • project completed in 120 days
  • employee satisfaction with work tools and processes increased from 40% very satisfied to 80% very satisfied by 6 months after the processes are in place
  • customer complaints reduced by 50% by 6 months after the new processes are in place
  • operating costs reduced by 20% by 3 months after the new processes are in place

 

The creation of project objectives is a negotition process, beginning with the project team understanding the business issues and opportunities from the perspective of the business leaders. The project team then creates the project plan, identifying the project scope and specific objectives that they believe their project will achieve. The project team should include in this first draft both the general objectives and the conditions of satisfaction for each objective (how much and when). The business leaders or executive sponsors then review this project plan and share their input on the project objectives and scope.

It is through this negotiation that the project team and the project sponsors align themselves for a good project start. This early engagement also builds ownership and buy-in to the project with key stakeholders in the organization.

 

Coming up next: selecting the best team members for your project

Send this page to a friend


If you do not already receive new tutorial announcements, register for free with the Learning Center announcements and special offers.

 

Books and resources for project teams:
  • Project Planning Toolkit - this toolkit provides guidelines for successful project startup. Topics include writing your project plan, methodology selection and team creation. The toolkit includes a comprehensive Project Plan template.

  • Best Practices in Business Process Reengineering - this report gives team members, project leaders and executive sponsors a first-hand account of what is working and what is not, combining data from three benchmarking studies (1997, 1999 and 2002) to present the most accurate, up-to-date picture of process redesign and reengineering projects as well as insight into the evolution of business process design.

  • Change Management Toolkit - designed for project teams chartered with implementing a change.  Assessments, guidelines and worksheets help you develop a change management strategy and plan.  Covers team structure, sponsorship, communication, training and rewards and recognition programs.

  • Best Practices in Change Management - presents comprehensive findings from 288 companies on their experiences and lessons learned in change management. This report makes it easy to learn change management best practices and uncovers the mistakes to avoid when creating executive sponsorship.

 

 


The BPR Online Learning Center offers several sources to help with reengineering and business process design projects:

 


Sign up to receive free tutorials, announcements and news as a member of our Learning Center community.

Email  

 


Send questions to bpr@prosci.com

HOME

 

BPR Online Learning Center is sponsored by Prosci.  Copyright 1996-2003. All Rights Reserved.

Tutorials | Bookstore | Benchmarking | Yellow Pages | Register | Comments | Home Page

 

970-203-9332 or (800) 700-2831 in the USA