SPONSORS

SPONSORS

Scope Change Control Process

 

Project Workflow Management

SERIES ARTICLE

By Dan Epstein

New York, USA

 



Note:
 This article is based on the book Project Workflow Management: A Business Process Approach by Dan Epstein and Rich Maltzman, published by J Ross Publishing in 2014. The book describes PM Workflow® framework, the step-by-step workflow guiding approach using project management methods, practical techniques, examples, tools, templates, checklists and tips, teaching readers the detailed and necessary knowledge required to manage project “hands-on” from scratch, instructing what to do, when to do and how to do it up to delivering the completed and tested product or service to your client.

The project workflow framework is the result of Dan’s research into the subject, having the following objectives:

1. Create the virtually error-free project management environment to ensure significant reduction of project costs
2. Reduce demands for highly qualified project managers using
the step-by-step workflow guiding approach.

While PM Workflow® is the continuous multi-threaded process, where all PM processes are integrated together, this article will attempt to describe the Scope Change Control group of processes as a stand-alone group of processes that can be used independently outside of PM Workflow® framework. It will be difficult in this article not to venture into processes outside of scope change processes, such as planning, quality, communications and other management processes, so they will be just mentioned. However, to get full benefit and the error free project management environment, the complete implementation of PM Workflow® is required.

In order to understand how PM Workflow® ensures this environment, I strongly recommend reading my article Project Workflow Framework – An Error Free Project Management Environment. in the PMI affiliated projectmanagement.com (https://www.projectmanagement.com/articles/330037/Project-Workflow-Framework–An-Error-Free-Project-Management-Environment)

The article above provides the overview and explanation of how the project workflow framework works and achieves the established objectives.

For more information, please visit my website www.pm-workflow.com


Scope Change Control (P7)

Purpose

The project scope, as opposed to the product scope, is the work required to deliver the solution to the client. The product scope is the scope of the business solution, described in the Business Requirements Document. Any change in business requirements is a product scope change, which will lead to the change in the required project work. Usually, the project scope change term is used for business requirements changes.

The purpose of the Project Scope Change Control process (P7) is to manage changes to business requirements and design and their effects on the project. The P7 process is also used when changes are required in the project cost and schedule due to the project’s poor performance. The Project Scope Change Control process ensures that:

  • Changes are identified, analyzed, approved, planned and implemented.
  • Project stakeholders are fully aware of all changes
  • All Scope Change Requests are documented and the approved changes are entered into the project plan

The Scope Change Control process is activated when the request to issue a new Scope Change Request (SCR) is initiated by any of the following:

  • Client’s team member
  • Delivery team member
  • Any stakeholder
  • Issue Management process
  • Legally mandated requests

In order to get scope change analyzed, planned and implemented, the Scope Change Control process interacts with other processes in all project process groups (frames).

Scope Change Control Process

The Scope Change Control process describes the interaction details between the delivery and client teams at the time when a project scope change is required.

It happens too often that clients directly request the delivery team members to implement scope changes, rather than following the scope change process. This is especially true, but no less insidious, when the scope changes are small. If team members accept it for implementation, the consequences of such requests – also called collectively “scope creep” – may be very grave and may cause one or more of the following problems:

  • Undocumented changes that could have significant technical, business, safety, environmental, social, and/or legal implications.
  • The scope change is implemented without the scope change requirements analysis.
  • The cost of implementing the change is not covered by the existing budget.
  • The implementation of the change is not incorporated in the project plan. Due to project dependencies many other project activities may slip the schedule or require extra work as a consequence of the changes. Even if the change takes only a few hours to implement, there may be many other project tasks delayed hours each. This delay may easily cascade and be multiplied several times in the overall effort to incorporate the change, causing significant overall project slippage. The later in the project cycle the change is requested, the greater the cost and the greater the overall impact to the project.
  • If the impact of the scope change on other tasks and projects is not thoroughly investigated, this may affect not only the project, but the steady-state operation of the organization.

Therefore, the Project Scope Change process must be strictly followed by both the client and delivery team members. This must be made very clear to everybody. Rules for the enforcement of the Scope Change Process must be included in the Statement of Work. Also, the delivery team members must be specifically instructed not to accept new change requests or modifications from anybody except project manager or specifically authorized personnel.

Considering that some clients and delivery team members may find it difficult to follow the change request process flow chart at Figure 10-1, the following description attempts to resolve this potential issue. This description should be included in the Statement of Work. The process comprises the following steps:

More…

To read entire article (click here)

 

Editor’s note: This series of articles is based on the book Project Workflow Management: A Business Process Approach by Dan Epstein and Rich Maltzman, published by J Ross Publishing in 2014. The book describes the PM Workflow® framework, a step-by-step approach using project management methods, practical techniques, examples, tools, templates, checklists and tips.  The book teaches readers how to manage a project “hands-on” from scratch, including what to do, when and how to do it up to delivering a completed and tested product or service to a client.

How to cite this article: Epstein, D. (2018). Scope Change Control Process, Series on Project Workflow Management; PM World Journal, Volume VII, Issue X – October. Available online at https://pmworldjournal.net/wp-content/uploads/2018/10/pmwj75-Oct2018-Epstein-scope-change-control-process-series-article.pdf

 



About the Author


Dan Epstein

New York, USA

 

 

 

Dan Epstein combines over 25 years of experience in the project management field and the best practices area, working for several major Canadian and U.S. corporations, as well as 4 years teaching university students project management and several software engineering subjects. He received a master’s degree in electrical engineering from the LITMO University in Leningrad (today St. Petersburg, Russia), was certified as a Professional Engineer in 1983 by the Canadian Association of Professional Engineers – Ontario, and earned a master’s certificate in project management from George Washington University in 2000 and the Project Management Professional (PMP®) certification from the Project Management Institute (PMI®) in 2001.

Throughout his career, Dan managed multiple complex interdependent projects and programs, traveling extensively worldwide. He possesses multi-industry business analysis, process reengineering, best practices, professional training development and technical background in a wide array of technologies. In 2004 Dan was a keynote speaker and educator at the PMI-sponsored International Project Management Symposium in Central Asia. He published several articles and gave published interviews on several occasions. In the summer of 2008 he published “Methodology for Project Managers Education” in a university journal. His book, Project Workflow Management – The Business Process Approach, written in cooperation with Rich Maltzman, was published in 2014 by J. Ross Publishing.

Dan first started development of the Project Management Workflow in 2003, and it was used in a project management training course. Later this early version of the methodology was used for teaching project management classes at universities in the 2003–2005 school years. Later on, working in the best practices area, the author entertained the idea of presenting project management as a single multithreaded business workflow. In 2007–2008 the idea was further refined when teaching the project management class at a university.

Dan is an author of many publications in professional magazines, speaker at the international presentations, a guest at podcasts, etc. The Project Management Institute’s (PMI) assessment of his book says: “Contains a holistic learning environment so that after finishing the book and assignments, new project managers or students will possess enough knowledge to confidently manage small to medium projects”. The full list of his publications and appearances can be found at the website www.pm-workflow.com in the Publications tab.

Dan can be contacted at [email protected].

To see other works by Dan Epstein, visit his author showcase in the PM World Library at https://pmworldlibrary.net/authors/dan-epstein/