Have you ever been in this situation?
A large project was looming, and the Powers That Be want to dive in head first. This recent and very large acquisition (30% of our size when we bought it) needed to be integrated into our supply chain and distribution network; the customers were demanding it, and we were leaving an awful lot of value on the table by not moving forward.
There were a few theories behind this take-it-slow approach. “Cultural sensitivity” was lauded as an important reason to Go Slow – but part of our collective pause was fear of the unknown. True, the company was stable – actually, quite strong – with a mature SAP system. But like all gargantuan projects, the original SAP implementation had it’s share of headaches – big problems that stay with you through the years, like a Mother-In-Law sandwich. And in the years since the Big Project, the core team had scattered; some had gone into non-IT roles, some had taken on other tasks in IT, and many had moved on to other employers.
Still, time was moving on, and even the most pessimistic among us felt the challenges of trying to live on two systems. Time to grab a mitt and get in the game!
Now Things Get Interesting
The executive team, eager for action and finally ready to make some of the tougher organization and culture decisions, were starting to pay attention to the Confident Ones that knew the Operations team and processes could handle the increased volume. The more they looked, the more they saw talented, knowledgeable people pushing billions of revenue through a complex distribution network, keeping customer deliveries on-time and inventories low. Unfortunately, some overconfidence started creeping in. How tough could it be?, some said, since many from the old SAP team was still employed? We could pull together a team and whip this thing together – no problem.
At first, they didn’t listen to the important facts; the last SAP go-live was at least six years prior, and the knowledge had started to fade. Some of the Project Leads were gone, and the project deliverables were not put together in a “cookbook” form – nothing really re-usable. In addition, this new acquisition had seven locations, and the largest single go-live weekend from our past was three locations.
Thankfully, the company had made another acquisition a year earlier. This was an easier bite to take – $150M in revenue, and only two locations (building #2 being a little distribution warehouse across town). We decided to convert this smaller company first – a chance to dust off the cobwebs and get in some practice for the “main event”.
In hindsight, a terrific idea – because we ran into plenty of problems. Nothing major from a technical perspective – but the project struggled mightily from decentralized issue tracking, not enough on-the-floor support, accounting changes, and no detailed hour-by-hour plan for the important go-live weekend. The implementation made it through, limping over the finish line as a qualified success …
… except for the fact that we learned a ton, and made a huge number of changes and improvements before we took on the Big Project. The Little Project ended up being a strategic success because we re-learned a lot of stuff that we forgot. If we hadn’t completed the Little Project for practice, the Big Project would have been a major failure, and caused significant customer hassles.
Build One to Throw Away …
… is a pattern that appears in many places; test markets for new products, iterative development for web sites and reports, even pre-season football games. When you are trying to introduce wildly new or perceived risky work to your organization, a terrific way to get folks comfortable with the impending change is to do a pilot program. And if the team seems a bit too enthusiastic about approving that big project budget on process or technology that is very new, a Proof of Concept phase will allow the group to see real-world results while reducing the risk and cost of major failure.
Large projects introducing product and process innovations for your customers will often involve stuff where “new” represents some “risk” …
- New Technology: Has your team ever worked with this specific technology before? Skills learned on one platform don’t always transfer will to other platforms. Modern web development is getting more advanced every day, and mobile development requires a very different set of tech competencies. Now the Internet of Thing comes along, and the ground shifts again.
- New Processes: It’s a reasonably safe bet that business process and tech capability have changed a lot in the past five years or so – enough to suggest that old assumptions, skills, experience have a good chance of failing, and should be dealt with carefully.
- New Teams: The people with the required skills have moved on to different roles. If the original team has done any significant knowledge capture, now it is time for the Transfer. If you haven’t – well, it’s a whole new crew to teach – from scratch.
- New Environment: You may not know all the rules; the world changes every year, and your old assumptions may not hold true. This goes for internal projects (facilities relocations, major systems upgrades, etc.) just as much as the external ones (web sites, product launches, etc.)
Like Riding a Bicycle
It’s not just the project team that gets the value from doing One for Practice; when we finished to rollout for the Little Project that became our training ground for the Big Project, there were plenty of people smarting from the painful experience we just went through. It was widely recognized that the SAP conversion was not optional – but we very mindfully applied the learnings from the recently completely lead-in effort to avoid major communications and planning issues that would have massively delayed the bigger and much more complex Big Project.
It turned out to be one of the best go-lives the company ever experienced. And the customers barely knew we were making the change.
Now there’s a great success metric for a project …
# 24 November, 2014