Business Solutions with SAP

Integrating Business Stakeholders as Part of SAP IT Convergence

August 29th, 2011 by
Business to IT Convergence with an SAP Center of Excellence

IT Convergence

The other day I was having a conversation with an IT executive from one of America’s largest companies.  I was really interested in his perspective as a hard working senior level IT insider.  We started talking about the role of IT and business as well as the future of business and technology.  In the process I relayed my passion for how IT needs to integrate with the business and how the future was going to change significantly (see e.g. What is the Proper Relationship for the CIO, CEO, and CFO?).

I gained a new appreciation for how difficult an IT executive’s job can be when the economy is in turmoil.  I’m sure my comments and perspective were challenging but here is part of what I gained from that conversation (my assumptions and my “read” may be wrong)…

The wider global technology discussion (inside and outside of the company) is putting real pressure on IT return on investment, IT Convergence, and full integration with the business (see Steps to Achieve SAP IT Convergence).  Even while all of this takes place there is still a critical need to stay on top of technology trends and be sure the organization does not stagnate.  To stay competitive what does he do with “cloud” processing, do they need different applications for some of their processes (CRM, APO,SRM, etc.), what about social media (does it even fit), virtualization, shared services, service excellence, outsourcing, in-sourcing, etc., etc., etc.

This executive’s IT organization is being challenged to do more with less.  As a result of cost-cutting pressures his organization is having to look at outsourcing while he also has to maintain a positive and upbeat appearance in the face of working through difficult cuts.  He has to continue encouraging and rallying the troops while some of them will not be there.

A Simple Response to the Nagging Problem of Business IT Convergence

With all of this background in mind one of his responses to me set me back a moment for its simplicity, candor, and most of all the underlying frustration.  It is certainly one of those very difficult struggles that many corporate technology leaders today face:

“What is the business responsibility for this?”

The business not only has responsibility but they have to help drive solutions and delivery. The various business stakeholders must see, understand, and then accept their role in developing the technology roadmap. And once it is developed they must help ensure its execution.

The Business to IT Convergence Solution That Was There All Along

The IT Convergence approach in the SAP enterprise is partially based on best practices around IT Governance.  By creating a governance structure that involves and integrates both the business and IT stakeholders you gain business buy-in and involvement.  I have written a solution brief on this approach and provide a free, no-obligation MS Access application to build technology roadmaps (see the Solution Brief, governance process, and application overview here:  Beyond Technology Alignment )

The basic takeaway here is that business involvement is critical.  They are already making technology investments, with, or without your involvement. So it is critical to gain that convergence so that technology investments are performed as a partnership and not in isolation.  As a recent Harvard Business Review post by Ray Wang notes:

“[O]verall corporate tech spending is up by 17 to 20% in our latest data, spending by IT departments is flat at best. It’s business leaders, not their IT colleagues, who are driving purchasing decisions.”

Coming to Terms with the Consumerization of IT, and a followup with more details on his site at: (both retrieved 8/23/2011)

So the key here is to integrate the business into the IT and application infrastructure.  One way to do that is through leveraging SAP steering committee skills and business connections to ensure meaningful involvement by IT.

Additional Steps to SAP IT Convergence – Creating the Center of Excellence

Last week’s post provided a few high level steps to achieve SAP IT Convergence, and this week I am adding to that list the following items.

  • Pursue business executive sponsorship but don’t wait for it to get started.
  • Start a communication program
  • Engage at all levels of the organization
  • Conduct one or more pilot programs and capture lessons learned
  • Hold IT staff accountable for participation
  • Don’t let available tools stifle participation or innovation

Related Posts:

SAP Project Manager – SAP Program Manager, Lessons from the Trenches

July 25th, 2011 by
SAP Project Insight

SAP Project Insight

This is a continuation of the previous post which addressed early requirements for good SAP project management (see Effective Results from SAP Project Managers – SAP Program Managers).

SAP Project Management Responsibility

A manager’s primary responsibility, above all else, is to ensure the success of those they are responsible for managing.  Overall success of any initiative is directly tied to the success of those responsible for delivery of that initiative.  This is especially true in fast paced, moderate to large scale SAP projects.  If your reports succeed then you as a manager automatically succeed.

An SAP project manager or SAP program manager must focus aggressively on removing obstacles, encouraging success, and fighting against those things that would impede momentum.

Once again, I will re-emphasize:

I don’t blame client project managers because if they had all of the resources, skills, and experience, they would not need outside help.  These posts are focused on contracted help who are supposed to ensure your success.

What can SAP Project Managers or SAP Program Managers Do to Help Ensure Success?

One of the first requirements of a contract SAP project manager is to build momentum.  Once momentum is built that contract SAP project manager or program manager must do everything possible to sustain that momentum.  Some of the things which help to build, sustain, and then manage momentum include:

  • An articulated obsession with building and maintaining momentum.
  • Activities, tasks, responsibilities, and value added tools are defined ahead of time and not made up in real time.
    • People must understand what is expected of them – project requirements in the form of deliverables, tasks, and timelines are communicated early in the project and reinforced *before* transition points throughout the project.
    • These “expectations” must be laid out early in the project, throughout the entire project lifecycle (beginning to end) and have proper transitions built into the planning.
  • Tracking mechanisms must be simple, easy to understand, and easy to manage.  Overly complex or involved tracking mechanisms destroy momentum and “cloud” visibility into progress.
  • During blueprint emphasis is focused on design that will enable execution, if it doesn’t enable execution (or Realization) it is a waste of time (see  How “As-Is” Process Mapping Can Damage Your SAP Project).
    • Project emphasis must be on execution – execution builds momentum.
    • There is an emphasis on coordinating activities rather than administrative overhead–, some administrative overhead is necessary but only to the extent that it directly supports execution).
    • Project management is actively and directly engaged in coordinating execution activities beyond checking off spreadsheets.
  • After blueprint emphasis moves to execution over design.  Areas where design continues to be evident must be aggressively managed so that design only supports directly executable activities that are in scope.
  • Risks to success are identified and mitigated throughout the project.
    • Issues, risks, decisions, or other obstacles to project success are regularly captured and worked to resolution.
    • Periodic QA reviews at appropriate milestones or intervals.
    • Obstacles to activity or execution are aggressively managed (with few exceptions there is no “we can’t do ‘x’ until ‘y’ is perfect)

Do You Have a “Slick Politician” or a Real SAP Project / Program Manager?

There are unfortunately too many politicians in the project manager ranks and too few “straight shooters.”  Project manager politicians are destructive to morale, on-time delivery, and are dangerous to budgets.  However there is a measure of diplomacy that is required so how do you know when you have a political SAP project manager or SAP program manager rather than a skilled and talented one?

A manager’s primary responsibility, above all else, is to ensure the success of those they are responsible for managing.

Think about that a minute.  If a manager’s primary responsibility is to ensure the success of those they are responsible for then what would be a sign they are not a good contract project manager?

If your reports succeed then you as a manager automatically succeed.

The worst kind of project manager is the one who will “throw others under the bus” to deflect from their own shortcomings.  They demoralize and discourage project team cohesiveness while crushing momentum.  They create an environment where people do not want to do anything at all for fear of becoming the next scapegoat.  When things go well they are the first in line to take credit for what went well (even when they weren’t involved).  They lack integrity and character.  They spend more time and effort trying to cover their own back side than on trying to ensure the project is delivered successfully.  If you see these signs in your contract project manager you should seriously consider firing them.

Popular Searches:

  • explain the economic hardware and software factors for vendor selection

Related Posts: