On a recent ERP project I was a part of, the team absolutely nailed issue management. It seems so simple, but can be the difference between a smashing success – that rare ERP project delivered on-time and on-budget; and the typical project – late, expensive and poorly received.
There is no tool more prosaic than Issue Management. There are no secrets about the need to manage issues or what information to capture – you can find good guidance in a dozen places. Many of these guidelines, however, are aimed at hardcore software teams. Earlier in my career, I had used some of these recommendations straight out of the book with great success when leading development for a software product company. On an ERP implementation I led right afterward, issue management did not go nearly as well. What is special about issue management on this type of project and what did we do to get it right this time?
Issue management in an ERP project requires special attention to governance, access, flexibility and completeness. On this project, we used an issue management database in Deloitte’s e-room. It is a simple tool, but with enough functionality to do the job. It was how we used it that made the difference.
Governance
An ERP system involves a diverse cast of characters, with different experience and interests – this puts special importance on the governance process. In particular, how you open, close and confirm closure of issues.
Although anyone on the project could submit an issue, the PMO had to approve it before the issue went from New to Open. This was most important at the start of the project. Some business leads were participating in their first project, and had to learn the difference between an issue, a risk and a task. Issues that might result in enhancement / development requests with long lead times were supposed to be flagged – the PMO review allowed us to call out issues we thought hadn’t been flagged before the development lead time became a problem.
The rule on our project was that the business owner should open her own issues, and only the business owner could close it. This kept us out of conflicts between the consulting team and the business – everyone knew the business had the final say. We weren’t rigid about these rules. There were times it was more important to get clear status and make sure issues were documented, so we encouraged the entire team to open and update issues. But we tightened up again at the end of the project to make sure that issues were closed and agreed to.
Another key part of governance was that the PMO had to also approve closure of the issue (with the unfortunate naming convention that the issue was now “close-closed.”) Early on, this helped us educate people if they were closing an issue with to do’s left to resolve it. When we could, we reviewed these with the full 3 dozen or so core team members, so that how these were resolved was known, and if one team was kicking a problem down the road to another, the other team had a chance to speak up. As time got tight we couldn’t afford to spend the whole team’s time on this review, but by that time the norms of communication and responsibility had been set.
Access and Visibility
Everyone needs access to the issues system. You don’t need a fancy tool, but you do need everyone to be able to update and review issues. There is no excuse left for this not to be a simple web application with a database back end. It needs to be trivial to access and easy to know what the right values are for status and priority.
Issues need to be reviewed as a team (either full team or sub-teams) regularly – once a week is usually the right cadence. Project and development managers may practically live in the tool, but a team review on a weekly basis helps to keep the importance of documenting and resolving issues front and center with the entire team.
Flexibility
The basic fields will be the same in every issue management system: Name, Description, Date Opened, Severity, Resolution Details, etc. On every project, you will also come up with some special ways you want to categorize or tag issues.
We occasionally had specialized areas where a focused initiative generated a bunch of issues. We would sometimes create a separate database to whittle these down to a manageable number before dumping them into the central store.
We also modified the process at different stages. Early on, it was important for the whole team to understand issues and how they were being resolved. As some teams fell behind others, their time became more important than the communication benefit. We excused teams, or at particular crunch times, had the PMO review independently with each team.
Completeness
We constantly preached the mantra that issues needed to be documented and managed in the issues database, and chided teams when issues we had discussed in the hallway didn’t show up in their review. Particularly as timelines got tight, this allowed us to make sure that resources were focused on the priorities that the business cared about.
As go-live approached, we repeatedly used the issues database as the basis for the go/no-go review on a team-by-team basis. This allowed users who had never been through such a tough decision to approach it many times. If an issue was identified as ‘Critical’, which for us meant go live should be halted, we had time to focus resources on it and time to get the business acclimated to possible workarounds.
Special thanks to the Deloitte, ERP and Finance project leads for demonstrating how to do this right: Tom Pendergast, now Managing Director at Deloitte; Sal Companieh, now CIO for Cushman Wakefield; and Donna Rojas, now Global Technology Director, Strategic Programs at CW.