MS Dynamics NAV End User Developer License

Tell me about it.

I once had a "Consultant" at an end user, they had "Navision Development Experience" and sent me some code. "Please put this in the database between X and Y"

Now the code is not what I would call standard, it got a little political, and I managed to get a little irritated.

Funnily enough though it was my revised code that went to production.  

 

Now that Microsoft have stopped renewing licences (in the UK at least) to individuals and just give the NSC a licence for them to distribute to their employees and extenral contractors, you are inevitably going to see an escalation of the work done by poorly trained "developers".

Nothing new there and not limited to Navision.

As David says, the customer really needs the input from the freelancer (who has to be competent to earn a living) to protect themselves from poor development or implementations.

I do the same thing as many freelance consultants and make written suggestions to the client that they can then pass on to the NSC, I try and make the descriptions and words look more like the end-user so the NSC does not get upset.
(Does not always work).

To become a full time freelance developer, I suggest joining a NSC and getting all the training and experience for as long as it takes before going 'solo'.
At least you will get a full developers licence eventually, but it will run out so you had then better keep good pals with the NSC so you get the renewals and latest versions.

Rgds,
Colin

colingbradley:

As David says, the customer really needs the input from the freelancer (who has to be competent to earn a living) to protect themselves from poor development or implementations.

I do the same thing as many freelance consultants and make written suggestions to the client that they can then pass on to the NSC, I try and make the descriptions and words look more like the end-user so the NSC does not get upset.
(Does not always work).

Not sure I agree with you there. The BSC (ISEB, SIGIST), ISTQB and ISO clearly state that the 2nd most common failing in any software development is caused by the Documentation and Specification.

To try and dumb down what you are trying to tell an NSC is a waste of time and money. I would rather communicate with an experienced consultant on a customer site on a technical level than have them try to make it look like it was written by an end user. If you can communicate on the same level it makes the whole process more effective.

I'm sure your customers employ you for your vast experience in Navision for precisely that reason. What’s the point in employing you to write a requirement the same way an end user would? Why not just do it themselves?

I've come across freelance consultants that know nothing about what they say they do. Now that’s annoying!

 

Absolutely I agree with Tony. Where a free lance would be most valuable is to help 'translate' user requirements into NAV technical terms. I would LOVE to work with an external consultant if that person:
a - knows about the customer's business, not just a little bit, but really *KNOWS* about it
b - knows what they are doing from a functional NAV standpoint, so they can point to the gaps
c - knows what they are doing from a technical standpoint, know about database/software design

A and B are absolute must haves, C would be nice. If C isn't there at least there is a good basis to discuss where to fill the gaps.

What I've seen is where the external consultant actually tries to make the SC look bad to make him more valuable, and in the end that is very counter productive. It just does not help when everything you do is questioned behind your back. The most important part is to be on the same team and pursue the same goals.

Just to clarify.
A proposal to the client that is written in a clear and concise manner describing the functional requirements is a must.
What my comment about changing the words a little is to ensure that no references are made to things that the end-user would not know about.
For example, specifics abut HOW something may be done in code, but rather saying WHAT is required.
I have read some specifications and it was very clear that the person who wrote them was a developer, which is fine in some cases. However, we were on track about not upsetting the company that the client is paying a lot of money to each year and not providing the client or the NSC any reason to feel threatened.
As far as the A, B & C is concerned, is that not essential?

Personally I would not feel threatened by a document that describes technical detail, as long as it is correct and the writer is open to discuss it (knowing that there is more than one way to skin a cat). If I don't agree with some of it I would open a dialog, involving both the customer and the person that wrote the document, as a team effort.

The reason I say having technical expertise is not essential is because I can do that myself. As long as I can talk requirement and technical detail with the consultant, the requirements are clearly worded, and we can come to an agreement on how we're going to implement the system. Customer process knowledge and knowing NAV functionality are essential for the document to have any validity though. If either A or B are not present, then there is no added value for the customer to have an external. This applies also to a solution center consultant mind you.

If I were to get a document describing technical detail without the requirement, I would ask for the requirements too, so I can validate the design. Not to try and find something wrong with it, but to make sure the customer's interests are best served.

<edit>I guess if there are reasons to keep the fact that there is an external from the NSC, you have to do this. If there is no such reason I believe every suggestion, idea, should be welcomed by everyone involved. Team work is of the greatest essense. It's the customer's money, and if they want to involve an independent third party to keep us honest then that's what they need to do.</edit>

The last bit (keeping it from the NSC) is what this was all about.
If I am working with the NSC then everything is in the open. There are some situations where the client is prohibited by the NSC to talk to an independent. I have one of those clients right now. The get me in on a regular basis to sort thngs out  even though I am prohibited to change any of the code.
Tricky situation. In this case I know that the developer employed by the NSC has done some very poor work. I can only suggest how things can be improved.
The alternative is to suggest they use another NSC but that is fairly obvious. The client feels locked in so this is their only way to help them feel in control.
None of this is ideal for anybody (except I get paid for my knowledge) but other than causing a rift and then possible legal action, it is probably the best solution.
Mostly I prefer being called in by the NSC to solve difficult problems or resolve situations that are getting out of hand.

Right I was wondering if that were the case. Would it be possible for you to be employed by your customer on a part time basis?

We're getting a bit off topic here :)

Have not worked for anyone since 1982. Probably not a good idea to start now.
Essentially, when I come in to a firm for a specific project, it is very similar to part time work except they do not have any need to consider paying employers tax and so on.
Me and I am sure most freelance professionals, are working to analysise the needs, do the job and go!
My clients may sometimes want small fixes or reports but those can be done off-site, much cheaper for the client.
I like to go to different places and have different problems to solve, probably another requirement for going freelance.

I should have put quotation marks around that :) I wasn't suggesting you actually start working for your customer. What I meant is if you are "employed" by your customer, their NSC could not have objections, and you could do what you can do and be a partner in those discussions. I'm sure there are 'temporary part time' work constructions you could fall under while maintaining your independent status.