Gross-to-Net-Automation-Projects--Lessons-LearnedI’ve learned quite a bit while at varying organizations involved in differing Gross-to-Net (G2N) automation or business process optimization efforts. So knowing that, everyone asks the questions: ‘What have you learned? How would you have done things differently? What do you wish you had known, that you now know, before starting the project?’ Well, now I’d like to share my learnings with my fellow G2N community and certainly welcome back any feedback or additions to the list. I think we will find that we all have something to learn in this space!

The number one piece of advice that I have that applies to all of the four lessons below: keep an open mind. Most don’t heed this advice, or even want to hear it; as open mind means things like scope creep and increased budget. Quite the contrary, in my experience, I’ve found that those that keep an open mind from the beginning of a project actually avoid things like scope creep and extended timelines. While, on the other hand, those that go into a project with an absolutely limited mind, tend to come to the realization of what is actually needed, way too late in the game. And as we all know, this realization of requirements so late in the game, typically does push back deadlines and increases budget.

Here are a few valuable lessons I’ve learned, so that hopefully you won’t have to ‘learn’ them as well.

Prepare for Iteration

When taking a process that is so traditionally managed manually and with a ton of spreadsheets, all the while having complex methodology and varying levels of calculations, it is important to come to the conclusion early that you may not get this right the first time. Maybe right is the wrong word, rather ‘perfect’ the first time. A large part of effort in such a project which automates many significant manual processes and models, is in the automation model work itself. At first, this may seem like a simple translation from what is on the paper (or in the spreadsheet) to a system model; and it will most likely start out like this. But after about 20-30 models, you will start to realize, ‘OK, maybe there is an easier, more consistent way to calculate these fields, or pull in this particular data.’

This becomes very clear as you begin to have your team (especially the cross-functional business team) review and provide feedback on these newly automated models. And I must emphasize, this iterative review at some point while this modeling is still in progress, is crucial. Gaining new, outside perspective early on, is exactly what you need to ensure that your models are not only capturing all your requirements, but doing it in a fashion that is efficient, effective and will benefit the cross-functional organization.

It’s also important to begin to consider downstream processes and reporting requirements early on. We will discuss a little further as we approach Project Stakeholder Management and Change Management.

Available Technology Did Not Meeting Business Requirements

A new, shiny system out-of-the-box may look just as good to you as that iPhone 6 you got your daughter for Christmas, looks to her. All of those fancy features, slick dashboards are a promise for a new, better way. But your ten-year old daughter doesn’t need to check the stock market, or keep track of her blood pressure or step count, let alone require finger print entry to the phone itself.

We let ourselves get just as caught up on the nice-to-haves versus the need-to-haves (your actual requirements.) In order to avoid investing in a system that you think you need, but in the end doesn’t meet your true needs; I say one simple thing: keep true to your business requirements every step of the way. What I like to do, is map out all of my requirements to the capabilities of the new tool or technology, and ensure each of your requirements can and will be met. Also, take the car out for a test drive before you buy.

KPIs Changed During the Project

I’ve come in contact with quite a few finance professionals who live and die by their forecasting KPIs; so much that they could repeat the metrics in their sleep. So, you could imagine how tough it is for them to come to terms, three-quarters of the way through a G2N project, with the fact that their impeccable 2% forecasting error threshold, is really more like 10%.

Breathe…and keep an open mind. Remember, that 2% really meant nothing if it was misrepresented. Through optimization of related business process, you’ll find a more reliable, accurate and telling set of KPIs; KPIs that tell the truth and provide solid indicators of not only your business performance (both financially and operationally,) but will allow you to accurately measure up against them.
Prepare for this. Begin to consider new ways of approaching KPIs, and maybe most importantly, consider your financial reporting risk in the case that in two months, you need to drastically change your error rate (sorry, sorry, sorry.)

Project Stakeholder Management and Change Management

Be realistic about what functional areas across your organization are or will be affected by this project, and do it up front. I can’t tell you how many times I’ve seen upstream and downstream impact analysis done AFTER Go-Live. This is a big road block for business enablement or pull-through of the benefits of that newly implemented tool or technology. Try to get a good feel for who needs to be included, and pull them in as early as you can. If these groups can’t contribute during the project, for one reason or another, make sure to work them into your change management plan.

For the last time, keep an open mind. Disassociate an open mind with an open budget, and come to terms with a few of these simple, G2N project truths. Trust me, you will only benefit from it in the long run