Every implementation of Dynamics NAV is completely different from another one. The reason is because every company, no matter how similar of industry, is run differently. The company that is going to use the ERP software (usually called the customer) is different, the requirements are different, the scope is different, and even the team implementing it might be different. This brings a lot of uncertainty to the process and is the main reason why methodology has to be used.
Implementing Dynamics NAV is considered as working in a project environment. By definition, a project is a temporary endeavor undertaken to meet unique goals. The company implementing Dynamics NAV (usually called the consultant) is probably used to this kind of environment. On the other hand, the customer is probably used to working in an operational environment, where the same processes are repeated over and over. For the customer, implementing a new ERP system is like running in the jungle with dozens of options to take at each step and no idea about where to go. Therefore, methodology is not only going to help the consultant, but also the customer, understand exactly what's going on.
Methodology is not only applicable to the development and the implementation, but also to stuff such as how the project is going to be billed or how the project team is going to transfer the knowledge to the support department at the end of the project. You have to define some aspects before starting any project:
- Billing: A Dynamics NAV project means time and work investment before the go-live date. Usually, projects do not show results until the end. Even on Agile methodologies, you will need several iterations before the go-live date. Both the partner and the customer must be balanced in order to have the best relation possible. This can only be achieved by billing the project as it moves forward.
- Estimating time and cost: At the beginning of the project you will have to estimate the project, either in cost or time. Use templates to help you estimate and ensure that you don't forget any task.
It is normal to think about the development time of a certain requirement and forget the time it takes to design it or implement it. It is also normal to forget the tasks related to managing the project, and it is time consuming.
For each requirement, you can use a template like the following one:
Analysis
Development
Test
Implementation
Requirement 1
3h
10h
2h
2h
Requirement 2
1h
4h
1h
0.5h
Use this template to estimate all the requirements, even the ones that are going to be accomplished with standard functionality, because they will consume implementation time. Also, use this template (or a similar one) to estimate migration requirements.
Use another template for the rest of the tasks of the implementation. Write down all the tasks needed for the implementation and make sure to check them all for estimating a new project.
Some tasks that you should not forget are project management, software installation, training, support, and so on. To estimate the project management tasks, we use a percentage of the whole project estimation. It is up to you to fix this percentage, but it could be something like 10 percent. In a complex implementation you can also break down this task and perform the estimation from there.
- Planning: Determine how you will plan the project; planning both the phases and the everyday work. Visibility is important; therefore the whole team and the other people in your company have to be aware of the project plan.
You might also need to use a tool such as Microsoft Project or Microsoft Excel to plan the whole project. You could then print the plan of the whole project and distribute it to the people who are going to be involved in this implementation.
The project plan should be shared with the customer as early as possible. This helps everyone plan their vacation and time off to ensure they are around when they need to be around.
- Purchases: Your project will, at least, involve the purchase of the customer's Dynamics NAV license. In some projects you will also have to buy other things, such as hardware if you are in charge of providing it.
Determine when and how you are going to do all of your purchasing, and do it the same way in all your implementations.
- Communication with the customer: Communication is a very important part of any project. Determine how, who, and when you are going to communicate with your customers.
It can be through meetings, e-mails, phone calls, or shared documents. Also decide on the single point of contact from the partner side as well as the customer side.
If too many people from the partner side talk with too many people from the customer side, it can be chaotic and you will probably end up with inconsistencies.
- Communication between the team: This is also very important, especially if the team is placed at different locations. If someone has talked to the customer and has decided on something, the rest of the team must be made aware of it. One of the best ways to keep a tab on everything is to immediately follow up with an e-mail on what was decided, to both the customer and the parties involved as partners.
- Development and testing: Determine the strategy the company is going to use when developing and testing: how the code will be written and marked.
If you have not defined this, you can end up with everybody developing on a local machine, marking their code in a completely different way, and having to invest a lot of time to put everything together.
- Acceptance of the developments: Your implementation methodology has to ensure that the customer accepts the developments as the project progresses. This involves delivering the bits and pieces of the project as soon as they're completed. Don't wait to show everything in the last week before the go-live date. If you do so, prepare yourself for a tough support phase with an unhappy customer.
- Documentation: Determine what has to be documented, the structure each document will have, and how it will be named.
It may seem that this is a very bureaucratic process, but it can really be as simple as you want. By documentation we don't mean that each project has to generate a thousand pages of documentation, but that the few documents that are generated follow the same structure and are archived at the same place.
Even on smaller projects, where only one person is involved, plan ahead so another person can come in and pick up where that one person left off if he/she goes on vacation.
- Reporting and control: Think about what kinds of reports you will have to generate and the kind of control that the project will have. You may want to control the project advance, the time, cost consumption, and so on. Invest time in your project to this area, even if the project seems to be okay, or you won't see the diversions until it's too late.
To control the project advance, we recommend you to plan demo/training sessions, so that each developer can show his/her work to the rest of the team. These demo/training sessions have two purposes. One, the project gains visibility and is part of the communication between the team members that we talked about earlier. Two, it allows feedback from the team members on improvements needed in a project or whether a project is being done completely wrong.
There are different kinds of methodologies. The main ones are Waterfall and Agile. The Waterfall approach is the most used approach while implementing Dynamics NAV, but Agile gives better results, especially on software requirements. This is why Agile approaches have been gaining ground for the past few years.
In the next sections, we will cover both the approaches and learn how to use the best of both.
The Waterfall model is a design process in which progress is seen as flowing steadily downwards (like a waterfall) through the phases.
The following diagram shows the typical representation of a Waterfall approach:
As you can see in the diagram, one phase does not start until the last one has finished. In the next section of this chapter, we'll talk about the phases of a Dynamics NAV implementation, which are presales, getting the requirements, analysis, development, deployment, and support. In our case, the analysis phase cannot start until all the requirements have been taken care of, and the development phase cannot start until all the requirements have been analyzed.
Companies have chosen this approach because it is the one that, theoretically, brings more certainty. Using this approach, the whole scope of the project is defined after getting the requirements, so it is easy to fix a cost for the project and fix an ending date. But, as we said, it is just theoretical. In reality, the requirements that are gathered at the beginning of the project may not be what you end up going live with. The reason is because in the earlier stages the customer does not know Dynamics NAV, but once they realize the potential of NAV, they will certainly want to change how they work for the better.
This is very similar to building or remodeling a house. In most cases, the owners want to make changes to what the architect drew because they see something that can totally make their house a lot better.
The Agile approach is based on iterative and incremental development. It is typically represented like the following diagram:
In this approach, you perform several iterations through all the phases before you reach the end of the project. With this approach, the customer needs to be more involved in the project and work more closely with the partner team.
The Agile approach is the best to meet the requirements and is able to more closely fit into the customers' needs. It is the approach that adds more value. However, it is hard to estimate time and costs at an early stage. And for the company implementing Dynamics NAV, not to exceed their budget may also be very important; in some cases even more important than the value added.
This is usually solved by establishing a win-win / lose-lose relation between the customer and the partner. Both parties agree with a desired cost. If the project ends up with less cost than expected, then both sides win. If the project ends up costing more than expected, then both sides lose.
We have worked for many years on projects implemented by following the Waterfall approach. The cost of the project is set up at the beginning of the project, and sometimes it can be tough to ask the customer for a revised budget.
With the cost already fixed, the customer always tries to get more value for the same price and the partner ends up lowering the quality for the same price. Fights between both happen when one party says that this is not what we agreed upon in the first place, and the other party argues that this was implicit in the requirements.
The win-win / lose-lose relation balances the equation between the value added and the final cost.
To use the best of both approaches, you can have an initial getting the requirements phase, but with less detail than in the Waterfall approach. In this first phase, the requirements of all the areas are covered, so it helps the partner team to make an approximate estimation of the project cost and time. This helps the customer identify if the project fits their needs and also their budget. After that you loop through all the phases focusing on a few requirements at a time.
Of course, using this approach, the cost of the project is only an approximation; it may cost less or more.
If the project is finished with less cost than estimated, both the customer and the partner win, because they share the benefits of the savings. On the other hand, if the project costs more than expected, both have to share the cost overrun. This can be achieved by returning part of the savings to the customer, and compromising on the cost of the underestimated projects.
This kind of relation between the customer and the partner is new in the Dynamics NAV world and several cultural aspects must change inside the organizations, but we are sure that the results will be worth it.
Microsoft Dynamics Sure Step is a methodology designed by Microsoft, focused specifically on the implementation of all the stacks of Microsoft Dynamics ERP and CRM products in which Microsoft Dynamics NAV is included. The Sure Step process is available for both On Premise and On the Cloud deployments.
This methodology is not just a set of methods and a knowledge base about implementation projects. It consists of:
- Best practices that let the consultant know how an implementation task or a set of tasks should be performed to achieve the best possible result, or to avoid mistakes that have already been made by someone in the past.
- Tools that make it easier to perform the tasks by automating or streamlining time-consuming and error-prone tasks, such as organization and business process mapping.
- Templates that boost productivity by providing a documentation framework. Preparing documentation using these templates ensures that every important aspect of the documentation has been touched, and that nothing important has been missed.
The Sure Step methodology provides the two distinct implementation approaches we have been discussing, namely, the Waterfall approach and the Agile approach. We will define them in the following sections.
There are three types of Waterfall-based implementation project types. In addition, there is one Waterfall-based upgrade project type. Now, the four types of Waterfall-based implementation project types are as follows:
- The Rapid project type
- The Standard project type
- The Enterprise project type
- The Upgrade project type
This is, in theory, the fastest and most straightforward approach. The Rapid project type is designed for out-of-the-box implementations of Dynamics NAV solutions. This means that when you choose this method, you use Dynamics NAV as is without any customizations. It prescribes 14 activities from solution to "go-live".
In my personal experience, this is a terrible approach to NAV and I would never recommend any company to use this implementation method. Taking away customization from NAV is taking away one of the most powerful tools Dynamics NAV has to offer. It's like taking the balloons away from a clown. Without the balloons, the clown will just be scary.
The following is a screenshot of the Rapid project type, including the activities shown in the left navigation tree:
This is typically used in most Dynamics NAV implementations for fixed price implementations. Using this method allows the Dynamics NAV partner to know and understand your business. It allows all your users to know your Dynamics partner as well so an accurate estimate can be established
The next screenshot is of the Standard project type in Sure Step:
This is the most detailed of all the Sure Step project types. This project type is typically used in large organizations where multiple departments with multiple heads of departments in multiple locations need to be involved in the project. Basically, you should use this project plan if all the hands in the world need to be in the cookie jar.
The following is a screenshot of the Enterprise project type in Sure Step:
This is a project type specially designed to address upgrade projects. It differentiates between technical upgrades and functional upgrades. A technical upgrade is meant to port an existing solution to a new product version. A functional upgrade is meant to not only port an existing solution to a new product version, but also to add new functionalities to the new product version.
The following is a screenshot of the Upgrade project type in Sure Step:
This type is used to manage the Dynamics NAV implementations where the solution needs to fit very specific needs of the customer for whatever reasons. These customers are typically very involved with their partner, from specification design to development to testing.
The next screenshot shows the Agile project type in Sure Step:
The Sure Step Agile project type has Sprint cycles to include the Analysis, Design, and Development phases.
A Sprint cycle is a set period of time during which specific work has to be completed and made ready for review. At the end of each sprint, you are adding value to the project by adding finished portions of the product. Usually, sprints last from one week to one month.
The Agile project type does have two phases, Deployment and Operation, at the culmination of the Sprint cycles. So, in this context, the Agile project type deviates from a strict Agile approach, and is fashioned as a blended approach for ERP/CRM deployments.