Any project, ERP or otherwise, will live or die by its project planning. I recently jumped in halfway through an ERP project to find that the project plan was a chocolate mess and had to be rebooted halfway through the implementation – the project team had to scrap the old plan and engineer a completely new project plan. There were five common issues that derailed this project plan, and these mistakes are common in every failed public sector project:
- Day-to-day management of the project plan
- Resource allocation
- A single point of failure
- Traumatic budget mismatches
- Last minute policy and procedural changes
Let’s dissect each of these issues and consider ways to avoid them on future projects:
The first and most time-consuming issue is the day-to-day management of the project plan. A project plan is like a pet; it needs love, attention and food every single day. Just like a pet, a project plan, is a constant struggle that demands vigilance, even on the weekend and holidays. There are many ways that a project manager (PM) can give the project plan love and attention. My favorite technique is a daily meeting at the same time every day where the PM can take the temperature of the project. Key project resources, champions and the PM should meet for focused discussions on what must be accomplished that day. Effort can be reallocated on the spot and everyone should receive an update on the status of the project. While this takes discipline, it does not have to be time-consuming. A focused PM can hold a daily meeting, make decisions and move out in less than 30 minutes.
The second issue is proper resource allocation. It is not only important to get the right human resources for the project, but it is equally important to use them wisely. Nothing is more corrosive to a project than the “hurry up and wait” syndrome prevalent in the public sector and in particular the U.S. Department of Defense. Forcing a project team member to travel all night or on a weekend to be on a jobsite at 7 a.m. on Monday can be counterproductive if there is not a solid resource allocation plan. The real coffin nail to motivation is to have them sit on their hands while the PM figures out how to use them. “Hurry up and wait,” a favorite tactic of most U.S. airlines, does not work well with ERP implementations. It is much better to have a consistent schedule with surge periods laid out well in advance to allow project team members to mentally prepare, obtain a backfill person if necessary and plan out their personal lives.
If your project is behind, don’t make the mistake of throwing people at it to speed things up. At the beginning of a project, create a thorough plan that includes risk mitigation and contingency, and be sure to use your resources wisely. Having a plan in place will allow you to achieve higher productivity, more project buy-in and more resources who will work with you again in the future. It is also vital to plan around holidays and vacations well in advance. Giving someone Christmas Day off but working them 18 hours on December 24 and 26t is not only counterproductive but could lead to valuable resources finding a reason not to work on your project.
Single point of failure is another common issue in public sector ERP implementations. Every organization has one or two employees that do more than their fair share of work on a project. They often have a portfolio of skills that make them incredibly useful and attractive for your project, but don’t fall into the tiger trap of letting them be involved in every aspect of the project. Eventually, their Herculean efforts will fail and fail hard. They will be pressed into crazy hours on another project or will shatter like a dropped mirror. Sadness ensues and the project schedule will definitely slip while the PM and the project team picks up the pieces and looks forward to seven years of bad luck. Everyone on the project must carry their fair share of the burden. While single-point failures love the challenge and the attention of being involved in everything, do not let them take over your project and hold you hostage. A savvy PM will sit down with the single-point failure, understand their pressures and allocate reasonable time and effort commitments to them. If the single-point failure cannot give your project enough time without jeopardizing other projects, then you need to hire a new employee, contractor or consultant to help both projects succeed.
The fourth item is a mismatch in budget expectations. Most public sector PMs are under a lot of pressure to finish the project on-time and on-budget. Occasionally, issues will come up that will jeopardize the delicate balance of schedule and budget. The PM should unambiguously present the issue to the stakeholders in a decision forum, like a steering committee. The budget issue usually is resolved by slipping the schedule or cutting capabilities to minimize the impact on the budget. Another tactic is to crash the schedule and dramatically increase the budget. A recent client of ours wanted to throw people at a go-live date by working overtime and weekends, yet held the expectation that the budget would only minimally increase. I am no Warren Buffet, but these are contradictory expectations and will unfailingly lead to a demoralized project team. The PM must calmly but firmly map out the options, let leadership make a choice and force them to choose their poison: go live on a specific date with increased budget and diminished capabilities or go long and let the budget be king. The most important concept is that the decision must be owned by the client’s leadership team. Crashing the schedule, throwing people at the problem and working longer hours cannot be accomplished within the original budget.
The fifth project planning issue in the public sector is policy and/or procedure changes. I was on a recent project where the host organization let us conduct a fairly hands-off ERP implementation. Halfway through the implementation, the host organization got involved and forced several new policies and procedures on the implementation team. Several of the policy changes, particularly the process to introduce new project team members and the new decision matrix for the project, were time-consuming and caused schedule slippage in key aspects of the project. It goes without saying that all policies and procedures should be agreed upon before the start of the project. However, this sometimes cannot be avoided with some stakeholders, sponsors and organizations. In these cases, the PM should have a contingency plan for anticipated mid-project changes.. . If the client changes policies and procedures more than their underwear, a sharp PM should inform the client of the danger of mid-project changes and allocate slack time to prevent inevitable schedule slips from jeopardizing the go-live date.
