by Debbie Wilson | December 28, 2018 | Comments Off on “ERP: Project or Product?” by Tim Faith
For most of my experience with ERP, I was on the consulting services side of the house. My life was managed by Project Managers, project timesheets, project deliverables, work breakdown structures, gates, phases and go-lives. The go-lives were the fun part, quite honestly, maybe second to the late night coding/testing sessions where nicknames were earned and Nerf guns magically appeared. Each new project brought on an excitement for a new role, a new client, a new city and a new target go-live. I’d get to know the client, and they’d get around to asking: “How many projects have you done?” “What project were you on before?” “Oh, you were on THAT project!?” Eventually, there was a point in the project where the hotel was boring, the airport was a pain and the go-live was a moving target that seemed increasingly off in the distance until it wasn’t. Even still, the project moved (creeped?) along. There was always a new resource to be trained, knowledge to be transferred, a presentation to be made to the steering committee, a budget to be evaluated, burndown charts to be updated: all in service to the project. Honestly, it took a couple of projects for me to really appreciate the art of project management and the magic of the project manager. When I was actually named as a project manager, that PMBOK was my best friend, let me tell you. There was that point when you had that one Executive Steering Committee meeting where you read off the project status board, and it’s like that scene in Apollo 13 where you hear this status is Green, the next status is Green, that status is Green, Green, Green, Green, Green… Then you hear those magical words from the Executive Sponsor, “Well, I guess we’re good to go live”.
Go-live weekend (or week) hits, massive amounts of data is converted, servers are fired up and configured, and the choreographed dance of the ERP go-live is in motion. It’s a beautiful and stressful thing. Something unexpected always happens, and someone always (well, most of the time) comes through in the clutch. Then, there is transition to support, go-live party time, and off to the next project. And the next one, and so on, for about 13 years.
About 10 or so years ago, I was on the other side of that scene. I was the customer, managing a go-live of an ERP implementation. And I was stuck with feeding the beast that is ERP and making sure it was content so it didn’t rise up and bite us. I kept the lights on, managed uptime, reported to my customers that nothing was broken, and resolved the occasional bug. Sometimes, I’d even build out something cool! I was content and happy (lazy, even?) until my business counterpart, Tom, asked, “How can we do this better?” Now Tom is totally not his name, as I value this person’s friendship and would never want to incriminate the guilty. So, if you are a Tom, I’m not really talking about you. Unless I am. Anyway, we got into several discussions on how we could be ‘better’, what we have done ‘better’ in our IT lives, and what would ‘better’ look like for not us, but our customers (the rest of the people in the multiple offices). The answer ended up being right in front of our faces, or rather, in our hands. We landed on the approach of the iPhone apps (Angry Birds for the win!), and how there were frequent small updates, fixes and iterations that were not really major events. We started adopting product management and Scrum practices for the ERP, and built from there. Our customers were more aware of what we were doing. The more accountable and involved the ERP team was with them, the more it was reciprocated to our ERP team. As I left that company and continued into other consulting and support jobs, I always internally referred back to that pivotal time of seeing ERP as a product to manage, not simply a project to finish.
So, what is the point? Here it is: many are still viewing ERP through the lens of an IT project. Whether an upgrade, a patch update, an adoption of a new module, or even a new implementation, IT and the PMO will often do the heavy lifting to deliver. For example: business requirements will be gathered, but it might not be six months to a year before the business will actually see the requirements in the system. At which point, the requirements will have changed, and maybe for a very good reason. Then what? Play the blame game, or evolve and adapt?
Part of the product management philosophy and practice is involve customers (the business for ERP folks) early and often. Build with them mind, test with them, demonstrate for them, adapt quickly because of them. It’s not as simple as it reads on paper, but, from experience, it is worth the efforts. You will likely continue to read Gartner notes from the ERP team, and this shift from ERP project to ERP product will become more apparent. This will no longer be an ERP that was delivered to you by a vendor; rather, this is your ERP to manage for many years to come for your customer’s benefit.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.