ERP implementation project management

Implementing an ERP is a long project, with many people on the client's side and on the implementer's side, and with a trait that makes it delicate: almost everything depends on everything else. Migrated data conditions the tests, tests condition the training, and the go-live date does not move easily. Running it well takes two things: a phased plan that everyone understands, and a follow-up of hours and changes that does not depend on anyone's memory.

The phases of an implementation

PjMan comes with an "ERP implementation" project template with the eight phases this type of project usually has:

1. Analysis: understand the client's processes and fix the scope.
2. Configuration/set-up: get the system ready for those processes.
3. Data migration: prepare, load and validate the historical data.
4. Custom developments: whatever the standard does not cover.
5. Training: key users and end users.
6. Testing/UAT: acceptance tests with the client.
7. Go-live: the start of production use.
8. Post go-live support: stabilisation after launch.

When you create the project you pick the template and its phases are copied into the project, with their code (F001, F002…). They are independent copies: you can rename them, reorder them, add others or delete those you do not need, and each phase accepts sub-phases. If you later change the template, projects already created are left untouched. (Creating a project, Master data and catalogues)

What tends to go wrong

Every project is different, but some problems repeat:

• Data migration is underestimated. It is often the phase where hours deviate most. If you estimate by phase and task, the deviation shows as soon as work starts.
• The scope grows without anyone deciding it. Small requests accepted out of courtesy end up consuming hours that were not in the budget.
• Decisions get lost. What was agreed in a follow-up meeting is forgotten unless it is written down with an owner and a date.
• Testing gets squeezed. When what comes before slips, the margin that gets cut is the acceptance testing.
• Problems show up late. After go-live, issues arrive that have to be sorted, assigned and closed.

How PjMan helps

• Hours per phase, at a glance. Each task carries its estimated hours, the team logs theirs and each phase shows hours logged against estimated. The project header gives the total deviation. (Time and expense tracking)
• Hours budget. You can set an hours budget when creating the project and compare it with what has been logged.
• Change requests. Each out-of-scope request is recorded with its estimated impact and its approval, instead of being absorbed in silence. (Change requests)
• Risks. A register with probability, impact and mitigation plan, for the things that have not happened yet. (Risks)
• Meeting minutes with follow-up tasks. Each agreement from a meeting generates its task, with a due date, so it is not lost. (Meeting minutes)
• Issues after go-live. With severity, priority, configurable statuses and assigned people. (Issues)
• Plan and work. The Gantt chart of the phases and a Kanban board of the tasks, on the same data. (Kanban and Gantt)
• Each role, its own view. The PM runs the project, management sees the portfolio read-only and each consultant sees their tasks. Optionally, you can state the main platform or technology of the project from a catalogue of your own organisation.

A starting point, not a mould

The template is a reasonable proposal, not an obligation: a small implementation may not need custom development, and a large one may split the migration into several phases. If you always work with the same phases, create your own template and use it in all your projects. The predefined template cannot be modified, but you can create yours from scratch.

Try it

Create your account, create a project with the "ERP implementation" template and estimate the hours of the first tasks. Or explore the demo, which includes sample projects.