|
When I first saw the movie Titanic back in 1997, I remember wondering why it was considered such a romantic movie. Sure, there’s the iconic picture of Leonardo Dicaprio and Kate Winslet on the bow of the ship leaning into the wind with their hair blowing. OK, that’s romantic. They were a dashing couple riding the high seas on a glamorous trans-Atlantic voyage. Again, that’s pretty romantic.
Still, as I reminded my lovely fiancée when we saw the movie, the SHIP SANK! The brilliant engineer designed a boat that was supposedly unsinkable and the brave captain piloted it right into an ICEBERG. Sorry – not romantic.
When I started managing and consulting on ERP software projects in the 90’s, I started with romantic notions of what IT projects would be like. As long as I had the right equipment and an experienced crew then all my projects would be successful, right?
After 17+ years of voyages, I’m a bit more jaded but no less sure that IT projects can avoid Davy Jones Locker. That’s because I’ve seen a few projects go to their watery grave and, fortunately, lived to tell the story.
Now I know that if you don’t do these 4 things properly then your IT project WILL go down. And sadly you may go down with it!
1) Keep a tight rein on project management
Titanic captain Edward J. Smith made essentially one fatal mistake. He piloted the Titanic straight into treacherous icy waters because he was so overconfident that his ship was unsinkable. A good project manager never makes that kind of assumption. They’re also never afraid or too proud to make a course correction when conditions change, or rely on the co-pilot’s advice (usually from a consultant) if it makes sense.
The best run projects are planned carefully and managed to reach “milestones” and provide “deliverables”. The PM first develops a project plan using a project management tool – some like MS Projects – that builds in dependencies so that the plan can adjust automatically when things change. Believe me, they will change. The milestones then become the buoys along the way and the deliverables become the gifts you give your stakeholders when you reach each milestone.
The idea is to deliver “wins” at intermediate points in the project so that you can know whether you are off track – before you’re taking on water. Preferably these deliverables are tied to the key performance indicators (KPI’s) of the project and of the business.
The minute that a milestone is missed or a deliverable isn’t delivered on time, then it’s time to course correct and maybe to sound the alarm. My favorite PM methodology uses an “80-20 rule” and a series of conference room pilots (CRPs) to gauge readiness and celebrate milestones.
This methodology recommends flow charting and testing the processes that you do 80% of the time and then presenting these in the software with a “CRP 1” to show management hat you’ve got those down. Then you proceed to the “20%’ers”, which are all your exception processes, reports and customizations. Interestingly, the testing of the 20% processes typically takes about 80% of the time. You will DIE if you don’t get them nailed down and documented before you go-live – especially the reports!
I also think it’s important to have a person running the ship that has a track record of success with the software you’re implementing, not just a generalist who can supposedly manage with a “one size fits all” approach. Certifications such as a PMP are important, as are business certifications related to the industry. I work with ERP software in manufacturing, so APICS certifications such as a CPIM or a CIRM indicate that a PM would have the business knowledge underlying the ERP system as well as general management skills.
2) Document, Test and Train Thoroughly
Imagine if the passengers of Titanic had clear, step-by-step instructions to know where to go and what to do when the ship was hit. Certainly far fewer people would have died. Of course they needed more lifeboats, but if the passengers had been trained and organized then they would’ve made much better use of the ones they had.
When a project starts, I don’t spend a lot of time on “as is” processes. Heading in we know that whatever processes they were using before weren’t working that well, so I don’t waste time documenting them. Instead I like to work with the client to build “to be” business processes using my knowledge of best practices, document them in the software itself or in a flow charting tool like Visio, and post them clearly for everyone to see.
Here’s an example of a “to be” flow. Note that it includes both manual and system-executed steps. Because we developed this flow right in the ERP modeling tool, the system-executed tasks can be done by double-clicking on the boxes and opening up the “sessions”.
These process flows then become the basis for a resource library of “work instruction” documents complete with screen shots. Work instructions are usually written in MS-Word or generated using an on-line documentation tool, converted to PDF format and posted on Sharepoint or a website. Training presentations can bedone in PPT (I know, old school) or another presentation tool and posted in PDF as well. The format isn’t important, just as long as the content is solid. Then anyone – system users, execs, auditors, etc. – can look them up easily online.
Training is SO important, and so often in failed projects it’s overlooked or done in slipshod way.
3) Implement REAL Change Management
When the Titanic was sinking, the passengers didn’t need a newsletter telling them that a lovely string quartet was playing on deck under a starry sky. It was nice that the band was playing. It calmed those poor folks as they were going down – but they STILL went down.
No matter what people tell you, no one likes change. Uncertainty causes them to be confused and make mistakes. A new IT project is frightening for most people because they have to learn new things. They may fear for their jobs. Consequently they cling to what they did before, regardless of whether it’s working or not.
That’s why I think that change management – true change management, not fluff – is so important. It starts with setting up clear, regular communication about the goals of the project, how stakeholders will benefit, and how it’s going. Tell them straight. Never lie – especially if it’s bad news.
The best example I’ve seen of good change management is a client who created an intranet site that became the “home page” for all the key users when they went came in each morning. During the project, there was a one page summary of how the project was progressing towards each of the milestones and deliverables in the project plan. The client PM also tracked the consultants so that they could figure out how their all-important budget was doing against the plan and do an earned value analysis (EVA).
In addition to regular weekly meetings with the key users to communicate how we were doing, we reviewed key items on the “issues log” reviewed daily. If an item continued to pop up on the log without resolution, then we scheduled time with the steering committee.
Occasionally we had “bitch sessions”, particularly near the “go-live” date, so that we could surface underlying rocks. We served pizza, so everyone got on board. The meetings were quick and didn’t have to be formal. I’ll admit that many “planning sessions” were at the local brewpub. Good times.
The good news is that if you do these 3 things well, I can virtually guarantee that you will ride your ship triumphantly into the sunset!
I hope you’ve enjoyed the post and picked up some useful tips on avoiding IT project disasters. You might also like '3 Surefire Ways to Take the FEAR Out of a Startup' and 'David and Goliath: 3 Easy Steps to Turn Small Into POWERful'. Here's the link to the full original post '4 Things You Must Get Right or Your IT Project WILL Fail'.
For more excellent information about why IT projects fail and how to avoid problems, read analyst Michael Krigsman’s Beyond IT Failure blog on ZDNet. Michael Krigsman is on Twitter @MKrigsman. I've gained more understanding about ERP software project management and change management by reading Eric Kimberling's posts on Panorama Consulting's 360 ERP Blog. Eric Kimberling is on Twitter @EricKimberling and Panorama Consulting is on Twitter @PanoramaERP. Try the Twitter #hastags #erp for ERP software and #ensw for enterprise software. You'll find lots of goodies under the #ceo and #cio hastags as well. Happy hunting!
You might also want to pick up a copy of ‘why new systems fail’ by Phil Simon. Phil Simon’s website is philsimon.com. His blog has useful tips about how to avoid IT project disasters, manage “big data” and use visualization tools to analyze information more effectively.
If you’re interested in the topics of enterprise software, ERP software, BI, consulting, manufacturing and others, then I invite you to check out my new website inforln.com. There is an enterprise software resource library with examples of work instructions, whitepapers, etc., an ERP software presentations library, videos and our new blog. It’s my baby.
I’m always looking for stories, ideas and guest posts for our company blog. Please feel free to leave a comment below to share your thoughts. Contact me atdan(dot)aldridge(at)i-app.com if you have questions or want to connect.
Posted by Dan Aldridge
Dan Aldridge is the CEO of Performa Apps, an ERP software consulting firm specializing in Infor LN and Baan. Dan has almost 20 years of ERP implementation experience. He has helped dozens of companies with their ERP software implementations and training including Carrier, Mercedes Benz, Snap-on Tools, Blue Bird, Flextronics and a host of other manufacturing companies. He is a serial entrepreneur and blogger with his new site inforln.com.
You can reach Dan on e-mail at dan(dot)aldridge(at)i-app.com or on his social networks: About.me, LinkedIn, Twitter, Google+, Scoop.it, WordPress, Slideshare,Pinterest and Facebook. His company is on LinkedIn, Twitter, Facebook,Google+,YouTube, Scoop.it and Slideshare.
|
