I once heard someone state that a crappy system implemented well is far better than an awesome system implemented poorly. I’m paraphrasing, but this is one of those thoughts that have stuck with me over the years and it drives a lot of what I do. Not because I want to sell crappy systems and implement them well, but because if a crappy system implemented well is so good then think how much better an awesome system is when implemented well!

In my experience, most consultants tend to think along these lines too – even if they don’t verbalize it quite that way to themselves or their customers. I don’t know any consultants who set out to do a bad implementation. However, many consultants seem to equate a good implementation with project stages and tasks that often only result in higher billable hours and do not necessarily add actual value to the project.

I almost never end up competing with other Dynamics GP VAR’s directly. However, I was recently approached by a prospect as the VAR they were talking to was not local and the prospect preferred to work with a local partner. The prospect couldn’t understand why our quote was approximately $25,000 lower than the other quote, and asked us to review both to point out the differences. Essentially, the other partner was following a more old school ERP Implementation process, while we were following a more streamlined process. As a result, we ended up with not only a less expensive project but one that would complete much more quickly.

So the question is, why do some partners feel they need to charge for so much project? Is it really necessary for you? And how can we run successful projects without it?

Old School ERP Implementation

People have been implementing software for years, and a set of implementation best practices has grown out of that. I certainly don’t think I am any smarter than all of the consultants who have come before me and blazed this trail, but I do think that we need to consider which best practices actually apply to any given ERP implementation. In much larger implementations where you have hundreds of people involved and software that’s hard to change post-implementation, I believe that every single best practice is not only recommended, but required. I would argue, though, that Dynamics GP implementations don’t look like that and we have a little more leeway.

If you are working with a Dynamics GP partner who uses old school big project methodology look out for these three costs:

Discovery

The discovery phase is a billable exercise whereby the consultant (or worse, consulting team) who will be implementing your system learns about your business operations. Although some firms have a standard set of questions, or even a form, the process almost always ends up with the consultant(s) and the project team sitting in a room talking for some span of time.

Discovery tends to last for a week or two and the outcome is usually an “as-is” or “current state” document. During this phase, the actual solution is not usually discussed.

Design

Once the discovery is complete, the design phase can begin. Based on what was learned in the discovery phase, the project team will document how Dynamics GP is to be implemented for this particular project. During this phase, several decisions will be made as to which modules will be implemented and how those modules will be configured. Often, the software is not actually opened during this phase, as setup and training come in a later project phase. If add on solutions are required, they will be discussed at this time.

This phase tends to last another week or two. At this point, you have spent 2-4 weeks talking about your company and the software, but it likely isn’t even installed yet! The usual outcomes of the design phase are the system/solution design document (sometimes called a “to-be” document) and a project scope document. Sometimes other project management documents such as the project charter are written at this time as well.

Project Documentation

Documentation is just paperwork, but Project Managers seem to love it. With traditional waterfall project management, there are lots of choices for documents you can prepare. Some of the most commonly delivered in ERP Implementations are the charter, the statement of work, design documents, decision log, and weekly status reports. Even though the information contained in the documents tends to be similar (some documents are just reworded versions of earlier documents), the time spent on each one is billable.

Most project managers will tell you that without the discovery and design phases and this level of project documentation you will not get the right system, the costs will spiral out of control and the project will fail.

I disagree.

The Briware Method

As mentioned earlier, at Briware Solutions we prefer to blend project phases where possible. For example, our sales process always includes one of our senior consultants and much of the “discovery” is done before the customer has even decided to purchase the software. Our design, configuration, and user training is also blended into one step. We open the required configuration windows, discuss the options, and decide which fits your business best.

We also find it efficient to combine project documentation. As such, we only have 1 project document that we deliver: the Configuration Document. As part of the presales process, the Configuration document acts as a design document, and is used for handoff to the consulting team later on. As the project progresses, the document is updated with configuration decisions, issue resolutions, installation notes, and any customization design. In the end, you have a complete record of your project as well as a technical reference. As mentioned in a previous post, we try to have users build their own user documentation, and often copy that into the configuration document as well.

Is Project Management important?

I am not saying that we don’t do project management. What I am saying is there is a different way to do it. Working from a single document, we’re not going to duplicate efforts. We do have a project plan, but it’s flexible.

This is possible due to one of my favourite things about Dynamics GP: it is highly configurable. There is very little that is set in stone during a Dynamics GP implementation. If we go live and a user decides they can’t work a particular way, we just change the setting and fix how they work.

But we also know the areas that do need to be finalized from the beginning. For example, we will spend a lot of time designing the chart of accounts because it is difficult to change a chart of accounts down the road. Not impossible, just difficult.

If you are a company that wants to get the project done without a lot of extra fuss or expense, then you need to work with a partner like Briware Solutions. There is nothing old school or bloated about our methodology.

And we promise you’ll still end up with a very well implemented system.