A4B Notes

Lessons Learned from a Delayed SAP Go-Live

On November 15^th I completed a contract that ended up being a year plus two and a half months in duration.  It was enjoyable in many ways, I met a lot of very talented colleagues (we had a strong team of SAP consultants) and the process owners and the users at the client were both friendly and professional.  The go-live was quite smooth by comparison to typical and the entire team (save the Business Warehouse report developer) has departed within 6 weeks of go-live with everything documented and handed over to the internal support team.  Yet, by budget measures, this was not a successful project and it’s time to share some of my lessons learned (or rather re-learned in many cases).  As we did not have a lessons learned meeting to close out this project (at least not with the consultants), I’ll put my own out there.

1)      When is a “template” not a template?  When it is not documented and many of the processes it may support have multiple methods within other business divisions and there has not been a determination of best-practice.  On this project, we were doing a Canadian deployment of a “template” approach that had been developed for multiple vertical business units in the US.  As is quite typical, Canada (as a horizontal business unit) comprised product lines from each of the US verticals and thus, could adopt business processes from all of the vertical business units in the US.  And, although they shared a common SAP instance, each vertical business unit had developed their own fairly customized business processes and determining what was “in the template” was a matter of judgment.

2)      Who is best suited to estimate the amount of work involved?  The consultants who will do the work (if they are experienced) together with the project manager.  We kind of did this at times during this project.  And we kind of made efforts to level-load the consultants (adjusting roles and picking up some of the variable tasks with lesser-loaded consultants) but we could have teamed better on that front.  It’s important to have honest conversations about how much work we really have (and not be too pushy with those who have lots or too quick to jump on those who have little).  This is difficult in any work environment, but very important for projects as the longest work stream will ultimately be the project duration and there can be a lot of unnecessary cost if the project does not have mostly-balanced work streams.  We had some of that on this project and I was the lightest work stream in this case.  Fortunately, I was local and could be flexible with my schedule.

3)      Change is hard to take, but some take it harder than others.  I have often seen on ERP implementation projects, one business area that just isn’t keen on a new system.  Although this is typical across the board (we all find comfort in what we have every day), when one department finds reason to delay, it can be quite costly as all areas need to wait.  I ended up leaving this client 3 months after I was originally scheduled to leave.  The scope of delivery in my area was expanded and the users and process owners were able to use the extra time to become that much more self-sufficient, but I don’t think that in my area (even with my diminished work schedule) the client really got good value for that investment in the extra time.  I think that some extra leadership push on the change management front to bring in the go-live date by even one month would have saved substantial costs.  As a team, I think we felt we were ready a month early and we didn’t really have a team discussion to make that determination. I do understand that erring on the side of caution can often make sense, but I was left wondering in this case about the cost of that caution.

I’ll leave it there.  This was, overall, a good experience and a fairly smooth move to SAP for the client.  I believe the process has begun for the client overall to recognize the SAP solution as a strong one – better in many ways (but not all) than the solution being replaced and the cost of maintenance will be lowered significantly.  I enjoyed having work I could get to and from daily from my home and it was a great team to work with.  I honed my knowledge in many areas of the SAP solution set (most notably, my areas of production planning and execution) and learned some new tricks (and applied for the first time a few I had known about). 

As all projects should, this one leaves me more qualified for the next one and I look forward to taking that next one on.

Some Things to Consider before Outsourcing

As I sit in the coffee shop as much at work as I ever was when I had a "real" office, it really drives home the nature of structural change our businesses and economy are undergoing.  When anyone can contribute to a business from anywhere, we are left asking what a business really is.  Additionally, the opportunity to reduce cost by outsourcing is virtually limitless (even $0 may not be a practical limit as new revenue models are put in place where businessesmay actually be paid for doing traditional cost processes a different way).  So what must remain core to all businesses?

At the inner-circle level, I'd contend there must be two things:

1.  Harmonization of intentions.  Whether your inner-circle is employees, partners, outsourcers or other stakeholders, it is important that they be carefully selected such that their business and other intentions create a harmonic resonance with your own.  Without that, growth will be very difficult to foster.

2.  Understanding and control of strong business processes to develop brand.  Your brand is ultimately the impression you leave with your customer - and this impression is developedbased upon high-quality delivery, at speed for a favourable price.  Each of these elements is the outcome of sound business processes (regardless of whether you or your outsourcer executes them).

I'd be happy to hear your thoughts on the above.  Of course, if you're reviewing what is "core" versus "outsourcable" at this time (as many of you are) we'd be happy to be involved in the discussion.

An Operating Framework for an Organization

Vision?  Mission?  Purpose?  Values?  You can see these words thrown around with respect to operating a business.  Organizations can easily spend "too much time" on these things but, kind of like "too much training" that I wrote about on Monday, I'm not sure that "too much time" is a possible perspective here.  To effectively accomplish something, an Organization (Enterprise, Corporation, Club, etc.) must have enough of a stated "raison d'etre" that it can guide and serve its own people and society in general. 

Components of the above may be for team only, customers only or for some other subset or stakeholders, depending upon the culture of the Organization, but some statement of the above should exists.  Here's a framework I have adopted from a few different sources.

1.  Purpose

This answers the fundamental question - Why do we exist?  As individuals and for ourselves, we may struggle with this our whole lives, but with an Organization, it's founders had better be able to articulate Why.  If this can't be answered, we may as well close up shop.

2.  Vision

How is the world different (or how is it going to be different) as a result of the Organization's existence?  Of course, while existing, the Organization does things, so you could take this also to mean "What changes will the Organization's actions effect?" but I think the original context is more broad and allows more freedom in mode of achievement.

3.  Values

How will the Organization conduct its affairs?  What can customers, employees, suppliers and other stakeholders expect consistently from the Organization?

4.  Mission(s)

Guided by its Vision and respecting its Values, what concrete step is the Organization currently focusing its intentions toward?  Some will contend that there can be more than one Mission at a given point in time, but I'd suggest that is risky (although, yes, possible).  Mission provides focus and focusing on more than one thing can be difficult.

Like most Organizations, Answers 4 Business is a work-in-progress, and we are still strengthening our ability to define and articulate Vision and Mission.  If you want to review where we are currently with that, the link is below.  We do work with businesses on aspects (developing, communicating and re-engaging) of the above and would welcome discussions and suggestions you may have.

http://www.answers4business.com/WhoVision.html

How to Develop and Retain "Super-Duper Users"

"Super-Duper users" - the unsung heroes of successfully-implemented business systems (such as ERP, CRM, SCM, etc.).

By other names, we call them power uses, super-users or, in some organizations, business process owners (although that definition usually entails a little more).  These are the people who know the business needs extremely well (because they work in it on a daily basis) and know the capabilities of the implemented business system (often in better detail than many of the so-called "experts" or "consultants").  With knowledge being power, they are naturally sought out by peers, managers and subordinates for guidance and advice on how to get the job done.  And also, for tips on what improvements can be made to make the business system and the business fit together better, or to adjust to a change in the business needs.  As often as not - they are the first sought out.

So - how do you find them, develop them and retain them?  There is no magic formula, but here are a few tips that can help.

1. Identify and recognize them.  Very few people have "super-user", "power user" or "super-duper user" on their business cards - and we don't need to go there - but recognizing the tasks and responsibilities associated with the usually-informal role is a key first step.  This recognition is, ideally, a mix of qualitative (for example, the occasional "attaboy", an e-mail note of thank you, or an entry on an informal support organization chart) and quantitative (an evaluated and compensated part of a role definition).
2. Train them.  This can go to the point of "over-training" them (whatever that means) and still be useful.  They already know a lot about how the business system works - teach them more.  And let their interests and current challenges blend to guide them on what they need to learn about.  Additionally, they already know a lot about how the business works - teach them more about that, too!  The motivation for this is mostly selfish for the business - these people are your informal front-line on making things happen in the systematic, repeatable ways you are hoping for in your business - and they are the "go-to" people for the others in your organization - what could be a better investment than keeping them fully-informed?
3. Certify them.  This ties points 1 and 2 together nicely.  This gives you the comfort that they really know what they are doing (as well as the certifying body needs them to anyway - which is usually a good start) and it gives you a very good excuse to recognize them again.  Beyond that, it allows them to act as an example for others in your organization to aspire toward - and that can only strengthen the overall level of engagement and thus, useful adoption of the business system.
4. Challenge them.  You will undoubtedly be improving your business over time - tweaking the business system, implementing new functions, adjusting processes.  Super-duper users want to be involved in that.  They may be as good at the day-to-day business as anybody (often better) but that is precisely the reason you want them engaged in the improvement process as well -  you'll get faster and better results.

So, that's a start - I am interested in your comments and other tips you may have for developing this important asset.  I will also borrow and possibly paraphrase a very catchy statement on the training aspect of the above:

"The only thing worse than training your people and having them leave, is not training them and having them stay".