Rant again

seckpin

I have left the vendor enviornment for quite a while already, so I really have no idea how the partners implement NAV anymore.

As our company implemented NAV in various countries, we have dealt with vendors from different regions. The main vendor that we have now has never produced any documentations for implementation, such as the functional design document, setup checklist, or even deliverables and go-live sign-off. Our business users were inexperienced in system implementation and they did not know that these were essential in any proper implementation methodology. So for most countries, this vendor implemented NAV with what we termed as "shit and run" approach.

A different vendor we dealt with recently in a particular country did provide us with a "Sure Step FDD". All the setups and design are clearly stipulated in this document and we found it very good, clear and concise. We were told by this vendor that this is a document "required" by Microsoft when the partners implement NAV.

Lately when we were about to go live with one of the countries, we asked the main vendor to produce a setup checklist for sign-off (note: not the full FDD but a list of all the essential setups such as posting groups, decimal roundings, local currency codes, etc., for business to check and confirm). We asked them if Microsoft did not provide them with a standard set of documents for implementation. They claimed that all the while this has not been required and there is no manday included for preparing these documentations. If we demand for these now, we should pay for them to do it.

Probably it is true that they did not quote us the mandays for preparing implementation documents. Yet I would have thought that there should be at least SOMETHING for the business to confirm and sign off on the system setup and go-live, just to avoid future dispute if not for anything else.

It is disappointing that Microsoft does not really care about ensuring the quality of the partners. A lot of times, many businesses will just pay the vendor to perform the implementation and the business users may not have any experience in system implementation at all. All they can do is just to depend and trust the consultants and project managers of the solution centres, believing in their professionalism and the "brand name" of Microsoft -- after all, all these vendors always come with whatever numbers of certified consultants and Microsoft awards. Sadly, it often turned out to be nothing but great disappointment.

matttrax

I don't think this is limited to just NAV Partners, or even Microsoft Partners. Microsoft does not own the partner. They cannot, and should not, force a partner to do a job in a certain way.

That said, a partner should still do the job the right way. And that includes supplying all of the documentation that you specified.

Some partners are good, some are bad. When customer file their change of partner forms with Microsoft and enough customer leave that partner it will be looked into I'd imagine. They do have policies in place to deal with bad partners.

seckpin wrote:

It is disappointing that Microsoft does not really care about ensuring the quality of the partners. A lot of times, many businesses will just pay the vendor to perform the implementation and the business users may not have any experience in system implementation at all. All they can do is just to depend and trust the consultants and project managers of the solution centres, believing in their professionalism and the "brand name" of Microsoft -- after all, all these vendors always come with whatever numbers of certified consultants and Microsoft awards. Sadly, it often turned out to be nothing but great disappointment.

If you've chosen a partner based solely on the number of "certified" people they have then someone has done a bad job. Get customer references, visit a customer site, ask them to explain their process start to finish.

Again, quality can be bad no matter what type of business. Think about a chain restaurant. There's always that one Taco Bell that never gets your order right, but most of the other ones do a good job. You can't make sure that every partner is doing their job correctly.

DenSter

While from a user perspective I would agree with you that documentation should always be included, and of course more detailed would then be better than less detailed. Honestly I cannot for the life of me imagine a situation where there is not at least a bit of documented functional requirement and at the very least some sort of documentation about how those requirements are implemented. What you'll find though is that this documentation mostly describes the original intent, I think it is quite common that the documentation is not completely updated to the actual situation.

Now user documentation is a different story. Are you talking about comprehensive Company specific manuals? Every single partner in the entire world WANTS to create all of this, as it is a big revenue stream. I can also tell you though that user documentation and instructor led training are the first ones to go when budgets are finalized. It is quite common for companies to say something like "we will have our super users create the manuals and train our users". When they realize that this is a HUGE task on top of their regular jobs, this often gets left behind. It is then very common for end users (I mean the people that actually use the system) to complain about their partner about this, when it is in fact their own management that decided to "save money" and leave the documentation and training out of the project.

Surely you don't expect partners to provide all this documentation for free, as it is a LOT of work to produce. Check the original project plan or the statement of work to see whether documentation was ever part of the plan.

Not saying that you are not right, there *should* be clear documentation. You just might be surprised why there is none.

seckpin

No, I wasn't talking about user manuals kind of documentation. I know these documents do not come free and you are right that most of the time, this is done internally.

What I was referring to was the documents that one would normally expect in any system implementation, such as a design document, or a setup checklist specifying the setups as stated in my first post, or at least a go-live sign-off with suporting documents. As much as you find it hard to believe that the partner did not produce any of these, we are even more appalled that they made it sound like we are being unreasonable to expect any of these.

I guess we have only oursleves to blame, in that the earlier implemented countries (business users having no experience in system implementation) accepted such approach and now that our internal IT comes into picture and started to ask for proper documents for new implementation, they can easily use the reason that "this has not been the way we implement the system for your company all the while".

DenSter

I'm really not trying to disagree with you, because I do agree that there needs to be "proper documentation", whatever that means. Most of the time though that means whatever level of documentation the customer and partner have grown accustomed to. I don't think trying to assign blame to anyone is very useful. Whenever I read a "rant" I try to be devil's advocate and point out that there is more to it. We don't get the whole story here, so it's very difficult to say anything about whether your situation is "right" or "wrong".

I can imagine that your company and your partner started out with a certain level of documentation (you say 'none' but I would say it is more likely that there is 'some', let's not squabble about how much is appropriate), successfully implemented a couple of sites, and then kind of felt that there is enough 'trust' in daily operations that documentation didn't get as much attention as is generally accepted. I think it is reasonable to expect that in this situation, because of the level of co-operation, there is less documentation.

Then another partner came in, they wanted to make sure they made a good impression, produced minutely detailed documentation of everything they did, so you go "wow it is really nice to have so much documentation" and then the demands for more to the first partner start going out. My guess is that those conversations were very tense, especially when matters came up about meeting expectations (was it in the budget/plan to begin with) and who should pay for it. The situation was probably also fed by lots of talking points from the new partner that the old partner doesn't know what they are doing. What do you expect? New partner has a way into a multi-national implementation, they have an opportunity to make the other partner look bad, maybe sign the deal over, lots of money involved. It is of course very possible that the original partner was getting lazy, and that is inexcusable.

Again, I am not trying to make you look unreasonable, but I think there is much more to this story than we know. What it comes down to is that up to a certain point, it seems to me that your partner was meeting your expectations, and when working with another partner, you found out that those expectations could have been higher, things started to get tense. I'd suggest to sit down with the partner, and redefine those expectations. There's nothing wrong with being a demanding customer, and if your partner is not able to meet your expectations, it might be time to move on.

seckpin

Actually if the situation is as what you have described, then I would say we were indeed being less than justifiable to ask for those 'basic documents' now.

Our internal IT Team was recently established because the so-called 'successful' earlier implementation started to show signs of failure. It turned out that the design and implementation were flawed in the way that there is no consideration for scalability and different requirements of various countries. It may look fine when first went live and in the first country, but just a year or two down the road, with more countries implemented and more data went in, the situation starts to get bad.

The company finally realised that taking a hands-off approach and let the vendor and business users implementing systems without proper monitoring is not right. That's when our internal team came into the picture. All members had worked in one or more solution centres before, and we were all taken aback by the lack of professionalism of the vendor.

Just to quote one example, we had never worked in any solution centres before that did not require the customers to have a go-live sign off after the implementation was completed. Yet, this one never bothered, and we actually had to scramble for doing 'backdatd' sign off with each country ( some even dated more than a year ago) before the internal audit came in and we had to clear this audit concern that was raised.

As for the new vendor that was engaged because of different region, what they produced was what we had expected any implementation should have, not really something that wow us as if we see it for the first time. Rather, what really 'wow' us was that it is the first time we came across a partner who actually did not and refused to provide these things.

However, I do agree with you that it is indeed a 'change of expectation' in a way that before our team's existence, our business users did not know anything and accepted whatever way or standard that was provided. Now that we as once consultants ourselves, we do demand certain things that we deemed as 'basic' stuff. But to be fair to this vendor, they were already used to providing such standard and no one had raised any issue before, so it perhaps is indeed hard for them to accept our demand, or at least not without additional cost.

Anyway, it's a rant after all. We are stuck with them for now, so we just have to carry on despite all these frustrations.

Thanks for the comments!

DenSter

It's for sure a difficult situation, and I hope you and your partner (whoever that turns out to be) can find a way to set and meet expectations. Good luck