Off Roading and Hindsight

I'm sure I'm the only GP consultant that has ever been part of a project that has gone over budget or missed a deadline.

But to help those of you who have a perfect record delivering on-time and under budget projects, I thought I would share some thoughts about two observations I have noticed about projects that either took longer than anticipated or ran into unexpected complications.

The first is a concept I like to call "Off Roading". I grew up in an area where a 15 minute drive could put you out in the middle of the desert, with not a building or car or person in sight. When I was in high school, a friend of mine fancied himself as an off road type of guy, so he would take his parents' Chevy Suburban out in the desert, pull off the paved road, and just hit the gas.

This wasn't just any Suburban with fancy off road suspension, big nobby tires, and extra clearance around the wheel wells. Nope, this was the kind of Suburban that would hold 2 baby car seats and have groceries in the back. It was the basic model with no special suspension and city road tires. In short, it was not made to be driven at 40 miles an hour across the middle of the desert. Flat tires, cracked windshield, and alignment mayhem were the result.

That's a dramatic analogy for what sometimes happens during a Dynamics GP implementation.

The customer may request a modification to Dynamics GP to accommodate a unique business requirement, and after a little thought, you may figure out how to tweak, bend, bolt, weld, or duct tape something together that will meet the requirement.

There is definitely a need for workarounds, customizations, or an occasional band-aid to handle certain business processes and requirements, since no software package will accommodate every client's requirements out of the box. And often times the workarounds or customizations are trivial or simple. But sometimes they aren't.

In general, I think it's good to at least recognize and acknowledge when you start to go "Off Roading" so that you can begin to assess the risks and plan accordingly.

One project where I had to Off Road was when a client needed to import thousands of GL Clearing Entries. Unfortunately, there is no standard integration for Clearing Entries, so we had to reverse engineer the clearing entry transaction in GP and create our own custom integration. There were a few tricks we have to figure out, but fortunately that one went relatively well.

But then there was the project where a client wanted to fully automate the entire Dynamics GP AP check printing process across over 20 companies. We're talking a single button click to select checks, print a selection report, print the checks, post the check batches, and then save the posting reports for over 20 companies! This was like Off Roading on Mars.

At the time, we worked out a detailed project plan that we thought covered all of the tasks and included sufficient time to handle unexpected complications, so we thought we were playing it safe. Although we did finally deliver a solution that miraculously worked, despite our best efforts trying to plan the project, I think we ended up spending over twice as much time as we had originally estimated. It was vastly more complex and treacherous than we anticipated, with very specific implementation issues that we could not have possibly foreseen, since such a project had literally never been done. It allowed the client to decrease their AP payment cycle from 3 full business days to just a few hours, but it was a challenging project, to say the least.

There are many corollaries to these lessons, such as recognizing your limitations, having the fortitude to decline high risk projects, and developing better project management practices (such as using the Dynamics SureStep Methodology), but I'll leave it at that for now.

And that brings us to Hindsight.

"Why didn't you..." "You should have..." "Why wasn't this..."

It's always easy to see the mistakes in hindsight because you've already made them, they seem obvious in retrospect, and you sometimes have scars to show for them.

Although it would be ideal to avoid the mistakes in the first place, projects don't usually go perfectly, so I think the opportunity is to use hindsight not just to beat ourselves up over the mistakes, but to try and figure out what new practices, procedures, or tools we can adopt to try and minimize some of those mistakes in the future.

You would think that this is obvious, and therefore easy. But it isn't. Despite understanding Off Roading and Hindsight, I recently worked on a GP customization that seemed pretty straightforward during the (non-billable) requirements gathering stage. But the development and implementation was much more complex than I had anticipated. Was there any way for me to fully assess the complexity in advance? Perhaps partially, but not fully, as I can't spend 20 non-billable hours to write a proposal for a 40 hour project. Could I have put in a ludicrous amount of "buffer" time to handle the complexities that I discovered? Highly unlikely, as I would have been unable to justify, in advance, the hours for such a budget, and couldn't have possibly guessed the appropriate number of hours.

So in hindsight, I have learned several important lessons about recognizing when I'm Off Roading, and hope that I better assess the risks the next time the pavement ends and the desert looms in front of me.

So, remember to fasten your seat belt and make sure to check that rear view mirror.