I just read "The Truth Is, Users Hate Change" [Business Mentor, March 2006 issue], and it rang true. Along with six others, I am about to embark on a system replacement project, and change management has been one of our greatest fears. Our formal kickoff is scheduled for May 4, and our contract provides us with 27 months of implementation time before costs exceed the budget. Our other concern is that senior management won't be available to make the decisions when they need to be made, which can delay a project and increase the budget.
University Advancement Services, University of Rochester
FLEXIBILITY, NOT FORMULAS
I just finished "The Ingredients of Project Success" [Project Expert, March issue]. Your argument for a robust project management process conflicts with your examples: the doctor's pre-op exam, the pilot's preflight checklist and the chef's proven recipe. Each is a formulaic, proven procedure that is executed the same way each time. A formulaic approach to project management quickly proves unwieldy by imposing artificial bureaucracy on small projects or by oversimplifying large, complex efforts.
Implementing a well-defined process for managing projects -- such as the one developed by the Project Management Institute -- is a healthy goal for organizations. Each project follows a similar path through an established framework, and managers can govern their projects without forcing initiatives into a one-size-fits-all "recipe."
The key is a robust process that provides structure and allows for flexibility. If it's too rigid, it crumbles; too loose, and it becomes unmanageable.
IT Process Architect
Elk Grove Village, Ill.
I just read "Reasons to Get to Know Your End Users' Business" [Project Expert, February issue]. Your article addressed all the projects I've worked on, especially my last one. For five years, a behavioral health company had developed a system that was the most dysfunctional one I've ever seen. The CIO and developers created a system based on data requirements without understanding end users' needs, let alone business processes.
After firing the CIO, the company hired a contract CIO, who in turn hired me to manage the project. In six months, we developed a system that everyone loved. And we went from dysfunctional paper medical records to a totally electronic system.
In my experience, few programmers can talk to executives and dig into business processes, and they don't want to. Many of the projects they lead become disasters.
AN ERP PROJECT TO LEARN BY
My students recently read your December ERP Journey column ["Like an Ill-Fitting Tuxedo, ERP Needs Some Tailoring"], and they really enjoyed it. It's difficult to show students real-life experience in a project as large as enterprise resource planning implementation, but this column gets them as close as possible. My students look forward to catching up on the whole project.
Mary B. Curtis
University of North Texas
DITCH YOUR ASSUMPTIONS
As I read the ERP Journey column "Our Missteps Teach Us to Assume Nothing" [January issue], I flashed back to an implementation I was involved in with SAP in Japan. One of the lessons I learned was assume nothing and question everything. We made our dates, but not without a heroic effort. Since then we've embraced a rigorous project management methodology from Fujitsu called Macroscope. Good luck on the rest of the project.
IS Director, Planning and Technology
This was first published in May 2006