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.

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:

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.

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 2 Worker Based Two Levels:

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

WBS 3 Extract of Sure Step Enterprise 4 level WBS:

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

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.