Workday Project Scope – How to know where the boundaries are?

Author Emma SauzaEmma Sauza
Date November 16th, 2020

A Project Scope should ensure that all of the required work and only the required work necessary to complete the project is accomplished (PMI, 2004, p103) meaning that any work that does not support the needs of the project is Out Of Scope and should not be performed. This seems like an obvious concept, but unfortunately, only 29% of projects are completed successfully, meaning that the remaining 71% either fail outright or are “challenged” – completed over budget, behind schedule, or deliver fewer features and functions than the Customer expected (Standish Group, 2004). One of the top factors for project failure is the incorrect definition and understanding of Project Scope.

Setting the Project Scope 
Effectively establishing and managing the scope of a Workday project is key to success, but, at the same time, is one of the most challenging responsibilities for both the Consultants and the Client.
The establishment of the project scope starts during the sales meetings and is officially set up during the Customer Scope Review Meeting in the Plan project phase. The document that comes out of that meeting is called the Project Scope Statement.
The Project Scope Statement provides a baseline understanding of the boundaries of your project to include the project’s scope, the work required to complete the deliverables, and ensures a common understanding of the project’s scope among all stakeholders.  You must be aware that any work not explicitly included in the Project Scope Statement is implicitly excluded from your project, although, this is a living document and could be updated as change orders are added, by the agreement of both the Client and Consultant of course. 
Project Scope Statement
The Project Scope Statement provides the definition and deliverables for the following:

  • Business Need  List of Requirements that need to be addressed.
  • Project Objectives and Justification → Contains objectives and why they are important, if available, measurement methods and your  success criteria can be included.
  • Scope Description → Includes characteristics of the product, service, and/or the results it will produce. 
  • Project Strategy → Provides an overview of how the project will be conducted.
  • Project Schedule → Links to high-level timeline for the project.
  • Project Exclusions → Lists the boundaries for the project, includes what needs to be specifically called out as not in scope.
  • Project Constraints → A list of any limits, deadlines, resource restraints … that will govern the approach that  will be taken to complete the project.
  • Project Assumptions → Statements on how uncertainty will be addressed during plan, testing and project deployment. 
  • Project Risks and Mitigation → Includes the risks identified after each phase of the project is completed.
  • Change Orders → Provides the Change orders’ numbers that may result in a change in project scope after their approval. Change orders may have an impact to both schedule and budget.

Types of Project Scope
There are 6 types of scope:

  • Core Functional Scope contains the functional areas that are standard in the regional packages, such as Core HCM, Absence, Financial Accounting, Banking & Settlements, Customers and Suppliers.
  • Add-on Functional Scope gives you the option to pick and choose add-on Workday functionalities such as Time Tracking, Recruiting, Talent, Advanced Compensation or Expenses.
  • Additional Functional Scope is an option if the functional scope packages contain a gap in business critical requirements, such as additional countries, additional financial institutions, additional reporting or additional historical data conversion.
  • Additional Package Scope includes items that require extended timelines, some examples are Unions, Project Billing, SFDC Integration, and translations.
  • Data Conversion Scope & Integrations  are two additional types of scope that cover the technical piece.

How to identify and manage Scope Creed? 
Balancing a fixed scope against business needs can sometimes prove to be difficult. Scope creep can be any item not specified in the Project Scope Statement that is found once the project begins.
Scope creep can result from some common factors such as new or expanded requirements, acquisitions or divestitures, undefined or redefined processes, changes in pre/post-test requirements, extended data conversion and testing and training preparedness. Therefore, it is important to to identify and understand the out-of-scope item in order to determine the complexity and level of effort required to integrate it and be aware of any risks, issues, and costs associated with the new scope item.
The additional scope item has to be summarized and presented by the consultant and  it is up to you to decide if you would like to proceed with a change order to document the additional cost and potential timeline push. It is very important to be aware of the changes and challenges that an out-of-scope item approval may carry, in most cases a new scope item can significantly affect the initial project plan timing and a replanification must be carried out in order to assign new resources that may not be available for future dates.
Key Takeaways 
Defining the Project Scope in a collaborative environment provides several advantages to the project team. Clearly state, document and ensure a common understanding within all stakeholders of Project Scope minimizes overlooking decisions, increases alignment on the project scope deliverables, and reduces confusion related to what ideas or decisions mean, avoiding any additional costs and timeline pushes. A realistic and achievable Project Scope Statement is key for Project Success.

Get in touch with us.

Fill out the contact and someone from our team will get in touch with you as soon as possible.