Budgeting and scheduling projects: by Ali Raafat

Id:155593
In many cases, the ERP schedule and budget are not worth
the paper on which they are printed. Many project managers
shoot themselves in the foot by prematurely committing to a
plan that only sets the wrongexpectations. Others throw darts
to come up with a go-live date, or falsely assume the quote
fromthe consultants is the gospel. The problem is once
unrealistic expectations are cast, they are not goingaway.
Could this be why so many ERP projects fail? In fact, some
argue many projects are not really failures, just a failure to
manageexpectations! For most senior managers, the project
schedule and budget are usually their biggest concerns.
Providing the best possible answers is part of a project
manager’s survival guide, but there are also other
implications.Unrealistic time and cost commitments drive
poor project decisions. Many project managers cut corners in
an attempt to catch up to a plan that was never agreed upon
or feasible from the start. On the other hand, most teams will
rally around a schedule if they had input in developing it and
believe in the plan.
Three Stages of Estimating

Estimating the project schedule and budget usually occurs in three stages:
1)Developing early estimates before a decision to proceed with an ERP software
evaluation,
 2) When securing project funding after evaluating software andconsultants, and
3) Formulating a baseline schedule and budget during the planning phase which will be
used to manage the project. Each stage of estimatinggoes deeper into the details since there
is more information availableas the project progresses.As with all estimates, always
include your list of assumptions, constraints,and risks. If the project takes too long and cost
too much, and this list is notdocumented, management will not recall all the things that
drove the previous estimates.
 Early Estimates

 The project manager should anticipate that senior management would want at least
high-level estimates before making any type of financial commitment to the project.
There are many ways to develop stimates, but it will never be a science
 Baseline Estimates

Early estimates are necessary, but the project manager needs a handle to manage activities
and expenditures on a daily basis. Unlike other plans or estimatesprepared previously, the
baseline schedule and budget represent the detail required to manage deliverables. The baseline
is also a tool to measure progress and actual costs for specific line items. This is why it is called
the baseline since it is the yardstick by which all actuals or changes are measured. The baseline
schedule should be aggressive, yet achievable. It is prepared during the latter stages of the
planning phase. At this point, we know much more about the project. The objectives, scope,
and software rollout strategy are known. The implementation teams are now in place, and the
software consultants are engaged to perform preliminary analysis and to assist with planning.
In addition, senior management and project team education and software training and the As-Is
analysis should be complete or well underway.
 In other words, for the first time, we have more information and all the project resources
are in place to develop a real schedule and budget.
The Detail Schedule
The right scheduling is a “top-down, bottom-up” approach, with several iterations. It is
top-down in that it begins by decomposing (breaking down) theajor phases and
deliverables into specific tasks and task dependencies (i.e.,Task A must complete before
Task B can begin).When breaking down the project work, at some point activities should
be organized around each software module and usiness process. The reason is that
current process analysis, the To-Be processes, configuration set up, testing, etc., are
associated with modules and eventually business processes. It is best to plan the project
the same way. The scheduling process is bottom-up in the sense that the dates to start and
complete major phases and deliverables are derived by the associated lower level tasks
dependencies and durations (elapse time required to complete a task). Therefore, the
project master schedule is not pulled out of thin air. It should be based on what must
occur to complete each deliverable and thus the entire project. Once the project
management team constructs a first-cut schedule, they validate it for structural integrity.
This ensures all tasks are included, dependencies are properly linked, resources are
assigned, and task durations pass the test of reasonablenessDuring validation of the
schedule, pay special attention to the tasks on the critical path. This set of related tasks,
when added together, determines the total project duration. For items on the critical path,
it is prudent to revalidate tasks durations and dependences. Most project scheduling
software will identify items on the critical path. Next, determine the workloads placed on
each team member by timeperiod and compare these to their committed project hours for
the period. Adjust the schedule or task assignment accordingly. As imperfect as it is, most
scheduling software contains some type of rough-cut capacity planning capabilities. After
working the schedule within the project management team, review the draft with the
entire project team. This is an interim sanity check to gather more input prior to
finalizing. It is an important step because those implementing the plan must believe and
support it. It is best to get team “buy-in” early, rather than first presenting the schedule to
the team after it is final. In the latter case, the project manager could become the only one
committed to making it happen.
 The Critical Path
Part of finalizing the schedule is to work the critical path to complete the project
sooner. One way to compress (crash) the critical path is to shorten the task durations
by adding more resources. Nevertheless, continuing to add more resources does not
necessarily continue to reduce the time to complete a taskproportionally. Eventually,
the law of diminishing returns applies. Another technique is to look for the earliest
possible start date for items on the critical path. It may be possible to start some
tasks sooner than the “hard” serial task dependencies suggested in the existing plan.
Usually, there are critical activities that can run somewhat concurrently with others
on the critical path, thus reducing the overall timeline. The best way to do this is to
break up a single task into multiple tasks and then start the first one earlier.For
example, let us assume Task 2 can only start after Task 1 is complete (according to
the current plan). Upon further analysis, Task 2 may really consist of Task 2A and
2B. It may be possible to run Task 2A concurrently with Task 1. Task 2B is now
dependent on the completion of Task 1 and 2A. Wehave now taken the time for task
2A off the overall project timeline. Finally, another technique is to decouple task
dependencies for a few major items on the critical path and simply force them to
start earlier. For example, software development is normally on the critical path (this
is one reason tominimize software modifications). Nevertheless, it might be possible
to get a jump on the design of a few high priority or difficult data conversions,
interfaces, or software mods prior to the “official” design phase (of course, if the
steering team approves the mod). If you take this approach, treat each piece of major
development work as a separate project, but linked with the overall project. These
“mini-projects within the project” might have dedicated resources. Of course, there
are risks in starting something too early and encountering more rework than it was
worth. The key is to find the “sweet spot”—when these types of tasks can start early
without causing excessive rework.
Use of Slack Time

Once the critical path is set, another step in finalizing the plan involves using slack time
effectively. Tasks not on the critical path have “slack.” To a certain extent, it does not
matter when these start or finish as long as completed before they become critical. All ERP
projects have slack activities, so use this time to your advantage by scheduling non-critical
items when most convenient to the team, or to smooththe workload when resources appear
overloaded.
Scheduling Mistakes

Building a schedule is always somewhat subjective, but the goal is to make it a

If the cost estimates in the project-funding document provided some room for the unknown, the final budget will probably not exceed those estimates. Thus,
budgeting at this point should be a process of fine-tuning the numbers as more decisions are made during the planning phase. When finalizing the budget, the
biggest advantage is we now have a real project schedule with assigned resources. Better yet, the steering team and other major stakeholders have reviewed
the schedule and they support it. This allows for revisiting the estimated number of hours per week for each consultant, and lock down the final consulting
budget. One way to fine-tune the consulting hours is to “ramp up and ramp down” the hours to better reflect how you plan to use each consultant at different
stages of the project. For example, during the planning phase, project management consulting hours per week should be at their highest. Once the project is
launched, the hours should ramp down considerably and stay relatively flat until the cutover phase begins. How low one can go with project management
consulting hours depends on what the project manager (assigned from within the company) is capable of doing, and the level of support required. Once the
planning phase is complete, project management consulting could be perhaps one day per month or one day a week. If a PM consultant is required more than
two days per week, one may question whether the client project manager is capable performing the job. In terms of application consulting hours, fewer hours
should be planned for completing the preliminary analysis, the As-Is analysis, and when the project team is attending software training. Preliminary analysis
runs concurrently with the planning phase and this time is necessary for consultants to become oriented to your business and the project. However, it is not an
efficient period during most projects since the project is still somewhat unstructured. So be careful not to overkill consultant hours during this time. A couple
days per week during the preliminary analysis phase should be enough, most organizations can conduct the current process analysis on their own. An
application consultant should be able to review the completed process maps, ask questions, and provide feedback without attending these meetings. This
should take a consultant only a few hours versus setting through many meetings. If the consultants are to conduct the team software training, this cost is part of
the education and training budget. by the consultants, during this time the consultants may not have anyone to work with or anything productive to do. If so,
do not schedule them during this time. During the prototype, design, and construction phases, application consulting hours progressively ramp up since more
support is typically required during this time. How much it ramps up depends on how quickly the project team can learn the software. Once formal testing
begins, consulting hours should again ramp down since testing should always be the primary responsibilityof the organization. Hours should increase for all
types of consultants during the cutover phaseso they can assist with final preparations. If the system is truly ready for golive,consulting support after cutover
should be heavy for only two weeks or so. Hours should then ramp down, and end completely within about four to five weeks. In establishing a weekly budget
for application consultants, as a rule 40hours a week on a routine basis hould be avoided since this means consultants are camping out on the project. On the
other end, eight hours per week is notan efficient use of consulting time either. Time is wasted, as the consultant gets reoriented to the project every week. The
hours scheduled for a consultant for most weeks should be zero or 16-32 hours.Finally, the consulting budget is just a budget. The project manager will
determine the actual schedule to be released to each consultant as the project progresses. This is important because if you give consultants all the budgeted
hours, they will burn every minute of it whether it is necessary or not.