Implementing Microsoft Dynamics AX 2012 with Sure Step 2012

By Keith Dunkinson , Andrew Birch
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Installing and Setting up Sure Step

About this book

Microsoft Dynamics AX is a comprehensive Enterprise Resource Planning (ERP) solution for midsize and larger organizations that empowers people to work effectively, manage change, and compete globally. Microsoft Dynamics Sure Step is an implementation methodology, a toolset, and an application to help Dynamics partners (AX, CRM, NAV, GP, and SL) successfully implement their Dynamics solutions such as Dynamics AX.

"Implementing Microsoft Dynamics AX 2012 with Sure Step 2012" will guide you through the Sure Step phases; from installing and setting up Sure Step, to working through the diagnostic and requirement phases, to harnessing the power of standard AX to make the most out of modifications, this book is a must for project managers and team members alike.

With detailed discussions of the diagnostic, analysis, design, development, deployment, and operation phases of the Sure Step Methodology, Implementing Microsoft Dynamics AX 2012 with Sure Step 2012 enables you to turn methodology into practicality with its real-life examples and helpful hints on applied aspects of AX implementations. It includes details of technical concepts that are important to understand and help you to effectively manage the project, as well as hints and tips based on real world experience that you won’t find in the standard Sure Step Methodology.

Implementing Microsoft Dynamics AX 2012 with Sure Step 2012 will enhance your understanding of Sure Step Methodology as well as increase your knowledge of AX 2012 that will better equip you to manage and deliver your project.

Publication date:
March 2013


Chapter 1. Installing and Setting up Sure Step

In this chapter, we will examine the installation of Sure Step and setting it up for a specific project including some of the key choices we need to make, and activities that should be undertaken at this time. After reading this chapter, we should be able to: download and install the Sure Step client, create an appropriate Sure Step project, and initiate key activities for our Dynamics AX project.

Sure Step is the methodology created by Microsoft for implementing Dynamics projects. Although Sure Step includes content for Dynamics: NAV, AX, GP, SL, and CRM, our book is only focusing on AX. In some cases, one Dynamics project will be split into multiple Sure Step projects. This may be the case for projects covering one or more phases or for global rollouts, with sub-projects covering multiple territories or lines of business.

Sure Step has evolved through several versions, and gains content and maturity through each one. There would be no need to use an earlier version, so we have only considered the current version in this book (Sure Step 2010).

Sure Step is designed to be used by both customers and partners, and although it is currently most often used by partners, it is becoming more and more common for customers to follow Sure Step methodology when implementing ERP systems. In this book, we use "project" to describe an implementation of Microsoft Dynamics AX. In most cases, one Microsoft Dynamics AX project will be the subject of one Microsoft Sure Step project.

For more comprehensive information on Sure Step, you should refer the Microsoft training materials, or the Packt Publishing title Microsoft Dynamics Sure Step 2010 ISBN 978-1-849681-10-0 by Chandru Shankar and Vincent Bellefroid.

This chapter will introduce the Sure Step methodology, explain how to install the Sure Step client and create new projects, discuss the various engagement and project types that are available within Sure Step, and explore the steps that need to be taken during the project initiation phase.


Installing Sure Step

Sure Step is available to Microsoft Dynamics customers and partners via download from the Microsoft CustomerSource or PartnerSource portals respectively. The download and installation of Sure Step is simple and similar to installing other Microsoft desktop applications. For this reason, step-by-step instructions will not be detailed here, however, this information can be found in the instructions that accompany the download.


Creating the Dynamics AX project

Once the Sure Step client is installed, it is time to create a project for a Microsoft Dynamics AX implementation. To create a project, run the Sure Step client and select the Projects tab from the opening screen.

Once the Project tab is selected there is a list of existing projects. Upon choosing the option Create New Project, a wizard guides us through the creation process.

The first stage of the wizard asks us to enter the project data as shown in the following screenshot:

The fields marked with a red asterisk (*) are mandatory.

The solution and product are obvious and the project name is a matter of personal preference, but the engagement is worthy of an explanation and is detailed in the following sections.

Engagement types (offerings)

Engagement types refer to the choice of Diagnostic, Implementation, or Optimization offerings.

Diagnostic phase offering

Selecting a Diagnostic phase offering creates a Sure Step project, with content and guidance exclusively covering solution envisioning (Diagnostic activities). This allows the partner and customer to gain a high-level understanding of the fit of the solution to the customers' needs, which in turn allows the partner to be able to define the scope, cost, and risk of the implementation more effectively. This type of offering is therefore, intended to be used by a partner to increase their customers' confidence in, and commitment to, an implementation of a Dynamics product.

If a Diagnostic offering is chosen, there is the option of including one or more of the Decision Accelerators pictured in the following screenshot. Decision Accelerators such as Requirements and Process Review, Fit Gap and Solution Blueprint, Architecture Assessment, or Scoping Assessment are often very useful in later phases of the implementation, and will provide important high-level information about the project. Each project will often require a different combination of Decision Accelerators depending on individual circumstances, and more details on these can be found in the next chapter.

Implementation offering

Selecting an Implementation offering creates a project, with content and guidance covering the full project implementation including the envisioning (Diagnostics) phase. This includes the key phases, namely Analysis, Design, Development, and Deployment. The Sure Step implementation project is intended to be used to help a customer (who would normally be working with a partner) to successfully implement a Dynamics project, and is the case we are considering in this book.

Optimization offering

Selecting this option creates a Sure Step project, with content and guidance covering the upgrade or improvement of an existing system. As the fundamentals of the upgrade template are covered in the implementation template, we will not be specifically covering the optimization in this book.

Project types

Depending on which Engagement Type we have chosen, Sure Step will now require entry of a project type on the next step of the wizard. Typically, we will choose an Implementation offering, which is the template that will be covered in the scope of this book. The five project types (Rapid, Standard, Enterprise, Agile, and Optimization) are described in the following sections. This is a very important choice, because the content and guidance for the project types differ markedly.

The typical project types are Rapid, Standard, and Enterprise, all of which are referred to as waterfall project types, as they follow discrete sequential phases as shown in the following screenshot:

Choosing a project type requires both subjective and objective evaluation of the risk and complexity of a project. Subjective analysis should include an assessment of the capability of the project teams, the buy-in of senior management, budget and timescale constraints, and so on. When looking back at challenged projects, the choice of too lightweight a project type is often cited as the reason for failure. When choosing the project type, projects have generally not yet encountered difficulties, and often budget and timescale constraints can be given too much weight in making the choice of project type. As the decision includes subjective and objective evaluation, it is ultimately a subjective choice which the project manager or governance team needs to be prepared to be accountable for.

Some objective analysis points are identified in the following table:

Project type

Business Process Analysis

Lines Of Business



Fit to the Gap Fit

ISV solutions








>90 percent









>75 percent









<75 percent









<75 percent




Rapid project type

A Rapid project type will be created using the minimum artifacts (objects such as documents, spreadsheets, and diagrams) and processes of a structured project. As the project has less complexity and less risk, a more pragmatic approach can be taken to manage the project. Rapid project types suit small systems with little customization and well understood business and technical requirements. A very good use of the Rapid project type is when implementing repeats or small variations of previously implemented small projects—as tends to occur when working in vertical markets.

Standard project type

A Standard project type will be created with more artifacts, particularly around business process analysis and project governance. These suit more typical AX projects. Standard projects suit typical AX implementations with one or two sites, perhaps an Independent Software Vendor (ISV) solution and some customization.

Enterprise project type

An Enterprise project type will have the maximum number of artifacts and content based around quality assurance, governance, communications management, and all the elements required for managing large teams delivering complicated projects.

Enterprise project suit more complex projects. Complexity is a bit subjective as it is influenced by all of the factors in the following list, but most of them on their own don't necessarily make a project an Enterprise project.

  • International

  • Multi-site

  • Complex modifications

  • Multiple ISV solutions

  • Organizational Change Management

  • Business Process Reengineering

It is simple in Sure Step to create fictitious projects of all these types to review the content differences, which can be done using the Sure Step client.

Agile project type

The Agile project type is based on a wholly different approach to projects than the previous types. The previous types are all waterfall methodologies, where one stage is completed before progressing to the next stage through a familiar model of diagnosis, analysis, design, development, and deployment.

A typical Agile project type follows an iterative approach shown in the following screenshot:

An Agile project does not follow the waterfall type of approach and lacks some of the structure and stages of these types of projects. In an Agile project, an initial Diagnostic activity will occur, followed by an Agile Preparation phase. This will be followed by iterative cycles of Analysis, Design, and Development, known as sprint cycles. Each sprint cycle will focus on a pre-agreed list of activities, and anything outstanding at the end of that sprint cycle will be assigned to a later sprint cycle. There will be major sprint cycles (typically monthly) and minor sprint cycles (typically daily). At the start of each sprint cycle, there will be a sprint cycle review meeting to agree a list of activities to include and to provide an update on progress.

Agile projects tend to be used where requirements are not sufficiently detailed but the project needs to get started, or where requirements are frequently changing. They are therefore iterative and their duration is hard to predict. This makes them difficult to manage and they should be avoided by inexperienced project managers. Even in an Agile project, it is important to ensure that activities from a Standard project type (testing, training, data migration, and so on) are completed and managed properly.

Upgrade project type

It is slightly odd that having not chosen an Optimization Engagement Type, you are nevertheless offered an Upgrade project type even for an Implementation offering. We will ignore this for the purposes of this book, which is about implementing AX, not upgrading it.


Project initiation

Project initiation is expected to occur between the Diagnostic and Analysis phases. On a larger project, each phase requires some initiation activity of its own and it is particularly common to initiate the Diagnostic phase separately from the Implementation project as the Diagnostic phase is often part of the decision making process. The appointment of a project manager to commence end-to-end planning activities can occur anywhere in this cycle which obviously influences initiation as discussed in the following sections.

Concluding pre-sales and sales activity

It is desirable that all sales and pre-sales activity is concluded prior to kicking off the main project, although some overlap is common. It is, unfortunately, not rare for the pre-sales and sales activities to have not formally concluded, or to have been handed over from the sales team to the delivery team. This is the first thing a project manager should be chasing and why we have emphasized it here. See the relevant Sure Step details, but at this stage a Project Charter, Statement of Work, Implementation Contract, Proposal, and Requirements review are among the key minimum requirements to plan a project.

Document repository

As both the partner and client project teams need to share documents and files, we should provide a repository. Not all content should be visible to all users of the repository, so appropriate security controls or multiple repositories need to be considered.

Setting up the repository early in the project provides useful structure and saves hunting for current versions of documents later in the project. Microsoft SharePoint and/or SharePoint Workspace should suffice, although there are numerous options.

Although there are many Sure Step documents, in this book we want to consider some of the most important and most overlooked, that in our project experience, can help make the difference between managed expectations or a degree of failure. Accordingly, below we have identified some of the first items that belong in the document repository.

Communication plan

The communication plan should be one of the first documents in the repository and Sure Step provides a good template document for this.

The plan identifies all key project documents and communication types (for example, meetings). From within the plan, we can see the current version of all documents and communications, who last edited them and who is responsible for them. In addition, adding a URL to anything that has an associated file is a good practice for easy reference. Early in the project, this provides an index to key project files and documentation and should be maintained throughout the project.

Project hierarchy, communications, and meetings

Project hierarchy refers to the tiers of management governing a project. It is vital to establish the governance at the outset of the project and clearly communicate it to the whole project team—one of the functions of the communication plan.

Different projects will require different governance structures depending on risk, size of the project, project type, project duration, and so on. This should be established as soon as the project kicks off and evolved during the project, if necessary. Each of the governance groups should attend a kick-off meeting of the project, and in larger projects, kick-off meetings of every phase. These meetings can be separate or combined as is appropriate.

It is most common to have three levels of governance, whose team members overlap a little as shown in the following screenshot:

Statement of Work and Project Charter

Several documents are required at the outset of the project. The Statement of Work (normally provided by the partner) lists the scope of the key deliverables of the project. The Project Charter lists the rules of engagement of a project. These are supplemented by the System Proposal and Project Contract, but most of the time, the high-level scope can be checked from these two documents. Sure Step provides good templates for these.

Functional Requirements Document

The Functional Requirements Document (FRD) is a more obvious document and is perhaps the most important project document which details scope at a functional level. Most projects do contain an FRD, but in retrospective evaluation, they often lack some of the detail required. The FRD should contain all of the customer's requirements listed from a process or functional perspective. Each requirement should be listed in sufficient detail to satisfy the project team members from the customer and partner that the requirement is well enough understood to agree scope against. Each requirement should be identifiable via a reference which can be cross-referenced from the Gap Fit, Software Design Specifications, and so on.

Non-functional requirements

Non-functional requirements are also captured such as technical environment, high availability, migration, and so on. This is covered in the later chapters.

Other documents

The Gap Fit, which records the level of fit of requirements to the standard application, is a simple but important document; this is rarely lacking in a project, so we have not focussed on it here. There are many other documents we could mention, but if we look at the Documents tab of the Sure Step projects created earlier in this chapter, we can see and learn more about them there.

Work Breakdown Structure

The Work Breakdown Structure (WBS) is an entity used to link activities for the purposes of measurement and management. Sure Step includes a template WBS, but we may make our own if we feel it would be more suitable to the project. The benefits of having a clear and defined WBS from the beginning of the project are often realized in later stages, when reporting on the progress and budget to key stakeholders becomes more important. Three examples of structures are provided in the following tables. WBS 3 is the only one extracted from Sure Step; the others are examples of alternatives.

WBS 1 Worker Based Single Level:

WBS Level




Consultant 1

Andrew Birch


Consultant 2

Keith Dunkinson


Consultant 3

Andrew Dunkinson

WBS 2 Worker Based Two Levels:

WBS Level





Consultant 1

Andrew Birch



Consultant 1

Andrew Birch



Consultant 1

Andrew Birch



Consultant 2

Keith Dunkinson



Consultant 2

Keith Dunkinson



Consultant 2

Keith Dunkinson


Sure Step provides good templates for WBS including the following one:

WBS 3 Extract of Sure Step Enterprise 4 level WBS:

WBS Level



Sure Step Enterprise methodology


Analysis phase


Program management


Project planning

Conduct Executive kick-off

  • E1.1.1.1

  • Executive kick-off meeting

Develop Organizational Change Management Strategy

  • E1.1.1.2

  • Organizational Change Management Strategy


  • Develop leadership action plan

  • E1.1.1.3

  • Leadership action plan


  • Finalize Project Charter

  • E1.1.1.4

  • Project Charter


  • Finalize WBS and project plan

  • E1.1.1.5

  • Project plan


  • Review and Approve Project Charter and project plan

  • 1.1.2

  • Risks and issues management


  • Conduct Organization risk and readiness assessment

  • E1.1.2.1

  • Organization risk and readiness assessment analysis

  • E1.1.2.2

  • Risk and readiness assessment report

Linking the WBS to planning activities, progress, budgets, and the timesheets enables close cost control and duration management of the project.

WBS levels

We may measure and manage at any level of the WBS, but what we must consider with using detailed levels is that activities and budgets then need to be planned and recorded at the same level of granularity. We can of course manage different things using different levels of WBS, but again, consideration is required to ensure they can be reconciled at an appropriate level of detail.

Labor and materials tracking

Reconciling progress and budgets requires collecting information at the appropriate level of detail. Therefore, the budgeting formats and timesheets need to be agreed before the project begins. All too often, this is not realized until after the project has commenced and reconciliation has already become futile.

Time logs

In particular, timesheets from the consulting team (or indeed any budgeted resource) need to be broken down into the level of reporting required. This can be difficult for resources who undertake a wide range of activities in a day, and this should also be considered when planning the granularity of measurement and management required.

Initiating Cross Phase activities

While we have covered some of the more important and arguably less common activities, there are of course many more we could have considered. The project type, our project's needs, and our own experience will influence choices, and adoption of methodology for the project. Sure Step includes good content for Cross Phase activities, project type selection, Organizational Change Management, and so on. Once we have made our decisions, we should look again at what Sure Step has suggested before setting them in stone. If we are not sure, we can seek peer review. There are numerous forums for Sure Step and experts are available to help if necessary. The Microsoft forums, LinkedIn Dynamics World, and Mibuso are all useful reference points.



Sure Step is readily available to Microsoft Dynamics partners and customers and can easily be installed and set up. Utilising Sure Step appropriately requires experience of implementing Dynamics projects in a structured fashion.

In a Dynamics AX context, Sure Step includes content and guidance covering:

  • Phases: This section explains how a project type goes through iterative cycles, such as Diagnostic, Analysis, Design, Deployment, and Operation.

  • Project types: This section describes different project types, namely Rapid, Standard, Enterprise, and Agile.

    • Cross Phase activities: This section provides information on how Cross Phase activities are configured using Sure Step, which are listed as follows:

      • Organization: Program Management, Training, Business Process Analysis.

      • Solution: Requirements and Configuration, Custom Coding, Quality and Testing.

      • Technology: Infrastructure, Integrations and Interfaces, Data Migration.

    • Project Management Library: This section provides information on and best practices for standard activities that are carried out by project management throughout a project.

    • Organizational Change Management Library: This section provides a blueprint of the approach to Change Management for the project.

    • Role identification: This section provides an overview of the customer and consultant roles that are involved in a Dynamics implementation.

    • Solution optimization: The different types of solutions available are described in this section, which is listed as follows:

      • Solution types: General; Manufacturing, Public Sector, Retail Industries, Service Industries, and Customer Care.

Project initiation activities should be considered very early in a project, as they are much harder to implement properly once a project has started without them.

Every project is unique and while trying to conform to standards, we need to be flexible and dynamic in our approach to achieve the best results within a reasonable timescale and cost.

In this chapter, we have introduced you to the Sure Step client and discussed the various Engagement and project types available. We have also outlined the activities needed to move an engagement from the pre-sales phase on to the implementation phase. In the next chapter, we will cover the Diagnostic phase, including Decision Accelerators, cross-phase activities and third party products.

About the Authors

  • Keith Dunkinson

    Keith Dunkinson has over 20 years’ experience implementing ERP systems for many companies, working with over 100 successful ERP implementations. He owned and ran The Computing Practice, an ERP solution centre where he worked in a variety of roles for over 16 years, selling and implementing Dynamics NAV, SAP, Oracle, and Sage software. Keith now works as the business development director at AxPact Limited – the world’s largest global supplier of Microsoft Dynamics AX – where he is involved in bringing together and managing over 30 independent Dynamics AX solution centres and leads the AxPact Project Governance Initiative. Keith still works hands-on in the sale and governance of AX delivery projects through his own company ERP Advisers Ltd; including being the lead project manager/project governor on a number of complex AX implementations.

    Browse publications by this author
  • Andrew Birch

    Andrew Birch has over fifteen years’ experience in the technology industry starting his career as a network infrastructure engineer before moving to an operations management position in a software development company. Andrew began working with AX (Axapta) in 2003, and has since become one of the foremost proponents of Dynamics AX in Europe, speaking at several Microsoft events, with his projects winning a top industry award. He has been heavily involved in the creation and implementation of Microsoft Dynamics AX add-ons, particularly for the feed industry, that focus on real-time integrations between AX and production control systems. Andrew is now the lead consultant at Binary Consultants, a company he owns and runs with some of the most experienced and creative Dynamics AX and Microsoft .NET professionals in the UK.

    Browse publications by this author
Book Title
Access this book and the full library for FREE
Access now