Sure Step in action: business process change

Service Providers (or colloquially partners) often refrain from undertaking organization or process changes during implementation projects of Microsoft Dynamics solutions. And it comes as no surprise: there are many risks related to it, and customizations are taken as a more traditional approach.

Customizations are easy to predict, they do come at risk, but at least the risks are known and often easily managed entirely within service provider’s organization and reach, while organizational change is unpredictable, and often exceeds consultants’ knowledge, experience and expertise.

However, with or without intention or consent, organizational change will always happen. No solution has ever been 100% fit, and since the customer must do their business with the solution, the remainder from fit to 100% will always and without exception be satisfied with an unmanaged, unintentional, but evolutionary process change.

Instead of leaving it all to chance, Sure Step offers much better ways.

When analyzing a Fit Gap Worksheet, the main task is to classify each requirement as a fit (standard feature, configuration, workflow and, in my humble opinion, ISV solutions) or a gap (customization).

Workflow, which I would prefer calling organization, or process, was the one thing that was missing from previous versions of Sure Step (and was included in Sure Step 2010) which basically played along the approach so frequently taken by consultants and service providers: to adapt the solution and not promote business process change. I’ve even encountered great Dynamics solution providers who plainly said “we don’t do process change, and we don’t suggest that to our customers”.

What a pity.

If there is fair, but not complete match between a requirement and standard functionality, customizations are generally the approach undertaken by project parties. However, instead the customer company may decides to undertake an organizational change, and adapt the process to fit the standard functionality, instead of customizing the standard functionality to fit the process.

There are hundreds of reasons why this is a far better approach than customization, and I’ve blogged about them in Monkey Policy, Top 7 reasons why to avoid (much) customization, and in many other occasions I can’t even remember.

There are a number reasons why solution providers often refrain from choosing or recommending this approach:

  • They lacked capable and experienced senior resources
  • They often lacked industry experience required for such a feat
  • They wanted to avoid responsibility in case a process change fails
  • To eliminate inherent risks in venturing into an unknown area
  • If process change is initiated, but not completed, the project will turn into a total mess
  • Customizations are easier to predict, design and execute
  • Customers weren’t generally ready to fully commit to organizational change
  • Customers generally expect the solution to adapt, not themselves to adapt
  • And so on, and so forth…

The problem with process, or organization (or workflow if you wish) change is that indeed, the service provider can’t really execute it. That’s something that must be driven and totally supported by customer’s organization. Without proper experience, and often without customer’s true commitment to such a (often radical) change, it doesn’t surprise me that service providers decided not to come anywhere near it.

The problem is – organizational change always happens. In my experience, I have never seen a solution which was 100% fit between the customer’s processes (needs or requirements) and solutions functionality. Here’s why:

  • Functionality which was deemed as fit proves not to be exactly fit (due to overseen intricacies, defective acceptance tests, etc)
  • Some feature which wasn’t considered at all conflicts with the process
  • Some features are forgotten during analysis
  • Some are simply ignored or un-prioritized
  • Some are postponed to “the Phase II”
  • New circumstances occurred, and the requirement changed in the meanwhile
  • Market changes reflected on customer’s processes
  • And again, so and and so forth…

If, or better when, after implementation the customer gets a solution which is not 100% fit, there is absolutely no possibility to conduct the everyday’s business but through process adaptation. When the budget is drained, and customer is no longer paying for any changes, the only option is what human species was exceptionally skilled at for millions of years: adaptation.

Inevitably, people will change their daily habits to match the capabilities of the solution. They will start using things in the solution that they weren’t aware existed. They will abandon certain procedures which aren’t effective anymore. They’ll invent new procedures to overcome the limitations of the solution.

All in all—they will survive, or at least give their best shot at it.

The problem is, if not controlled, the inevitable evolution that’s about to happen, may bring the whole organization down. Evolution is random, it is governed by statistics, and like it or not, some will draw the short straw. Why should it be you? The change doesn’t have to evolve, a better choice is a controlled change, a development.

Until recently, service providers were practically helpless at this. If they lacked the industry expertise, or experience in similar ventures, they really didn’t have much choice but to simply withdraw and do what they do the best: customize.

However, Sure Step 2010 changes that, and brings new guidance called Organization Change Management (which can be found under Project Management Library).

This project management discipline is about initiating, supporting, monitoring and ensuring the success of organizational change, which often coincides with implementation projects. The following diagram (taken from Sure Step 2010) shows the processes of organization change management:

image

Sure Step 2010 is very specific, although unfortunately not too explicit, about organization change management as opposed to customization. Whenever possible, you should opt for it.

Now, at least, there are tools which can guide your path.

3 thoughts on “Sure Step in action: business process change”

  1. Hello Vjeko

    I’m reading your blog since a few weeks and especially your posts about Sure Step are very interesting to me.

    May I have a suggestion for a future post? Sure Step covers and describes in detail all phases of an NAV/ERP implementation project. But what about the time after the implementation? How can Sure Step assist a Consultant/Supporter when changes happen to NAV? I’m thinking about support and change requests, hotfixes and updates.

    Thank you, for blogging about NAV and Sure Step!

    regards,
    Giovanni Pedicini

  2. Hello Giovanni,

    Thanks for the comment! I’m really glad that you find the blog useful and interesting. I hope I keep up with it 🙂

    About the suggestion you give, yes – I could actually blog about it. Sure Step does have some guidance on that, even though full support falls somewhat outside the scope for Sure Step. I would say that Microsoft Operations Framework has more to say about operating a solution than Sure Step, but I’ll give it a try, and do my best.

    Enjoy the blog, and see you around!

    Ciao,

    Vjeko

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.