ERP Software Logo1

Microsoft Dynamics vendors provide comparisons and opinions to professionals in the ERP/Accounting software selection process

 
 

Briware Solutions Inc.

How Long Should My ERP or Integration Project Take?


Email | Print

It takes nine months to make a baby.

And no matter how much money you offer, you simply can’t assign three women to the job and have it done in three months. That’s just a fact of life.

I would argue that the same is often true with technology projects. If a project is taking longer than you expected, throwing another person on the project won’t necessarily get it finished any faster.

In fact, it could make it worse.

When a consultant gives a time estimate to a client, it is just that - an estimate. The estimate is based on the average time it has historically taken that consultant to complete similar projects. Some projects take longer than the average, some projects take less. That’s a simple fact of math. The actual time a project takes is affected by several factors and not all of those factors are foreseeable.

As soon as a project seems to be taking “too long”, the customer will often ask us to put more people on the project to speed it up.

Admittedly, there are times when that will help. For example, if I have seven independent tasks and five of those tasks are being held up because they are being done by one person who simply doesn’t have enough hours in the day, then it makes sense. You throw another body at it and it should go quicker.

But there are many other times where it won’t. For example, when you are building an integration adding an additional cook to the kitchen can quickly spoil the soup! You often are best to stick with that one person who has written the hundreds or thousands of lines of code and has the overall picture still in their head. Throwing another body into the mix will make things worse because now the first person has to stop to explain to the second person what's been done so far and what needs to be done. Not only does that take time, but it also breaks the train of thought for the first developer who now has to refocus.

I remember a specific project I worked on years ago that is still a bit of a sore point for me. I was using Crystal Reports to build a custom invoice layout for a company whose contracts had dozens of different combinations of sections. They wanted certain parts of the invoice to show or not show based on different aspects of the contracts, and some were mutually exclusive while others had to print in a different order depending on contract checkboxes. At the end of the day, it had 39 detail sections - which is really hard to keep track of!

This was back in the days of on-site work. At one point the customer saw me sitting for about fifteen minutes, not appearing to be doing anything other than moving my fingers in front of my face. He went to my project manager and said, "This guy hasn't done anything for fifteen minutes. You should give him someone else to work with since he is clearly stuck and I don’t want to pay him to twiddle his fingers."

We had to explain to him that someone else to work with would not have helped me at that point because what I was doing was trying to picture these 39 complex pieces and how they would work together. I was going through the logic in my head, and it just takes time and focus. (Side note: when I say “we”, I mean the PM had to explain it. This was in my younger days and “we” agreed my "youthful passion" shouldn’t be part of the conversation.)

Another time we were dealing with a very large, complex integration project. It involved at least six different maps. The person who had been working on it had spent quite a bit of time, and they had written hundreds of lines of code.

At some point, the customer realized that they had failed to mention a requirement. In their mind, it was just a question of “adding a check box.” But, the developer had to go back and look at everything that had been built up to that point in order to retrofit that requirement in. It actually added an additional forty hours of work which translated to an extra couple of calendar weeks. The customer was not happy. But sometimes it just takes as long as it takes. We can’t dictate how simple or complex something is.

Last year I needed a motor replaced in my refridgerator. To me, that sounds like an easy job. But the guy spent an entire day doing it. I had a couple of choices: I could complain about how unreasonable the amount of time seemed, I could do some research and determine if it was a reasonable amount of time, or I could choose to accept that he's a professional that does this every day and he knows the situation better than I do. I chose the latter. I choose to trust the people I'm paying to be professionals until they prove to me that they aren't professionals.

Obviously, you need to work with an ERP Partner that you can trust. Then trust that they're going to bring in extra bodies when they need them and they're going to get stuff done as quickly and efficiently as they can.

My purpose here is not to tell you how to avoid having a project take too long. I just want to promote the understanding that sometimes, what we do looks easy on the surface but it's just not.

And if you force it to move faster, the results are likely not going to be the best. Sometimes babies come a little quicker too; sometimes they take a little longer. The average is nine months. When they come out too soon, there can be problems. So, maybe you can build that integration quicker, but at the end of the day, you likely won't be happy with the results!

Just be patient. It will be done when it is done, and it will be done right.

If you are looking for a Microsoft Dynamics partner you can trust contact us at 844-BRIWARE or rod@briwaresolutions.com.

By Rod O’Connor, Briware Solutions, www.briwaresolutions.com

Ask This Expert a Question / Leave a Comment