Lessons I learned from a 3-year ERP adoption IT project

The SME company I joined in 2015 had purchased Microsoft Dynamics Navision 8 years prior. Their 40-year-old company had been running it’s ERP functions off of a COBOL programming language software package (multiple applications) that was purchased from an external software company decades previous. COBOL had become a deprecated computer language and the ratio of computer programmers learning COBOL was quickly dropping. For 8 years the company had tried to get off the COBOL system and fully onto Navision and an internal .NET application, but it hadn’t gotten far. The few resources the project had assigned to it were overwhelmed by the complexity and depth. The resources also weren’t dedicated and hence had other job responsibilities and duties. One major problem was that computer programmers for COBOL were very old school, and many of them never did much documentation, so trying to capture the requirements was extremely difficult. If you wanted to find an answer or gather a requirement, chances are it had to come from some programmer’s memory.

The COBOL applications handled inventory control, invoicing/billing, procurements, job costing, customer report generation, customer data file generation, payroll/time sheets, sales reports, manufacturing tracking, customer database management, overall financial management, and much more. Almost all functions of the company operated through the COBOL programs. Just before the time I arrived on the scene, only a few of the company functions had made a partial transition off of COBOL, and a mechanical engineer had just been tasked with the project. I picked up the project with this mechanical engineer and the rest is history.

Together we started planning the project timeline, while also realizing that this project was heavily agile in nature. Unlike most waterfall projects that could have scopes, budgets, and schedules duplicated from previous lessons learned, this was a complex project that was unique in nature relative to the company it was being implemented. We began with xmind mapping software which helped us get a better understanding of the tasks that laid before us. We were then able to create a product backlog which we prioritized as best as we could, documenting all issues into Redmine project management software. To help keep visual track of the project tasks through their various stages (e.g. backlog, assigned, WIP, done, etc…) I began utilizing the Trello Kanban board PM software tool. We had gotten other dev team members involved in the usage of the project management software as well. (That project is for another blog post)

We’d have daily morning meetings to discuss the work we’d completed the day before, and the next steps we needed to take that upcoming day and week. The other challenges we faced were found in communications between the numerous stakeholders including manufacturing shop managers, COBOL programmer, Navision consulting company we’d hired, the internal .NET programmers, as well as the dozens of other stakeholders (e.g. customers, sales/marketing team, finance department, employees that would use the new systems, etc…).

Our first goal was to NOT interrupt normal business processes. This required lots of sandbox testing in test servers and databases before going live at the beginning and end of sprints/releases. Our other main goals were to attempt to complete the transition within 5 years. That may sound like a long time but when resources are stretched thin, and it’s a company with huge divisions and operations, 5 years was a great estimate including buffers. Coming up on project closure we are getting to the end of year 3. We were also able to find ways to do some development in-house meaning we saved on overall costs by not outsourcing expensive IT development to 3rd parties.

Lessons learned:

Only as good as your weakest pm area

What I learned from the experience is that project management is not about being good at just one area of project management (e.g. soft skills, technology, planning, control, etc…), but rather, that like the weakness in a chain, a project is limited by the weakest part of the chain. You can have great planning and technology skills, but without the correct soft skills, the project is hampered, and vice versa with any project management area. You can have the best soft skills and technical skills, but without the proper planning and control skills, your project will suffer. We had a person at the company worked at that others were literally afraid to approach and talk with because they feared this person yelling at them. I found that getting this person’s trust through trying my hardest and working hard in the trenches with him was the best way to be able to connect with him and to capture direly necessary requirements. Had my soft skills been lacking, this project surely would have resulted in failure. The point is that a project manager is only as good as their weakest characteristics, so it’s imperative that PMs find what areas they struggle and continually improve those areas.

Need to find the right balance of documentation

There were times in the project where mistakes were made with tracking issues. Not just with underreporting, but more often with over-documenting. I attempted to plan things that were far from certain, in detail, far in advance. Sometimes a year or so ahead of time. Now on some generic, repeatable project this might have worked out just fine. Problem was this was a highly agile IT project with a changing requirement backlog. A backlog that was constantly changing in prioritization as well as in scope. I quickly realized that it came down to documenting in detail, vital information that was known, while documenting at a higher bird’s view information that was less well known at the time. In-line with this came making sure others on the team were documenting the right information as well. Some people wouldn’t have documented anything if not given the nudge, and others would have written books had given the chance (usually the former more than the latter). The important part that was highlighted was documenting what was perceived to be of value and that would most likely need to be utilized in the future. Once proper documentation processes were put into place, the project didn’t experience the numerous speed bumps that arose from the lack of proper documentation. I quickly learned that there’s a balance to the amount and types of documentation needed.

Soft skills are just as important as triple constraint and technical skills

I also realized first hand why most project managers say that soft skills are sometimes more important than technical skills. I get along with most people and usually don’t have problems with people at work, but not everyone is like that nor strives for this goal. There are people that you have to work very hard at communicating, at making this communication clear, at setting implicit and explicit expectations and building trust before any real work can be achieved. Being able to create a link between all of the different stakeholders involved was paramount to the project’s success. Without the ability to connect with the various stakeholders, and more importantly their various personality types, requirements would have been harder to capture, work effort would have been less productive, and the results would have suffered.

Expert and referent power were the most powerful types of management styles

Part of this lesson was a different lesson altogether, that out of all the various types of management power, expert power and referent power were by far the most powerful and meaningful. True power isn’t given, it’s earned. By showing you’re an expert, and showing that you’re personal and trustworthy, and showing that you are willing to get into the trenches with your team, THAT is far more powerful and motivating than punishment power. If punishment power was the most powerful then every dedicated projectized manager would be successful, yet projects continue to fail in the real world. Projects that have project managers that utilize referent power, expert power, and relational power are projects that have the best chance at succeeding.