This is final installment of the series that presents the merits of using a WBS when planning your ERP implementation project. In this blog, I describe how to capture everything from the WBS workshop in a chart and using this chart to create your project schedule.
After the WBS Workshop
• Assign a number to each deliverable using a numbering scheme similar to that shown in Figure 1 & 2 below. Figure 1 shows an example of the overall project WBS. Figure 2 shows PHASE 1 being decomposed into another level of detail with each of the three Level 2 deliverables being further broken down into smaller sub-deliverables.
• Document the WBS in a word processor or spreadsheet.
• Print and post it on the wall for the project team to see.
WBS Fig 1Figure 1 – Sample of a Level 2 Project WBS
Fig 2Figure 2 – Sample of Level 3 Detail for Phase 1 of the Project WBS
Some like to show all levels in one diagram for completeness. However, I prefer to show more (Level 3) detail on separate pages for numerous reasons. First, for presentations to the Senior Management team, the overall project level is usually sufficient detail. You can always pull up Level 3 details if needed but more often than not, it isn’t required. Second, it is much less daunting showing the project one level at a time than to show a massive WBS chart. Third, as your project progresses, you can pull out the phase of the project the team is currently working on to help them appreciate what’s immediately in front of them. And lastly, it is easier to maintain individual sheets of the WBS if some of the deliverables change during the life of the project.
The WBS Chart in Relation to the Project Schedule
I have seen many Project Managers start building project schedules (either in a spreadsheet, word processor or project management software) without creating a WBS. In some cases, they’ll use a cookie cutter template schedule where ‘one size fits all’. For an experienced PM, this may be perfectly fine but even then, it assumes that the PM can accurately predict all the nuances associated with the project and/or client.
I suggest that a far better approach is to build the project schedule using the WBS Chart as the basis. You’ll recall the numbering scheme I used in the WBS examples above. I use these same numbers in the WBS column on the project schedule. This logical approach is easily understood by everyone on the project team as they were the ones who help create it. Figure 3 below shows the project schedule that was developed for the WBS from above. I expanded the ‘Project Initiation Documents’ deliverable to illustrate the Level 3 WBS numbering in the schedule.
Fig 3Figure 3 – Project Schedule Derived from the WBS
An ERP implementation requires a significant investment of company resources (people, money, time) and success is never guaranteed. However, the likelihood of success is enhanced when the Project Manager brings the project team together and gets them to work as a cohesive unit.
Planning and conducting a WBS workshop helps the project team and management team understand the implementation methodology. It is an invaluable tool to get the project team working together and without exception, I have learned more about my clients from these workshops, than I could have by creating the WBS on my own. That’s the beauty of this approach. When the project team helps the Project Manager build a better plan, team is far more likely to support it.
In closing, I’ve had many people compliment me on how logical this process is and that it makes a lot of sense. The only problem now is that they have also commented on how easy project management is!
Note about the author.
Brian Sakamoto is a Senior ERP Strategy Consultant for QStrat Inc. He has been implementing ERP solutions since 1995 and he has also held senior management positions in Supply Chain at successful manufacturing companies in the Greater Toronto Area. He is a Licensed Professional Engineer, Master of Business Administration, and a Project Management Professional.