I was once in a restaurant and noticed another guest, who ordered a steak by saying to flip it after 2 minutes and to add exactly 3,5g of salt and 2g of pepper. The waiter was as puzzled as me: Why giving detailed instructions for buying a full service? Certainly, this person never went to a restaurant before or he never learnt how to properly utilize a service.

For me, as a regular guest in restaurants and with long year experience in Microsoft Dynamics NAV projects, there is a striking similarity in software development. Unawareness of the service leads to detailed instructions from non-technical persons, frustration about the software and exploding costs.

For this blog post, I have compiled useful tips to keep your life easy and the costs low. Please enjoy my top 5 tips to get the most out of the service your Microsoft Dynamics NAV partner offers.

Tip #1: Invest time in preparation

Before you start to compile your first change request, save a little time to introduce yourself into theoretic topics of software development. It will give you a basic understanding of the general process of software development, what to expect from your partner and what to plan for. Unfortunately, software development is not just hammering code into a console. It’s more to that before and after. It’s worth the time and you will gain an understanding what value your partner should offer you.

Because there are a lot of buzz words and different approaches flying around, it is a useful start to ask your partner first, what kind of methodologies they are using.

I really like to know if the person in the restaurant knew about a restaurant before this day.

Tip #2: The team is important

It’s a valid question to ask what an internal project team has to do with change requests for your partner. Well, the software development process itself includes a lot of different roles and tasks to fulfill. I just like to mention two obvious ones: business related requirement analysis and testing.

It’s impossible for one person to manage everything alone and therefor I can easily write that the team is a vital and important part of every project (maybe it’s even the most vital and important part of a project).

The team is in charge for a lot of the daily project tasks and you will possibly delegate parts of your own responsibility. There is always a risk that a person of your team develops a fear or blocks against the project due to unknown expectations. It’s just fair for everyone who is involved, to know what challenges lie ahead because it might be possible that your team members must adapt to new working methods, different results and competencies.

Try to eliminate reasons of fear and blocking by discussing the new tasks before the initial kick off.

Tip #3: Pitfalls are gaps are nescience

Pitfalls are silent, can be easily overlooked and are happy in the dark. But only until no one notices or traps inside. Btw. the person from the restaurant with the steak-issue. Even he was with his wife there, he didn’t get anything from the free salad bar. He must have been unaware of the price calculation and that the salad bar was in the price included. It may didn’t kill him, but he missed a nice opportunity to get something extra.

Such problem exists in the business world and especially in software development also. But, unfortunately, the consequences of nescience in business is different. Fortunately, still no one gets killed… But, nescience could have an impact on your planning and on your overall project budget, because when the gaps are discovered it might be a new situation for certain areas, for which it becomes necessary to invest more time and money to implement it proper into your software or it might be necessary to change already existing, tested and delivered parts of your software (or a combination of both, of course). Nescience can really grow into a nightmare which could postpone the GoLive-date, let the budget explode and weakens the project in general.

Unfortunately, there is no general approach to avoid pitfalls in software development. For me personally, it’s always a mix of curiosity, knowledge of the business and the will to dig further and beyond into a process, even when everyone thinks the topic is home and dry. I try to be tenacious even when this means I have to get, old and already talked about topic again on the agenda.

The only direct hint I have is: Areas which haven’t been discussed enough are likely to be one of the reasons why software projects get delayed.

Tip #4: Be a client (and not a software developer)

In my professional career as a Dynamics NAV consultant, I was often (and I’m still) faced with a kind of request which contained the approach to change the application using technical descriptions. It’s always a shame, when a customer limits the flexibility to utilize the experience and knowledge of the software developer. Developing changes in Microsoft Dynamics NAV consists of a couple of best practices and guide lines which have been published by Microsoft. Microsoft is very keen to keep an eye on the quality of 3rd party module of NAV by validating the module internally before confirming the official interoperability with its product (and first then it is allowed for the module developer to official sell the module).

By describing a requirement using technical specifications the customer loses the wider, more abstract perspective and approach of a software developer. A (good) software developer always tries (should try) to integrate a change request into the whole picture of the client’s business and to make sure that processes, which are running before and after, are delivering/receiving the correct result. What I often also saw is a lack of complexity in use cases for a requirement. For example, when a customer requests to create a Credit Memo based on an Invoice directly, the customer might forget that partial Credit Memos are sometimes necessary.

I’m remembering the guest in the steak-restaurant now and I think that this person didn’t have been aware of the benefits of the services which a restaurant offers. It is not necessary to dictate detailed instructions about the preparation of the food, because the experience and knowledge of preparing and delivering food which satisfies the customer is part of the service for which you pay in the end.

When a client discusses with the developer the changes to the software, the developer is mostly interested in the business demands which make the change necessary and what goals are connected.

Tip #5: Build a good relationship with the team of your partner

Finally, a very naturally, but crucial point which I like to describe by simply leaving the following statement as it is:

A friend is someone who listens to your bullsh*t, tells you that it’s bullsh*t, and then listens to more of your bullsh*t.

To be honest, a little small talk with the waiter benefits a restaurant visit always.