If We Could Do It Over

Two manufacturing customers were comparing notes as I sat down at the lunch table at Convergence, the Microsoft customer convention. Customer A was considering Microsoft software and Customer B was close to "going live" (i.e. stopping their old system and using the new one exclusively). In the course of the conversation, Customer B made four major points:

1. If we had to do it over, we would have more training of our development staff at the start of the project.
2. The project was a lot more complex than the VAR (the consulting firm that sold them the software) realized.
3. The VAR refused to admit that they had done anything wrong. They just kept charging time and materials regardless of how many resources they threw at the project.
4. We stopped letting the VAR run the project.

These are good lessons to consider if you're about to launch into a project, particularly when it involves processes that are as complex and company specific as manufacturing.

More Training

Training is tricky. If you do it all at once, there is a tendency to forget the material or get overloaded. If you do it too late, the customer may already be frustrated by working with a system they don't understand. It's a good idea to leave space between sessions to allow the people time to absorb and hopefully apply the lessons, but training needs should be raised at the regular status meetings to be sure nobody is spinning their wheels. You do have regular status meetings, don't you?

Complex Projects

The concept is simple. You design a product, build it and sell it, right? The deeper you get into a project though, the more complex it becomes. Sometimes, even the customer's managers don't appreciate the complexities. It isn't until someone who actually processes the transactions sees the system that some issues emerge. If the discussion gets to finger pointing, you've lost. People will stop talking and start blaming. This problem has to be stopped before it starts. From the beginning, both sides have to take the position that this is a joint discovery process. The key is constantly checking the assumptions and progress. That's another good use of regular status meetings.

Billing and Milestones

Customer B brought up a nice idea: set up the project as being time and materials, but once the milestones are set, get a firm quote for each one. That spreads the risk between both the customer and the consulting firm. I don't have any experience with that scenario. If you do, please leave a comment.

Whose Project Is It?

Project Management theory is clear on this point. The project is always the customer's responsibility. The customer leads the project. It cannot be effectively delegated to an outside vendor or subcontractor. If you don't have a qualified person on staff, engage an independent project manager. The consulting firm can and should have someone to manage THEIR responsibilities, but that person should not be put in charge of the whole project. They have neither the authority to delegate work to the customer's staff, nor do they understand the full scope of the project.

Resolution

To resolve their issues, Customer B took control of the project and went directly to Microsoft and the developers of the add-on package that handled manufacturing. The project ended up exceeding budget, but they are close to going live and are confident that the software will work for them. Their experience will help them in future projects, particularly if they document it as part of a Lessons Learned session.