SAP ROI — Enterprise Architecture & Business Solutions

Over the years I’ve been on projects where there was great project management and others where the project management really stunk!  The projects with really good project management generally ran smoother, had less stress, and the project team was generally more productive.

A FEW of the Characteristics of a Well Managed ERP Project

There are a few things that I saw which were consistent with projects that were well managed.  In a nutshell they are summed up in the following key points:

1. The project manager produces a published project plan with tasks, timelines, deliverables, milestones, and checkpoints.
2. The project plan was at sufficient detail to manage the rolled up tasks, but not so detailed that the individual tasks were micromanaged. 
3. Team leads had individual responsibility at a deliverables level.
4. The deliverables were constructed at the detailed task level so that their progress could be reported to the rolled up project task.
5. The project manager knew ahead of time what was coming in the next major phase and communicated that to the whole project team ahead of time, and at the transition times to the next phase.
6. The “tools” or deliverables templates, resources, and tracking mechanisms were defined AHEAD of time, and then presented to the whole project team with explanations on what information was needed and how to use them as they were needed (JIT or Just In Time).
7. Team leads held regular weekly status and progress meetings on deliverables status which was then regularly reported to the project manager and directly tied into the rolled up project tasks.
8. There were several scheduled proof of concepts / prototypes / demos of functionality long before a solution went to testing.

This list is fairly generic and can be applied to just about any project.  Many, if not all of these items may seem common sense, intuitive, or basic but you would be shocked at how many projects deviate from these basic principles. 

SAP Prototyping, Proof of Concepts, Functionality Demonstrations, or Playback Sessions

And that last item, the numerous proof of concept reviews, prototypes, or functionality demonstrations throughout the project were critical.  These prototyping sessions were valuable because if they were properly scheduled (early and often) they quickly reveal:

• Consultants who might be better on your competitor’s project(s)
• Areas for genuine business value-add or ROI that might require a scope adjustment but the benefit far outweighed the cost
• Capture and correction of process gaps before integration testing
• Adjustment to process focus through better articulation of business need after “seeing” what functionality is there
• Identification of gaps and risks in application functionality
• Indicates whether your outside project manager is able to coordinate the necessary work-streams to accomplish the proof of concept sessions
• Work through and resolve any early warning signs of performance problems

By insisting that your first proof of concept or prototype session occur right at the end of blueprint you have sufficient time to make any necessary staffing adjustments.  Maybe your competitors need some “help” on their projects :)

Warning Signs to Be Aware of In Prototyping

The first warning sign is if a prototyping session or timeline is missed without a clear justification.  For example, if the system landscape was not set up in a timely manner to construct the demo or prototype.  Unless this was due to procurement, logistics, or security issues outside of the project manager’s control then this should be viewed with suspicion. 

If there are SAP or ERP application problems which cause the delay you may want to take a hard look at any consultants who are responsible for installing and maintaining the various software applications.

Another warning sign is if the prototyping sessions are chaotic, disjointed, and generally fouled up experiences.  Usually this will fall into two categories, either a) the project manager is not as experienced as you might need, and therefore might be better off working for your competitor(s), or b) the project timeline might be too tight and there is not enough time to do the prototyping in a proper manner.  How can you tell the difference? 

There are lots of things to consider, but here are a few:

• Is the problem because one key process area is not ready
  • Is the dependent process, or process bottleneck too complex for the time frame?
• Would a few more days make a significant difference in the readiness, coordination, and execution of the prototype / demo?
  • If only a small time adjustment is needed, and there are obvious or clear results from just a few days, the timeline might be a little too tight
  • If a short delay does not produce a significant improvement in the organization of the prototype presentation as well as the fit and finish then you may have a project management or a consultant problem that needs to be addressed

To gain additional insight on this critical stage of the project, especially in the beginning when a properly formed foundation is so critical please see the post entitled “Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results.”

Related Posts:

• Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results
• Planning For a Smooth SAP Go-Live: Part 2
• Planning For a Smooth Go-Live: Part 3
• ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?
• SAP Failures: Is Lack of Sr. Mgt. Commitment the REAL Issue?

Too often today I see lots of hype around various social interaction methods in the enterprise. Companies talking about adopting things like Facebook and Twitter inside the organization. Some of this is just silly.

Facebook, Twitter, and other social media outlets may provide tremendous outlets for interacting with customers, gathering market intelligence, or promoting your brand, but without some business direction they can be more destructive than productive.  Collaborative initiatives that are divorced from a specific business purpose are disasters waiting to happen.

The future technology to IT to customer to market integration paradigm will require meaningful Web 2.0 technology to bring it all together.  But the real issue here is what do you want technology to do?

Here is my first pass at a systematic process for using technology collaboration tools for innovative products or services that are also customer focused.

Conceive

• Collaborate (technology integration)
• Gather intelligence and research
• Ideas (customer immersion narrative) [FN1]
• Socialize (customers, employees, other stakeholders)
• Evaluate (emerging trend or fad)

Develop

• Organize and prioritize
• Prototype (mock-ups, story boards, paper prototypes, actual working models)
• Pilot (finalize design, costing, materials or talent, etc.)

Market

• Market trial
• Refinement
• Sales Campaign

Where Can Technology Enable and Support Innovation Breakthroughs?

Technology tools can support collaboration, gathering marketing intelligence / research, prioritizing, and potentially piloting (engineering, design, etc.) a new product or service.

What are your thoughts?  Is this a process model worth exploring?

======================

[FN1]  See the three part series that explores this topic in more detail.  This series lays out some initial guidance on understanding and then deploying customer focused innovation.

• Striving for a Customer Focused Approach to Innovation 1 of 3
• Striving for a Customer Focused Approach to Innovation 2 of 3
• Striving for a Customer Focused Approach to Innovation 3 of 3

For More Details on the Specifics of Collaboration, Social Media, Technology Integration, and a look at creating a Learning Organization see these posts:

ERP III – Is the Integration of Collaboration the Future of Enterprise Applications
http://www.r3now.com/erp-iii-is-the-integration-of-collaboration-the-future-of-enterprise-applications

SAP, ERP III, SOA — Learning Organizations through Social Media Collaboration
http://www.r3now.com/sap-erp-iii-soa-learning-organizations-through-social-media-collaboration

The ENTIRE INNOVATION SERIES is outline below:

From Collaboration to Innovation to Market – Toward a Working Model
http://www.r3now.com/from-collaboration-to-innovation-to-market-toward-a-working-model

A process oriented approach toward a process model for moving from collaboration to innovation to market. A first pass at integrating collaboration with a structured creative process and moving from idea (conceive) to design (develop) to market (sell).

=========================

Business Strategy and IT Strategy to Reproduce Apple Innovation
http://www.r3now.com/business-strategy-and-it-strategy-to-reproduce-apple-innovation

Overview of Apple Innovation and the focus on Jobs as the head of Apple. The apple innovation secret (if it can be called that at all) is about relentlessly pursuing the customer experience at the point of customer frustration. Where there is customer frustration or customer dissatisfaction there is opportunity for gaining market share for the company who is able to address that point of frustration.

=========================

Striving for a Customer Focused Approach to Innovation 1 of 3
http://www.r3now.com/striving-for-a-customer-focused-approach-to-innovation-1-of-3

Categorizing and Defining the 3 primary types of corporate innovation. I’ve dubbed these as “Stoic” (minimalist or continuous improvient); the “Stretch” (striving for a known future state); and the “Maelstrom” (directionless chaotic storm of ideas). The names you use really don’t matter, but these are the 3 types of what companies call “innovation” that I have seen.

=========================

Striving for a Customer Focused Approach to Innovation 2 of 3
http://www.r3now.com/striving-for-a-customer-focused-approach-to-innovation-2-of-3

Explaining the use of an “innovation narrative” in the “Stretch” type of innovation. This method produces a future state narrative which may not be achievable but provides a customer and market focused direction to aspire to for new products or services. That narrative acts as a future state blueprint for product or service development to move toward.

=========================

Striving for a Customer Focused Approach to Innovation 3 of 3
http://www.r3now.com/striving-for-a-customer-focused-approach-to-innovation-3-of-3

Practical ideas and practical application of some methods of moving toward an innovation culture. Some specific examples around how SAP (the big ERP vendor) has been very successful at integrating their customers, vendors, and their internal organization into an extended development dialog are explored. Includes an overview of how this all ties into the collaboration model I started in a post entitled “From Collaboration to Innovation to Market – Toward a Working Model”

=========================

Process Execution of Business and IT Innovation
http://www.r3now.com/process-execution-of-business-and-it-innovation

The final post in the series on innovation.  After this same short review of all of the material covered in this series the final guidance that you must appoint owners or champions at key points in the innovation process is suggested.

Related Posts:

• ERP, SAP, or IT Project Management and Prototyping for Success
• Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• ERP Business Case: Do You Really Need a New System?
• Using SAP to Improve Revenue and Profitability

After you have done all of the hard work, selected the vendor, and started on the blueprint path you have one more “low risk” opportunity to ensure breakthrough project success.  Keep in mind here there is more risk involved in this area of the project than in the previous stages because they were fully under your control.  You could directly mitigate the risk, you could decide against contracting with a particular vendor, and you could simply back away from anything up to the selected vendor beginning the project. 

Now that the vendor is selected you have one more major set of tasks that is still relatively “low risk” to the business to see solid results.  This is the last big opportunity before incurring huge costs to ensure that you are getting what you pay for–, that is in the blueprint phase.

Keep in mind that during or at the end of the blueprint phase of the project there are risks to changing out problem or underperforming consultants, and those risks are compounded by the size of the team covering a particular area (for example, a smaller team covering a single SAP module like SD, MM, PP, FI, CO, etc., carries higher risk than a larger team covering a single module).  If everything goes well up to this point then the reason you may end up replacing a consultant will probably be related more to personality and team dynamics than a lack of skill.  Some of the personality and dynamics you can work through, however a lack of skill is dangerous to your entire project.  As a result if there is a risk to replacing consultants during or at the end of the blueprint phase it may still be your best course over the longer term of the project.

You may wish to define in advance with the selected implementation vendor how they would mitigate the risk of replacing one or more consultants during or at the end of the blueprint phase of the project.  This way you are both setting the expectation in advance and forcing them to consider how they would actually take care of this problem.  By doing this you will help to ensure that the right tone for quality and results are set throughout the project.  This is your last chance to ensure that the vendor resources are the right fit and have the right skill and talent for your company.

1. A proper blueprint must contain the details of the HOW the functionality will be implemented, not WHAT will be implemented.  The WHAT of the blueprint is the scope.  You wouldn’t consider a home plan a blueprint if it only included an exterior elevation and a few artists’ renderings of the interior would you?  If the home plan didn’t have the foundation details, roof details, electrical, framing, HVAC, etc., you wouldn’t consider it a blueprint at all.  If your vendor provided blueprint document doesn’t contain the translation of the business requirements into the “HOW” of the functionality then it is not a blueprint, it is just glorified scope.




2. Be sure the implementation vendor provides a Blueprint Template ON DAY ONE of the blueprint phase.  Ask for examples of prior blueprints (scrubbed of the client name if they wish).  Ask for these as part of the proposal.  If ACTUAL samples are not provided, with significant setup details then disqualify any non-responsive vendor. 




3. Pay close attention during the start of the Blueprint to find out whether the consultant has any idea of what meetings to schedule, what key company individuals (by job / role) need to be in those meetings, or whether they know what to do.  This is a HUGE indicator of the fakes, frauds, cons, and those who do not have experience.  They don’t know where to start; they don’t know what people they need in what meetings or what order the meetings should be done in.




4. Be sure to sit in on the first couple of requirements gathering sessions for EVERY consultant.  If they seem clueless here, they probably are.  You might want to consider an IMMEDIATE change before you invest in a mess.




5. If you are a large enough company that you have more than one consultant assigned to a module you will want to insist that EVERY consultant conducts requirements gathering sessions with you there to observe. 




6. Unless they have been clearly noted as “juniors” or otherwise made clear to you as the paying customer they do not have experience, there is no reason companies should pay outrageous rates for inexperienced but “smart” folks.  And just to ensure that more senior consultants aren’t “flying cover” for them you might want to insist that they lead their own requirements gathering sessions while the more senior consultants are doing other work.




7. Create a blueprint project requirement that at least one entire process string, start to finish, for a simple process area must be completed by every single module.  This should include basic organization structure requirements and should be completed in less than 2 weeks after the first meeting (a really good consultant can do an entire process first pass including all documentation and requirements in a week).  This is another check point where you can evaluate the quality of the consultants that the system integrator has brought to your project.  IF you find that a consultant was unable to accomplish the task, or if their process blueprint documentation is so lacking in the HOW it will be done in SAP (rather than just the “what” the process is) then I would seriously consider asking the integrator to REMOVE this consultant from the project.  Better to do it now and possibly hurt a little of the blueprint timeline.  The alternative is to have this person possibly slow down the whole project, or make a mess out of the system design, setup, and testing, and then possibly blow the budget and timeline.  And even if they don’t blow the budget and timeline, and even if they don’t make a mess out of the project, WHY do you want to pay that integrator such a premium price for some junior resource that will not add any value to your business?  If that is what you want, PROMOTE FROM WITHIN!  It is cheaper and it creates more visible opportunity within your own company.  You don’t need this kind of high paid dead weight on your project.




8. Insist that a prototype of the simple process they defined is performed within 4 – 6 weeks of the blueprint start.  No matter HOW big, or complex, or far flung your company is there is no reason that a basic but CORRECT org structure and basic business process can not be set up and demonstrated within 6 weeks unless you have less than optimal consultants.  This is another chance to evaluate whether or not you should keep this person on your project.  If you want breakthrough business results then you had better have truly talented consultants.  If you settle for less then you will also settle for less than the results you really want from this huge investment.

Obviously there are risks involved in any SAP, ERP, or technology project.  If those risks are identified and addressed early on in your project you will set clear expectations about the quality of the work and what the final result should be.  There are things that need to happen on the company side of the equation as well, but this article addresses your investment in the system integrator.

If you make the hard decisions up front, and if you are diligent with taking steps like what these articles define then key project expectations about success and results will be set.  These approaches help you to see through a lot of the hype, hoopla, and sales garbage that is so prevalent and also sets expectations about the quality of resources you want on your project.  There is no way to anticipate every avenue some unscrupulous or desperate vendor might take, but by setting certain expectations and keeping the “traps” in place early on you are more likely to eliminate those vendors from the process before they can do any damage.  By being diligent early in the process through changing improper resources (and possibly demanding credits) you can help to set a tone and expectation about the quality of results you expect as well.

Four Part Series:

Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results

Related Posts:

• ERP, SAP, or IT Project Management and Prototyping for Success
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• Planning For a Smooth Go-Live: Part 4
• SAP as a Change Enabler
• Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP