10 possible pitfalls for every ERP project manager

I think we all have experienced the impact project management can have on the projects we work in. Good project management can make hard projects really rewarding to work in. But there is also a chance that bad project management can make even small and easy projects fail. So who is responsible when a project fails? Very seldom it is simply one person or role to blame, but often a heavy burden lays on the shoulders of the project manager.

So I have tried to list 10 possible pitfalls for every ERP project manager based on my own experience working with both great and not so great project managers.

1. Failing to define the project scope
   This should be the first task that is completed in any project. Without a clearly defined scope of the project it is very hard to get the deliverables needed out of the project. The scope needs to be defined, documented and communicated in a way that makes it understandable for every stakeholder and participants in the project. Try visiting a project that has been going in for a while and ask a random member of the project team if they can tell you about the scope of the project they are working in. If the response you get is unclear and you sense that they feel uncertain about the project scope then that should really be a red flag for any project. This awareness throughout the whole project organization lifts the awareness of a possible scope creep making it easier for everyone to raise their hand when they are told to deliver something that is possible out of scope.
   Of course the scope of a project can be changed during the duration of a project, but then it is equally important that the new scope is communicated in the same clear manner as the original scope.
2. Do you have a project plan that is really useful when it comes to executing your project and measure your project teams progress?
   Breaking up your scope and deliverables into a project plan might not be the hardest task, making a project plan into something that becomes a useful tool for the whole project is way, way harder. Have you ever been in a project where the project plan turned into something that only the project manager thought was a useful tool? I have. I can’t count how many meetings I have been in where I as a project team member have been presented with a project plan that I really could not relate to. After some of these meetings I have really been questioning myself if I was in the right project plan meeting at all or if I have entered the wrong conference room. Was it my project or another project they showed the plan for now?
   In this case it is legit to ask if I have paid enough attention or not. So in this scenario I could be the problem and not the project manager. Then I will argue that either way – the project has a problem. If I do not pay enough attention to understand the project plan someone needs to address that with me to either have it corrected or in worst case have me removed from the project. If I do not understand the plan, I probably do not understand the scope or at least not the part of the scope that I am responsible for contributing to so what good do I do in this project in that case?
   I think much of this comes down to the structure and the level of details in the project plan. And finding the balance here can be really hard. If we look at most project methodologies they will tell you that you really need a very detailed plan. But if that is the case I think that project management needs to structure that plan so it can be communicated in parts to different stakeholders so they really understand what part of the plan they should relate to. If I need to participate in a project plan presentation that takes two hours and only 1 or 2 of those minutes really relates to my part of the project – then it might be understandable that I do not pay that much attention during that presentation. So my advice – break your plan into different part – consult your team when the details of the plan shall be laid out.
3. Get the right resources assigned to your project team and make sure they have the needed hours available.
   If you do not have the right competency in your project group you are bound to fail. And the resources also needs to have available hours in their schedule to execute the tasks in the project. Picking project resources that already have their daily scheduled filled with other tasks will never be able to focus enough on your project. So make sure the hours you assign them in the project are cleared for other tasks.
4. Make your work about the project and not about the project manager
   Some project managers seems to be blended by the last part of their title and think they are there to micro management every aspects of the project. Remember that you are there to facilitate the project and not to control every detail. If you had have the competency and the time to micro management every aspect of the project then why do you have a project group in the first place?
5. Make sure the status reporting is reasonable
   It is very understandable that any project need to be able to report status, progress and risk. But make sure not to come up with a status reporting model that requires that the project participants use more time reporting then they have available for doing project deliverables. It is not satisfying for anyone to write lots of project documentation that is never read by anyone.
6. Trust your project group
   The people in your project group are there for a reason. They are hired to do the job needed for the project. And even if they are not hand picked by you, you must trust that they are capable of doing their job – at least until they prove otherwise. They need to trust you and you need to trust them. So if you are set up with a project group of resources you do not know very well – make sure to spend enough time to get to know them as early as possible in the project. You will learn what their strength and weaknesses are, and they will know that you know what they are capable of.
7. Be transparent with your reporting
   If you are as a project manager are reporting to a steering committee or to your management group, make sure your project group know what status you report to the people above you, and let them comment on it possible before you hand off your reports. It is very demotivating for the project group to get back channeled information about the project they work on especially if that information is far from their own perception of the project status.
8. Manage your meetings well
   Make sure that every meeting you call for has a clear purpose, well defined decision points and and the the decisions are documented. Make sure you ask questions that are meaningful. I think every developers nightmare question is: “When are you going to finish your task?”. Instead try to ask questions about what your project team needs to be able to follow the plan and if there are any other resources they need help or assistance from.
9. Don’t make commitments unless you understand the work needed to fulfill them.
   Do not feel the need for giving commitments on the projects behalf before you have consulted your project team. Your client, managers and other stakeholders might try to convince you that the change in scope is small and not complex. But unless you are really sure you fully understand the work needed to fill the commitment don’t commit on it on your own.
10. If you don’t have knowledge about the project domain – make sure to seek advice
    Your project group fully accept that you do not know everything about the project domain – so remember to use their domain knowledge to deliver the best project possible. You do not lose face by admitting you need help from your project group to manage your project.