Darren Spurgeon - ERP Program Management

Objectives

This project was a multi-year effort to transform the company’s business processes and, along with them, their business systems. The following objectives were a part of this transformation.

Upgrade our existing Oracle E-Business Suite core financial platform
Replace our internal thick-client business systems
Build new customer & partner facing web applications
Implement new data warehouse and analytics tools

Contributing factors

There were many constraints and contributing factors that we had to contend with, including many cross-functional teams, distributed teams, multiple implementation vendors, slow business buy-in, and not the least of which were three restarts of the program before I took a management lead. I’ll address this more in the Challenges section.

Approach & Process

Defined architecture

Because this was a transformational project, virtually every process and system was potentially going to change. Obviously, there was a tremendous amount of work to design the future platform, so I don’t want to discount that. Nevertheless, I want to focus on the planning aspect of this effort.

It was critical we found a way to communicate those platform changes (current vs. future state) that was easily understood by all. Hence the first figure here, showing how the application landscape would change across the life of the project. It’s important to note that not every system was expected to change in that 3-year roadmap.

Team management

At its peak, we had 100+ people working on this project. Within the applications delivery team, there were a variety of subject tracks, all working on multiple systems and different aspects of the platform. So, it was important to have a workable day-to-day process for managing work that met the needs of complex relations while still be as simple as possible.

We used Jira to track everything, and utilized a healthy workflow full of various statuses that could help us follow activities as well as which system environment (or program stage) certain deliverables existed. This also helped us view performance of various delivery teams across sprints. As you can see in one of the diagrams here, every team was different and thus required a different approach to streamlining their efforts.

Timelines

At some point, you have to show specific delivery dates, and also keep in mind that the company has other priorities, too. It’s important to show how your large project fits into the timeline along with other milestones. Here, you can see a fairly standard timeline tracking projects, phases, and milestones.

Planning models

Lastly, we have the planning model. Ugh, it was truly a bear to put together a view that communicated everything in a meaningful way. Honestly, it took a day or two for anyone new to get up to speed on even the high level work breakdown. In the final two artifacts, you can see various teams and functional roles against estimates and work completed. The raw data comes entirely from Jira, and confidence in this data only came from drilling into the team the importance of estimating and logging time spent–kudos to our managers.

From this, we’re able to take estimated vs. actuals and telemetry around performance (i.e., throughput for each team and function), and then project out dates for when deliverables could be expected. Budget vs. actual spend is then derived from this.

Now, what I’m not showing is the secret sauce behind the spreadsheet. It took about two weeks to get those correct, but once established, refreshing the projections was a one-click step. OK, I’ll give you a hint: Jira w/ Tempo worklog exports + Excel + Power Query. Oh, and if you must learn any Excel formula, it’s got to be SUMPRODUCT. You can do sometruly amazing things!

Challenges

With a project of considerable size, you’re going to run into a host of challenges. The biggest one, by far, on this project was lack of early business buy-in. This isn’t uncommon, and during my tenure at CCHS, I would say it came in a variety of forms, from rather different people, and for perhaps reasons that kind of made sense from a certain point of view.

Now, you’ve got to understand that the C-level had already approved the project, but the commitment wasn’t exactly there from levels below. The technology side of the house, nevertheless, ended up pushing the project along for a couple of years before there was some support. This put a strain on relationships and there was more than a few accusations of sabotage on both sides. Not good. I’d say we never really got there with the level of support I would have liked.

Another challenge was the fact that we had a tremendous problem with our first Oracle integration partner, selected just before I came on board. I’ve not experienced a level of combativeness from a “partner” before, but that took the cake. After more than a year, their contract was not renewed and we started again. Choose wisely, my friends.

Outcome

Here’s where we get down to brass tacks. As it turns out, the project ended up getting broken apart into a collection of smaller projects. Yeah, what a genius idea, you say! Yes, this is generally the better approach, but there were lots of reasons why the company wanted to try a big bang approach. In any case, we got there in the end.

So, the project eventually transformed into a service platform implementation and a collection of smaller web portal applications. Ultimately, the large project was officially canned in favor of smaller deliverables that, drum roll, actually got delivered!

For my part, managing the software delivery aspect of the program, I was glad to see those applications come to fruition. Those included a consumer portal, client portal, revamped service portal (before the large service platform), and a migration to Amazon Web Services.