SAP & ERP Consulting from the Customer Point of View

Twelve Tips to Avoid an ERP Schedule Disaster

In my previous blog entries, we established the need to develop a valid ERP project schedule to serve as a tool to manage the project and set the right expectations (in terms of time and budget). The point is ERP planning is not about throwing darts to come up with dates or forcing a schedule to say what we want it to say. We can wish all we want, but a schedule should reflect project realities, and agreed upon planning assumptions.

In addition, we previously emphasized there are several key inputs into the project scheduling process. Two of them often destroy the validity of the schedule before we even get started:

1) Token client input, involvement, and no ownership of the plan,

2) Glossing over the important project scope details.

Project Plan Training

The goal of this article is not to get into a laborious discussion of cranking a project schedule. The discussion will focus on what the practitioner can do, when constructing the plan, to make sure it is a good predictor of the future. The assumption is the reader has a basic understanding of project planning concepts such as “work breakdown structures”, tasks, task durations, task dependencies, deliverables, and resources assignments. If not, take a basic project-scheduling course, and get any other assistance required.

Project Planning Software

It goes without saying some type of project scheduling software is necessary and a basic understanding of how to use it. However, contrary to popular wisdom, a mastery of Microsoft Projects, or any sophisticated project-scheduling tool, is not a prerequisite for constructing a valid schedule.

ERP Project Plan Templates

Furthermore, it is OK to use a schedule “template” as a starting point, particularly if one has questions about project phases, deliverables, and basic task dependencies as they relate to ERP. Templates, deliverables, and other information are readily available on the internet, and from software consultants and software vendors. However, templates are no substitute for getting educated, planning the project details, or, for that matter, getting the help to develop the schedule when needed.

The Sales Proposal is not “The” Project Schedule

In addition, it does not hurt to reference the sales proposals from consulting firms that may have quoted the project, but do not take them too seriously. Why? Sales proposals are just that… a sales pitch, not the real project schedule.

Sometimes it is very difficult to get this concept across to management since many want to hold the consultants accountable for unrealistic schedules (and budgets). What they fail to realize is the schedule is not the consultants, but rather the clients. Furthermore, when the schedule in the sales proposal is wrong (and they usually are) the client pays the price down the road, and the consultants are the beneficiaries of schedule and cost overruns.

The schedule used to manage the project is produced after consultants are selected (when using them), and as mentioned before, after the project scope and client project planning responsibilities are clarified. In addition, prior to publishing any schedule, specific project objectives, the project organization, roles and responsibilities, and time commitments of the team, are finalized and approved by senior management. A decent estimate of the budget is also an input, though the approved schedule is used to finalize it.

In all fairness to consultants, when developing a sales proposal there is simply not enough time, or justification of consulting resources, to get into the details required to flush out a valid schedule. Remember, vendors do not make money on proposals unless they are accepted. Therefore, they spend most of their time getting the client to accept it, and less time making sure it is right.

Avoid the Subtle Pitfalls

Some of the items listed below many not appear on the surface as a big problem. However, the devil is in the details and when one considers the cumulative affects, the results can be a project that ends up hopelessly behind schedule.

#1: Methodology Matters: Understand the ERP Deliverables

Most ERP projects use the “traditional” implementation approach, rapid deployment, or somewhere in between. Whatever methodology you intend to use, get into the specifics of the implementation process, and understand what it truly entails. This is because methodology affects activities, what is delivered, and content of each deliverable. In other words, it will have a huge impact on the work performed (among many other things).

For example, some rapid deployment strategies (wrong, right, or indifferent) skip the formal project team-training step and do it on the fly during the project. Another example is “current process analysis”. The traditional approach treats this as a distinct phase with “current process map” deliverables. On the other hand, rapid deployment may involve informal current environment overviews, discussions, and more or less jump right into prototyping. The point is not to get into the pros and cons of any particular methodology. Nevertheless, in this example, both have a “current process analysis” line item in the methodology, but the level of detail, the type of work, and the physical deliverables can be very different.

#2: Organize the work breakdown structure around business processes

ERP software is implemented around business processes. So why not organization the schedule the same way? This approach also makes the schedule easier to develop and understand. Whether we are talking about team training, current processes, “to be” processes, design, configuration, testing, or end-user training, the common thread is the focus on business processes. Granted, not all project tasks are easily organized in this manner, but most are.

#3: Allow reasonable time to define the unknowns

Any project task with the word “define” or “design” in front of it usually implies more unknowns, more issues, and more decisions. When you stop and think about it, an ERP implementation is about making decisions. In fact, deciding something can take longer than the execution of the decisions.

Therefore, unreasonable timelines to understand the issues, gain consensus, and make decisions can kill a planned go-live date in two ways. First, the schedule is not real to begin with. Secondly, when we rush to complete analysis and design because of unrealistic timeframes to make informed decisions, rework is enviable.

#4: Recognize the project tasks between phases

For example, it is not realistic to assume one will complete the first round of Conference Room Pilot Testing on Friday and immediately jump into round two testing on Monday. The point is there are “wrap up”, “transition”, and “preparation” tasks required to complete one phase and start executing the next.

In the testing example above, the team must wrap up documentation of round one test results, discuss new issues identified, make more software set-up changes to address the issues, prepare additional test cases, and perhaps set up additional data for round two testing.

In this example (like others), some of this can be accomplished concurrently within the round one testing timeline, but certainly not all of it. Considering there are dozens of phase transition points on any project, this can add up to one big schedule mistake.

#5: “Decomposed” project tasks

There is a human tendency to generalize any topic and not consider all the details and implications involved. The sum of all generalizations over the course of a project can be significant.

The best way to help avoid this is to break down tasks into their components and estimate the duration of each component separately. One should decompose each task to the level where the logical steps required to complete it are revealed. One does not have to take this concept to extremes. However, in the end, an effort to do this will result in a much better picture of the project and timeline.

#6: Take advantage of “earliest possible” and “latest possible” starts

Most know project tasks have “dependencies” that must be acknowledge in the schedule. In other words, one cannot start Task B until Task A (predecessor) is first completed.

However, many tasks (as initially defined) are not truly serial in nature, particularly at the highest level of the work breakdown structure. That is, tasks within a given phase can run concurrently with the previous phase to a certain degree. By recognizing this, one can construct a plan to take full advantage of “earliest possible start dates” and “latest possible starts dates” for specific activities.

Again, first decompose each task into logical components. Then take the resulting tasks and link them to their true predecessor task. This allows for the earliest possible start for project activities, which is particularly important for those on the critical path. However, there are a few exceptions where a latest possible start makes the most sense. For example:

A) It is usually best to schedule most training as close as possible to the time of need (as late as possible). But also remember, the task of developing a training schedule can start as early as possible

B) Tasks that share resources with those on the critical path could start as late as possible to smooth resource loads when necessary. In this case, the task does not start immediately after the completion of its predecessor. This is called using the “slack time” associated with non-critical task. The idea is to focus resources on the critical path until the latest possible start date of the non-critical items.

#7: Consider the “estimated level of effort”

As discussed in my previous blog, when defining project scope also define the “level of effort” (and complexity) required for each scope item. This comes into play when estimating task durations.

With regard to “level of effort”, the time to define, design, build, and test, system interfaces and software customizations / enhancements are almost universally under-estimated. The obvious goal is to minimize any type of custom program development when it is feasible to do so. This is because when it gets out of hand, custom development will end up on the critical path.

#8: “Theoretical” vs. “actual” resource capacity

One cannot assume because an individual is committed to working on project 32 hours per week for example, all this time is spent on tasks appearing in the schedule. There is a concept of “theoretical” capacity versus “actual or observed” capacity that should not be ignored.

For example, when planning the capacity of a machine in a manufacturing plant, the capacity used for scheduling usually excludes changeover times, average downtime, etc. This same logic holds true for project scheduling. One way or another, actual resource capacity should be reflected in task durations.

This resource consideration may seem trivial at first, but do the math and assume a twelve-month schedule where four people are spending three hours per week on activities not in the formal schedule. In this case, the schedule assumes it has these 624 hours, but the truth is it does not.

#9: Include quality checkpoints & follow-up activities (plan for rework)

These type of activities are not necessarily formal events, but normally include things like “design reviews”, presentations for approval or feedback, etc. These, and the associated follow-up tasks, are important to include in the plan not only for quality purposes, but also because “changes” normally result.

Feedback and change for the better are good things, but even small changes, can cause rework. This is called “planned rework” since it should be expected and already in the schedule.

#10: Protect the Schedule

We all know everything does not always happen according to plan. Nevertheless, there is such a thing as being proactive to increase the likelihood that it does.

In terms of scheduling, the question is: “what can we do in advance to make sure Task B happens according to plan”. The other angle is “what can go wrong with Task B, and how can we prevent it from going wrong”. This thought process is particular important for activities on the critical path since slippage here means slippage in the go-live date.

The following is a very simple example of “protecting the plan”. How many times have you scheduled an end-user training class and only half the people show up? A simple way to help prevent this is a letter or email (actually created by the project manager) from the highest-level manager at the facility. It communicates the training schedule, who is to attend, and attendance is expected. This letter goes to all attendees plus their managers. Do you think attendance will be better the next time around?

However, why put this simple item in the schedule? One reason is by the time the letter is created and sent, several weeks could go by in most organizations. Secondly, this communication is very important for the success of training, so enter a task for it.

#11: Verify the structural integrity and sanity check dates

Project schedules are usually developed “top down and then bottom up”. This means start with the top of the work breakdown structure, define and decompose tasks, link dependencies, add resources, durations, and then move back up the structure to clarify and validate.

After several iterations, check for structural integrity of task dependencies and relationships since this is where most errors occur. The integrity of the tasks on the critical path must be 100% correct and durations validated and validated again. The project planning software tool can usually help with some integrity checks.

#12: Document and communicate assumptions

When presenting the proposed schedule include project objectives, scope, resources, and time commitment assumptions. Also, document and communicate all other assumptions that surface from all parties involved when building the schedule. Be diligent about this. The reason is people tend to forget the assumptions baked into the plan. This is particular true if the project falls behind schedule.

Conclusion on ERP Project Planning

Again, the scheduling process is not performed in a vacuum. It requires the involvement of all key client stakeholders along the way. Senior management approves the final version. When the schedule is not acceptable, there are only a few choices. Change project objectives (lower expectations), apply more resources to the critical path, or reduce scope. Anything else is wishful thinking.

=========================

Editor’s commentary - Steve Phillips runs a great blog which is linked here:

http://it.toolbox.com/blogs/street-smart-erp

Be sure to visit his site and support his efforts!

Related Posts:

• Some Reasons SAP Projects are Over Budget and Over Time
• ERP Project Planning – Getting Real (Part 1)
• SAP Implementation Projects: Still Crazy After All These Years
• More on Vendor Selection Criteria and Methods for ERP Project Success
• ERP Project Plan: Getting Real Part 3

Let’s develop a project schedule people can believe and support. After all, it is people that must make any schedule a reality.

When it comes to ERP project planning, there is nothing wrong with an aggressive schedule. In fact, it is encouraged. However, being dumb about it is a different story and only results in a plan that is eventually tossed out the window. We are now operating in the blind and later must deal with the ramifications of unrealistic expectations.

Edicts do not always work 

First, there is a false premise when senior management edicts a date, it will somehow automatically happen. No matter how well intended, edicts with no supporting detail behind them rarely accomplish anything (or cause even more confusion). In addition, some organizations waste years selecting ERP software or approving a project, then attempt to slam-dunk it within six months or less.  Finally, some use the same bad software for eons, and then suddenly wake up one day and insist on replacing it almost overnight. I have some bad news; “it ain’t gonna happen”.

Project Managers can be their own worst enemy

Some project managers publish dates without a clear understanding of how they are going to get there. Others develop valid schedules and later cave in to unreasonable schedule demands. These demands usually come from people that understand little, if anything, about the project details. As a project manager sometimes you just have to say “no”, and take the political risk of doing so. It comes with the territory.

The Sales Pitches are Over; it is Time to Deliver the Goods

In the meantime, some software consulting firms are no help in setting the right schedule expectations. Many more or less throw darts to come up with dates or attempt to use “templates” as a substitute for project management experience. Other software consultants intentionally “low ball” the schedule and do the “bait and switch” maneuver after they get their foot in the door. It is amazing how many clients fall for the oldest trick in the book. 

It can get worse. Even after services are sold to the client, some firms continue to act like sales people (or master of ceremony) not project managers. For whatever reason, they cannot bring themselves to tell client management any bad news. This is unfortunate because the client is paying consultants big bucks for their expertise.

The point is, when outside help is required to develop a project plan,  get project management consultants very familiar with the software and have scheduled the implementation many times before (on projects within a similar industry, scope and complexity). Also, hire consultants that will not sugar coat the real issues. What you need now, more than anything else, is the truth. Finally, never let consultants develop a schedule in a vacuum. The client must be heavily involved from the start, help shape and develop the plan, get their hands dirty, and understand the assumptions behind it.

There are Consequences to Your Project Planning

One might say, “So what, we missed the schedule. We will revise the schedule, and give it the old college try again”. Unfortunately, when we totally miss the mark, good things rarely happen:

The Project Plan Relationship Between Time and Money

An invalid schedule usually means a blown budget down the road. When a project budget reflects a twelve-month schedule, but it actually takes sixteen months, do the math, and assume consultants cost at least $150/hr and you probably have more than one.

The Calm Before the Storm

While it appears everyone on the project is busy working on something, the question is, are they working on the right things, and at the right time? When they are not, it usually means delays and rework later. This is not about poor budget estimating; it is money that otherwise should not have been spent. This is one reason why software consulting cost can average 60% or more of the total project cost. I do not know about you; but this is an unacceptable percentage from my perspective.

Deflating Those that Must Make Your IT Project Happen

When a project schedule really is not doable, it is not hard for most people to figure out. In this case, do not expect the project team to get too excited about attempting to implement a plan that is doomed from the start. I cannot say I blame them. 

Feeding the Naysayers

Any project has doubters throughout the organization, but when we incur schedule slippage due to poor planning, this only fuels the informal grapevine. “See, I told you they do not know what they are doing”! This certainly does not help the cause of the project, the team or make “organizational change management” any easier.

Taking Project Planning Shortcuts

No matter what implementation approach or methodology utilized, in order to get back on schedule people sometimes do nutty things. The result can be a host of unintended consequences such as poor software quality, higher cost, lack of user acceptance and failure to achieve project objectives.

A Project Schedule is Not a Wishlist

The goal is to produce a valid project schedule that achieves project objectives. In addition, a schedule the project team and key client stakeholders believe, support, and can actually use to manage the project.  

In terms of a timeline, a good project schedule is not necessarily one that depicts what we ideally want to occur. Nor is the sole purpose to “light a fire” under those that must make it happen. Above all, the project schedule should reflect reality.  If not, no one except the project manager and consultants will own it. The problem is, for the schedule to actually materialize; all key client stakeholders must first believe it, in order to get behind it (including sr. management, the project team, IT, key functional managers).

Once senior management agrees on project objectives, scope, resources and the schedule is properly developed, adjusted and verified, the project “is what it is” (whether we like it or not).  When we cannot live with the proposed dates, there are only a few options available: 

              Apply more resources to the critical path,

              Change the project objectives (goals, benefits, etc),

              Reduce project scope (modules, interfaces, processes, etc)

All of the above can eliminate associated tasks or reduce task durations. However, permanently cutting objectives or scope for the sake of meeting an arbitrary schedule is not very smart. When it comes to resources, there is a law of diminishing returns. For example, assigning nine people to screw in a light bulb is not going to get it done any faster. Above all, when moving up schedule dates, avoid “voodoo” scheduling. This is when we manipulate the dates forward, to get the schedule to say what we want it to say (with no valid cause and effect justification for doing so).

Define the Project Path to Get There

A project schedule should convey specific project deliverables, supporting tasks, task durations, dates, responsibilities (resources) and recognize the relationship between tasks (dependencies). This does not imply any plan is perfect since scheduling is just as much an art as it is science.

However, when the right people are involved and proper detail, durations and dependencies built into the “work breakdown structure”, many of the assumptions and imperfections at lower levels of detail tend to cancel each other out. This means at the highest level of the schedule, planned start, and planned completion dates for key project deliverables / milestones should be reasonably accurate (including the go-live date).

This level of the plan(sometimes referred to as the “Schedule of Deliverables”) serves as an important road map with regard to where the project is going and when we want to get there. The dates at the individual task level are less relevant (except on the critical path), but they do serve as input to planning weekly activities as the project unfolds. They also are a day-to-day gauge to tell us if the project is on track per the original plan.

It is Sometimes Hard to Argue With the Facts

Finally, a project schedule (with the details to back it up) is a project manager’s best defense against those that insist on unreasonably aggressive timelines. In other words, anyone can throw dates around, but it is hard to argue with the work required and the sequence in which it must be accomplished, particularly if the goal is to be successful. On the other hand, a project plan and schedule with no detail is wide-open for criticism, second guessing and manipulation.

In previous blog entries, we discussed the importance of proper definition of project scope, assigning the right internal resources to the project team and getting all key client stakeholders heavily involved in the planning process. In my next blog, we build on this foundation and discuss how to construct a project schedule while addressing the common and not so obvious pitfalls. Finally, we close out this project planning series with a discussion on methods to estimate and budget for software consulting cost.

=========================

Editor’s commentary - Steve Phillips runs a great blog which is linked here:

http://it.toolbox.com/blogs/street-smart-erp

Be sure to visit his site and support his work!

Related Posts:

• Some Reasons SAP Projects are Over Budget and Over Time
• SAP Implementation Projects: Still Crazy After All These Years
• The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
• Reduce SAP Project Stress Part 3
• SAP Implementation Focus, Software Engineering or Business Process Engineering?

Thirteen Dimensions of Project Scope

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 by prematurely committing to a project schedule and budget that sets unrealistic management expectations. The problem is 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, inadequate definition of project scope (and boundaries) is a major reason the plans are invalid and quickly tossed out the window. In other words, we need a project scope, schedule and budget that closes expectation gaps. A project plan people can believe and use to actually manage the project. What a crazy idea!

Project scope not only drives baseline project schedule and budget; but it also sets user expectations regarding what they will get (and not get) within the software functionality. When users are later told something is out-of-scope they really need, the project is in for many unhappy users or scope creep that results in surprise cost and schedule overruns. Take your pick.

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 the ability 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. The goal is to assist the practitioner in understanding the key elements of scope, potential implications, and set the right expectations. Next this enables the practitioner to develop a schedule and budget that is real and people can support. After all, it is people that 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, level of detail and other twist that warrant a separate and distinct perspective on scope. 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 discuss how this information is used to develop a project schedule and budget.

The Thirteen Dimensions of ERP Project Scope and Boundaries

1) Align scope with project objectives

The fact is 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. It is never a good idea to proclaim the project will solve all the world’s problems, and at the same time, limit scope to the bare bone 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, last minute acts of desperation to cut scope to get back on schedule are usually done without a full understanding of the original objectives that are now compromised. Therefore, if scope is to be cut half-way through the project, objectives and expectations must be realigned with the new reality.

On the other hand, too much scope beyond what is required to achieve objectives (and for the software to function effectively) is not a good thing either. This is usually not a popular philosophy among users, but a necessary one since “scope creep” is inevitable to some degree on any project. Therefore, early on it is important to “condition” managers and users that the system is not intended to be “all things to all people” and 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, there could be more than one “business unit” at a location, each having its own customer service group using the same software. In “multi-site” scenarios, the scope issues are three fold.

First is the coordination and communication effort required to get and keep all team members, key managers, and users at each site on the same page. Not to mention, I have yet to see any multi-site implementation where a certain amount of politics and finger-pointing between sites did not slow progress. 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 plays into the decision to treat a given business process at each site, as a single or separate process from a design and set-up 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 drives the overall footprint of project. No doubt, this is one of the first steps in addressing scope. The bad news is when some put a project plan together, the software modules in-scope are one of only a few things considered.

The problem is without further definition, it is difficult to 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 means more complexity, more risk, more time, and more money.

In addition, whether a module implies 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 often over looked. Each module has features, functions, and capabilities. It is always best to consider  the capabilities to be utilized right 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 and this is never a perfect process. However, this is different then going far down the road spending time on features of marginal value (and no one cares about).

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.

For example, within this major process, some of the “sub-processes” include: 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, in many cases nothing could be further from the truth. A simple example is “receipt of a purchase order”. In most companies, there are many types of purchase orders that are received and transacted very differently (and for good reasons).

As a result, from a scope standpoint each 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. This is similar to the complexity factor, but I like to highlight it separately because it can have huge project implications.

For each business process, it begs the following questions:  How convoluted is the current business process? Does it need significant reengineering? Are you planning to implement an entirely new operating philosophy? On the other hand, are you 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 one must redesign a process, the more decisions to be made (usually the longest pole in the tent), the more design work to be done, the more emotional it gets, the more issues and unknowns, and the more testing required. There is nothing unusual about any of this, but there is no way around it. When significant process changes are needed, 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 clean up 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. This includes not only field sizes, etc 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. 4) Keep in mind, it could be much less time consuming to load data manually versus the alternative of writing conversion programs.

9) The Number and Complexity of Interfaces

This includes interfaces between “other” systems and the new ERP system. The time and cost to design, develop, test and maintain interfaces are almost universally under-estimated. 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 (expect problems at some point).

Therefore, ideally one wants 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 a few modifications to the new software are required 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 nevertheless, can be critical to the business. Also, interfaces to other new third-party software or hardware included in scope must be acknowledged.

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 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

The number of reports should be estimated 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 frequency of usage.

Ask the users to review the list and comment on what reports they “must have” within the new system (wrong, right or indifferent – at this point we are trying to estimate. It is OK if the revised list from the users is full of assumptions) However, this will eliminate many reports that exist today.

Next analyze the list to see if the “must have” reports can be combined, eliminate by standard reports from the new system (or with slight modifications) or the availability of data on-line (or via spreadsheet user downloads) from the new system eliminates the need to write reports. Once this is accomplished the list should be more manageable.

Finally, add a contingency of about 15% to 20% to cover new reports the team or users will eventually asked 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” (subset of the entire population) to be heavily involved. Of course, the more people involved, again, 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, it is necessary to get a handle on training time and resources requirements. Think of this as a rough-cut end-user training plan (not a detail 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 was learned. The more one compresses the timeline to meet this objective the more resources typically required.

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 in order to get the right people involved early on, estimate a duration for end-user training in the schedule and to properly budget for it.

12) Software Customizations or Enhancements

Most know by now software “mods” (customizations or enhancements) increase risk, time, cost, and can negatively impact software quality. Therefore, eliminating or keeping them to an absolute minimum is always recommended. However, in the real world organizations make mods and often for very good reasons. 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 there are strong perceptions mods are required, 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 evalution) 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 means: 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? (for the sake of future upgrades).

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 as this point.

E.    There really are no other viable solutions

The need for the mod is tested and verified again during the prototyping phased (usually following project team training and runs currently with current process analysis). The reason is, 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, estimates are revised and present 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 – They are on the Critical Path

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, it is a good idea to build some reasonable “contingency” in the schedule for good measure(even though senior management must later approve any mod and the project schedule is revised accordingly).

When there is a “no modifications allowed” policy proclaimed by senior management, 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 rest with senior management, not the project manager.

13) Boundaries (what is out-of-scope?)

For all dimensions of scope discussed above, it is always best to go back and document what is “out-of-scope”. This more clearly establishes the project boundaries. The reason is people sometimes “hear what they want to hear”, and make assumptions on their own about what “in-scope” means.

We have all been there before when the manufacturing manager says (for example): “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 include.  Why not state the out-of-scope items up-front to avoid confusion or prevent someone from attempting to slide it in the back door later?

The problem is 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 tough decisions are usually required by the project manager and senior management.

The final version of the scope deliverable is next presented to all the above as a last review. Depending on how formal the organization, it is  signed-off by the executive steering team. Now, as a project manager, you have something valid to serve as input into scheduling, budgeting and later controlling  the project. 

http://it.toolbox.com/blogs/street-smart-erp

Related Posts:

• SAP Implementation Projects: Still Crazy After All These Years
• Some Reasons SAP Projects are Over Budget and Over Time
• ERP Project Plan: Getting Real Part 3
• ERP, SAP, or IT Project Management and Prototyping for Success
• Planning For a Smooth SAP Go-Live: Part 2