Skip to Content

Back in the mid-nineties when I was in consulting, our average SAP implementation took three years, with hundreds of consultants on two or more continents. These projects were very large and very complex and difficult to manage as it was. This is why every project manager dreaded the term: scope creep.

It was simple, relatively speaking, to lay out the deliverables in the beginning of a project and get agreement as to each party’s responsibilities. However, over the life of a project, issues come up constantly and, in an effort to make progress under the pressure of project deadlines, people jump in and tackle them, often without regard to whether the issue was “in scope” or not.

I’m sure most of you are quite familiar with this scenario and how quickly it can spiral out of control. I don’t need to go into the horror stories. Even if it’s fun sometimes. 🙂

What I think most people don’t consider is that it’s really no different in the internals of a customer organization. Just as in a client-consultant relationship, teams have initial expectations of each other that may be well-defined early on, but over time and successive implementations, the landscape grows in size and complexity, and the responsibilities of teams often creep out of control without regard to what may be the optimal way to grow.

Recently, after a few reorganizations, my team – the SAP Infrastructure team (some call us Basis, some call us Architects, some call us… well, we won’t go there in public) – came under new management not familiar with SAP, and in trying to explain what our team did and why, I realized that a lot of it was hard to explain and there was no clear rationale other than “that’s just the way we’ve come to do things over time.” And since I came in well after the group was established, even I didn’t understand it all.

So I embarked on a process to get back to basics – to start over and document what we do and why – and it was very enlightening!

Having been indoctrinated with ITIL, I set out to design a service portfolio. I met with our group’s stakeholders and asked them, not being confined by what we had done in the past, what services did it make sense for our group to provide going forward? What did we do well? What did we not do well? In what additional areas could we add value, and where were we just getting in the way?

This process is still getting started. We have gathered requirements and put together a service portfolio, and are in the process of presenting that to senior management. But the feedback we have already been getting has been overwhelmingly positive. Relationships formerly bordering on adversarial are turning around quickly. When you open yourselves up to discussion with stakeholders about what it is that you can do to deliver more value to them, they are eager to help. You don’t have to know anything about ITIL to know that being customer-focused is the key to delivering value.

Of course, this can’t be the end of the process. Unlike in consulting where, once the implementation was done I got to leave, this has to be seen through, and a service management practices must be implemented to ensure quality and consistency, not to mention improvement.

I plan to report back on our progress but, in the meantime, if you want to hear more about our experiences, and you’ll be attending the SAPPHIRE NOW / ASUG Annual Conference in Orlando, you can attend my session “Most Valuable Functions in Solution Manager” where I will discuss how to use Application Lifecycle Management practices to deliver value to your stakeholders. I hope to see you there or, at the very least, back here. 🙂

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Martin English
    …. is the WORST reason to keep on doing something.  Unfortunately, with budgets and time pressures, we don’t always get the luxury to sit back and take a long view at the totality of what we SHOULD be doing.  Even when we do, the politics of change, and the sheer effort to get other groups and people to change, can be very daunting.

    An alternative method is to search out the low hanging fruit, by brainstorming with one or two particular groups at a time.  The guiding principle must be that the first ‘Change Projects’ should be obvious ‘no brainers’.  This is for three reasons, first to get buy in from management (be it the business or the IT group affected), secondly to provide motivation to the people involved in executing the change, and thirdly (probably most important) to get buy in from the people affected by the change.

    Once two or three of these have been successfully implemented, both you and the organisation will have both the confidence and authority to embark on more complex changes.  You will also get the benefit of seeing how one change affects the need for subsequent changes; it may be that making one change reduces, say, the volume of help desk calls about passwords, so that a subsequent change related to passwords becomes a lower priority.

    I know this only skims the surface of the Change Management skills and techniques required in many organisations, but it’s an area where I have no real qualification, except that I’ve seen what worked for me in one particular organisational culture.  A key phrase that kept me going through some of these changes is “Technology is easier to change than People, so be prepared to make more of an effort with People.”


    BTW, I’ll be attending Sapphire via the virtual sessions; I didn’t realise you were presenting, but I believe I have your session in my agenda already 🙂

  2. Susan Keohan
    Hi David,
    I am also familiar with Scope Creep as well as ‘That’s how we’ve always done it’ – and both are constant struggles – not only for our customers, the Business, but for our own internal organizations.  I look forward to hearing more on your efforts!
    Well done,

Leave a Reply