Defining Scope for ERP Implementations

I know that everyone whole-heartedly agrees that having a well-defined ERP implementation scope statement is strategic to success.  However, there are few articles or other resources that provide detailed guidance on building scope statements.  I would like to focus on one key area that is typically not clearly articulated for ERP implementations.

Components of a Scope Statement

There are many tactical objectives for a scope statement (defining a statement of work, supporting change control processes) but the strategic objective for a scope statement is to define focus!  Without focus all other ERP implementation best practices are done in vain.  It is important to not only define what should be the focus of the project team but also to define what should be out of scope.  Following is a summary of the key areas to address in a scope statement.

ERP Scope Definition

ERP Scope Areas

Now granted the above list is not a mind-sweeping revelation with most experience ERP implementors.   However, the challenge I’ve observed has been in clearly defining ERP product scope.   In the next section I will briefly discuss one of the key challenges.

Key Challenges with Scope – Product Features

An area this is typically not defined well is the business processes and ERP product features that are part of the implementation.  Too often business processes and product scope is defined only at the product level (example: we are implementing PeopleSoft Purchasing module).  How can I tell what business activities and features are out of scope?  Developing focus is much harder to develop and maintain.  Following is an illustration of how product scope should be defined our example above .

ERP Product Feature Scope

ERP Product Features – In Scope

Key points:

  • Important that you designate which ERP product functionality is in scope.
  • You need to briefly explain how the product feature supports the business activity.  A scope definition provides less value if the project team and project stakeholders do not understand how ERP will support the business.
  • There may be situations where an ERP product feature is in scope but only limited functionality will be used (example: The project manager cannot be the only role responsible for scope management.  The project team and project stakeholders must take an active role in focusing on scope.
ERP Product Scope - Out of Scope

ERP Product Features – Out of Scope

Key points

  • Important that you designate which ERP product functionality is not in scope.
  • You should define all software features associated with the ERP product.  This exercise will ensure that you have a complete product scope statement.

Project Scope

Project scope refers to the individual implementation tasks that must be performed as part of the ERP implementation.  The challenges I typically see with this area are (1) the implementation activities are not specific and (2) there is no clear, quantitative evidence regarding which party is responsible for performing the activity.  I recommend that the Implementation Partner should provide a detailed project scope statement with responsibilities clearly defined.

ERP - Implementation Activities Scope

ERP – Project Activities Scope

Please do not fall into the trap that ERP scope can be reduced by eliminating implementation tasks (ex. organization change).  Project tasks can be applied at different levels but disregarding activities is a recipe for failure.

Risks of not clearly defining ERP implementation scope

A best practice for any ERP implementation is having a defined scope change control process.  Unfortunately, having a scope change control process without also having a well-defined product scope statement will most likely result in failure.  How can any one identify scope creep no one understands the scope?  It has been my experience that the majority of scope creep starts as discussions outside the standard project meetings where unclear expectations result in losing focus on the prize.  If the first time you hear of scope creep in a change request then you are being more reactive than proactive.  I’m not saying that scope change is wrong or not necessary but I am saying we should do everything in our power to minimize exploring requirements that do not align with the project objectives.  As Barney Fife would say “nip it in the bud”.

Summary

An effective ERP scope statement has to be more than just a document – it has to be a clear vision and expectation in the mind of your project team and business stakeholders.  Scope change control has to be more than a trigger for an Implementation Partner to create a contract attachment to their Statement of Work.  A clearly defined scope statement is a filter that enables business stakeholders, internal IT groups, and the Implementation Partner to align focus for mutual success.

About these ads

About Brett Beaubouef
For the past twenty years Brett has helped customers select, implement, and manage ERP solutions across five industries (manufacturing, professional services, staffing, retail, and telecommunications). Business process knowledge and experience includes human resources, benefits, compensation, recruiting, time & attendance, finance, resource scheduling, contract administration, services procurement, sales, billings, project accounting, and project/portfolio management. Software selection experience includes evaluation of both ERP software and proposed implementation services. Brett has recently authored a book on leading ERP/COTS implementation strategies.

14 Responses to Defining Scope for ERP Implementations

  1. Pingback: Tweets that mention Defining Product Scope for ERP Implementations « ERP the Right Way! -- Topsy.com

  2. Wayne Schulz says:

    It’s been my experience that defining scope is a lot like catching a greased pig. Just when you think you’ve gotten a handle on it something slips away from an unexpected area.

  3. Bocar Diallo says:

    Hi,

    I fully agree with your approach .functionalities are sometime blurred. For Payroll projects in Africa , we don’t have the enhanced retropay functionnality . We take the time to list what the customer can and will do ( and not do ) so things are clear at the beginning .

    Bocar,

  4. TBoehm30 says:

    That is a good list to have, thanks for posting.
    I would add a couple of items:

    Modules to be installed (possibly listed ERP Products and versions but should be explicitly listed separately)

    Legacy data to be transferred. This will prevent people from trying to get transactions loaded when account balances are what you really need.

  5. Gicu says:

    The impression that drive business is in ERP hands is wrong.

  6. Pingback: ERP Application Strategy Roadmap for Maximizing Long-Term ROI « ERP the Right Way!

  7. Pingback: Viable – Manageable ERP « ERP the Right Way!

  8. Very informative blog over ERP Implementation . I like this blog. Keep blogging.

  9. Pingback: Defining Product Scope for ERP Implementations | Pardaan.com

  10. Pingback: Building a Better ERP Estimate « ERP the Right Way!

  11. Pingback: Building a Business-Aware Cloud Solution « ERP the Right Way!

  12. Pingback: ERP Implementation 101 – Deployment vs Requirements Gathering | ERP the Right Way!

  13. Pingback: Troubleshooting ERP Projects | ERP the Right Way!

  14. Pingback: Fusion Weekly Issue #21 – 20th September 2013 | The Fusion Weekly Newsletter

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 4,404 other followers

%d bloggers like this: