As an Enterprise Project Management Consultant, I have been part of several implementations and have had success at varying levels. I have learned several lessons along the way and have used each to help me in the next implementation. In this post, I discuss what I consider to be the top eight among those lessons, in hopes that this will help in your implementations as well.
These are applicable whether you are a consultant/partner helping your customer or a project manager running this project internally.
Note: You may be a Project Manager or a lead assigned with the EPM Implementation Project internally, so apply “Stakeholder” or “Customer” as appropriate.
1. Customers are better at critiquing than creating.
It is important to remember that customers do not always know exactly what they want, especially in an EPM implementation. Chances are that they have not seen Project Server before and do not understand the functionality you are talking about. So the lesson here is always to try to SHOW the customer what you are talking about, and then let them tell you how the solution will or wont work for them. Remember, demos always work!
2. Customers are not always right!
Yes, you read it right. The customer/stakeholder is NOT always right. Often when you are working in an EPM implementation a lot of change is involved, and the natural tendency is to replicate the old processes in the new tool, leading to the same problems the customer had in the past. However, if you really want the implementation to be successful, you need to guide your customers to re-evaluate their current processes and redesign those processes if necessary.
3. You must crawl before you walk or run.
Project Server offers so much in terms of functionality. You’ve got Project Management, Schedule Management, Portfolio Management, Workflows, Documents, Issues, Risks, Timesheets, Tasks, Financials, and so on. While it is VERY tempting to do everything, at least a little bit of everything, that is not the best way to approach the EPM implementation. Help your customers identify the most critical requirements and keep a finite list. Focus on implementing the smaller list of features first and well. This will not only allow the customers to get acclimated with the tool but will also give you some early wins, which should make the future enhancements much easier.
4. Why the heck am I doing this?
A lot of times, EPM Implementation Projects are internal projects that are implemented by PMOs or leadership teams intent upon improving the processes and project management practices within. While this is a really good objective, it is common that these projects are run entirely as a top-down push. However, it is really important to answer the question “Why am I doing this?” to the lowest level of the organization involved. EPM implementations have a direct impact on MOST levels of the organization and unless this question is answered properly, you will never have the buy-in you need to make the implementation successful.
5 .Let customers use it.
I have discovered (painfully) that several times, the design that was agreed to during design phase is not always the right one. It is very possible that once the design is implemented and customers start using it, they find that it was not what they expected or that the other design you proposed initially was better. To overcome this buyer’s remorse, I have always found it helpful to do a pilot of the implementation before going live. Some people view this as testing, but in my opinion, a pilot is a free-form test of the processes and design and is generally done after the system testing has been completed. Freezing the design before we went live has helped me greatly in various scenarios.
6. Training is a continuous improvement process.
The most critical thing to remember about an EPM implementation is that training is not a one-time event. Not all users are going to be experts in one session, one day, or one month. Training is a continuous process. The training program should have specific goals and target levels. Ideas include: developing reusable materials, holding weekly lunch-and-learn sessions, or holding mini-contests. The bottom line is that training is going to be your most useful weapon to take on the challenge of change management during EPM implementation. Do not blow it!
7. Encourage user participation.
As tempting as it is to be the super-god-of-Project-Server-who-knows-it-all, you need to develop Super Users for your implementation who can help their groups with Project Server. In addition, encourage users to help each other. The Project Server Forums and the MPUG Forums are a great example of community collaboration. Establish an internal discussion forum, and instead of your answering every single question, let other users answer them. Crowd sourcing is the name of the game currently and you should embrace that concept through the use of such things as discussion forums and success stories.
8. Quick resolutions bring quick wins.
OK. So you have completed the implementation and are in post-Go-Live mode now. Project Server is very transactional in nature, so no matter how perfectly you have implemented the solution, you are going to have issues once in a while. Here is the rule: be absolutely fanatical about providing a response/solution as FAST as possible. This is where the users confidence in the tool is built up or destroyed. I have seen several scenarios where the implementation went very well but the support fell through, and the eventual conclusion was that the tool had too many issues and did not work. Remember, the confidence of your users in the newly implemented tool is based on a trial period, and you need to make that confidence permanent through excellent support and follow-up.
Conclusion
I could keep going on and on with the lessons learned. At the end of the day, this is all regular project management, but it is amazing how many of these principles are ignored (including by me). I would be very interested to hear about your lessons learnt. Please post any comments you might have.
