Choosing a go-live date

If you ask any accountant which date to choose to start working with Dynamics NAV, they will always answer "January 1". The reason behind this answer is that, for most companies, January 1 is the beginning of their fiscal year. It has advantages, no doubt, but it also has drawbacks. The year has 364 additional days to work, but limiting yourself this much is not worth the hassle and stress.

In this section, we will see the pros and cons of going live at the beginning of a fiscal year versus going live on any other date. With all this information, you should be able to choose the best date in your case and know the consequences of your choice.

Going live at the beginning of the fiscal year

All companies analyze information at least annually. Among other reasons, because the tax authorities require certain documentation submitted annually as balance sheets. Starting to use Dynamics NAV at the beginning of the year has another major advantage; there is no need to do anything special to get annual information. There is no need to seek information in two different systems and add it somewhere, and then repeat this process every time you need to analyze the information.

We are not just talking about accounting. Accounting information is the easiest to add. This is because accounting is an area where everything is regulated, and so there will not be many differences between the old system and Dynamics NAV. No major problem here. But there are other areas where it may be impossible to obtain information from the old system. We will never have complete information in the first year.

Let's see an example. Imagine a company that sells items. In their old system, the company had no way to classify the items by category, but in Dynamics NAV, they do. Now they want to analyze the sales by item category. As you can imagine, there will be no way to have complete information on an annual basis as the old system did not have this information. Therefore, the only way to get complete information from any area is migrating at the beginning of a fiscal year.

As you can see, the major (and the only) advantage here is having complete information on an annual basis for analytics and statistics purposes.

What cons do we have?

A project is, by definition, a temporary endeavor with a defined beginning and end, undertaken to meet unique goals and objectives. Implementing Dynamics NAV is a project. At the beginning of the project you have some requirements which give you the details of the amount of work needed to accomplish it. Along with the resources available, you can perfectly plan when each task must be done in order to get the entire job done before January 1. However, when it comes to software projects, changes in requirements are on the agenda all the time.

Each project has three main constraints that must be balanced: time, cost, and scope. This is known as the iron triangle.

In order to keep the triangle balanced, any change in one of the sides modifies at least one of the other sides. Therefore, any change in the requirements (scope) produces a change in the cost, the time, or in both of them.

If you choose January 1 as the migration day, the time side will be pretty difficult to change. You will have to wait a whole year for it to be January 1 again. Your other option is to increase the cost side. You can put in more resources to help finish the project on time. But this is not an easy solution. Resources are not always available, plus you will have to teach them what the project is all about. Wouldn't it be easier if you could just go-live two weeks later?

Another con is that the month prior to the go-live date is quite busy, both at the implementer's and at the customer's ends. All the training has to be done, all the development has to be tested, and the new requirements usually come at the end! Plus, usually the customer is asked to leave as few things pending as possible, and complete most of the tasks. This again means extra effort. Besides, December is not the best time of the year to ask people for extra effort. It's Christmas, kids are off school, and moms and dads want to be with their children playing with the new toys Santa brought them.

Okay, there are not that many cons on the list. Just two, but they are important enough to consider another date.

Going live in the middle of a fiscal year

Here the pros and cons are just the opposite of those in the case we discussed earlier.

The main advantage is that the starting date can be moved. Don't get us wrong; it does not mean that you can play with the date with no consequences. Your customer will always ask you to be committed with a date. But in case of some change within the iron triangle, you will always have the chance to negotiate a change on the time side to balance the triangle.

It is better to go live a few days late with guarantees than do it on time if some new feature hasn't been implemented or tested yet.

Choose a date, bearing in mind what your customer's busiest time of the year is and try to avoid it. As we mentioned earlier, the month before the go-live date is a pretty busy month. Actually, the month after it is also a very busy one.

The main con is that, in some cases, the company won't have complete information, on an annual basis, during the year they start to work with Dynamics NAV. But don't worry, you also have the option of doing an extra job to mitigate it. You can post historical data, such as accountant entries or item entries, into Dynamics NAV. Read the Historical data section in this chapter for more information. If you choose to migrate the historical data, the main con of going live in the middle of a fiscal year is gone and only the pros stay.

So, there is no reason not to choose a date different from January 1.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.33.41