Twelve Tips to Avoid an ERP Schedule Disaster
In my previous blog entries, we established the need to develop a valid ERP project schedule 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 several key inputs for 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
This article is not a laborious discussion of cranking a project schedule. Rather, the discussion focuses on what the practitioner can do when constructing the plan to ensure it can mostly predict 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 you need.
Project Planning Software
It goes without saying that you need some type of project scheduling software and a basic understanding of how to use it. However, contrary to popular belief, 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, you can 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 not a 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 management struggles to accept this concept 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, senior management finalizes and approves any specific project objectives, the project organization, roles and responsibilities, and time commitments of the team. 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, they simply do not have 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, they can face 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 something in between. Whatever methodology you intend to use, get into the specifics of the implementation process, and understand what it truly entails. Methodology affects activities, what is delivered, and content of each deliverable.
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 and discussions, and may 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, type of work, and 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 organize the schedule the same way? This approach 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.
#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 executing 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, we will likely need to rework the project.
#4: Recognize the project tasks between phases
One cannot realistically complete the first round of Conference Room Pilot Testing on Friday and immediately jump into round two testing on Monday. “Wrap up”, “transition,” and “preparation” tasks are 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
Many people tend to generalize a topic and not consider all the details and implications involved. However, 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 until they can reveal the logical steps. 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 acknowledged 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 and latest possible start dates and 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, sometimes the latest possible start makes the most sense. For example:
A) You should usually schedule 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 is 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 a certain number of hours per week, all this time is spent on tasks appearing in the schedule. You should observe the difference between theoretical capacity and actual or observed capacity.
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 such as 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 to consider changes.
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, you should be 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 particularly 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 sent from the highest-level manager at the facility, but actually created by the project manager. It communicates the training schedule, who is to attend, and that 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. Often, people forget the assumptions baked into the plan. This is particularly 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!
