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:
Be sure to visit his site and support his work!
Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.