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.
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.
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 refer to the choice of Diagnostic, Implementation, or Optimization offerings.
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.
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.
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 |
Sites |
Users |
Fit to the Gap Fit |
ISV solutions |
Complexity |
Countries |
|---|---|---|---|---|---|---|---|---|
|
Rapid |
No |
1 |
1 |
1-35 |
>90 percent |
0 |
Low |
1 |
|
Standard |
Some |
1-2 |
1-3 |
25-250 |
>75 percent |
1 |
Medium |
1-5 |
|
Enterprise |
Extensive |
>1 |
3+ |
250+ |
<75 percent |
>1 |
High |
5+ |
|
Agile |
No |
1+ |
1+ |
1+ |
<75 percent |
1+ |
Medium |
1+ |
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.
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.
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.
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.
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.
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.
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.
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 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:
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.
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 are also captured such as technical environment, high availability, migration, and so on. This is covered in the later chapters.
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.
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 |
Resource |
Name |
|---|---|---|
|
1 |
Consultant 1 |
Andrew Birch |
|
2 |
Consultant 2 |
Keith Dunkinson |
|
3 |
Consultant 3 |
Andrew Dunkinson |
WBS 2 Worker Based Two Levels:
|
WBS Level |
Resource |
Name |
Activity |
|---|---|---|---|
|
1.1 |
Consultant 1 |
Andrew Birch |
Analysis |
|
1.2 |
Consultant 1 |
Andrew Birch |
Design |
|
2.1 |
Consultant 1 |
Andrew Birch |
Development |
|
2.2 |
Consultant 2 |
Keith Dunkinson |
Analysis |
|
2.3 |
Consultant 2 |
Keith Dunkinson |
Design |
|
2.4 |
Consultant 2 |
Keith Dunkinson |
Development |
Sure Step provides good templates for WBS including the following one:
WBS 3 Extract of Sure Step Enterprise 4 level WBS:
|
WBS Level |
Activity |
|---|---|
|
1 |
Sure Step Enterprise methodology |
|
1.1 |
Analysis phase |
|
1.1.0 |
Program management |
|
1.1.1 |
Project planning |
|
1.1.1.1 |
Conduct Executive kick-off |
|
|
|
1.1.1.2 |
Develop Organizational Change Management Strategy |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Linking the WBS to planning activities, progress, budgets, and the timesheets enables close cost control and duration management of the project.
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.
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.
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.
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.