Avoiding Project Management Landmines
By Jim Clarke
You live, you learn. Implement projects, and you certainly do.
I am not a career project manager, just like most people who assume the role. Therefore, what I have learned about the subject comes from the experience of jumping into the position when needed. These points are intended for those who also find themselves in the role of project management as a sub-part of their regular jobs.
Project management is a dangerous endeavor by design. Whenever change is involved, risk is present also. Although we all recognize the need to change, there are far too many examples of when change hurt rather than helped.
There are many success stories to read on-line. Most have a similar ring, largely because they are designed to sell software, consulting or project management services. This is not that sort of article. I find that disaster is a better teacher than success.
In order to assist those that are embarking on projects, the following is a list of the potential errors that I would have preferred to have not experienced for myself.
- The “Light Switch” Error: Big projects tend to come with deadlines and expectations. This implies a self-created D-Day. Due to the complex nature of projects, there often are many small initiatives wrapped up in the larger effort, as well as many departments or areas of the organization that are affected. Make the change all at once, and it may be difficult to diagnose what is happening immediately after implementation. Often there are just too many moving pieces to track.
If possible, it is preferable to implement in stages, so that each piece can be tested and monitored before the next portion is installed. This eliminates the confusion caused by mass simultaneous installation of many small changes.
The “Deadline Tail Wags the Project Dog” Error: The project will take…as long as the project takes to implement. Often factors outside of the change initiative itself cause the timeline to be set at a point that is not related to the reality of the implementation. Absent a reality check that justifies outside expectations to the project itself, and you have the formula for disaster through incomplete work due to the looming deadline.
The “What Project?” Error: Within every project, there are complex layers of stakeholders and players that need to know what is happening. Some are suppliers, or vendors, others are from other departments or work at different sites than the location implementing the project. Does everyone really know what is happening, their roles, and when they need to execute? Sometimes there is so much work to do on the minutia that the over-view communication does not occur until its too late to keep from offending those that should have been informed early in the planning. Regular updates to all effected parties including new dates, roles, progress and so forth should go out at periodic intervals.
The “You Never Asked Me” Error: Similar to number 3 above, this is the deadliest error of all. The need for projects originates from a variety of sources, managers, workers, and officers can all be the catalyst for change. Projects are eventually approved at high levels, and the layout and timing then tend to then roll down hill to those directly affected. This is the wrong sequence for the best result…a step is missing. After a project is approved, those who will be most effected need to be consulted for advice. Senior management and even mid-level managers are too often removed from the day-to-day issues that the users of any system experience. Early on in the implementation, the feedback from the users of the processes that will change is critical.
The need for the project should be self-evident to everyone, but the steps needed to execute, the timing issues, and complexities of operating the business before during and after the go-live are the area of expertise of those that actually do the physical work. Get this information early on and you have more than buy-in from the troops … you have engaged the workforce and made them stakeholders in the process. Fail to do so and the opposite can be true … lack of accountability for success at low levels, or worse yet, an erosion of trust in management.
The “Front-Loaded Budget” Error: This mistake is so common that it seems to be endemic of projects in general. The budgeting for a project tends to be event-driven. Planning and consulting takes time and money, plus prior to implementation processes change and are tested, and there is money and time allotted for that. At various points, capital expenditures occur of the acquisition of new software or equipment, and the appropriate installation time is allowed and budgeted for. Finally, the go-live has costs associated with it that is predicted and added to the plan. So often, this where the planning stops … in the days after implementation.
The error here is that if major changes were made, there then there is a period of trouble shooting, adjustment and human learning curves that has cost implications. This is the back-end of project budgeting that is nearly always missed. This period of adjustment can last as long as 18 months before new methods and systems are part of the fabric of the organization. If the combination of the planning and post-implementation learning curves is more time than is acceptable, this has to be considered up front, not after the change goes into effect. The best source of information on how long this may take is the people actually doing the work, the users of the new systems. Again, getting user input is one of the keys to success.
The “No Finish Line” Error: It should go without saying that goals and expectations have to be set as part of the planning process. Even when they are, projects can take months to complete, and in that time the business itself can change. Mergers and acquisitions, new items, lost product lines, projects in other departments … these are all examples of changes to the business itself that can alter the results of a project. Each of these occurrences, and events like them, are times when the projected results of the project may need to be re-evaluated. Getting agreement from all stakeholders and users is important when something changes in the organization during the time of project planning and post implementation. Without agreement on the goals of a project after a change to the business occurs, it is easy for those involved to be aiming at the wrong goal, or worse yet, different goals. Agreement on the new target allows for new consensus, an update on the project status, and a re-focusing effort on the results that are sought. Failure to do so can lead to the “No Finish Line” error in which there is not agreement on what the goal now should be, and therefore the project never ends.
Real career project managers undoubtedly have even better advice on how to avoid problems when implementing change. These ideas came from the experience of living through them, so hopefully sharing will help others who are just now tackling their own initiatives.
You live, you learn.
Jim Clarke is a Distribution Industry professional from Portland, Oregon.
Jim has held positions ranging from Sales Manager to Director of Operations. Along the way, Mr. Clarke collected experiences and developed a unique vision regarding business culture, the nature of execution, and the successes and follies of businesses today. Over time Jim came to believe that common sense is the missing element in so many of today’s theories about business.
Jim can be contacted through his professional blog: Unauthorized Business Thinking.