Customer Success with Microsoft Dynamics Sure Step

Chapter 5. Implementing with Sure Step

In the previous chapter, you discovered the discipline of managing projects and walked through project management essentials, the four pillars of project success, project management adoption, and the organizational benefits. You also discovered earlier that by carrying out the prescribed activities of the Diagnostic phase, one of the outcomes is that both the customer and the service provider arrive at a common understanding of the business needs and a vision of the required solution; thereby, setting the stage for a quality delivery of the envisioned solution.

This chapter builds upon our learning of the customer situation and discusses how Sure Step can assist the service provider in delivering the envisioned solution on time, in scope, and on budget. In this chapter, you will discover:

· The implementation approaches in Sure Step, including the notion of phases and cross phases

· The waterfall-based implementation project types, including Rapid, Standard, and Enterprise project types

· How to set up Solution Rollout programs

· A detailed description of each of the Sure Step waterfall implementation phases

· The Agile Implementation project type

Implementation approaches in Sure Step

The Sure Step methodology provides two distinct implementation approaches for solution delivery: waterfall and agile. The waterfall approach to solution delivery is a sequential process that depicts a linear flow of activities from one phase to another, culminating with the solution being promoted to production and then into operation. In contrast, the agile approach represents an iterative solution development method that promotes a collaborative process between the resources that own and specify the requirements for the solution and the resources responsible for the development and rollout of the solution.

The notion of phases and cross phases

Keeping up with the principles of the waterfall approach, Sure Step provides waterfall-based project types that assemble the activities across five vertical implementation phases: analysis, design, development, deployment, and operation. These phases and their activities are detailed later in this chapter. Sure Step also groups its activities into horizontal swim lanes, or cross-phase processes as they are called in Sure Step, which we will discuss in detail in this section.

Cross-phase processes are a key aspect of Sure Step because they allow the logical grouping of related activities that span multiple phases of a project, highlighting the activity flow for a specific aspect of the implementation effort. Cross-phase processes highlight the dependencies between the activities in the grouping, as well as interdependencies with other cross phases. The grouping can also provide a role view or pivot for the users of the methodology, such as depicting the series of activities that will be led by the project manager, trainer, or developer.

The Agile project type groups its activities into sprint cycles. The activities of sprint cycles encompass the analysis and planning for the solution, the solution design, and the development of the solution. Following development, the Agile project type leverages the Deployment and Operation phases of the waterfall-based approach, to aid the rollout of the solution in a consistent fashion. We will discuss the usage of phases and cross phases in the Agile project type in a later section.

The following screenshot shows how the phases and cross-phase processes are manifested in the Sure Step waterfall-based project types:

Sure Step aligns the activities into nine cross-phase processes that are grouped into three areas: Organization, Solution, and Technology.

· The three Organization cross phases are:

· Program Management

· Training

· Business Process Analysis

· The Solution cross phases are:

· Requirements and Configuration

· Custom Coding

· Quality and Testing

· The Technology cross phases are:

· Infrastructure

· Integration and Interfaces

· Data Migration

Each cross phase can include multiple activities; however, depending on the project type, a cross-phase process may or may not be used. For example, in the Rapid project type, the Custom Coding or Integration and Interfaces cross phases have no activities called out, as the Rapid project type caters to out-of-the-box solution delivery. This is explained in more detail in the upcoming section.

Waterfall-based implementation project types

To address the scale and complexity of the customer's implementation engagements, Sure Step offers the users the choice of three waterfall-based implementation project types and one waterfall-based upgrade project type. The focus of this section will be on the three waterfall-based implementation project types: Rapid, Standard, and Enterprise. The Upgrade project type provided by Sure Step will be covered in Chapter 7, Upgrading with Sure Step.

The Rapid project type

The Rapid project type represents the simplest delivery approach among the Sure Step waterfall-based project types. The Rapid project type is designed for out-of-the-box implementations of the Microsoft Dynamics solution, which essentially entails zero or minimal customizations to the standard solution.

The Rapid project type prescribes fourteen activities to the Go-Live solution, and as such, it is positioned in Sure Step as a lean or accelerated delivery approach. The relatively low number of activities, of course, doesn't directly translate to fewer implementation hours, but it does imply a minimalistic approach that requires extreme discipline and hard work from the customer and consulting teams. This is because such a lean approach does not factor in any time for missteps—it has no leeway in the budgeting and resourcing structure of the project.

The following is a screenshot of the Rapid Project type, including the activities shown in the left navigation tree:

Before selecting the Rapid approach, it also very important that in the Diagnostic phase, the service provider and customer determine that the standard Microsoft Dynamics solution has a high degree of fit with the customer's requirements, and that no major customizations or add-on Independent Software Vendor (ISV) solutions are needed to complement the standard solution. If proper due diligence is carried out to determine that a high degree of fit exists, the Rapid project type can indeed live up to its name and provide a rapid delivery of the solution. It could be a recipe for disaster if one of the two parties—the consulting or customer teams—willfully chooses this project type even though they are aware of additional rigor needed in developing the solution.

The following are the ideal conditions for the usage of the Rapid project type:

· A very high degree of fit exists between the customer's requirements and the selected Microsoft Dynamics product's features. The general rule of thumb is to look for about 90 percent degree of fit or higher to justify the usage of a Rapid project type.

· Zero or minimal customizations will be needed to meet the customer's requirements, nor does the solution include any ISV solutions. It is important that if their requirements are classified as gaps with the prescribed solution, they will require only simple custom code development efforts.

· Business process analysis is not in the scope of the rapid engagement. A rapid engagement necessitates that the customer undertakes this effort, and it is not a requirement for the consulting team.

· Significant integration or interfaces to third-party sources is outside the scope of the engagement. Developing code for integrating to outside sources can be fraught with factors outside the delivery team's control. For that reason, going with a minimalistic approach is not recommended if the solution requires integration and interface development.

· The migration of data from legacy or third-party systems to the envisioned solution is straightforward or it is outside the scope of the engagement. Just like integrations to third-party sources, extracting data from outside sources introduces factors beyond the control of the delivery team, and hence it is not recommended.

From a general customer profile standpoint, the Rapid project type is typically used in small-to-medium sized businesses deploying Microsoft Dynamics solutions. The typical number of users for the solution in these companies is small—up to 25. The usage scenarios for the solution could include companies moving away from homegrown legacy systems or smaller systems that no longer support their growth. These customers must have gone through the selection process in the Diagnostic phase to determine a good fit with the Microsoft Dynamics solution and would be looking for the solution to go into production with a limited amount of functionality in a relatively short timeframe so as to quickly realize value from the solution.

Also, the customers that fit the Rapid project type profile may have a relatively small number of users both on the business and IT side with prior experience in implementing or using ERP/CRM solutions or solutions that encompass a high swathe of the organization. The relative inexperience in this area requires that the customers choose a good partner who understands their vision and can deliver the solution to meet it. For the customer, it is also judicious to lean towards a more out-of-the-box solution deployment. Hence, it is preferable to choose the Rapid project type, so that they can start with a more straightforward solution and gain experience before jumping into complex solution scenarios.

While the typical usage of the Rapid project type is for smaller businesses, it is important to note that this project type should not be considered as limited to the size of the customer. When you look past organizational size and look at usage patterns and needs, you may find other use cases for this project type. For example, the Rapid project type could also be applicable in multisite deployments, where the solution has already been developed and delivered to the first site and where a very similar solution is being delivered to additional sites.

The Standard project type

The Sure Step Standard project type is suitable for a majority of Microsoft Dynamics projects and hence the most widely used. This project type includes activities in all nine cross phases to support customizations, integrations, interfaces as well as business process analysis. As such, the Standard project type can be used on typical medium scale, single-site implementations.

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:

The Standard project type is best suited for medium-to-large sized businesses that find a fairly high degree of fit of their solution requirements with the corresponding Microsoft Dynamics solution. The rule of thumb on the degree of fit is around 70 to 80 percent, but more importantly, the required customizations should not be overly complex, in which case, the Enterprise project type may afford a more rigorous approach to managing the custom code development process.

The usage scenarios for the Standard project type include the following:

· The customer's requirements can be met to a fairly high degree (about 70 to 80 percent fit) by the selected Microsoft Dynamics solution, which may or may not include an ISV solution in addition to the core Microsoft Dynamics solution. The activities in the Standard project type provide more prescriptive guidance for the setup of the ISV solution in conjunction with the Microsoft Dynamics solution by the service provider, and hence the Standard project type is more suitable than the Rapid project type.

· Business process analysis activities are included. One of the most widely used features of Sure Step is the extensive business process maps included. These process maps afford customers and service providers an excellent starting point to map their future workflows from the standpoint of using the standard Microsoft Dynamics solution functionality. Not only do the process maps allow the customers' end users to understand in a graphical manner how the solution functionality is designed to operate, but they also allow them to visualize how their current processes could fit into the new system, and if there are opportunities to make simple tweaks in their processes to alleviate the need for complex customizations. The importance of this cannot be minimized for the long-term outlook and Total Cost of Ownership (TCO) of the solution.

· Organizational Change Management (OCM) is identified as a key discipline for customer engagement though the need is not as stringent as it would be for large-scale engagements.

· Custom code development is needed for the requirements classified as gaps, with the prescribed solution being simple to complex, but not overly complex, as stated earlier. For highly complex customizations, the additional rigor in the Enterprise project type may be better for the customer and the service provider.

· Custom code development may encompass integration or interfaces to third-party sources as well as migration of data from legacy or third-party systems to the envisioned solution. Again, it is suggested not to make these coding efforts overly complex.

The Standard project type customer profile is the one with a fairly decent number of system users—typically up to 250. With a higher number of users from a cross section of the organization, the solution not only needs to account for varied requirements in each of the business units, but it also needs to handle interdependencies across these units. As such, moderate-to-complex customizations can be expected to retrofit the standard solution to the customer's workflows. The solution will also likely need to interface to a few subsystems both from a data integration standpoint and from a reporting and Business Intelligence system or data warehousing standpoint.

The customers in the medium-to-large segment also typically have a reasonable number of experienced business and IT users who have used and deployed other non-legacy business solutions. Averages in this segment may be up to 20 years of full-time experience on the business side, and ten years on the IT side, with ERP/CRM and general business solutions. For the customer, it is important that these users are an integral part of the team that is helping to fashion the overall solution requirements in selecting the solution that best corresponds to their needs and in delivering the solution, including configurations and all the way through to user-acceptance testing. It is easy for these users to be wrapped in their day-to-day activities and not have time for the project, and as such, it is the responsibility of the management of the customer organization to ensure that these users get some sort of a relief from their daily tasks to be able to participate and have meaningful contributions to the solution delivery engagement.

The usage of the Standard project type can also be extended beyond the medium-sized organizations to large enterprises. For example, a large multisite organization looking for a common solution across its organization may look to deliver a similar solution that has already been deployed in a pilot site. While the pilot site solution may have been developed using the more robust Enterprise project type, future rollouts of the solution to ensuing sites could use the Standard project type. Such usage scenarios of solution rollouts are described in a later section.

The Enterprise project type

The Enterprise project type 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 the service provider throughout the length of the engagement. Large-scale engagements are typified by complex requirements and solution scenarios that necessitate a thorough approach to governance and oversight in all disciplines, including project management, solution configuration and setup, custom code development, and testing. To cater to these types of usage scenarios, the Enterprise project type is provided.

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.

The typical usage scenarios for the Enterprise project type include the following:

· The requirements for the solution include complex customization and/or multiple ISV solutions in addition to the core Microsoft Dynamics solution. In large engagements, especially multisite projects, it is not atypical to see multiple development teams spread out in different continents, building on specific requirements for the same solution. It is critical that these teams are all working with the same sheet of music, so to speak. In other words, they are all working towards the same goal. To ensure that there is tight coordination between the teams and that each of the teams understands the interdependencies, the Enterprise project type is used.

· The custom code development efforts may include complex integration or interfaces to third-party sources as well as migration of data from legacy or third-party systems to the envisioned solution. Again, the diligence provided by the Enterprise project type is needed here to ensure that risks are identified upfront as well as that mitigation scenarios are also developed to alleviate the risks, if needed.

· Due to the far-reaching effects of the solution, a concerted effort for OCM is needed for the customer. The Enterprise project type prescribes activities for OCM experts to plan upfront and develop strategies and techniques for managing the projected change across the organization.

· In concert with the OCM activities are the deep Business Process Analysis activities that allow the service provider and customer organization to discuss and document the future or to-be workflows for the customer. The activities and templates provided in Sure Step facilitate this for enterprise-scale customers.

· Large-scale engagements also require the installation and management of multiple environments for developing the solution. This not only requires a bigger investment in the hardware for the project, but it also requires activities for planning, setting up, maintaining, and transitioning these environments, including clear documentation for the teams that will be supporting these environments after the handover, as prescribed in the Enterprise project type.

· Multisite engagements, especially the ones where a common, consistent solution is desired across the organization, also need a rigorous set of solution configuration and development activities advocated by the Enterprise project type. The development of the solution for these organizations can get even more complicated when each location also has a set of unique needs that must be considered over and above the common list of requirements across the organization. The unique needs may stem from local country laws, accounting and reporting regulations pertaining to the local country, or from specific requirements of the local marketplaces.

The profile of the organization requiring the usage of the Enterprise project type is that with a very high number of system users—250 users and above. Depending on the number of locations that the solution is to be deployed at, coordinating across all of the users requires a well-planned and thought-out approach, which is provided by this project type. This includes activities for gathering the requirements across the locations, training the super-users and end users for each location, as well as a thorough User Acceptance Testing of the solution at each site prior to deployment.

The organizations in this segment are also characterized by a large number of experienced users in the business and IT groups. Due to the size and reach of the solution, the customer organizations typically appoint selected resources from this experienced group as dedicated resources for the length of the solution delivery engagement. In effect, these resources are extensions of the implementation team, and these power-users typically become the lead internal go-to persons to support other users after the solution becomes operational.

Setting up a program for solution rollout

In the previous sections, we discussed the different options for implementing Microsoft Dynamics solutions using Sure Step. Sure Step has three waterfall project types (Rapid, Standard, and Enterprise) along with one Agile project type. These types guide the implementers through solution development and the rollout of a single release or the rollout to a single location of an organization. However, these project types can also be used in concert with each other on phased solution rollouts or on multisite engagements, and this will be the focus of our discussion in this section.

Phased solution rollouts

In the previous chapter, we introduced the notion of the phased approach to solution delivery. This approach, not to be confused with the phases within a waterfall project type, refers to the rollout of the solution to the customer organization in multiple releases. The phased solution delivery approach is executed in practice by selecting and enabling an initial subset of solution functionality in the first release and then building on that with the help of additional features in subsequent releases. The alternative to a phased approach is delivering the full solution in a single release, also referred to as the big bang approach to solution delivery, which we have already covered in the preceding sections.

The Sure Step project types can be used together to facilitate the phased solution rollout. Essentially, each release is treated as a subproject, and the corresponding complexity of the requirements being enabled in each release will dictate the appropriate usage of the corresponding project type. The general concept of the phased solution rollout is depicted in the following screenshot:

Following this concept, the next screenshot shows an example of its usage for an ERP solution implementation. In this screenshot, Release 1 of the phased approach uses the Standard project type to enable the Finance operations of the customer. This is followed by Release 2, using the Rapid project type to deliver the Inventory Control and Order Fulfillment functionality. The last release, Release 3, uses the Agile project type to deploy the Advance Planning and Scheduling functionality.

Multisite engagements

As you move into the larger organizational domains, the ERP/CRM solution requirements often transcend multiple locations for the customer. Multisite engagements can include both multiple sites in a single country and multiple locations around the world. The latter, of course, introduces far more complexity with country-specific requirements, such as taxation and accounting rules. But in a majority of the cases, the customer's overarching objective is to deploy a common solution across all sites.

To enable the development of a common solution across multiple locations, Sure Step provides the Core-Site Build option with its Enterprise project type. In this approach, the service provider works with the customer to conduct requirements gathering workshops, involving key Subject Matter Experts (SMEs) and business leads from all of the relevant locations of the organization. The output of these workshops is a combined Functional Requirements Document (FRD) for the enterprise, which forms the basis for Core Build.

Core Build can be viewed as a common denominator solution. In the classic 80-20 rule, Core Build will include functionality to support about 80 percent of the requirements of the enterprise. However, Core Build is just a developed solution, which means that it cannot be rolled out by itself. Core Build is always deployed in conjunction with Site Build, which constitutes the functionality to meet the remaining 20 percent specific requirements of the corresponding site. The actual rollout at a given site can be staggered in time, or they can be rolled out with overlap. The timing itself is very topical and depends on the specific requirements being enabled for the enterprise.

The next screenshot shows the Core-Site Build concept. The diagram shows one Core Build and subsequent Site Builds (Site 1 Build, Site 2 Build, and Site n Build) and corresponding Site Rollouts (Site 1 Rollout, Site 2 Rollout, and Site n Rollout).

In some cases, the customer may also have a diverse set of companies within their portfolio, each of which has a very unique set of requirements, and so it is better to treat each of the sites as its own project. For these multisite instances, the Sure Step project types can be used in tandem, which is similar to the approach undertaken in the phased approach. An example of this scenario is shown in the next diagram. The diagram shows individual Site Builds and corresponding Site Rollouts (Site 1 Build-Rollout, Site 2 Build-Rollout, and Site n Build-Rollout).

Sure Step waterfall implementation phases

The previous sections provided an overall look at the different delivery options provided in Sure Step, including the different project types for single releases along with the ability to combine the project types for phased or multisite deployments. Given this background, it is a good idea to dive deeper into each of the implementation phases, to get specific use cases and real-life scenarios for the content and templates provided in the methodology. We will look into it in the following sections of the chapter.

The Analysis phase

Most of us know what an Analysis phase is, and we usually explain it as the execution of activities to demystify the customer's requirements and business processes in greater detail—the "What in detail" so to speak. Is that all?

The start of the project

By kicking off the Analysis phase, we start with the real implementation of the project. A good start will set the tone for our further implementation. The question, What is the purpose of the Analysis phase?, is usually responded to with the following answer: To further analyze and document the customer's requirements. Sounds right, or is it?

Start your engines

This answer is quite incomplete as it neglects the important function of starting the project. This is where we start our engines, set our course, and take off. In aviation, the departure is considered to be complex and critical. This is not really different in software implementation projects—the beginning is always crucial. In the Analysis phase, we are not only investigating and documenting customer requirements and processes, but we are also kicking off risk and issue management, scope management, change management, cost and time management, communication management, and quality and resource management. It is here that we set the tone for our project culture and communication for this specific assignment. So, we need to understand that much more needs to be done than just investigating requirements and processes, and we need to plan for much more.

Expect some delays

In the Diagnostic phase, we worked hard to get a signed contract from our customer, the formal go for our project. The truth is that many things can occur after delivering and defending our proposal. The ideal case for us would be the customer accepting and signing our proposal immediately and giving us a go-ahead to start our implementation project. If we are lucky, events might unfold in this way, but alternative scenarios are no exception either. The customer's decision-making process might consume significant time in terms of duration. It can take weeks or even months before we get the approval. In tough economic times, the investment decision can also be postponed until the upcoming fiscal year, causing even more delay. Once we receive the formal nod from the customer by means of an approved contract, we are still not certain that the implementation project can start overnight. The execution of implementing activities needs to be strategically and carefully planned, so it might take some extra time after the contract agreement before we can really start. We need to consider this time (dis)connection between the Diagnostic and Analysis phases when setting out our flight plan for the Analysis phase.

A chance to establish the project culture

In Chapter 4, Managing Projects, we discussed the importance of establishing a guiding project culture for our specific projects. In fact, we defined it as one of the four pillars of a project's success. Connecting both the customer and the consulting teams to our values, beliefs, priorities, and behavior associated with this project is crucially important for our success. Before we jump into the execution tasks of our project, we need to align all stakeholders and team members with our approach and all crucial elements of this project. We need to practice what we preach right from the start of our implementation project. Now, when does the implementation project start? The answer is it starts right now, in the Analysis phase.

A look back

Before we define and discuss our next steps, let's have a look back on where we are now. The following diagram describes the flow from decision accelerators to the final proposal. This diagram includes only three important decision accelerators: Requirements and Process Review, Fit Gap and Solution Blueprint, and Scoping Assessment. A diagnostic phase could also include the other Decision Accelerators, but as stated before, you can deploy Decision Accelerators as desired. The diagram categorizes two types of tools and templates: working and key deliverables. Working deliverables are those tools and templates that serve as the toolbox for your consultants, helping them to increase their efficiency and quality. They can pick any instrument from the box whenever they need it. Sometimes, they need to use many of these tools, in other cases, they will need only a few. Key deliverables are a subset of the customer-facing deliverables. These are documents that we will deliver to our customer as the final output of the engagement. It is important to see to it that these documents support our communication and formalize the customer's validation of the described topics.

When speaking about aligning people with our vision and approach and creating a guiding project culture, we need to realize that by executing Decision Accelerators, we did produce valuable tools and rich information. In fact, everything we need to jumpstart our guiding project culture has been compiled in the project charter, which is a key deliverable from the Proposal Generation activity.

A good project charter is priceless

In Sure Step, the project charter is generated during the Proposal Generation activities—key components in the proof stage of Microsoft's Solution Sales Process (MSSP). The conclusions drawn in the preceding diagnostic activities become inputs to this Proposal Generation activity, where the key tasks involve drawing conclusions and packaging the available information and documentation.

The Sure Step project charter answers the basic and necessary questions about the project:

· Why: What are the business objectives, key success factors, and project objectives? What is value proposition addressed by the project? Why is it being sponsored?

· What: What are the major deliverables? What is in scope, and what is out of scope?

· Who: Who will be involved, and what will be their responsibilities within the project? How will they be organized? Who are the key stakeholders?

· When: What is the project schedule, and when will the milestones and deliverables be complete?

· How: How will the teams engage? How do we address change, issues, and risks? How we will execute, manage, and control the project?

The following screenshot is the table of contents of the Sure Step project charter and it clearly illustrates that all of the diagnostic conclusions are gathered here:

So, can you think about a better instrument to align all stakeholders and team members in terms of the vision of our approach and about all crucial elements of this project? The value of a project charter is priceless. It compiles all relevant project information on what, who, how, and when into one document functioning as a rock-solid guideline for all stakeholders governing the entire engagement.

Project planning sessions

We discussed earlier that there might be a time gap between the end of the Diagnostic phase and the start of the Analysis phase. Therefore, we might need to revise and update our project schedule and project charter at the beginning of the Analysis phase. The following diagram illustrates the finalization of the Diagnostic output in the planning sessions in the beginning of the Analysis phase:

Project planning sessions are conducted as joint exercises with the customer. The session agendas include an overview of the project, timeframes, deliverables, the establishment of the project structure, risk and stakeholder analysis as well as planning for communication, change control, resources, and quality.

Kick off your communication culture

We all know the concept of kickoff meetings, but do we undervalue the importance of it? We sometimes tend to deliver our kickoff meetings as an operation, namely by redelivering the exact same content repeatedly. We typically introduce our company, ourselves, and the consulting team, and we ask the customer to do the same.

Then we talk about our phases, the time and budget constraints, and the product we are about to implement. And finally, we try to close this meeting in a positive atmosphere. This kickoff meeting content is then identically redelivered in all of our projects. But is this good enough? To answer that question, we need to consider the following two important things:

· Projects are unique by definition

· There might be a time gap between the end of the Diagnostic phase and the start of the Analysis phase

Unique projects require unique kickoff meetings. What makes each project unique? Let's list some important differentiators:

· Stakeholders and the organizational context and complexity

· Stakeholders' objectives and expectations

· Business and project objectives

· Critical success factors

· Areas and requirements within scope

· Areas and requirements out of scope

· Customer and consulting implementation teams

· Budget and time constraints

These elements are always different in our implementation projects. Therefore, we need to address them during our kickoff meetings. By doing so, our kickoff meetings will include the necessary elements to make them unique. We need to bridge our kick off content with the unique character of each implementation project. This means kick off meetings cannot be executed in an operational way. Kickoffs need to be tailored to each specific project and presented in the context of the customer's unique organization.

This is exactly why Sure Step recommends the following agenda topics for the kickoff meeting:

· Introduction

· Project definition and objectives

· Key deliverables

· Success criteria

· Project approach

· Project team and organization

· Roles and responsibilities

· Training and testing

· Controlling, reporting, and sign-off

· Communication

· Project scope

· Q&A session to provide an opportunity for the customer, stakeholders, and team members to express any concerns or worries

Wrapping up

Yes, preparing for this kind of kickoff meeting will consume some time, especially when you need to create this content for the very first time, scouring for information in various documents and places. Take a look back at the agenda points. Where can we find this information? Yes, you are right; the project charter compiles all this information into one document. A solid project charter generated through diagnostic activities is your jumpstart for unique and effective kickoff meetings. This is why Sure Step lists the following preconditions for the kickoff meeting:

· Initial project planning is in place

· Project stakeholders are identified

· The project charter is established

· The project is ready for execution

We can now further complete our diagram by adding the kickoff meeting. The following diagram illustrates how the information generated from diagnostic activities is compiled in the project charter and re-used as input for the kickoff meeting:

A value-oriented kickoff meeting is key to aligning all of the stakeholders at the start of the implementation project. In the time period between the end of the Diagnostics phase, the signing of contract, and the start of the Analysis phase, many scenarios might unfold. At the consulting site, the team involved with the diagnostic activities for a specific project is likely to be released by now and already planned and active on other engagements. At the customer site, key users may have switched departments or left the company. New managers or department heads can be employed, bringing new visions and priorities with them. Business procedures and requirements might have been reviewed and altered because of newly arising business opportunities. Many new scenarios are possible when facing a longer period between the end of the Diagnostic phase and the start of the Analysis phase.

Then what is our mission now? During the kickoff meeting, we need to verify and validate if we still have the consensus and support for what has been stated in the project charter. This is absolutely crucial for starting a successful engagement. Do we still have the same stakeholders? Do they still support the project objectives and priorities? Do we still have a consensus around what is in, and what is out of scope? Are the new consulting team members aligned with the diagnostic conclusions? Do they have questions about the scope and business processes? Is it clear what documents need to be signed off, who needs to sign-off, and what signing off really means? We also need to present and review the planning and set out our next steps, including what is expected from whom.

So, the kickoff meeting is not just a small coming together to present ourselves and the company; it needs to be more than that. We not only need to align people on the what, how, and when, but we also need to hunt for existing issues and changes that have occurred since the end of the Diagnostic phase.

To train or not to train?

One of the first activities that you might consider to plan for after the kickoff meeting is training. Training is not only an excellent vehicle to educate people, but it is also a great instrument to manage perception. In Sure Step, training is one of the cross-phase processes, facilitating a better project life cycle planning. Phases should not be exclusively reserved for their core activities but they need to contain a good mix of all cross-phase activities. In this vision, training should not exclusively be reserved for the Deployment phase. Why would we consider planning for training in the Analysis phase? How can we benefit from this? Our goals for training in the Analysis phase are important. The following are some of the ideal goals we should have in mind:

· Creating awareness for the new solution

· Introducing the functional architecture and standard concepts of in-scope functional areas

· Introducing the applications' vocabulary

· Creating a mutual understanding of processes and functionalities within customer and consultancy teams

· Facilitating perception and organizational change

· Improving efficiency and quality of the upcoming analysis workshops

If executing training during the Analysis phase realizes even a small portion of these objectives, it would still be worthwhile. Do we then need to plan for training the complete team of the end user about their new solution? The answer is simple, and it is no. We do not want to educate the end users at this moment in the project life cycle as this would be far too early and not effective. Research clearly shows that by Go-Live time, the end users would have forgotten most of it, and our training investment would not generate any return. What we want to plan for are small training sessions for well-targeted groups. We want our key user team to understand the functional outlines of our solution in relation to their expertise domains. Therefore, we need to demonstrate and throw light on standardized functionalities and flows for the applicable functional areas to a selected audience. It might unfold discussions, but this is exactly what our aim is—good customer interaction, feedback, and active listening can provide us with a wealth of information.

At this point, we might already find some opportunity to demonstrate that it is possible to execute existing processes in a slightly different sequence or manner, while still achieving the same or better results. You got it right; we should start managing perceptions right here before our core analysis activities. Organizational change management is not something that you initiate just before Go-Live; it should be omnipresent in your project life cycle planning. You might ask what possible risks are associated with this training. The biggest risk is to address the wrong audience. This training, which is referred to as Conduct Solutions Overview in the Sure Step jargon, is unsuitable for the real end users as they have only one objective: they seek answers on how this new solution will address their detailed daily work. In this Solutions Overview training, they will not find those answers leading to potential frustrations and negativity. And as you know, bad news travels fast. That is the reason why we need to manage these sessions well and communicate effectively to our customer, for whom these sessions are intended.

The following diagram illustrates the continuation of the activity flow after the kickoff meeting:

The uncontrolled Analysis phase

Project management status reporting usually does not disclose many problems during the Analysis phase. When we ask our application consultants about the status during the analysis activities, they usually reply that all is going well. Some project managers do not perceive this phase as an intricate situation, and they entrust the success of this phase to the competence of the involved business analysts. They reassure themselves that when they deploy highly skilled and experienced business analysts and application consultants for the business process analysis workshops, they do not need to worry about too many unexpected troubles. It also appears that such project managers are not too concerned about the deliverables in this phase either. They just need to have a written document describing and explaining the customer's needs in terms of desired functionalities for their business processes. It now looks as if the only one challenged during the Analysis phase is the business analyst, while the project manager is only facing a nice little job, namely planning the workshops and gathering some feedback during the workshop activities. If this were true, we would not need a project manager during this phase. Let's take a closer look and find out what the real challenge is for the project manager in this phase.

We have already discovered in the previous sections that we need to plan for more than just the pure analysis activities and that the Analysis phase represents the start of the implementation project. This will challenge the project manager to kick off the project culture and approach, and this involves a bit more than just planning a few interview sessions. But even if we were to ignore this, the real analysis activities are also demanding good project management.

If we limit our responsibilities to the planning of workshops, asking our applications consultants how it goes, and then waiting for the final document deliverable, we are giving away all control. The first control element that we lose is progress reporting. If we can report the progress only in terms of the final document deliverable, there is not much we can really do except to wait for this final document and figure out the progress in terms of percentage complete. Now we all know how accurate that is. The second control element that we will be missing is the quality control. If we are waiting for this final document deliverable, we can assess the quality only once it is ready. By then, it may be too late to initiate corrective actions. Most project managers may not even read the complete analysis document deliverable as they lack sufficient time to go through all of the details.

Giving up on progress and quality tracking capabilities in your first phase of the project life cycle is not a wise thing to do, and it will set the tone for the rest of our project. If we do not give attention to these important aspects here, we most likely will not do it later either.

Unfortunately, there is something else that can go out of sight: setting priorities for the analysis activities, scope management, and issue and risk management. These are all endangered during the deployment of passive project management during the Analysis phase. These elements are covered in the next section, where we will list and discuss some real-life analysis scenarios.

Scenarios for real-life analysis

In an uncontrolled Analysis phase, we can recognize the following typical scenarios.

Back to square one

To come straight to the point: application consultants starting afresh and analyzing everything all over again—how recognizable is that? Quite a few application consultants start their core analysis activity totally disconnected from diagnostic results and without guidance on the priorities of the to-be-analyzed scope. Can we predict the outcome of such a scenario? The outcome is probably an analysis document covering a lot of detailed information on less important topics, and at the same time, lacking good information on the more important and complex areas. In many cases, customers also get frustrated because they had to supply the same information all over again. It looks like we are back to square one and that our earlier executed pre-study analysis activities didn't make much difference. Customers will not understand why we charged for it and complain about lost effort. Act surprised!

Scope creep sneaking in

Most of us know all about changing scope. It is one of the most popular reasons reported as cause for project failure. Knowing all about this threat, we prepare for it. Armed with change requests, we combat the scope creep monster from the first moment we identify it. At least that is what we tell ourselves. The problem is that most of us identify scope creep only in the later stage in the project life cycle when we come out of development activities and engage with testing activities, or even worse, when we are preparing for Go-Live. Unfortunately, our chances to win the battle at this stage are minimal.

We need to be aware that scope creep is likely to slip in furtively during the Analysis phase, especially when our analysts are disconnected from good diagnostic results. During these workshops, our analyst team will meet with several department heads, key users, and business analysts, among others. They will all have their views on what should be automated and how. They might give new information about existing requirements or even formulate completely new requirements at this stage. If our analyst does not identify or report this now, our scope creep monster will start growing and become a giant at the later stage.

No issues, no risks

Passive project management during the Analysis phase will not provide the analyst team with much guidance on their responsibility, specifically not when speaking about issues and risks. During the Analysis phase, project managers frequently ask their consultant team about how things are going and only rarely will they report issues and risks. In most cases, everything is reported to be under control. This is because the application consultants might not feel responsible for identifying issues and risks at this stage. Risk and issue identification at this stage is commonly seen by the analyst team as a responsibility for the project manager. The problem is that the project manager is not engaged in all workshops and interviews, and lacks the information needed for this issue and risk identification. As a consequence, not many (if any) risks and issues are reported during this phase, and that is a missed opportunity. One thing is certain: there will be issues and risks to be faced in the Analysis phase, but if they are not identified and reported here, we will face the consequences later in the project life cycle.

We can summarize by stating that there are more than enough reasons why project managers should take control of the Analysis phase. There is much more to be done than the core analysis activities, and even the management of these analysis activities requires a solid approach and a clear vision from the project manager. In the next sections, we will discuss how Sure Step can help us.

Analyze what?

To know what needs our full attention and what might require less of our attention, we need to look back at our diagnostic results. The following diagram illustrates the connection with the diagnostic results:

Consultants can prepare for the Business Process Workshops by reviewing diagnostic conclusions and re-using diagnostic instruments and deliverables. The project charter should provide a complete picture on what's in scope and what isn't, business priorities, key success factors, and known issues and risks. Questionnaires and product-specific process maps represent an excellent jumpstart for the Analysis phase if these were modeled during the Diagnostic phase. They visualize already identified bottlenecks and complex areas within the overall customer business context and will clearly provide guidelines for the consultant team to plan the analysis activity. The analysis team will also benefit from the Fit Gap Analysis Worksheet, which provides very valuable input in terms of:

· Requirements linked to business processes

· Requirements prioritization

· Requirements categorized in terms of standard features, configurations, customizations, workflows, and ISV solutions

The following diagram illustrates how the Fit Gap Worksheet can act as an input instrument for Business Process Workshops:

With the given prioritized requirements, including estimated effort and complexity ranking by means of categories, an application consultant can plan and prioritize the available analysis time much better, leading to more efficient and quality-driven analysis engagements in less time.

Go for interim analysis deliverables

If we want to follow up on the progress and quality of our application consultants during the Analysis phase, we should plan for intermediate deliverables. Produce a simple document, such as a workshop report, because it can make quite a difference. As a project manager, you need to instruct your teams that a workshop report needs to be produced after each workshop. It contains standardized sections so that all application consultants use the same format in documenting the workshop results. This makes it much more convenient for project managers to follow up as every document can be read in the same way. Once a planned workshop is finished, a workshop report needs to be made available by the consultant. An insufficient workshop report will be questioned by the project manager and might lead to corrective actions. Workshop reports generated after the workshops themselves, and not long after the sessions, will prevent the additional risk that important information will be forgotten.

A great additional benefit of working with standardized intermediate document deliverables for analysis activities is the possibility to direct the desired output in terms of structure and quality. It will also set clear expectations to the consultants for the delivery.

The following screenshot shows one page from a workshop report:

This page makes it very clear that application consultants should not just record what the customer stakeholders tell them during the workshops, but that they are also responsible for generating conclusions, linking the information with the diagnostic scope, identifying issues, and motivating process changes in order to avoid superfluous customization. As a project manager, you can now organize your follow-up by asking two questions:

· Do we have a workshop report by the end of the workshop?

· Has section 6 been filled in by the application consultant in a quality way?

This approach represents a vast difference from the "waiting for the final deliverable" approach.

Managing scope creep during the Analysis phase by means of Fit Gap Analysis

One of the consequences of an unmanaged Analysis phase, as discussed in the previous section, is the instance where scope creep sneaks in. During the Analysis phase activities, new information about existing requirements becomes available, casting the original request in new light or even allowing for the formulation of new requirements. These cases are unavoidable even with a solid implementation methodology. Not identifying these changes in scope affects all stakeholders in terms of duration, cost, quality, and expectations, making identification them our real challenge. The following diagram introduces the Fit Gap assessment as a valuable instrument during the Analysis phase:

Once all business processes and the requirements investigation has been tied up, it is time to document all findings and conclusions in a Functional Requirements Document (FRD), providing a complete description of the requirements for the new solution. Now that we have all of the scope defined to the level of detail required, we can reassess the Fit Gap situation.

Sure Step advocates the benefits of reassessing the Fit Gap situation once requirements are captured in the Analysis phase. It prevents scope creep from sneaking in unnoticed, it reinforces the knowledge on the envisioned solution for all stakeholders, and it provides warning signals to the project manager to address a number of topics. If our assessment revealed new requirements, changes, and other important scope challenges, we need to embrace this precious information. It proves that our consultant team was very attentive for the scope impact on both the project and business, and we are triggered for some good project management action, our real job. Act now! What can we do then? We should at least communicate about these identified areas. What is the opinion of the consulting team? How does the customer team feel about it? What is the impact? Can we find alternative business processes and solutions? We should not panic about these cases, nor should we ignore them. These cases are omnipresent in projects, and identifying them in the Analysis phase is a step in the right direction. What is recommended to resolve them? As projects are unique, your approach and solution for these challenges will be unique as well. You will probably need a recipe with various ingredients, such as business process changes, rejecting a number of new unimportant demands, and accepting some real scope changes. Your recipe needs to taste well in this context. It needs to be aligned with the objectives, budget, time, and cost constraints, while also being accepted by a substantial coalition of stakeholders.

Did we just mention scope changes? Sure Step makes it clear that scope changes and their management cannot be uniquely reserved for the final phases of the project life cycle. Addressing scope changes in Sure Step is an element of proposal management. Sure Step literally states: Proposal Management is an activity that needs to be executed within all cross phases of the project implementation life cycle. Thus we can start making Change Requests in the Analysis phase. This means that the customer organization will be familiarized with this process quite early in the project life cycle. A Change Request is an effective instrument to keep scope creep under control, but it needs to be handled with care. This instrument will lose all its impact when operated in only one phase and with its becoming overabundant. Sometimes we tend to think that the change request is there to resolve not only all of the scope issues but also all quality issues. When clear quality issues are injudiciously and shamelessly filed as change requests, and every scope issue is transferred into a change request, we are creating a mountain of paperwork. Best practice tells us that in these scenarios, the scope change issue will remain unresolved as customers will not sign off for these changes. Act surprised! Expert use of the change request implies a well-balanced use spread over the complete project life cycle as suggested by Sure Step.

We can now further complete our diagram of the Analysis phase:

Do not forget about data migration

Focused on the functional solution, data migration is often handled as a second-class issue. We love designing functional solutions, bridging business processes and software functionalities, and are so focused on it that everything else vanishes without a trace. This is not really smart, as non-functional requirements can be a hard row to hoe, consuming considerable resources and creating quite some risks. Most of us have already experienced how data migration challenges can impact project duration and even Go-Live decisions. That's why Sure Step addresses data migration. Topics such as the condition of existing data, data cleansing, amount of historical data to be migrated, identification of existing data sources, and master-data management need to be tackled right from the start. They need to ensure that these topics are addressed in the analysis workshops.

Interact with the infrastructure department

Good project life cycle planning requires a good mix of cross-phase processes in each and every phase. We have already seen that the Analysis phase is not reserved exclusively for the core analysis activities but that it also needs active project management and strong communications, training, and attention to data migration topics. It is also recommended to start interacting with the infrastructure stakeholders to build the sandbox and training environments. These environments are needed to allow customer training and familiarization with the core Microsoft Dynamics product, prior to any configuration or customization, and it provides an excellent opportunity to build up relationships and communications with the customer infrastructure people. The earlier we start to engage with them, the more time we have to prepare them for the turn-key moment.

The Design phase

Solution designing is a crucial activity in any software project. Even when not much customization is involved, we still need to envision the how of the project.

Do we really need a Design phase?

Do we really need a separate phase for designing the solution? This is an often-heard question. Some claim to initiate solution designing during the Analysis phase, while others include it in the Development phase, or even when convenient. From a waterfall perspective, you can plan your design activities in one or more phases as long as you execute what you planned for in a specific phase. So, there is no real waterfall reason for a specific Design phase. However, phases represent a breakdown in time, in order to plan and manage our project life cycle better. That's why Sure Step plans for a separate Design phase with dominant solution designing processes. After capturing the scope baseline, we can now concentrate on further developing our solution concept during a well-managed timeframe. Most of us are familiar with the what and how rule of thumb: during the Diagnostic and Analysis phase, we concentrate on the what aspect, whereas during the design phase we develop the how aspect of our project. This indicates what the dominant processes will be during those phases, but don't get mislead: project management and cross-phase processes have taught us that we need to plan for more in a phase than the core activities only.

The risk of a passive Design phase

The core activities of both Diagnostic and Analysis phases involve customer interaction by nature. Presales activities, such as requirements and business process assessments, proof-of-concept demonstrations, workshops, and interviews, among others, require customer interactions. This is not so obvious during design and development activities. Design activities are commonly envisioned and narrowed down to documenting the how. This means designing equals writing documents on the how aspect, with the only planned customer interaction being the validation of the document. Combining this with the same passive vision on the Development phase will jeopardize our project success significantly as we are factually locking out the customer from the project until the real deployment activities and postponing many of implementation activities. Do we really want to take that risk?

All activity in the Sure Step Design phase

Start singing Sure Step's praises, because it will release us from a passive Design phase. The real implementation activities start right here during the Design phase! Sure Step tells us not to wait until the end of the Development phase before initiating implementation activities. We need to maintain our contact with the customer organization by frequently interacting with the stakeholders. We need to raise the awareness and knowledge level of our stakeholders on the project and solution, stimulate organizational change, and continue risk and issue identification and management. There is so much to be done, and yes, we will also document some hows but without limiting ourselves to this.

We are implementing a standard package solution

Now let's think about this for a minute. What does it say? It means that we are not delivering a pure development project. A bulk load of requirements can be fulfilled by installing standard features, configuring, or ISV solutions. Then why do we sometimes initiate the implementation only after finalizing the development activities? Some standard functionality will be dependent on the customized functionality, and these requirements cannot be implemented immediately, but this does not apply to all of them. One of the key advantages of a package solution is that we can deliver quite quickly compared to customized solutions. We need to take advantage of this by initiating the implementation as soon as possible. There is really no reason for postponing. We will benefit from the early delivery of even small parts of the solution.

From requirements to design

During the Diagnostic phase, we gathered high-quality information, broke it down into requirements, and mapped with our standard solution by categorizing into standard feature, configuration, customization, ISV solution, and workflow. We refined this understanding during the Analysis phase and rechecked it again with our standard product. This means we can start the Design phase based on structured information that will guide us on what to do next: document and implement.

Document and implement

The following diagram shows what to implement and document:

Coming out of the Diagnostic and Analysis phases, Sure Step does not bring in only the information but also priorities, guidelines, conclusions, and a profound understanding of the to-be-implemented solution. Standard features from the standard or ISV solution can be immediately implemented along with the straightforward configuration requirements. Our implementation team must now start their engines and boost this project into warp drive. Some of the functionalities will need to wait to be installed or configured as they might depend on the customized functionalities. Do not panic about that since we can finalize the implementation later. The good news is that we have delivered part of the solution already, and the first customer complaining about that is still to be found!

Documentation is also part of the game. It is important to have a documented solution design, but we needn't include everything. We do not document the standard features but will concentrate on configuration settings and customized functionality. We useFunctional Design Documents (FDD) to document our configuration and customization outlines. The configuration settings are to be documented in the FDD-FIT, while the customization is documented in the FDD-GAP.

Sure Step also provides a Technical Design Document (TDD), as well as a Solution Design Document (SDD). The TDD is a translation of the FDD-GAP in technical terms. The goal of this document is to define and document the technical details of each system modification or enhancement. This can be an essential component for the upcoming development activities when we are, for instance, working with junior developers or even in an offshore development context.

The purpose of the SDD is to allow the business decision makers and other stakeholders to obtain a clear view of the proposed solution design in business language. This can be a required document in companies with a high organizational complexity. Where the FDD documents are beneficial in all waterfall project types, the SDD is typically used in an Enterprise project type.

The application consultant will work hand-in-hand with the appropriate key user to implement and document. That's why, at this stage, we should provide our key user with some training and coaching on the product's features and functions. This will not only bring our key user to the next level in the knowledge of the product but will also avoid misunderstandings and generate more commitment from the key user. Working closely with the key user will improve the collaboration for both teams, which is absolutely necessary for success.

Initiate testing

Once we have implemented features and functions, we can unleash the power of a critical success factor in every project—testing. Testing will allow us to interact with the key users, identify issues, work and steer the perception, and update business process models. Initiating testing at this stage will also enable our key users to prepare for, organize, and take control over the user tests scheduled in the upcoming project phases. They can start their envisioning process of using the new solution right here. They will understand what testing involves and increase their product knowledge. Well-informed and committed key users are vitally important for project success, but we cannot expect key users to reach our level of knowledge overnight. We need to make sure that they build up their knowledge and understanding in small pieces, so that they are ready when needed. That's why we start here by initiating tests and test scripts in the Design phase. We will start with testing the features and functions that we implemented together with the key user reinforced by the available Sure Step test scripts. After that, the key user can continue to prepare test scripts for upcoming tests.

Because of the commencement of testing activities, we will have issues coming in as well. Again, embrace this, as it is an excellent opportunity to communicate and work around these issues and to plan for corrective actions. This is exactly what we want: revealing the issues now so that we can overcome them instead of saving them for a later stage by not identifying them.

Interact with the infrastructure department

Installing and configuring the core product and organizing tests will also involve elements of infrastructure, namely the test environment. This is a good opportunity to continue to interact with the infrastructure stakeholders. What is needed for all this? What do we need to do to convert the training into a real test environment? We can work hand–in-hand with the infrastructure people, allowing them to get a better understanding of the infrastructural consequences of this new product; the interaction might reveal some new issues or risks as well. As you know, that is exactly what we want as it will allow corrective actions.

Don't give up on data migration

We need to continue our work on data migration that we started in the Analysis phase by designing the migration process and mapping the fields to be migrated between existing legacy systems and the Microsoft Dynamics application. Because we initiate tests in the Design phase, we can create a subset of data for testing here as well.

Start planning the deployment

A good project manager sees beyond today and knows that a well-organized Deployment phase is needed for a successful Go-Live. This project manager also knows that the success of the deployment depends on the commitment of the user organization. At the same time, we need to understand that our deployment activities will lay a heavy burden on that organization. Training, user acceptance tests, performance tests, and infrastructure readiness will demand a lot of their time and effort. We need to inform our customer about this and ask for their commitment and planning, and we need to do this well in advance. The Design phase is well chosen to initiate this. By now, both teams have a very good understanding of what is to come, so we should tackle this right here. Sure Step provides us with a deployment plan that outlines the processes and activities that need to occur during the deployment phase of the project. It will ask for the customer's understanding and commitment for these activities. This is more than just scheduling the deployment. The deployment plan must be an input for your communication around topics such as deployment scope, deployment strategy, deployment resources, training and testing organization, and the deployment schedule. Our goal is to get the customer's buy-in for the deployment activities. The bottom line is not just a document but communication, communication, and again communication.

The Development phase

This is what software companies probably know best: development. It leans most against our business ecosystem of information technology, and therefore we are on home ground. Nothing new under the sun then or is there?

Developers only?

The Development phase is quite often organized as a "developers only" period in time, not infrequently facilitated in the same philosophy. This is where the application consultant's load is reduced significantly, where our development team takes over, and they might even retreat into full isolation at the service provider's premises. Is this the best strategy? It is beyond doubt that the development activities will have a prominent place during this phase. And yes, developers might need to work undisturbed for a while, permitting maximum concentration. But as we have learned from the other phase's organization, there is more to take into consideration.

We need to keep our eyes open for the project life cycle planning and ensure that enough customer interaction and involvement are included as planned. We need to secure our communication levels with all stakeholders and maintain the collaboration between application consultants and key users. Last but not least, we also need to continue to further prepare the customer's infrastructure department for deployment. To conclude, the development force will play a crucial role in this phase, but they should not be the only players in this ball game.

Develop and freeze custom code

The requirements mapped as customization during the Fit-Gap exercises and designed in the FDD-Gap and TDD documents are developed at this stage. This not only includes the functional requirements addressing requested functionalities for the solution but also non-functional requirements such as data migration and interface requirements. The development team needs to start by reviewing the solution and technical design documents, after which they initiate the real development. They should engage in respect to all quality and documentation standards that were approved. In larger development teams, it is also essential that the development work is coordinated by a lead developer. The produced deliverables pass through multiple iterations of unit and function testing. Once successfully passed, the code is frozen to denote that it is not open to modifications any longer. Further modification can be made only if issues are found during data acceptance, process, or integration testing. Do not forget to update the design documentation when the delivered customization differs from the envisioned one.

Complete the testing

Once the customized functionality deliverables are being produced, we can further complete the testing that was initiated in the Design phase. We can now engage by testing more and more full processes, bringing it to the level of full solution testing. You got it right—testing is a cross-phase process that allows us to continue interacting and communicating with our customer throughout the complete project life cycle. It is now time to engage the integration and data acceptance testing. By now, our key users should be quite familiar with the testing procedures, and they are continuously increasing their knowledge of the solution. They will fine-tune the test scripts and can start working on the user acceptance test script necessary to drive the user organization through these tests in the Deployment phase. Thanks to our continued testing effort and collaboration with the user organization, we will collect issues and questions, and we will detect uncertainties and sensitivities within the key user team. It is imperative to work with this information! We need to tackle this right here, ensuring an optimal Deployment phase.

The following diagram illustrates how far we have progressed from the Design phase into the Development phase:

We can also continue the collaboration on the development of test scripts, which we started in the Design phase. Together with the key users, we can now prepare the user acceptance test scripts that will guide User Acceptance Testing (UAT) during the Deployment phase. UAT is the culmination of all the previous testing activities. Although previous test scripts can be leveraged, it is important that the UAT scripts focus on the main functions that system users perform.

Last call for changes

In any project, requests for changes are always on the horizon, no matter how well we have defined our scope or how well we have worked on the organizational change management. In the discussed life cycle planning of Sure Step, we tried to keep interacting with the customer organization to identify issues, risks, and requests for changes in all phases. This gives us the benefit of identifying them early, staggered throughout the project. In this way, we can manage proactively and prevent issues from becoming a true burden in the Deployment phase. In the Development phase, we will still retrieve and manage change requests, but by now, we need to be aware that after this phase, we need to bring the changes to a lower level and our end user organization needs to be aware of this. It is our responsibility as a project manager to sensitize our customer counterparts about this. Another communication challenge!

Can process models still change?

The answer to this question is yes. Because of our planned activities and interactions in the Development phase, we will receive feedback from both customers and consulting stakeholders. Our developers may have critical comments, the application consultants can throw up important insights, and our customer can also raise questions. A typical interaction that can generate this kind of feedback is testing, and as we have discussed, the testing activity is continued during the Development phase. Based on this feedback, we might need to bring in some changes to our solution design or persuade our customer to implement business process changes. Review and update of business process models is a continuous process that should be iterated throughout the project life cycle, with reviews and updates in Design and Development phases.

Start finalizing

It is entirely clear that Sure Step evangelizes good project life cycle planning, and this is again emphasized in the planned activities and deliverables of the Development phase. We have already seen that this phase is not exclusively reserved for the core development activities. Thoughtful readers will also discover that we need to start finalizing the lion's share of the implementation activities during the Development phase. This means that by the end of this phase, we have delivered the bulk of our deliverables, which will allow us to concentrate on the pure-deployment activities in the Deployment phase.

Finalize the system configuration and ISV solution setup

During the Design phase, we started to install and configure the standard feature and ISV functionalities, matching our customer's requirements. We can now complete this configuration effort as customized functionality will become available during this phase. This means we can now also implement and configure the customized features and, at the same time, bring the testing to the solution-testing level, as discussed in the previous section. The solution testing will inevitably cause configuration changes, and, after this process, we can freeze our configuration settings for the new solution.

Finalize design updates

Because of identified issues, changes, and updated business process models, we must update our appropriate design documentation as well.

Hand over non-production environments

The purpose of this task is to hand over the non-production environments to the customer's infrastructure team and ensure their readiness to accept and support them. This will allow us to interact with the infrastructure resources and build up their knowledge around infrastructure topics for the new solution.

The following diagram will complete our overview picture of the Development phase:

At the end of the Development phase, we can checkmark the following as complete:

· Customized development

· Solution testing

· Configuration and setup of standard and ISV solutions

· Design documentation

· Test script creation

This will allow us to concentrate fully on deployment activities in the Deployment phase. What five-star project life cycle planning!

The Deployment phase

Some consider the Deployment phase as the tail end of the project life cycle, while for others, it seems that they still need to start most of the implementation activities in this phase by starting the configuration and testing of the product. Then what have they done up until now? Deployment is a critical process in delivering a successful project. It involves preparing the transition to the operational use of a brand-new solution for the entire company. That's quite something!

Let's discover the critical activities for this phase.

What is critical for a successful deployment?

There is no question that infrastructure and solution readiness are the basis of a good deployment, but they only represent "half way there". The other half, even the bigger half, is the organizational readiness of the customer. Is there a supporting coalition within the user organization for this new solution? Can the key user organization see and appreciate the benefits of this new solution, and can they balance this with the efforts and difficulties that they experienced? Can they put the existing criticism and resistance into perspective? Can they envision the next steps and challenges? These are all important questions that any project manager must reflect on during the transition to deployment. The answers to these questions will guide us on how to organize the Deployment phase and where to put the emphasis. This must be our focus point during deployment.

Trainers' evangelists for change

Adequate training is one of the most important steps in a successful implementation. Making the users much more efficient in their daily jobs is a key objective that you will find in any business solution implementation project. For that reason only, users need to have strong knowledge of and insights into the product. But effective training will not only empower the users with the necessary knowledge on how to use this system in their daily company procedures, it will also orient their perception and trust in something that is new to them. For a majority of users, this can be their first encounter with this brand-new solution, and you only get a single chance to make a good first impression. For all of these good reasons, we need to plan sufficient training and resist the temptation to reduce this to a minimal level in order to cut costs.

Conduct end user training

Sure Step envisions the training for end users during deployment as short, directed sessions that begin with a broad overview and narrow successively to the end users' defined job tasks. Training scenarios must be role-based so that each user can work through the specific activities and tasks required by their daily job. It may be necessary to start each session with a Business Process (to-be) training session to ensure that all end users have adequate knowledge of the new processes.

A critical success factor is that the final task-oriented training is scheduled as close to the deployment as possible in order to prevent knowledge erosion.

Compose the trainer team

This training can be conducted by customer key users, trainers, or consultants of the consulting implementation team, or by an external third-party training vendor. It will most likely be a mixture as finding one trainer to do it all will not be so easy. Involving key users in the delivery of training for their departments is a wise thing to do. Key users know the end users much better, have strong knowledge on the business processes, and are strongly connected to the product and reinforced by their management. As such, they can evangelize the new solution and its inevitable change much better than any outside trainers. However, we need to make sure they have the proper product knowledge and a well-organized approach.

That's why we need to provide them with a train-the-trainer session beforehand. Some areas in our solution might require high-level expertise of the trainer, and therefore, it might be necessary to deploy specialized trainers from the consulting or learning organizations.

What about the data?

By now, all data migration design, development, and testing is finalized. We will need the data migration execution for training, testing, and deployment reasons. The end user training will need test data that simulates true use-case scenarios. The user acceptance tests also need actual transactions, from a day identified by the customer, which would provide a good sample of their business. So, for both activities, we need to migrate data that, in a way, will prepare us as well for the final data migration to the production environment supporting the deployment.

Sure Step recommends that the final migration is done in two steps:

· Initial migration of data into production: The initial migration of data into production is performed to avoid overloading the systems and is typically done a week before the actual Go-Live. This data typically includes static data.

· Final data migration into production: The final data migration is preferably done over the weekend prior to Go-Live. As most of the initial data is loaded a week before Go-Live, the final data load will take into account the data entered into the system after the initial data load. This concept expedites the migration process and eliminates last-minute glitches that can jeopardize the cutover.

The Go-Live as the user acceptance test

You might not believe it, but in some cases, Go-Live procedures are initiated without a prior user-acceptance test. The most common excuse is "we told the customer to test, but they didn't". You might even find cases where the UAT was used to compensate time and budget overloads of previous phases. In a scenario lacking a UAT, Go-Live will function as a user acceptance test, and the results of that Go-Live are highly predictable.

Do not forget the important goals that a UAT fulfills:

· Validating that the new solution supports the company's operational processes as envisioned through the requirements process

· Gaining the necessary confidence in the system by mitigating the risk of failure

· A last chance of identifying issues that had a lucky escape during previous test cycles

· Motivating the Go-Live decision

· Obtaining system sign-off

· Generating results that will support the project closure process

Your continued key user interaction will now pay off

We have learned through the sections on the previous phases how important it is to schedule interactions with the key users in all implementation phases. The cross-phase processes and the planning of these throughout the project life cycle is a crucial element within Sure Step. When it comes to UAT, we will really reap the benefits of this strategy. Our key users were connected with the product throughout the complete project life cycle. They built up their knowledge and perception of our product in small steps by being involved, trained, and coached in each phase. Being involved with testing in the previous phases has led to an understanding of the process and importance of testing. By now, they are really ready to support you in the organization and execution of UAT.

Can you imagine key users who were disconnected after the analysis for months and are only getting some training now? Just asking a user organization to perform UAT on a system that they barely know doesn't make much sense.

Early planning and commitment making the difference

UAT represents a serious load on the resource planning of the customer organization. A substantial number of the customer's employees need to free up time for both training and user acceptance testing. Nevertheless, this company is still in operational mode, and so their absence needs to be carefully planned in advance! It is also critical that the customer is really committed to investing in this effort, and therefore, they also need to be motivated in advance. Without early planning and real commitment, we will run into trouble and the no time, will do it later excuse will smack our ears. The good news is that we did create the deployment plan in collaboration with the customer already in the Design phase. At least when we did it the Sure Step way!

The focus of the user acceptance test

UAT must focus on testing the complete end-to-end system to ensure that the new solution meets the customer business requirements. The focus of the test scenarios is the daily routines of the users in the different departments, supporting the operational use after Go-Live. We are not testing one requirement after the other, but instead are testing real-life business processes based on real-life data. These tests must also demonstrate that the users can use the system properly.

Document and analyze the results

The testing results need to be compiled, analyzed, and subsequently compared to the test criteria. Sure Step provides efficient UAT test script worksheets and templates. These tools are made product-specific, including even role-based versions. They also can contain some preconfigured testing scenarios.

The following screenshot gives an example of a product-specific UAT test worksheet, including product-specific test content:

Execute performance tests

Many variables can interact to impact system performance. There may be a large number of users, a large number of transactions, improperly configured infrastructure, or environment variables; there are many other elements that can also impact the performance. We need to scrutinize performance before and after Go-Live. Therefore, scheduling performance tests at this stage is no luxury.

Infrastructure readiness

At this stage, we need to ensure that we will be able to run our new solution in a stable and performing environment during and after Go-Live. That's why we need to continue our infrastructure effort during the Deployment phase by building and configuring the production and disaster recovery environments.

The following figure lists the possible environments that can be initialized:

Check and cross-check

Flight attendants, please prepare for cross-check. Are you familiar with these words? A cross-check is a procedure performed by flight attendants before a plane pushes away from the gate and again when the plane lands. This procedure of checking the doors for having been armed with emergency escape slides is only one of the series of checks to ensure that a plane can taxi, depart, and land safely. This ensures safety and quality service as expected by the customers.

When we prepare for Go-Live, we should execute some checks as well. Delays and crashes will not make a great impression in our business either. That's why we need to assess final system readiness and ensure that all necessary steps and deliverables are in place. The Sure Step Go-Live checklist can be a valuable instrument to help us complete that procedure in collaboration with the customer.

Ready to take off

Go-Live initiates the successful processing of daily business transactions and activities in the new system. It took time, effort, sweat, tears, meetings, e-mails, interactions, and especially a lot of hard and intelligent work to get to this point. This is our takeoff both for the customer organization and the consulting team; a precious moment but not without danger if badly planned. As with any departure, we need to stay focused and prepare for some potential turbulence. To make the Go-Live cutover successful, we need to plan and document our cutover procedures. We might even need to run the cutover process as a dress rehearsal. The Go-Live cutover plan provided by Sure Step can help us in doing so. Re-using the deployment plan with a separate section on the cutover processes might be valuable as well.

And once in the sky, clap your hands and pop those corks because this really is an achievement! Celebrating this special moment together with your customer is not only fun, but it reinforces the feeling of success for both teams. Well deserved, enjoy!

The Operation phase

Pack your bags? Not really. Go-Live broadcasted our project live in the air but our show is not over yet. Go-Live is not the end of the project. It is time now for some on-board services.

Provide post-Go-Live support

After the Go-Live cutover moment, critical challenges unfold for the end user organization. They now really need to give up on their old and familiar routines and adapt to new procedures and software features and functions—not an easy moment for them, and they need our support. Imagine somebody stepping into your office and providing you a brand-new computer stuffed with unfamiliar programs. How would that feel? Just knowing that experts are there to address their questions and concerns is a comfortable thought and will avoid any case of panic. Quality onsite support will also allow us to advise the key users on how to address specific issues and the support role in general. A good key user team will also filter various support requests. During the longer duration of the post Go-Live support, the consulting organization can also switch from onsite to remote support, making the consultants available through live meeting, phone, or e-mail communications. This step requires a mature key user organization that is able to control the bulk of the support requests—another good reason for investing time and effort in the key users throughout the project life cycle.

Assuming that you will no longer collect issues and changes at this stage is like backing the wrong horse. The first days or even weeks of operational use of the new system will produce a lot of issues and change requests. These should be managed by using the same process as in the previous phases. However, we need to be perceptive of the fact that a vast amount of the complaints, issues, and change requests might be caused by resistance, fear, and other challenges to change. That's why we might consider additional communication and training to assist the customer through the reality of change.

Some things to do

The off-the-shelf benefit of having an Operation phase in the methodology is that it enables us to communicate some important things to our customer before and during the project. It makes clear that we will stay after the Go-Live, because we still have some things to take care of.

Clear pending items

One of these things is resolving open issues. These issues might have been identified even before the Go-Live cutover moment but remained unaddressed until after Go-Live. We will always have issues at the moment of Go-Live, and this cannot be a reason for postponing Go-Live unless these issues are really critical and considered to be showstoppers. Making customers aware about this before you reach that point is a smart thing, and Sure Step will help you in doing so.

So now we have reached that moment where some things have to be performed in the Operation phase. This activity can be found in Sure Step as Clear pending Items, indicating that we need to collaborate with the customer in finding a final resolution to our open issues. In most cases, not all issues are resolved as some have no impact on the business operations. This is an effort of communication and negotiation to ensure satisfaction on both sides. "Don't park your common sense outside" is the message.

Finalize knowledge transfer

We need to ensure that before we leave, the customer will have access to all important resources enabling them to take over control. They need to know the locations where all of the documents reside, security permission documentation needs to be available for the administrator, actual support information and logs need to be transferred to the customer support team, and they need to know how to log in to CustomerSource (name of a Microsoft portal).

Conduct performance tuning and optimization

Once our solution is operational for a few days, it is time to measure the performance and to provide additional tuning and configuration. Real performance bottlenecks might reveal themselves only after Go-Live. It is smarter to do this proactively at this stage rather than waiting for the performance to drop to an unacceptable level, where users start complaining about the performance of the solution.

Transition the solution to support

The time has come to say goodbye. The implementing consultants cannot remain onsite forever, and the customer organization needs to take responsibility for their new solution. They can organize the support entirely by themselves or use the operational supporting services of the partner.

To close or not to close

To close! Projects are, by definition, temporary, and so they need an ending date. A formal closing is an essential component of project management. Without closing, we end up in an operation for which we are not organized and do not have sufficient budget. Not closing our project will, in the end, evaporate all of our profit for which we worked so hard.

Closing – a nice little job?

We wish it was, but unfortunately we all know better. Closing is where it all comes together, and when we say all, it means all. How good were our project communications? How strong was our project culture? What quality did we deliver? What time and cost performance did we achieve? Was our Statement of Work (SOW) any good? What is the status of our relationship with the customer at this point? Was our project management effective? Is the customer familiar with sign-off procedures by now?

Building it up

Project closure is something that you build up in pieces by working on it throughout the project life cycle. Closing phases by means of Tollgate Reviews reports, signing of important deliverables, project status reporting, steering committee meetings, and formal testing results will only make your case stronger. There is a large bridge to cross when trying to get a sign-off, which now represents the first sign-off attempt since the approval of the SOW. We, as project managers, need to understand that project closure is an essential task of our job and that it does not come as a free lunch. We need to work towards closure throughout the process.

The core challenge

The core challenge of closing is the review of the deliverables against the SOW. We need to prove that we delivered what we promised to deliver in the SOW, and that might be a hard job when the deliverables were not specified in the SOW. This again stresses the importance of deliverable thinking against activity thinking. SOWs stuffed with activities will be hard to compare with what was delivered and will open the doors for long and exhausting discussions. Buying something that can drive refers to which kind of car? Hard to tell, right?

Sign please!

Yes, you need to have a formal sign-off representing the end of this project. To achieve this, we must communicate well in advance and organize a formal meeting with a fixed agenda, ideally attended by the project managers, executive stakeholders, and sponsors. With the formal signature, our flight has come to an end. We can now disembark the plane and celebrate our successful journey.

The Agile Implementation project type

In the previous section, we discussed the options for the waterfall approach in Sure Step at length. We now turn to the Agile approach, which as we noted earlier, represents an iterative solution development method that promotes a collaborative process between the resources that own and specify the requirements for the solution and the resources responsible for the development and rollout of the solution.

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 evolve 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-hand side navigation tree view and the methodology pane on the right-hand side 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. 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.

The Agile project type begins with a set of activities that constitute the Agile Preparation phase. Beginning with a project kickoff activity, Agile Preparation culminates with the achievement of its primary goal—the creation of Initial Solution Backlog. This backlog represents the initial subset of the requirements for the solution, which will be used to begin the development process in the next phase.

The Agile Execution phase follows the Agile Preparation. This phase is highlighted by the two sprint cycles. The sprint cycle, which is also referred to as scrum, denotes a time period up to four weeks in duration in which the team executes the development of the solution on an identified set of backlog items. The Sure Step Agile project type has two sprint cycles—a Daily Sprint cycle that is encompassed within a 30-Day Sprint cycle (as seen in the preceding screenshot). The development activities are carried out on a daily basis, including planning, analyzing, designing, developing, and testing. These activities are performed against the Sprint Backlog, which is a compiled list of requirements from the Solution Backlog that is broken down into smaller increments of product features. The requirements in the Sprint Backlog are then further broken down into manageable tasks during a Sprint Planning Meeting.

At the end of a Sprint Cycle is a Sprint Technical Preview activity, during which the implementer and customer teams review the developed solution for the requirements. This is a critical activity wherein the requirements are approved, or rejected, and fed back into the Solution Backlog for possible inclusion in a future Sprint Cycle. A Sprint Post Mortem is also conducted to evaluate the team's performance and discuss any opportunities for improvement. After the final Sprint cycle, an overall solution testing is performed, and the specification for the customer's production environment is finalized.

At the culmination of the Agile Execution phase, the solution then moves to the corresponding activities in the Deployment and Operation phases, including User Training and UAT. These activities were discussed in the The Sure Step waterfall implementation phases section. These two phases and activities also signify a shift from the classic Agile approach to a blended approach from business applications solution delivery.

The typical usage scenarios for the Agile project type include the following:

· The selected Microsoft Dynamics solution has a fair Degree of Fit—around 50 to 75 percent—with the customer's requirements. The customizations required to fashion the solution to meet the customer's solution vision are expected to be medium-to-complex in nature so that the development efforts can be encapsulated within the sprint cycles. Also, the envisioned solution may or may not include an ISV solution in addition to the core Microsoft Dynamics solution.

· Custom code development may encompass integration or interfaces to third-party sources as well as migration of data from legacy or third-party systems to the envisioned solution. Again, it is suggested that these coding efforts are not overly complex.

· Business process analysis activities and OCM activities may be included in the scope of the engagement. These activities will be executed in parallel with the development activities in the Agile project type.

· The Agile project type is typically applicable to single-site implementations, but it may be extended to smaller multisite engagements with about three locations.

The usage of the Agile project type requires a very disciplined approach by the project teams to control the overall scope of the project and manage it to fruition. It is highly recommended that organizations that choose this approach have experienced Scrum Masters or Sprint Cycle Managers—individuals well versed with the Agile discipline.

Similar to the Standard project type, the customer organizations using the Agile project type should also have business and IT users with multiple years of experience in deploying and using business solutions. It is also important that the experienced users are selected to be part of the solution delivery team and that they actively support the service provider during the implementation.

The Agile project type can also be used for the development of the pilot solution for multisite deployments. Such solution rollout usage scenarios are described in an earlier section titled Setting up a program for solution rollout.

In the following section, we will describe a few use cases of the Agile, Rapid, and Enterprise project types.

Use case: Agile project type for a multinational chemicals customer

After going through their due diligence, a chemical manufacturer selected Microsoft Dynamics CRM as their solution. The customer selected the Microsoft Dynamics CRM solution for the ability to use it as a platform and to use the Extended CRM or xRM capabilities as a starting point to build a solution catered to their specific needs.

As the customer and implementation partner worked through the requirements for the solution, they felt that while they had a good understanding of the overall needs, they were likely to unearth additional use cases for the solution during the development cycle. Both the customer and partner had past experience in a sprint cycle-based solution development approach and had experienced project managers to manage the solution delivery with an iterative approach. Accordingly, they decided that the Agile project type afforded them the best approach to tailor their solution delivery.

The SOW was structured to include nine monthly sprint cycles for the first release of the solution. The solution requirements constituted the initial Solution Backlog and became the starting point for the determination of the Sprint Backlog.

Use case: Rapid project type for a GP customer

A distributor in the small-to-medium Enterprise segment selected the Microsoft Dynamics GP solution to support their financial needs. The customer was using an old, unsupported ERP solution that was unable to meet their growth and additional user requirements for the system. The company decided to work with a Gold-certified Microsoft Dynamics GP partner to quickly install a limited solution for financial reporting, customer and receivables aging, and vendor and payables tracking.

The partner used the Fixed Scope Proposal and Statements of Work provided in Sure Step (refer to the next screenshot) as a starting template, and catered the engagement accordingly.

The implementation was structured using the Rapid project type and included specific activities for solution design, installation, configuration, and data conversion. Also included was a Conference Room Pilot (CRP) activity, which afforded the users a preview of the upcoming solution and the chance to review the solution configuration to ensure that it met the proposed design.

Use case: Enterprise project type usage by a global advertising organization

A global advertising organization found itself unable to meet increasing customer demand for detailed information due to its antiquated financial management application. Seeking to improve its financial reporting capabilities, the company decided on Microsoft Dynamics AX as a best-in-class financial management software as it had scalability and localization capabilities (both language and statutory) required for their global organization.

Due to the scale of the solution delivery, the customer needed an implementation partner that had a global presence capable of understanding local requirements, languages, and laws. The customer selected Microsoft Services and its Microsoft Global Solutions India (MGSI) group to work with their own corporate project team in order to develop and deploy the solution across multiple locations.

Using the Sure Step Enterprise project type and guidance, the teams worked together to gather the functional requirements for the solution and design the solution. The customer was impressed with the delivery approach, leading their VP and Corporate Controller to remark:

The Microsoft Services consultants who worked with us on our implementation knew the product inside out. The project management methodology used by the consultants minimized scope creep, which is very common for major system implementations, enabling us to finish on time and within budget.

Over 30 agencies were already using Microsoft Dynamics AX as of this writing, with more deployments in the offing. The company also runs an internally-hosted solution of Microsoft Dynamics AX to support its smaller agencies. The implementation approach provided the basis for this successful delivery. The customer's global program manager added:

Sure Step is a well-thought-out and flexible methodology that allows us to present a consistent plan and approach tailored to our global strategy. It helps with resource planning for deployments, provides ongoing financial status of each deployment, and gives us the ability to set expectations of required staff time commitment.

Summary

In this chapter, we focused on the project life cycle planning in Sure Step and talked about Waterfall and Agile project types, cross-phase processes, and how to set up solution rollout programs. We learned that Sure Step truly helps in engaging smart projects as it enables us through intelligent life cycle planning to be proactive, goal driven, efficient, and flexible at the same time. Sure Step taught us that we need to be flexible in our approach to the needs of the project, instead of deploying the same approach on all of our projects, while also keeping an eye on continuous interactions with the customer stakeholders.

As a quick reference, the following project types afford you the required flexibility in solution delivery:

· The Rapid project type is designed for out-of-the-box implementations of the Microsoft Dynamics solution with zero or minimal customizations of the standard solution.

· The Sure Step Standard project type is suitable for a majority of Microsoft Dynamics projects and is typically used for medium-scale, single-site implementations that require a moderate number of customizations and add-on solutions.

· The Enterprise project type is designed for large-scale engagements with complex requirements and solution scenarios that necessitate deep governance and oversight.

· The Agile project type represents an iterative solution development method that promotes a collaborative process for the development and rollout of the solution.

· Sure Step also includes a waterfall-based upgrade project type, which will be covered in a later chapter.

In the next chapter, we will learn about essential quality assurance and control principles supported by Sure Step. The next chapter will also provide an introduction to the optimization offerings.