In many cases, the ERP project plan is not worth the paper on which it is printed. Worse yet, many project managers shoot themselves in the foot because they prematurely commit to a project schedule and budget that sets unrealistic management expectations. Once cast, expectations will not go away and only come back to haunt you later. Could this be one reason why many ERP projects fail?
Even when the schedule and budget are formally published, many plans are quickly tossed out the window because they do not adequately define project scope (and boundaries). In other words, we need a project scope, schedule, and budget that closes expectation gaps.
Project scope not only drives baseline project schedule and budget; it also sets user expectations for the software functionality. When users are later told that something they need is out of scope, the project will deal with unhappy users or scope creep, resulting in surprise cost and schedule overruns.
Finally, a good scope document represents a major tool for the project manager to control the project. Like a referee in a football game, the project manager needs to be able to throw the yellow flag. However, it is always best when all parties involved understand the rules of the game before the ball is put into play.
Purpose of This Project Scope Article
The purpose of this article is not to imply good or bad scoping decisions. Rather, the goal is to assist the practitioner in understanding the key elements of scope, potential implications, and right expectations. The practitioner can then develop a real schedule and budget that people can support. After all, it is people who must make this plan a reality.
I make reference to the dimensions of project scope. This is because scope and boundaries do have dimensions in terms of different views of the project and level of detail. With regard to the actual deliverable, most of the dimensions below should contain a list of items, and each with a degree of complexity or effort (high, medium, or low). In the next blog entries, we will discuss how to use this information to develop a project schedule and budget.
The Thirteen Dimensions of ERP Project Scope and Boundaries
1) Align Scope with Project Objectives
Most organizations implement ERP for business reasons. Therefore, project objectives (what you want to accomplish) must initially drive project scope, not the other way around. You should not proclaim the project will solve all the world’s problems while limiting scope to the barebone necessities to get the software running on the computer. This is where rapid deployment strategies get into trouble since they are designed to limit scope for the sake of time and cost (though outcomes are far from guaranteed).
Furthermore, many who desperately cut scope last minute to get back on schedule do so without a full understanding of the original objectives (which are now compromised). Therefore, if scope is to be cut halfway through the project, objectives and expectations must be realigned with the new reality.
Too much scope beyond what you need required to achieve objectives (and for the software to function effectively) is not a good thing, either. Limiting scope is usually not a popular philosophy among users, but a necessary one since scope creep is inevitable to some degree on any project. Therefore, you need to condition managers and users early on that the system is not intended to be “all things to all people,” so expanding scope will not be easy. In fact, once approved, any proposed changes must be business justified and approved by senior management.
2) The Number of Sites Involved
For the purpose of this discussion, a site is defined as: 1) a physical location, or 2) a logical site. For example, a location could have more than one “business unit,” each having its own customer service group using the same software. In multisite scenarios, the scope issues are threefold.
First is the coordination and communication effort that you need to keep all team members, key managers, and users on the same page. Not to mention, I have found that politics and fingerpointing among sites slows progress in any multistate implementation. This does impact project effort and how quickly things move along.
It gets worse when the same software module is to be installed in more than one site. In this case, decisions regarding “common” versus “unique” requirements at each site are necessary– and this takes time. This also encourages businesses to treat a given process at each site as a single or separate process from a design and setup perspective. In any event, if the plan is to reinvent the wheel for each site, this will increase complexity, schedule, and cost (scope).
Finally, each scope dimension below should be defined at the site level (if the goal is to get a good picture of what the project truly entails).
3) Software Modules
The modules to include in scope drive the overall footprint of project. No doubt, this is one of the first steps in addressing scope. Unfortunately, when some put a project plan together, the software modules in scope are one of only a few things considered.
Without further definition, we struggle understand what modules mean from the standpoint of establishing expectations with users and estimating project duration and budget.
Beyond the fact that modules lack sufficient detail, some modules are more involved than others. For example, anything with the word advanced in front of it usually requires more complexity, more risk, more time, and more money.
In addition, whether a module states it is advanced or not, some modules are inherently more difficult to implement for most organizations. As an example, the Purchasing module in most packages is usually less of an issue than the Sales Order module. This of course is not universally the case, but level of complexity should not be ignored.
4) Key Features and Functions within Each Software Module
This is a lower level of software detail that many overlook. Each module has features, functions, and capabilities. You should always consider which capabilities you want up front. Otherwise, consultants and the team will waste time and money setting up software functionality that client management has no intention of implementing (or adds little value to the overall objectives). Granted, some discovery may be required to understand the applicability of features. However, this is different from going far down the road spending time on features of marginal value.
5) Business Processes
The client must identify the business processes to automate. In doing so, one must get into the sub-process level. For example, “Procure-To-Pay” is a major business process; but this alone does not tell the story. When we go to the next level, it starts to have meaning.
Within this major process, some of the sub-processes include the following: 1) Quotation process, 2) Requisition/Approval process, 3) PO process, 4) PO Receipt process, 5) Invoice/Voucher match process, and 6) Payment process.
6) Business Process Variants
All too often, people assume a particular sub-process (examples above) represent a single workflow. However, nothing could be further from the truth. A simple example is “receipt of a purchase order.” Most companies receive many types of purchase orders that they receive and transact very differently (and for good reasons).
As a result, parts of a sub-process may require unique analysis, system set-up, and testing to the point they should be treated as separate sub-processes (or perhaps children of a sub-process). No matter what we call them, when included they expand scope and must be recognized.
7) Degree of Business Process Redesign Anticipated
It is one thing to say a business process is in-scope, but again, this is only half the story. Business process redesign is similar to the complexity factor, but I like to highlight it separately because it can have huge project implications.
For each business process, you should ask the following questions: “How convoluted is the current business process? Does it need significant reengineering? Am I planning to implement an entirely new operating philosophy? On the other hand, am I attempting to automate a current process that is well defined and works well today?”
There is no right or wrong answer here, but the more you redesign a process, the more decisions you need to make, the more design work you need done, the more issues and unknowns you face, and the more testing required. There is nothing unusual about any of this, but there is no way around it. When processes require significant changes, schedule and budget for it accordingly.
8 ) The Number and Complexity of Data Conversions
In scoping conversions, get to the level of understanding the key files in the new software (target system), where the data is coming from (source system or otherwise), and how it is going to get there (manual or automated). Also, do not forget how history records are to be addressed (if at all).
The level of effort comes into play with the following considerations: 1) Source data cleanup required prior to converting, 2) the format of key fields in the existing system and the need to get the data into the format of the new software (not only field sizes for important data items, but also how the data is used within the business), 3) the anticipated complexity of the conversion process, program logic required, and level of effort to test, and 4) loading data manually versus writing conversion programs.
9) The Number and Complexity of Interfaces
Businesses almost universally underestimate the time and cost to design, develop, test and maintain interfaces between other systems and the new ERP system. The cost issue includes design and mapping of interfaces, third-party developers, or additional middleware required (software and hardware). From a quality standpoint, even when thoroughly tested, no interface is fail proof.
Therefore, you should aim to replace as many legacy systems as possible within each project phase to minimize or eliminate temporary interfaces (that exist only during the transition) and permanent interfaces (to legacy systems deemed outside the final project scope). This tends to be the case even when you need a few modifications to the new software to replace the legacy system.
Expanding the number of modules (to eliminate interfaces) is a trade-off between interface scope and additional module scope. From a user perspective, interfaces are usually assumed the path of least resistance, but often times they later find out this is not the case.
Each interface and the level of complexity should be documented in the project scope. When identifying interfaces, realize there may be more than one interface between two systems (and some going in opposite directions). Therefore, what may initially appear on the surface as a single interface may actually be two or more interfaces.
Do not forget one-off databases in the user area that are out of scope but linked with the legacy system. They may or may not be supported by the IT department, but nonetheless can be critical to the business. Also, you must acknowledge interfaces to other new third-party software or hardware included in scope.
It can get worse. Interfaces may force customization to the target or source system to add additional fields and screens to either system (to support the data needs of the other system).
Finally, the complexity issue includes (but is not limited to) the frequency of the interface, real-time or batch updates, sequencing and dependencies of data transmissions, and data format issues that impact the complexity of interface program logic (similar to data conversions). The question from a user standpoint: Must the users work in both systems (instead of one today)? If so, for how long?
10) The Number of Reports
You should estimate the number of reports since the accumulation of all reports can represent a significant effort. First, get a complete list of reports (from all current systems to replace), the distribution list for each, and the frequency of usage.
Ask the users to review the list and comment on what reports they must have within the new system. This will eliminate many reports that exist today. (At this point, we are trying to estimate. It is okay if the revised list from the users is full of assumptions.)
Next, analyze the list to see if the must-have reports can be combined or eliminated by standard reports from the new system (or with slight modifications). In some cases, the availability of data online (or via spreadsheet user downloads) from the new system eliminates the need to write reports. Once you accomplish this task, the list should be more manageable.
Finally, add a contingency of about 15-20% to cover new reports the team or users will eventually ask for once they figure out the additional information available in the system.
11) The Number of End-Users
Whether there are twenty end-users or a thousand end-users, the team still must do all the process and software work for implementation. However, the number of end-users impacts the number of key users to be heavily involved. Of course, the more people involved, the greater the scope. Not a bad thing, just reality.
The number of end-users also affects the end-user training timeline and resources. During the planning phase, you need to get a handle on training time and resources requirements. Think of this as a rough-cut end-user training plan (not a detailed training schedule). Do not wait two months before training to start this planning.
The project team must train end-users as close to go-live as possible. Training more than three or four weeks prior to go-live is a problem since users will not retain what they learned. The more one compresses the timeline to meet this objective, the more resources they typically need.
This time constraint could drive the need for more trainers since some training sessions may run concurrently. It can also impact the number of facilities, equipment, and other resources that otherwise could become bottlenecks. Therefore, one must consider the trainers and resources now to get the right people involved early on, estimate a duration for end-user training in the schedule, and properly budget for it.
12) Software Customizations or Enhancements
Most know by now software mods (customizations or enhancements) increase risk, time, cost. In addition, mods can negatively impact software quality. Therefore, eliminating or keeping them to an absolute minimum is always recommended. However, in the real world, organizations need to make mods occasionally. The question is: How do you handle them during the scoping and planning phase of the project?
Here is the answer: After evaluating software, when you believe you need mods, do not automatically include them in the project scope unless all of the following apply:
A. Software limitation is verified
Early testing/verification (immediately after the software evaluation) has been performed to confirm the software limitations exposed during the evaluation.
B. Functionality is linked to key project objectives
The proposed mod is deemed by management as critical to the success of the project.
C. It is understood what is required and how the mod is to be made.
The mod is defined in terms of specific functionality, external design attributes (screens and logic), and how the mod will be accomplished from an internal design standpoint. Internal design asks, “Are we proposing outright customizations to existing programs and tables? Or changes through more external enhancements that integrate with the system while attempting to minimize the impact on existing programs and tables?”
D. The Mod is pre-approved for scope planning purposes only
Management has pre-approved the mod with a full understanding of alternative solutions and project impact (extra time and cost). Pre-approval means the mod is recognized as in-scope and included in the schedule and budget, but no coding is allowed to proceed at this point.
E. No other viable solutions are available
The need for the mod is tested and verified again during the prototyping phased (usually following project team training and with current process analysis). Regardless of the original perceptions, once the team learns more about the software and looks closer at different ways of doing business, a proposed mod may not be required after all.
F. Final Approval
After prototyping, if a mod is still deemed necessary, the team revises estimates and presents them to management for a final approval. Afterwards, the scope, schedule and budget are revised accordingly, and the modifications can now proceed.
Get a Jump Start on Modifications Discovered Early On
Disposition of proposed modifications discovered during the software evaluation process must occur before the official design phase of the project. This allows for an early start in programming the modifications. The balancing act to consider is while any proposed mod must be understood and justified (with due diligence), waiting too long to start coding can put the schedule at risk. Always remember, most mods are on the critical path within the project schedule.
Other Potential Modification Scenarios
In the situation where some mods are expected, but none are yet defined or approved, you should build some reasonable contingency in the schedule for good measure (even though senior management must later approve any mod and revise the project schedule accordingly).
If senior management proclaims a “no modifications allowed” policy, do not plan for any. If mods are later proposed, they must be approved by senior management. In this case, the decision to expand scope rests with senior management, not the project manager.
13) Boundaries (what is out-of-scope?)
For all dimensions of scope discussed above, you should go back and document what is out-of-scope. This more clearly establishes the project boundaries. People sometimes “hear what they want to hear” and make assumptions on their own about what in-scope means.
For example, the manufacturing manager might say, “Steve, I thought shop floor control included wireless data collection!” Response: “Sorry Joe, that is not what we meant.” The point is, in-scope states what is included, but it only implies what is not included. Why not state the out-of-scope items upfront to avoid confusion or prevent someone from attempting to slide it in the back door later?
Even though the project manager may win this particular scope issue, he or she may actually lose in the long run when Joe no longer supports the project. It is better to get Joe on board with the decision early on or recognize it as in-scope before we put the ball into play.
Conclusion
The “Scope and Boundaries” document is a key deliverable within the “scoping and planning” phase and is completed before the project schedule and budget are finalized and the project is officially launched.
The scope document is the responsibility of internal project manager, with the help and guidance of the consulting project manager. It requires the participation of the executive steering team, executive sponsor, project team, application consultants, key managers (process owners), and some knowledgeable and influential end-users. Though many are involved and provide valuable input, scope must be managed very closely, and the project manager and senior management often need to make tough decisions.
In our scenario, the final version of the scope deliverable is next presented. Depending on how formal the organization, the executive steering team signs it off. Now, as a project manager, you have something valid to serve as input into scheduling, budgeting, and later controlling the project.
