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.
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 .
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.
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.
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.
Join the community! 10k followers across 100 countries!
Leave a Reply