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!
Let’s develop a project schedule people can believe and support. After all, it is people that must make any schedule a reality.
