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.
Chuck Ray
Senior Analyst
University Advancement Services, University of Rochester
Rochester, N.Y.
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.
Jay Elliott
IT Process Architect
United Airlines
Elk Grove Village, Ill.
SYSTEM DYSFUNCTION
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.
Chuck Mandt
President
Biz-e-solutions Inc.
Atlanta, Ga.
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
Associate Professor
University of North Texas
Denton, 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.
Jim Osborne
IS Director, Planning and Technology
REI
Seattle, Wash.
This was first published in May 2006
Join the conversationComment
Share
Comments
Results
Contribute to the conversation