Four Microsoft Dynamics GP Project Team Blunders and How I Become a Hero

January 22 2009

After reading the title you may be asking "what does one thing has to do with the other?" In the spirit of disclosure, most customers come to know about

About Mariano Gomez

Mariano Gomez is a Microsoft MVP, PMP and EVP for Midmarket Solutions at Intelligent Partnerships, LLC. He is the original developer of the Microsoft Dynamics GP Spanish release for Latin America and has been consulting and implementing technology solutions for organizations across the United States, the Caribbean, and Latin America for the last 20 years. Mariano holds an MIS degree from the University of Phoenix.

About Intelligent Partnerships, LLC

With over 150 years of combined management and technology consulting experience, Intelligent Partnerships skillfully partners with organizations to solve complex problems, boost operating performance and maximize value for stakeholders. 

A leading global professional services firm, Intelligent Partnerships draws on its deep operational and technical competencies to help companies across industries improve operating and financial performance.  Whether serving as business advisors or in interim leadership roles during periods of change or transition, our professionals take early and quick action in delivering measurable and sustainable impact to both top and bottom lines with a persistent focus on accelerated value creation and precise execution. Locations: Atlanta, United States; London, United Kingdom; and Dublin, Ireland.

More about Mariano Gomez


mpolino's picture

I would add "We don't need a Project Manager". Mark

mgomezb's picture

Mark, Much thanks for the follow up! Indeed, the lack of a project manager, or better yet, the lack of sound project management principles constitutes the fastest way to failure in any project. The scenario here is "we are a $10M company, we don't need a project manager". Translation: this is such a small implementation, why will we ever need a project manager? In fact, small projects may not need a project manager onsite and full time, but it is the responsibility of the customer and the partner to still put a layer of oversite to the activities being performed by the consultant onsite. At my former company, it was typical to have weekly status meetings with the client to provide an update on the activities being performed by the consultant doing the GP implementation. This was a 1 hour meeting in which a written document was provided to the client. One, it benefits the client, two, it covers the partner and the consultant onsite at the end of the day. Best regards, MG.- Mariano Gomez, MVP Maximum Global Business, LLC blog:

sledg77's picture

I've made a rewarding and lucrative career out of 'fixing' failed implementations. It truly is wonderful to be looked upon as the 'Hero' as opposed to the alternative. Let's hope the GP customers out there don't follow your advice so we continue to have plenty of work in the future!! Seriously though, you're points are stated perfectly. Great job as usual. Frank Hamelly MCP-GP, MCT, MVP East Coast Dynamics blog:

mgomezb's picture

Frank, It's great to see you reading my articles! I wanted to clarify a few things about the article itself. Failed implementations are not necessarily always a result of having bad partners. In fact, the article addresses failed implementations from a project team formation point of view. To the contrary, I believe if customers spend more time on project team formation, then I can see how we will continue to have more work in the feature, since project budgets can be fully utilized to support true business needs and not remediating what should have been in principle a 'slam dunk' with the right approach. Best regards, MG.- Mariano Gomez, MIS, MVP, MCP, PMP Maximum Global Business, LLC Blog: The Dynamics GP Blogster @

CAPnMASS's picture

I also have enjoyed quite of bit of success in this arena and with the current economy, I see more coming. There will be quite a squeeze on the budgets of customers and billable backlog for consultants creating a perfect storm. So the cleanup business should be fine. Unless the partner is completely inept, it is always the decision of the customer that creates the problem. The mistake the partner usually makes is not walking away! I totally agree with the thesis that the problem is in the beginning of the project and that the formation of an effective project team is critical. Hopefully, some of the ground work for this was done in the sales process. It is all about setting expectations and agreeing on the project objectives. The most effective tool I have used to avoid these problems is the kick-off meeting including requiring who attends. Requiring representatives from all levels at this meeting will indicate the level of commitment the client has to achieving success. This includes the top financial position and another executive level participant depending on the size of the company. The problem is not usually with the accounting department, other than executive involvement, other department such as operations, sales and sometimes IT do not cooperate initially . If I can't get key people to attend a 1 hour meeting, then I don't start the project. As a consultant, if you have failed to require a kick-off meeting and then successfully educated the client on setting up a quality project team and still continue with the project, then it is not longer the customer fault, it is the consultants. MG, very good analysis on the major failures of project teams. As far as getting paid for project management, quit trying to bill a line item for it! We have all tried and essentially failed to have small to mid size companies accept this practice. Either build it into the billing of consulting services or I have been exploring Fixed Scope packages that also includes the management functions.

Leslie Vail's picture

Good advice on project management - don't do line item billing. Too often the client doesn't value project management because it doesn't appear that the project manager is 'doing' anything. Of course nothing could be further from the truth. If the project fails, be sure it will be the project manager's 'fault' from the client's viewpoint. If the project succeeds, it's not an issue. In this case it is a very win-lose setup. I think Mariano wrote an article earlier on what to do to make a project fail (or maybe succeed) - not having adequate client involvement at a high level was one of the first items on the list for failure. The project team of consultants can't be the only ones at a company who are committed to the project. If it's not important enough for the company to devote key resources to the project, then it's not important enough for the consultant to be involved in the first place. I, just like any of us, hate to turn down work, but if the client isn't willing to be involved - I shouldn't be either. Thanks for your insight. Leslie

mgomezb's picture

CAPnMASS, Thanks for your very detailed input. I am a big Microsoft Solutions Framework (MSF) practicioners and one of the critical aspects highlighted by the Framework is Team Formation. This process is critical to the success of the entire project as you need individuals that are familiar with the technical aspects and the business aspects of the implementation. You also need the decision makers and everyone to be on board with the necessary changes that need to take place to move the implementation forward. Thanks very much for your comments. MG.- Mariano Gomez, MVP Maximum Global Business, LLC

EXEDY's picture

My users were definately pushing for #4. For reasons I can't understand, everyone HATES Smartlists. On the overall topic of failed projects, I (the sys admin) definately made some mistakes in managing the project, but my bigest one was assuming my partner knew what they were doing. We took a very long time examining our options before deciding on GP and one of our partner's selling points was how everything would be planned out. In reality they took a "figure it out as we go" approach. I had to make the decision to cut many major features we had asked for because I couldn't get an answer from them on how we were going to accomplish them. I was left with the feeling that our partners plan was to convince us we didn't need the features we were asking for. Now 6 months after cutting over to GP, we're probably going to drop some major 3rd party add-ons that have never worked right and try again. I guess my lesson is that I would never try to move to an ERP system that I hadn't worked with before in a successful, fully functional implementation. Now after a lot of late nights, I think I could figure out if GP was right for a company (in some future job) and what the real cost would be.