Every implementation of Dynamics NAV is completely different from another one. 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 environments. On the other hand, the customer is probably used to working on an operational environment, where the same processes are repeated over and over. For the customer, implementing a new ERP system might be like running in the jungle with dozens of options to take at each step and no idea of where to go. Therefore, methodology is not only going to help the consultant, but also the customer.
Methodology is not only applicable to the development and the implementation, but also to stuff like 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 go-live. 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, but 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 an implementation. Write down all the tasks needed for an 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, both planning the phases and the everyday work. Visibility is important, therefore the whole team and other people in your company have to be aware of the project plan.
We recommend you to use visible planning methods, like kanban boards. The following is an example of a kanban board we use; we call it the "iPad":
On the left column, S1, S2, and S3 mean week 1, 2, and 3, while Fin means done. Every week we update the board. When people finish a task, they move the corresponding task to the done area. In the figure, there are no tasks on the done area, because the picture was taken just after a planning meeting and all the performed tasks were removed.
You might also need to use a tool like Microsoft Project to plan the whole project, as kanban boards only work for short periods. We print the plan of the whole project and attach it on the bottom-right corner of the board so that everyone can know when each phase has to be ready.
You could also share the Microsoft Project file with the rest of the organization on your intranet or somewhere else, but the reality is that usually no one but the project manager watches it. Kanban boards, however, are located in a conspicuous place at the office, so that everyone sees it even if they are not looking for it. We've placed our kanban board next to the coffee machine.
- 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 are you going to do all 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. Determinate how, who, and when you are going to communicate with your customers.
It can be with meetings, through e-mails, phone calls, or with shared documents. But it is important to always use the same method to communicate the same kind of things. Also decide the person from the partner side who is going to talk to the customer, and the person from the customer side who is going to be the interlocutor.
If too many people from the partner side are talking with too many people from the customer side, it can be a chaos 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. In this sense, it is better to put the team together in the same room, whenever possible.
If someone has talked to the customer and has accorded something, the rest of the team must be aware of it. It also works the other way around. If people use different ways to communicate the same things, there is a huge probability of loss of information.
- Development & testing: Determine the strategy the company is going to use when developing and testing: how the code will be written and marked, where the development environment will be placed, and so on.
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: This is usually the Achilles' heel. Your methodology has to ensure that the customer accepts the developments as they move forward. Don't wait to show everything on the last week before go-live. If you do so, prepare yourself for a tough support phase with an unhappy customer.
- Documentation: Determinate what has to be documented, the structure each document will have, how will it be named, where will it be archived, and to whom is it going to be distributed.
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, you have to think that you are not alone.
- 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 of your project to this area, even if the project seems to be ok, or you won't see the diversions until it's too late.
To control the project advance we recommend you to plan demo sessions, so that each developer can show his/her work to the rest of the team. These demo sessions have two purposes. On one hand, the project gains visibility and is part of the communication between the team members that we talked about before. On the other hand, it prevents the 99 percent done effect.
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 from the past few years.
In the next sections we will cover both approaches and learn how to use the best of both.
The Waterfall model is a sequential design process in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The Waterfall development model originates in the manufacturing and construction industries, that is, highly structured physical environments in which after the fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
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 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 real life the requirements you've taken are wrong, because in earlier stages the customer does not know Dynamics NAV well enough to think on all the requirements possible.
Also in real life, the design of the solution is wrong because the partner does not exactly know how the customer works, even if they spend several days taking the requirements and covering all the customer business processes.
On the other hand, 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 closer with the partner team.
The Agile approach is best to meet the requirements and to perfectly fit into the customers' needs. It is the approach that adds more value. But it is hard to estimate times and costs at an early stage. And for a company implementing Dynamics NAV, not to exceed their budget may also be very important, in some cases 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 should win. If the project ends up costing more than expected, then both sides should lose.
We have worked for many years on projects implemented by following the Waterfall approach. The cost of the project was set up at the beginning of the project, and it was not possible to change it.
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 arrive when one party says that this is not what we agreed upon the first place, and the other party argues that this was implicit on the requirement.
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 could 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 will help the partner team to make an approximate estimation of the project cost and time. This will help 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. Yes, we know, you are all thinking that it will always cost more than planned and the risk of ending up with an unaffordable project still exists. The trick is to keep everyone focused and this can only be achieved by a win-win and lose-lose relation.
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 overrun. This can be achieved by returning to the customer part of the savings, and also offering a lower price for the overrun hours.
This kind of relation between the customer and the partner is new in the Dynamics NAV world and several cultural aspects must change inside 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.
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 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.
To address the scale and complexity of the customer's implementation, Sure Step offers the users the choice of three Waterfall-based implementation project types and one Waterfall-based upgrade project type. These are as follows:
- The Rapid project type
- The Standard project type
- The Enterprise project type
- The Upgrade project type
It represents the simplest delivery approach. The Rapid project type is designed for out of the box implementations of Microsoft Dynamics solutions, which essentially entail zero or minimal customizations of the standard solutions. It prescribes 14 activities from solution to "go-live".
The following is a screenshot of the Rapid project type, including the activities shown in the left navigation tree:
It is suitable for a majority of Microsoft Dynamics projects, and hence the most widely used. This project type includes activities in all nine cross faces, to support customizations, integrations, and interfaces, as well as business process analysis.
The next screenshot is of the Standard project type in Sure Step. Included in the screenshot is a partial view of the activities shown in the left-hand side navigation tree, indicating additional severity in each of the cross phases:
It is the most rigorous of all the Sure Step project types. Designed for large complex scenarios, the Enterprise project type is characterized by deep program management activities, requiring focus and discipline from the customer and service provider throughout the length of the engagement.
The following is a screenshot of the Enterprise project type in Sure Step. Included in the left-hand side navigation tree view in the screenshot is a partial view of the activities in the Analysis phase, which highlights the depth and diligence that is prescribed for project governance alone.
It 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:
We now turn to the Agile approach in Sure Step. The Agile project type was introduced in the Sure Step 2010 release, primarily to facilitate the development and rollout of the solution to those customers who expect to use Microsoft Dynamics as a platform and customize the solution to their specific needs. In doing so, these customers tend to involve their requirements during the course of the development process, necessitating a flexible and iterative approach to development, which is where the Agile project type is ideally suited.
The next screenshot shows the Agile project type in Sure Step. The left navigation tree view and the methodology pane on the right depict the sprint cycles characterizing the Agile project type.
While the Sure Step Waterfall approaches have activities flowing across five phases, the Sure Step Agile project type has Sprint cycles to encompass 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. If you want to learn more about Microsoft Dynamics Sure Step, we recommend that you read the book Microsoft Dynamics Sure Step 2010, written by Chandru Shankar and Vincent Bellefroid, and published in January 2011 by Packt Publishing.