Let’s develop a project schedule people can believe and support. After all, people are the ones who must make any schedule a reality.
When it comes to ERP project planning, an aggressive schedule is not a problem. In fact, it is encouraged. However, if you do not strategically consider this schedule, all you will have is a plan to toss out the window. We must deal with the ramifications of unrealistic expectations.
Edicts Do Not Always Work
First, many falsely believe that 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 sometimes 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 will achieve the deadlines. Others develop valid schedules and later cave in to unreasonable schedule demands. These demands usually come from people who 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.
The Sales Pitches Are Over; It Is Time to Deliver the Goods
In the meantime, some software consulting firms are of no help in setting the right schedule expectations. Many 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 can get worse. Even after they sell services to the client, some firms continue to act like salespeople, not project managers. For whatever reason, they cannot bring themselves to tell client management any bad news. However, the client is paying consultants big bucks for their expertise.
The point is, when you need outside help to develop a project plan, find project management consultants who are familiar with the software and have scheduled the implementation many times before (on projects within a similar industry, scope and complexity). Also, hire consultants who do not sugarcoat 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 as they 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 causes a blown budget down the road. When a project budget reflects a twelve-month schedule but actually takes sixteen months, do the math. Assume consultants cost at least $150/hr (and you probably have more than one).
The Calm before the Storm
While everyone on the project may appear busy working on something, the question is, are they working on the right things, and at the right time? When they are not, the project will later face delays and rework. 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 I find this percentage unacceptable.
Deflating Those Who Must Make Your IT project Happen
When a project schedule really is not doable, most people can see that. 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
All projects have 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 don’t know what they are doing!” This certainly does not help the project and team, or make organizational change management any easier.
Taking Project Planning Shortcuts
No matter what implementation approach or methodology the project uses, people sometimes do desperate things to get back on schedule. The project may then face 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, along with one that the project team and key client stakeholders believe and support.
In terms of a timeline, a good project schedule is not necessarily one that depicts what should ideally occur. Nor is the sole purpose to “light a fire” under those who must make it happen. Above all, the project schedule should reflect reality. If the schedule does not, no one except the project manager and consultants will own it. However, for the schedule to actually materialize, all key client stakeholders must first believe it to get behind it (including sr. management, the project team, IT, and key functional managers).
Once senior management agrees on project objectives, scope, resources, and the they properly develop, adjust, and verify the schedule, the project “is what it is” (whether we like it or not). When we cannot work 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.), or
- Reduce project scope (modules, interfaces, processes, etc.).
All of these steps can eliminate associated tasks or reduce task durations. However, permanently cutting objectives or scope for the sake of meeting an arbitrary schedule is not smart. When it comes to resources, you need to consider 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 manipulating 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, and responsibilities (resources). Additionally, it should recognize the relationship among 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 build proper detail, durations and dependencies into the “work breakdown structure,” many of the assumptions and imperfections at lower levels of detail cancel each other out. As a result, 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 regarding 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 are also 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 who insist on unreasonably aggressive timelines. In other words, anyone can throw dates around, but a successful goal needs a clear statement of the work required and the sequence in which it must be accomplished. 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!
