Privacy Policy Update Notice:

Sage North America updated its Privacy Policy on August 18, 2011. With this update, we made changes to the "Business Information Collection and Use by Sage" section of our policy to explain that our websites ("Sites"�) may use third party Internet advertisers that deliver custom ads to you. Such custom ads are based on information collected through cookies and web beacons when you visit our Sites. Please note that Sage does not control Internet advertisers' use of cookies or information collection. We also explain how you can opt-out of Internet advertisers' information collection. Click here to learn more. Sage North America values your privacy and is committed to maintaining your trust. Please read the full updated Privacy Policy, as you are bound by its terms when you use our Sites.

Close Privacy statement

Email this page to a Friend

Found this page interesting? Send it to your friend or co-worker by filling out this form. Add a personal message if you like.

Note: We will not use these e-mail addresses for any other purpose than sending your e-mail.


------- Privacy Policy Update Notice

How to Effectively Scope Your ERP Project

5/25/2010 at 3:31 pm by

You may have heard the saying: “How can we all be on the same page if there is no page?” This is especially applicable when undertaking an ERP implementation. Having a well-defined and written scope of work can mean the difference between a failed project with disastrous results, and a highly successful project with huge benefits. Assuming you prefer the latter, let’s look at what a good scope of work includes.

Anatomy of a good scope document
While each ERP consulting firm will have their own variations on their scope of work definitions, generally you should look for a table of contents that covers the following major areas:

Scope Statement
What is the project overall, when will the project be complete, how much will it cost, and most importantly, how does it meet the company’s strategic goals.

Objectives
Don’t confuse these with goals. Objectives are specific action items that will be taking place during your project. For example: install product X, convert data, provide training, develop custom reports, etc. Objectives should be focused around action items that solve specific problems and achieve desired results.

Project Risks and Mitigation
Making sure you proactively identify the things that can derail your project is critical. These can be things such as a key project manager leave during the project, unrealistic workloads, lack of proper hardware, communication issues, funding issues, etc. Each risk should be clearly stated along with how each will be monitored to help ensure project success.

Roles and Responsibilities
Basically, who is responsible for what. Be sure to list names and contact information for each person and define their functional role for each area of the project. Some example roles include project sponsor, key advisors, project owners, etc. Roles should also cover functional areas such as IT, financials modules, operational modules, sales force automation modules, etc.

Assumptions
This may seem, well, assumed, but often what isn’t said is the thing that gets you into the most trouble. The ERP implementation consultant may be assuming you are doing all data entry tasks, and you may be assuming they are. Be sure to identify as many assumptions as possible to avoid misunderstandings and project delays.

Deliverables
These are documents used by the team to achieve the objectives of the project. An example would be the scope of work document, project plans, training manuals, issues lists, etc. Deliverables are not the end result of the project, they are the written tools used to accomplish it.

Functional Requirements
The devil is in the details… and this is where they should be listed. Each functional requirements should be stated by functional area (such as general ledger, accounts payable, inventory control, etc.) and define details such as:

  • Manual input required
  • Data to be converted
  • Required reports
  • Interfaces to other systems
  • How this area will affect changes in current business procedures

Project Change Control
You can count on something coming up you didn’t anticipate. Since you know it’s going to happen, now’s the time to define how that should be handled. Clearly state who is authorized to request changes and as importantly, who approves them. A change request form should always be completed for any change, even if it doesn’t involve a dollar amount, such as changes to go live dates.   

Issue Escalation Procedures
If there’s a problem, does your team know who to go to next? You’ll want to clearly state how an issue should be escalated and to whom. The last thing you need is a problem quickly getting out of hand and turning into a bigger issue than it should.

Future Projects
This can probably be better stated as “what is not included.” If you are building a technological foundation for a second phase, future project or business strategy, list it here. It’s important that everyone works with an “eye” towards future goals and plans accordingly.   

In summary

Professional ERP implementation consultants know that the best projects are those where the customer takes ownership. Since most clients don’t know all the steps to implementing a new system (hence the reason you hired the consultants), the scope and work plan are your guiding light throughout the process.  Your ERP implementation consultant should be ready, willing, and eager to help you define a proper scope and work plan.

photo credit: viZZZual.com

Related Posts Plugin for WordPress, Blogger...
About the Author

Copyright / Trademarks - Privacy Policy

Email this page to a Friend

Found this page interesting? Send it to your friend or co-worker by filling out this form. Add a personal message if you like.

Note: We will not use these e-mail addresses for any other purpose than sending your e-mail.