"It's the System" | Managing Known Issues

As you might have read in one of my previous posts, I have lately done a turbo implementation with a large number of customisations.

As always with these kind of implementations it is not 100% issue-free when going into production, especially when implementing in such short time.

When we started to implement you make the usual list of things mandatory to have, things important to have, things nice to have and things cool to have but less important.

Now in a normal implementation you would focus on having at least the first three, or if not possible the first two before going live. We had to focus on only the things mandatory to have.

This makes sure that the system behaves as wanted if used correctly, but as most of us know, NAV's flexibility really becomes the heel of Achilles when people start using it, especially the classic client. By accidentally starting a wrong transaction by pushing a wrong button or setting up new masterdata wrong you can start an irreversable process. For example, if you create a new item with a wrong costing method it's next to impossible to undo.

So in the first few weeks after go-live the classic "Known Issues" list started to exist. Things that "Go-wrong-all-the-time" because people don't use the system how they should. Some of these things are easily fixed by people getting more experienced with the system, extra training or a small TESTFIELD or FIELDERROR somewhere.

Then what's left is the list of issues that take more time to fix. Normally no problem if you implement mandatory, important and nice things before going into production. So we had to make choices. Which issue to start working on.

In these situations you can never make a "right" choice. Whatever you decide, someone will be happy and everyone else will be dissapointed.

This is where project management get's really important. The classical phrase here is MANAGING EXPECTATIONS.

In our case we made the decision to implement some of the important issues that should have been done up front, knowing that we had some loose ends in the things that were running. And as you aldready know: What can go wrong, will go wrong.

Whenever this happens it is important not to end in discussions with end users or their managers saying "It's the system". Make sure to have a list of issues that you know that can go wrong and discuss them with your end users. This way you share responsibility.

Yesterday we had the first office meeting since "go-live" and the management asked me to join the meeting. Primairy reason: he was affraid for "it's the system" answers to everything that goes wrong. And they tried, as always, to blame the system.

But since we were prepared we could point at the shared responsibility. We explained why decisions were made to prioritise differently.

This is, was and always will be a difficult scenario in each customised implentation.

Transparancy and communication will prevent you from having an escalated project.

To be continued...

Comment List