Project Management – Lessons From The Perfect Science – Hindsight
By Jed Simms
One of the greatest challenges in a major systems implementation is to get senior management to focus on it.
They may attend Steering Committee meetings and, subsequently, training courses; but they are usually not interested or actively involved until after the implementation. Then they can tell you what should have been done differently.
From our reviews of major systems implementations, we can quote to you what executives have said in hindsight after the event. However, these are often the same executives that pushed for action rather than planning, resisted allocating business resources to the project or training, did not pay attention to what was happening throughout the project, and did not actively pursue the benefits or other potential results.
But after the event, they said…
We needed to plan more…
The project was driven by unrealistic end-dates and while the system may have been ready, the business was not. The planning should have started with the level of business preparedness required and then worked backwards to determine the workload and work plan
The planning was too internally focused. The potential impacts on our customers and suppliers were not identified, anticipated or managed. As a result our customers were poorly serviced with the ‘new system’ being blamed. The blame was with the implementation plan (or lack of it) in this area.
The planning did not take into account what could go wrong and hurt the company — the commercial risks. Hence, when our ability to order materials and supply our customers was disrupted by the new system’s glitches, we were not prepared and therefore customer satisfaction suffered and our competitors made moves on our best customers.
We needed more business ownership and involvement…
Most business managers really did not know what was coming. They did not understand how the new system was going to change how they and their staff worked. They basically thought it was going to be a new version of the old system. They were therefore surprised when things worked differently or information they received before suddenly was no longer available.
The project team did not fully understand how the business worked now. Hence, certain events and transactions were not supported by the new system. Because a ‘gap analysis’ approach was used, the current state was not fully documented. There were, therefore, more gaps than expected when the system was implemented.
The consultants were largely theoretical and did not understand the business. Their solution designs were often impractical. We should have had more of our own staff on the project, people who really understood our business.
The level of training was inadequate…
The training was too fast and did not allow time for people to move up the learning curve. It was “wham, bham, thank you we go live tonight!”
The training was not supported by written procedures or reference materials — the project team thought some on-line ‘help’ files would suffice; they didn’t.
I think the training team thought they did a great job as their end-of-session evaluations showed good results, but the real measure was the subsequent level of demand on the ‘help desk’ and that showed the training failed to meet the needs of the business.
The training was system-operational based. It was too limited. We did not know the context, the opportunities, why the changes were required, etc. We were just told, this is how you do it now. Business change was ignored in the training scenario, yet this was the most important bit.
There was no ‘sustain’ activities, so people quickly reverted to their old habit patterns; often working around the new system to create the old system as closely as possible. Equally, new staff’s induction training was ignored. We tried to give them the implementation training but found it was inadequate for people new to the firm and its processes.
We did not adequately communicate why we were changing our way of doing business…
The new systems introduced new disciplines. Correct account codes needed to be entered at source, purchase orders needed correct part numbers on them before they could be sent. These and many other ‘disciplines’ were introduced as part of the system but without any pre-emptive education or communications. They are therefore seen as examples of the new systems’ complexity and increased workload. The downstream benefits are neither known nor considered. As a result the system got a bad name as ‘too cumbersome’.
We should have spent more time defining and communicating the new levels of acceptable behaviour, upgrading it to, say, “first time accurate information capture”, as an example of what we now expect. No one appeared to think about any of these non-system issues.
We never planned to achieve the benefits…
The system came in and it was all hands to the pumps to keep the thing going, meet customer demands, climb up the learning curve, etc. We have spent so much time ‘fire-fighting’ that we have not even had time to consider reaping the benefits.
The project finished six months ago and we still do not have the expected benefits. And, if you ask around, who is accountable for realising them? The business say, “IT” and IT says, “The business”. Is it any wonder that no one has taken on the responsibility for obtaining the benefits?
The benefits were only theoretical in that the project never set out to deliver them, it only set out to deliver a new system. As the necessary steps to realise the benefits were never planned let alone executed, the fact that the benefits were never seen is hardly surprising.
We missed the opportunity…
The benefits were too focused on cost reduction rather than revenue growth. While we were busy cutting staff and saving money decommissioning legacy systems, our competitors were courting our customers. If we had looked at this project as an opportunity to increase market share, we would have taken a different approach and reaped lasting benefits in the market that our competitors could not quickly emulate. After all, anyone can cut costs!
I can’t help thinking that for all the money and disruption incurred we should have got something a bit more impactful. We may now have a ‘platform’ for the future, but I believe we missed the boat. We should have radically changed our way of doing business, increased our competitiveness and positioned ourselves for the next 5-10 years. What we appear to have done is increased our systems costs and our operational complexity, lost some of our former capabilities with the hope that we now have got a platform for future growth. Only time will tell whether it was all worth it.
How to learn from this
The lessons are quite easy to understand, but often hard for executives to observe with all the other business pressures.
• Time spent planning will pay off three or four times over in reduced downstream costs (over 30% of most projects is consumed in rework!)
• These projects are defining your business’ future in systems ‘concrete’, you must allocate your best business staff to the project if you want the best possible result. The project cost is usually the same, but the output value can be dramatically different
• Any system is only as good as how well it is used; educating and training your staff is critical to the success of the project — you can never over-train staff on a new system
• The executives need to actively lead the project, champion the changes and direct the activities — you cannot delegate the future of your company to a project team. This means allocating time each week to work on or for the project.
• The achievement of the business benefits is the raison d’etre of the project, not an afterthought or ‘nice to have’ — all project planning should ultimately be focused on the achievement of the business benefits with clear business accountabilities for each benefit’s achievement
• Before you start consider what your ‘desired outcomes’ are. What, in business terms, do you want to have achieved at the conclusion of the project? The word ‘system’ usually should not appear in this list. This is your chance to define the business ‘opportunities’ and set in train the project to achieve them. This approach raises the perspective from the systems-level to the business and customer levels.
The alternative, as too many companies have found out, is in hindsight to rue the missed opportunities and unrealised business benefits.
Jed Simms is the creator of http://project-sponsor.com the first web site exclusively focused on the management issues of project delivery and governance. Author of four books and over 60 articles, Jed’s work has been recognised as an “outstanding innovation” and as “world class” thought leadership in project delivery and governance.
http://project-sponsor.com is a self-serve resource for managers to use to meet their needs in a range of project-related roles, such as Project Sponsor, Steering Committee Member or PMO Manager. Our particular focus is on ensuring each and every project delivers the business outcomes, benefits and value expected. This may sound obvious, but is achieved in less than 10% of projects. We can tell you how, why and where you can fix it.
Contact us via the web site or Jed@project-sponsor.com
Article Source: http://EzineArticles.com/?expert=Jed_Simms