Microsoft Dynamics Sure Step 2010

The 2010 calendar year began with the global economy trying to crawl out of a recession. Still, businesses continued to invest in solutions, to leverage the power of information technology to drive down redundancy and waste in their internal processes. This was captured in a study by Gartner of the top industry CIOs, published in their annual report titled Gartner Perspective: IT Spending 2010. In spite of the recessionary pressures, organizations continued to list improving business processes, reducing costs, better use of information, and improving workforce effectiveness as their priorities for IT spending.

The Gartner study listed the following top 10 business priorities based on 2009 findings:

The Gartner study listed the following top 10 technology priorities based on 2009 findings:

These are also some of the many reasons that companies, regardless of scale, implement ERP and CRM software, which again is evident from the top 10 technology priorities of the CIOs listed above. These demands, however, happen to be articulated even more strongly by small and medium businesses. For these businesses, an ERP/CRM solution can be a sizable percentage of their overall expense outlay, so they have to be especially vigilant about their spending—they just can't afford time and cost overruns as are sometimes visible in the Enterprise market. At the same time, the deployment of rich functionality software must realize a significant and clear advantage for their business. These trends are picked up and addressed by the IT vendors, who are constantly seeking and exploring new technological ingredients to address the Small-to-Medium Enterprise market demands.

Having a predictable and reliable methodology is important for both the service provider (the implementer) and the users of the solution (the customer). This is especially true for ERP/CRM solution deployment, which can happen at intervals of anywhere from a couple of months to a couple of years, and the implementation team often comprises multiple individuals from the service provider and the customer. Therefore, it is very important that all the individuals are working off the same sheet of music, so to speak.

Methodology can be defined as:

The methods, rules, and hypothesis employed by, and the theory behind a given discipline

or

The systematic study of the methods and processes applied within the discipline over time

Methodology can also be described as a collection of theories, concepts, and processes pertaining to a specific discipline or field. Rather than just a compilation of methods, methodology refers to the scientific method and the rationale behind it, as well as the assumptions underlying the definitions and components of the method.

The definitions we just saw are particularly relevant to the design/architecture of a methodology for ERP/CRM and business solutions. For these solutions, the methodology should not just provide the processes, but it should also provide a connection to the various disciplines and roles that are involved in the execution of the methodology. It should provide detailed guidance and assumptions for each of the components, so that the consumers of the methodology can discern to what extent they will need to employ all or certain aspects of it on a given engagement.

As such, a solid approach provides more than just a set of processes for solution deployment. For the service provider, a viable methodology can provide:

For the customer, a viable methodology can provide:

In addition to the points listed here, having a "full lifecycle methodology" provides additional benefits in the sales-to-implementation continuum.

The benefits for the service providers include:

The benefits for the customers include:

In summary, a good methodology creates a better overall ecosystem for the organizations. The points noted in the earlier lists are an indication of some of the ways that the benefits are manifested; as you leverage methodologies in your own organization, you may realize other benefits as well.

Business solutions delivery in general, and ERP/CRM consulting specifically, is very different from deploying other solutions such as an e-mail system. It goes without saying that e-mail communications are extremely important for companies in today's environment. Yet, a company could function for a foreseeable period without e-mail —people may actually have to resort to what now seems to be an archaic form of communication and pick up a phone to talk to other parties. As humorous as it may seem, it wouldn't be far from reality, and some employees would argue that their efficiencies may actually increase during that e-mail downtime as they are actually able to focus on their core job requirements.

In contrast to infrastructure solutions, ERP systems specifically, and CRM systems to an extent, form the backbone of the company. These systems support core functions such as quote-to-order entry, order fulfillment, receipts and payments, HR and payroll, inventory management, distribution/production planning, demand forecasting, and sales pipeline management, among other things. A company would be crippled if these systems were down for a long period of time. This is why, depending on the usage scenario, ERP/CRM systems are typically perceived as mission-critical systems, while infrastructure systems are most often seen as business-critical systems.

This is also the reason that customers take a long time to do the necessary due diligence before selecting the right solution to meet their needs. Given this criticality, it is easy to see how having a methodology that goes beyond solution delivery to help customers with their selection process can be perceived as beneficial by the customer. It is also why customers should go through the due diligence in selecting their solution provider or implementer as they do on the business application itself. It is critical that the solution provider follows a robust process as evidenced by the methodology that they employ, both in helping the customer select the right solution to meet their needs and in delivering the envisioned solution.

During the customer's selection/due diligence process, it is important that they are guided through their requirements gathering process, including understanding their current ("as-is") and future ("to-be") processes. Then the customer should be able to ascertain how each of the requirements fits within the proposed solution. Additionally, the customer should be able to determine all infrastructure components (hardware and any third-party software), as well as the release schedule (overall plan with resource needs from both the consulting and customer organization). The key output of the due diligence phase should be a solution blueprint that articulates the proposed solution for the customer, as well as a statement of work that explains how the solution blueprint will be executed.

From a solution delivery perspective, ERP/CRM engagements are also considerably different compared to an infrastructure project. The following illustration depicts some of the products in the Microsoft portfolio. As you go from left to right in this spectrum, the projected solution delivery effort as well as complexity increases exponentially.

The key point in this graphical representation is that ERP/CRM solutions, on an average, require a level of customization that is far more than the typical infrastructure solutions. This is expected as these solutions are applied to multiple workflows within organizations in many different industries and verticals. As the customization need increases, so does the effort and complexity. This is not to say that all infrastructure projects will be straight off-the-shelf solutions, or that all ERP/CRM projects will be highly customized solutions. Any solution will have a range of complexity, from a quick, rapid deployment, to a longer, complex solution development and deployment. The point of emphasis is that this greater complexity implies a greater need for having an implementation methodology that ensures appropriate project and quality management during the solution delivery process. This is also what Sure Step delivers, which we will introduce in the next section.

In the previous section, we discussed the criticality of having a solid approach for selecting and deploying ERP/CRM solutions. This is exactly where Sure Step fits in—as a method and process for customers and service providers alike. We will introduce Sure Step in this section, and in the rest of the book will talk about how it is designed to deliver on these promises to an organization.

Microsoft Dynamics Sure Step is a full customer lifecycle methodology for all Microsoft Dynamics® solutions. It provides service providers with comprehensive sales through delivery guidance, project management discipline alignment, and field-driven best practices, while facilitating the due diligence process and a high-quality solution delivery for the customer.

The first release of Sure Step was launched in 2007, and since then Sure Step has evolved to meet the demands of the Microsoft Dynamics ecosystem. Existing workflows have been modified and streamlined and new ones introduced. The methodology has also been expanded into a full lifecycle methodology that includes the customer's due diligence lifecycle as a precursor to the solution delivery process. Also, more content is being made available to the users, with the current release providing over a thousand content pieces, from guidance pages to templates to general project management libraries. The following are key characteristics of Sure Step, including some of the highlights of the Sure Step 2010 release.

As discussed in the previous section, Sure Step covers the entire Microsoft Dynamics portfolio of solutions. In this section, we will provide an overview of those solutions, which is mainly intended to be a quick reference, or as a starting point for those readers who may not be familiar with all the solutions in the portfolio.

Microsoft Dynamics is Microsoft's line of business management solutions that provide Enterprise Resource Planning and Customer Relationship Management capabilities. The portfolio includes four ERP solutions, which were brought about by acquisition, and one CRM solution, the development of which was initiated in Microsoft.

Microsoft Dynamics GP (formerly known as Great Plains), and Microsoft Dynamics SL (formerly known as Solomon), were both acquired in 2001 from Great Plains Software, based in Fargo, North Dakota, USA. Great Plains was a mid-market business accounting software package popular in North America, while Solomon provided an ERP system with project management and project accounting functionality. Microsoft Dynamics AX (formerly known as Axapta), and Microsoft Dynamics NAV (formerly known as Navision), were both acquired in 2002 from Navision A/S, a company based in Denmark. Axapta and Navision were popular ERP solutions, especially for manufacturing and distribution midmarket companies in Europe. The ERP systems became the starting point for a new division in Microsoft called Microsoft Business Solutions, which also included Microsoft CRM. Microsoft CRM was primarily homegrown as noted earlier, and had its first launch (version 1.0) in 2003.

In 2005, Microsoft rebranded the products and created a suite of business solutions called Microsoft Dynamics. It includes the four ERP solutions—Microsoft Dynamics AX, Microsoft Dynamics GP, Microsoft Dynamics NAV, and Microsoft Dynamics SL—and one CRM solution—Microsoft Dynamics CRM. Microsoft SQL Server is the database technology used for the entire suite. The following diagram depicts the timeline:

The Microsoft Dynamics solutions have been designed to be familiar to users, work easily with the existing systems that customers have already deployed, empower people and teams to be productive, and help organizations drive business success. The ERP suite provides functionality to help business in the areas of financial planning and accounting, supply chain, project accounting, field service, and human resources processes. On the other hand, the CRM solution allows companies to streamline the way their employees communicate and collaborate with their customers with features such as customer relationship, sales force automation, service management, marketing capabilities, and workflow automation and analytics.

In addition to the comprehensive financial and process management tools at the core of the Microsoft Dynamics solutions, Independent Software Vendor (ISV) partners offer a number of integrated, specialized solutions that provide versatile business software that address specialized industry needs.

The Microsoft Dynamics solution features (as of this writing) are as follows:

It looks like a simple question, but have we ever thought about what is essential to our business? Before we can start strategizing on how to manage and sell projects, we need to understand what a project is and, even more important, what it is not.

Most people respond to the question by talking about activities, planning, and meetings, due dates, documents, people, and objectives. This is how many of us think of a project, but can we call all engagements where people try to reach objectives by means of planned activities projects? Probably not. For example, in the production plants of automotive companies, people realize objectives and collaborate on planned activities, but we wouldn't classify those as projects.

Before we can speak about a project, we need to be certain about the unique and temporary character of our endeavor. Projects are temporary by definition, as they have well-defined start and end dates. Most of us are well informed about the starting date of our project; the end date can be more of a worry and is often confused with the go-live date of the brand-new software solution. Projects are also unique by nature—not only because they produce unique deliverables but also because the context for the execution is unique. Unique can mean that it has never been done before, or maybe it has been done in a very similar fashion before but never exactly in this way. Therefore, no two projects, by definition, can be the same.

In most of the definitions of a project that we can find in literature, these key elements are well absorbed.

The Project Management Body of Knowledge (PMBOK) defines a project as a temporary endeavor undertaken to create a unique product, service or result. The temporary nature of projects indicates a definite beginning and end. The end is reached when the project's objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists.

By implementing Microsoft Dynamics solutions, we implement ERP or CRM software functionality, and from a product's point of view, many of these implementations are lookalikes. Then what makes these implementations unique?

Although we are implementing typical ERP or CRM functionalities, we need to implement unique business requirements for each customer. Every customer has unique demands for specific deliverables, such as internal reports and customized functionality, matching their unique organization of the business processes. But even more important to note is the fact that people make these implementations unique. Implementing the solution in a customer context is always unique because we are always working with different people. They always have a different background, knowledge level, expectations, goals, and their own unique way of working. We also work with changing consulting implementation teams, based on the availability of our consultants, resulting in a unique context. So yes, the Microsoft Dynamics implementations are projects because they are unique and they are meant to be temporary. We always need to deliver our projects in a limited timeframe and our engagements are never the same. However, this involves a lot of uncertainty and so our Microsoft Dynamics engagements are characterized by uncertainty going hand in hand with risk (in ISO 31000:2009 risk is defined as the effect of uncertainty on objectives).

Now that we have understood what a project is, we also need to understand what it is not. A project is not ongoing and repetitive; projects are not operations. Businesses driven by ongoing repetitive processes carry less risk because the context is much more controlled. In our projects, we do not have such controlled environments. We simply don't know who our key as well as end users will be and we also don't know how familiar they are with business processes and business solutions. We do not know how well they communicate and how they perform in teams. There is so much that we don't know when planning a new engagement.

What matters is to be aware of these risks and to be aware that the business we are in is completely different as compared to an operations-driven business. Only then we can really start strategizing on how to manage and sell projects. Therefore, we should review our future proposals and plans, bearing in mind that we are planning for a project, which ultimately means planning for risks. How well are these plans and strategies covering the uncertainties?

Most definitions of a project in literature include these elements of the unique and temporary character but do not outreach them. There are also few other questions that need to be answered:

Isn't it equally important to gain an understanding of the contractual and commercial matters:

The answers to these questions prescribe and justify how we will sell and manage our projects. Just outsourcing resources to carry out project tasks does not call for the same management as carrying all project risks in a fixed-price project.

Ask any software vendor for their definition of a business solution and you will receive answers focusing on functionality designed to help automate business processes, empowering every aspect of the business, and ultimately accelerating an organization's success. Words such as insight, efficiency, flexibility, cost reduction, responsiveness, and many more are used to voice proven return on investment.

But what answers would you get when you pose the same questions to the customers? The first thing that you will notice is that the answers will not be so consistent. Most decision makers do have their own reasons why they want to have a software solution in their organization. What they want to achieve is related to the unique history of that company, their incomparable way of doing things, and the industry sector to which they belong. Their objectives also have a direct link with the company's business plan and strategic objectives. This means a customer's definition of a business solution is never universal but always specific.

Although business solutions are designed to achieve the same results within organizations, customers usually seek for very specific solutions for resolving their unique problems and supporting the business challenges as envisioned by them. No matter how rich the functionality of the solution is, unique customer's expectations cannot just be delivered off the shelf. This gap needs to be bridged by the implementation process.

One might think that implementing business solutions in small and mid-sized companies is less complex compared to the large-scaled implementations in corporations. Be careful not to jump to conclusions here. In general, business processes are less standardized in these types of businesses. Instead, you will find a rich and interesting variety of procedures representing the unique way of doing things. This makes the need for a unique business solution even greater and demands a streamlined implementation process.

By now, you will have understood that the implementation process is a key part of the overall solution. But before you march into your customer's premises to start implementing, it could be wise to give some thought to the meaning of all this for your customer. Imagine yourself in your customer's situation and don't take things for granted. How will your implementation strategy affect this organization? Can they conceive what an implementation process is, and even more important, what added value it means for them? Are they aware of the risks, and do they know that it needs both parties to work together to implement a project successfully? Are they aware what their role would be?

Business solution implementations are rife with challenges. Even consultants, who have been delivering these solutions for a number of years, run into issues on projects that they may not have previously encountered. No matter the years of training and shadowing experienced colleagues, unique challenges are bound to come up. Having this in mind, it is not surprising that our customers sometimes cannot estimate the level of effort that they need to put into this implementation and that they are not aware of the importance of their involvement. It is then important for the consulting teams to make sure the customer understands their expectations in the overall solution delivery process.

Technology Evaluation Centers (TEC) is a research organization that has several publications on ERP/CRM solutions. In their research whitepaper titled 5 Tips to Assure a Successful ERP Implementation, they bring up some key points for the customer's implementation team.

Management buy-in is also considered one of the keys to successful implementations. TEC believes that it is essential that corporate management is actively involved in the system selection decision by naming an executive sponsor who participates and provides the necessary support for the project. A senior management sponsor to champion the expected organizational change is highlighted as "a critical, must-have step" for successful implementations.

Ensuring the participation of a cross-functional team is another key to success noted by TEC. A team comprised of all functional divisions and management levels within the organization facilitates active ownership of the project by the entire user community. This also ensures that the implementation team will be able to reflect the requirements of the users, thereby maximizing the value delivered by the solution.

These are good points for the customer team to keep in mind, so that they understand their responsibilities for implementing the solution. As the next section will illustrate, teams that ignore these lessons do so at their own peril.

Over the years, most of the reports on CRM and ERP implementations endorsed the existence of gaps between customer expectations and actual results. The studies also pointed out that time and cost performance still remain an undeniable point for improvement.

You need to be careful while interpreting these statistics. Most studies do not measure exactly the same things, they have different types of respondents, and the methodological approach may vary as well.

In the early nineties, Standish's Chaos Report shocked the industry, when it reported a 16 percent success factor on software development projects. The same report called 53 percent of the projects to be challenged on implementation, and 31 percent to have failed. Although considered to be controversial, this report managed to attract worldwide attention for solution delivery issues.

About sixteen years later, we still have Chaos Reports, now accompanied by many others. The 2009 statistics of the Chaos Report showed 32 percent success, 24 percent failure, and 44 percent projects to be challenged. Investigations of other research companies show slightly better statistics; however, they all conclude that there is still opportunity for improvement as most of our ERP and CRM projects take longer and cost more than expected.

While these facts and figures may shed a poor light, these statistics are not intended to discourage a relatively young industry sector or to put off executives from undertaking ERP and CRM projects. Instead, these should be viewed as lessons learned from failed and challenged projects, which the stakeholders involved in the solution implementations can use as input for continuous improvement efforts.

It also seems easy to transfer the responsibility for all failed implementations to the service provider. But as we have noted in the previous sections, a solution is made up of many components, including the product (software vendor), the service provider, and the user of the solution (the customer). While it might be easy to blame the implementer for all failures, it is not entirely justifiable. For instance, recent reports also offer insight into how customers impede their own projects.

Microsoft's own research into customer escalations of Microsoft Dynamics engagements has shown that almost half of the escalations were due to implementation issues. Further research indicated factors such as lack of formal processes within the teams, communication issues, and scope management, corroborating the need for a good methodology for solution delivery.

Many factors decide whether or not a customer perceives a project as successful. Time and cost are two of the most important criteria, but there is another parameter that is important but ignored sometimes—business value. Recent studies allege that ERP/CRM implementations under-deliver business value, and the organizational changes of the solution are reported as ineffectively managed. This again underscores the need for a good delivery process, one that begins with the organization clearly determining success factors for a project before undertaking it. For instance, Microsoft Services requires an understanding of the Conditions of Satisfaction (COS) to be noted within the Project Charter or similar project documentation, and signed off by the customer at the outset of the engagement. COS can be excellent measures of project success, but the key to measuring this is to clearly establish:

When these metrics are measured after the engagement, the teams can clearly determine success or failure of the project.

Nucleus Research released a guidebook, titled Maximizing success delivering Microsoft Dynamics, in October 2009. According to the guidebook:

Nucleus also noted that:

This chapter serves as an introduction to the rest of the book. We began with a discussion of the needs and priorities of the business solutions market. We then explained how, depending on the usage scenario, ERP solutions, and to an extent CRM solutions, can be mission critical to the customer organizations. This criticality underscores the need for a dependable approach for selecting the right solution to meet the customer's needs, a method that builds on the knowledge gained in the envisioning stage to deliver a solution that meets the requirements. We also introduced Sure Step as a methodology designed to fulfill these needs.

The chapter also includes a brief overview of the Microsoft Dynamics solution portfolio. We also introduced the notion of a project within the business solution arena, and discussed implementing these solutions and lessons learned from past implementations.

The next chapter covers the body of knowledge behind solution selling and how it aligns well with the customer's due diligence process. We will illustrate the benefits of this approach for both the service provider and the customer.