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. 🙂
