Contact QSTRAT   +1-866-762-3090

The WBS – A Key to ERP Implementation Success (Part 1 of 3)

The author of this entry,  Brian Sakamoto,  is a senior ERP Strategy Consultant with QStrat.


Earlier in my career as an ERP Functional Consultant, I would watch the Project Manager explain to clients our proven methodology for a successful ERP implementation. Phrases such as, ‘Shoulder-to-Shoulder’, ‘Conference Room Pilots’, and ‘Cutover’ were common speak those days. In all cases, I believe that the clients understood the general idea of the terms and undoubtedly formed an interpretation of what these events entailed. The PM would then map out the series of events in a spreadsheet for the client understand the relationship and interdependencies of these events. Still, I often got a sense of trepidation from the client as they put their trust in the PM to help them through this mind-boggling initiative. This article describes a project planning approach that I have used many times as an ERP Project Management Consultant to help alleviate anxiety experienced by a project team.

Over the years, I’ve had the good fortune of working with some excellent Project Managers and Senior Project Advisors and together, we achieved more than two dozen successful end-to-end ERP implementations. In my last ten years as a Project Manager, I adopted many of the tactical strategies used by my predecessors. However, it wasn’t until about five years ago when I was studying for my Project Management Professional exam, that I realized that I could use this thing called a Work Breakdown Structure (WBS) to help better organize and systematize my projects.   Also, I could use it as a vehicle to engage and educate a project team.

Nowadays, I conduct a WBS workshop early in the project to layout the framework for the ERP implementation and more importantly, to alleviate some of the client’s trepidation that I mentioned earlier. In this series of three articles, I present the following:

  • Definition of WBS
  • Conducting a WBS Workshop
  • Benefits of a WBS Workshop
  • Creating a WBS Chart
  • WBS Chart in Relation to the Project Schedule
  • Conclusion


Definition of WBS

The definition of Work Breakdown Structure is best described in Project Management Institute (PMI) Project Management Book of Knowledge (PMBOK), 4th Edition:

Create Work Breakdown Structure is the process of subdividing project deliverables and project work into smaller, more manageable components. The work breakdown structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables, with each descending level of the WBS representing an increasingly detailed definition of the project work.1

A key characteristic of WBS components is that they are described as nouns, NOT verbs. Examples of WBS components are documents, budgets, plans, hardware, software, and analysis. WBS components are not actions or activities. Words such as develop, train, review, write, or configure should not appear in the WBS because they are not considered tangible deliverables. These are verbs that achieve tangle deliverables. The distinction is small but it is important to remember when developing the WBS.

1 Ref. Project Management Institute: A Guide to the Project Management Book of Knowledge, 4th Edition. p.116


By decomposing an ERP implementation into smaller and more manageable series of deliverables, the project starts to become less daunting. Further decomposition of those deliverables into even smaller components makes it easier to wrap your arms around and assign to specific team members to deliver.

So, how far do you go? Well, the answer to that question largely depends on the Project Manager’s comfort and confidence that the team members responsible for the deliverable can complete it accurately and on time. If the component is large and complex, and requires many people to deliver, you should consider further subdividing the task. If the task is straightforward and predictable, the component can be left as is. My personal ‘rule of thumb’ is that if I am not confident it can be completed without me having to micromanage it, it should be broken down into smaller components.

You may be left wondering if you’ve captured all the necessary deliverables for the implementation. Well, that’s where you’re going to call on your project team for help by having them participate in a WBS workshop. That is the topic in my next article.

Leave a Reply