The Infallible 2-by-2 Matrix and the Magic Quadrant

A long time ago I worked for one of the big consulting firms where every interaction with the client seemed to involve a 2-by-2 matrix.  It got to the point that some of the consultants and most of the client laughed whenever one of these was pulled out.  It became a contest to create 2-by-2 matrices for everything and at one point in my life I aspired to publishing a book of 2-by-2 matrices to enable and empower everyday people to make good life decisions.  I think someone beat me to it at least in spirit.

I think the world has become conditioned by 2-by-2 matrices such that the goal is to always be in the top right hand corner – the so called magic quadrant – whereas being in the bottom left hand corner shows how much progress you still have to make.  As highly paid consultant I am supposed to help you find the path from where you are to where you want to be.  The funny thing about 2-by-2 matrices is that you can make them do whatever you want to serve your needs.  Take the example of where I should go for dinner tonight:  If I plot on one axis how likely the bill will conform to the client expense policy and plot on the other axis how well the restaurant menu prices align with my per diem I get something that looks like the graphic below.

If I follow this chart and adopt the recommendation of the magic quadrant I’ll be eating fast food every night because it’s cheap.  Unfortunately, I’ll feel like Morgan Spurlock in no time.

If I look at this chart with a more skeptical eye the two axes are showing similar information, so the whole thing is pretty bogus.  If you are going to use a 2-by-2 matrix to make a point with a client make sure it serves a useful purpose.  One of my favorite matrices plots employee/consultant willingness against ability as shown below.

In an ideal world all workers fall in the magic quadrant, i.e. are both able and willing to perform a certain task (could this be the nirvana of a low maintenance, competent and talented worker?).  The individuals who fall into other quadrants are potentially much more interesting and I would wager that not every worker falls in the same quadrant all the time.  After all, I’m not a big fan of “busy” work: I am able to do it but not very willing because I don’t value it.  But when it comes to blogging I am both willing and able (obviously!) [Ed. Note: You, sir, are a very able blogger!].  Workers who are able but unwilling present a special set of challenges for project management (you can lead a horse to water but you can’t make him drink), whereas workers who are willing but unable may be lacking skills they want to acquire.

The takeaway here is that there is a place for 2-by-2 matrices in conveying a message: stating an objective; starting a discussion, etc. but use them sparingly and only when it is relevant.

In the meantime, send me your suggestions for 2-by-2 life decision matrices and I’ll see what I can about giving you a credit in my forthcoming publication: Top Right Sure Beats Bottom Left.

It Depends

I don’t know anyone working on SAP projects that doesn’t laugh or roll their eyes when someone says “it depends”.  As much as I mock it, the response does have some merit.  For example, if a client asks you how SAP processes purchase orders it is difficult to give a single definitive reply and “it depends” is a great cop out.  Purchase orders: would you like an account assignment with that?  Do you want to use info records?  Do you have quota arrangements?  Do have to have requisitions for every PO?  And so on.

It is critical to make a rapid transition from the non-value adding “it depends” to a discussion of what matters to your client.  This is where your knowledge of their business and prior project experience come into play.  I would hope that during the project scoping and requirements gathering phases you gained enough of an understanding that you only suggest SAP processing options that are applicable to your current situation.  After all you wouldn’t discuss logistics invoice verification if you are only processing A/P invoices directly through the FI module.

This Happens on Every Project

This phrase shows up in various forms and the two most common variants I’ve heard are “Every project runs into this kind of thing” and “I’ve seen this before on other projects”.  If you find yourself making statements similar to these pause for a moment about how your client will perceive it.

I have only come across these phrases being used when a project has gone astray and has run into a crisis of some sort: testing is revealing a whole new set of requirements that weren’t captured during blueprinting; test scripts don’t have enough details; functional specifications lack detail; too many overlapping yet dependent activities, etc.

The best comeback I heard to “This happens on every project” was from an exasperated client who asked: “Just so I’m not surprised when it happens, what other things happen on every project that I should know about?”.  (Thank you Patrick!)

In short “this happens on every project” can often be traced back to an earlier failure of project management.  Sometimes the situation is unavoidable, for example, despite your guidance about not moving on to the next project phase because of incomplete deliverables your client insists on going forward because the timeline says it is time to move forward.  Sometimes, key milestones are met but the sign-off is far more conditional than it should be.  Regardless of the underlying circumstances your client probably sees you do one of two things:

• Reactively tell them this happens on every project and then describe how every project goes through some level of fire drill and triage to get things back on track
• Proactively manage their expectations and make clear the potential problems the project may run into: for example, designing and developing while integration testing is never a good idea.  In this way you provide leadership, not just management, and set a course to avoid a fire drill.

Typically a client does not like surprises and pro-active behavior is better than reactive.  I like to think that as a project manager I exist to prevent forest fires, not to fight them.

Consulting Catchphrases Conclusions

My underlying thought is that the consulting clichés have an element of truth and validity to them and you should strive to use them as a springboard to bring value to your client.  Think about where the clichés came from – usually a negative experience – and see if you can anticipate where you might feel compelled to use these catchphrases on your project and (ahem, forgive me!) avoid them like the plague.

Please let me know if you have any favorite overworked project phases and I’ll do a follow up posting if I get a good number of responses.

How much data to move? How much data to leave behind? What to automate, and what to execute manually?  How to gracefully orchestrate and execute a data migration cutover from one system to another?  Where and how to fit the data migration plan into the overall business implementation plan?  How to continue to run the business during the data migration phase of the business project implementation? These questions are all part of the planning fun!

Data Migration Testing

Processes that we have exercised and continue to exercise on a regular basis are no big deal, do not cause anxiety, or raise any blood pressures.  The daily report, the custom transaction, the interface that runs several hundred times a week – they are all second nature now.  They happen, and no one notices.

But reflect back to the very first time these processes went live.  This is precisely where you are with data migration.  For most, it is a once in a lifetime event.  It is important, then, to raise confidence levels, and reduce anxiety levels surrounding this activity.  This is achieved by practice, practice, practice.

Typically, I like to see at least three data migration test cycles executed in an isolated data migration client.  This allows for several attempts at exercising and fine-tuning the data migration plan; collecting nominal run time statistics to have some idea of how long the data migration might take; identifying and fixing any data migration program object defects; identifying and fixing any data mapping and content defects; and identifying and fixing any functional configuration issues. Each of these tasks are done with the goal of significantly improving the fallout rate with each data migration test cycle.  These data migration test cycles also give us the opportunity to practice our legacy extract skills, our fallout analysis skills, and our fallout manual cleanup skills.

Source Data Quality

Each data migration test cycle begins with the legacy or source data extract.  An important activity between data migration test cycles is the cleanup of the legacy or source data.  The data migration process will most likely discover many data problems.  Customer and vendor address data alone are enough to bring your bolt-on tax jurisdiction determination software to its knees – that zip code that is too short, too long, or just plain incorrect when combined with the associated city and state; the various abbreviations used in place of the actual city name; the city and state entered in the same field when they should have been entered into separate fields; etc.   If the source data is not fixed, your data migration test cycles will begin to look like the movie Groundhog Day.

Source data provisioning and cleanup could very well be problematic, especially in an acquisition or merger scenario where the providers are part of a different organization and have no incentive to participate in your project.  If you encounter this scenario, you will most likely need to engage the appropriate management level from your organization to have a serious discussion with the appropriate management level from the providing organization.  Recognize this, be in control, and raise that flag early.    Do not sit around for several days waiting for data to arrive, as this will only set your project behind schedule.

Data Migration Support for Other Testing

In any business project scenario, the development team will salivate at the thought of testing their customizations against your real data in the conversion test cycle box.  Likewise, the functional team will be chomping at the bit to use your real data to test configuration scenarios.  And the interface team and the data warehouse team can’t ever get enough data to play with.

While working within your three data migration test cycles, just say NO.  You absolutely need a controlled environment for data migration test cycles, and these other teams will not respect that.  They have a different focus and purpose which requires changing and manipulating degrees of freedom that you need held constant.

But, we are all on the same team trying to move the project to the finish line within the expected project timeline.  So to help your other team members, plan for additional data migration cycles to provide this data to these teams.  That’s more data migration practice for you, and it gives everyone else what they need.

The Perfect World of Data Migration

In a perfect world, for each data object to be converted:

1. The functional specification and mapping documents are well-written and clear.
2. A data load file is built exactly in conformity to the well-written functional specification and mapping documents.
3. The data migration ABAP objects are built exactly as specified by the well-written functional specification and data mapping documents.
4. No one is insisting that we move a square peg into a round hole.

In a perfect world, for each set of data that is to be migrated:

1. The legacy system data has been thoroughly cleansed.
2. The providers of the legacy data are genuinely interested in providing accurate data on time.
3. Server-resident load files in a Unicode system are correctly encoded to UTF-8.
4. A delimiter other than comma has been specified for the load file.

In a perfect world, the data migration test cycle client:

1. Is built in a box that is not the development box.
2. Is configured exactly like the client where the data migration ABAP objects were built and tested.
3. Is not open for configuration, unless by design.
4. Is not part of a transport path. to prevent the current cycle of conversion testing from being blindsided by any new configuration changes.
5. Is locked down so that only data migration and data validation tasks can be performed.
6. Is configured to handle a more background and update processes and fewer dialog processes.
7. Is built in a box that has enough disk space to be the repository for the primary load files and any intermediate processing files needed.

In a perfect world, at the project level:

1. There is an overall business cutover or implementation plan into which you can assimilate your data migration plan.
2. The data migration plan integrates nicely into the overall business cutover plan.
3. There is a strategy in place to bring the data current between the time the cutover freeze is enforced and the implementation date.

Stay Tuned!

In the real world, the fun is just beginning.  Those perfect world scenarios just never seem to happen.   But stay tuned!  In my next blog post in this series, I will discuss the details of the Data Migration Plan.  After that, in subsequent posts, I will drill down into some real world scenarios that I have encountered and discuss how I dealt with them.

In this post I’ll do a combined discussion about the use of offshore resources in an upgrade project as well as share some experiences working with remote resources.  My colleague, Mike Salvo, has already discussed ABAP customizations in an upgrade in this post.  Now that you’ve found these customizations, what do you do next?  Actually Mike provides loads of good advice about what to do next in terms of sorting out what is in the overall pile of objects that need to be examined.

What I hope is that you have documentation related to these objects: information that tells you why they were created, what they do, where SAP functionality is deficient in the current release and how you worked around the shortcoming.  This should be helpful in making the evaluation about whether you can remove a particular object or if you need to make sure it works in the new release in a way that satisfies your business and/or technical need.

I going to assume that you have been through the “bag of rocks” analysis described in Mike Salvo’s posts and now have a collection of pebbles, stones and boulders to work through.  This is where you can make good use of offshore resources to help out: there’s a lot of discussion about the use of offshore resources and you can use them really well or really badly.  Let me digress.

SAP Offshore Development Resources

I’ve heard many complaints regarding offshore resources, but the two biggest complaints that are trotted out as a serious offset to the expected cost savings are:

• The time difference makes turnaround time longer than projects plan for or like.  For example, if you work with resources in India you have to synchronize working schedules and often this means team members either work way late or very early in the day.
• The accuracy and completeness of what you ask for determines the quality of what you get back (a.k.a. you get what you ask for, not necessarily what you want): the difference in time zones makes it difficult to get clarifications and address questions quickly.  Consequently, development life cycles can be extended even if the hourly cost is lower.

A straightforward way to address the first issue is to work with an offshore partner in a time zone closer to yours.  In this respect I’ve worked with development partners in South America where the offset with US time zones is small.  This helps address the second complaint: by being in similar time zones it is much easier to either pick up the phone and address questions or send e-mail and get a quick response to a question.  I’ve been on projects where a quick answer to a question had to wait a day because of time zone and work schedule difficulties.  There may be a slight premium for using an offshore team in South America, but the turnaround time and responsiveness usually makes it worthwhile.

How does this digression help your upgrade?

Once you’ve sorted your bag of development rocks you can go through another level of review to rank the objects in terms of complexity and/or difficulty of remediation for the upgrade.  In general, I’d recommend keeping the most difficult work items close at hand and have onshore resources work them.  Any questions about what the object is supposed to do, any business process impacts can be addressed readily with end users and business analysts.  Objects that are less complex can be worked by the offshore team: you stand a good chance of getting what you need by providing clear documentation (all those project artifacts you maintain) and explicit instructions around what you think the remediation entails.  You should also set expectations around what comes back from your offshore partner: code that is free from syntax errors isn’t going to be enough, some level of testing and documented results are more likely what you want.

SAP Upgrade Onshore and Offshore Resource Balancing

I can’t tell you or even estimate how many onshore and offshore resources to engage in an upgrade project without knowing more about your environment and object analysis.  However, I would definitely recommend two key onshore roles:

• Development Object Remediation Lead: an individual who has responsibility for coordinating and prioritizing the objects sent to the offshore team and managing the associated sign out and sign in process.  This person also has the unenviable task of serving as the quality control checkpoint and enforcer of expectations with the offshore team.  There should be a corresponding role in the offshore team, too.
• Development Object Remediation Senior Consultant: one or more individuals with the expertise to address the complex objects

Smart use of offshore resources has the potential to reduce development object remediation cycle times and that should lead to direct cost savings.  Any steps that accelerate your overall upgrade project time line and contain costs should be viewed as a good thing.  Try it – you just might like it!

In short, if you have done a good job with your earlier implementation activities you should have a plethora of materials that can be reused.  Remember that after an upgrade your basic goal is to still be able to do what you could do on the previous release along with anything new you are introducing.  The way you execute business functions may be slightly different, but the underlying objective should be much the same.

For more on SAP Upgrades download the white papers:

SAP Upgrade Checklist

Customization Risk Analysis in an SAP Upgrade Project

SAP Project Artifacts for Upgrades

In short, don’t reinvent the proverbial wheel if you have one available to you already.

As you went through your initial SAP implementation and ongoing support work you probably generated piles of documentation and if you managed this well throughout the ongoing project lifecycle there is a good chance that you can reuse it.  In essence, the better job you have done identifying, capturing and testing the functionality used in your SAP system the easier it should be to reuse those artifacts to confirm continuity of business processes in the new release.  It sounds easy, but it is a rare project that consistently maintains and updates project documentation as functionality is introduced through point releases, production fixes, etc.

Whatever information you have is worth reviewing to see if it can be reused or at least used as a basis for building out the scope of testing for the upgrade.  In addition to the testing scope, you may have test plans, procedures and protocols that can be adapted.  Typical project artifacts for consideration include:

Functional Scope

Any SAP project starts with an initial functional scope which grows over time.  This is a great start point for defining what you need to test and circling back to find where you implemented non-standard functionality.  The standard functionality is likely to stand up to the upgrade and work straight away, whereas the non-standard stuff is where you want to pay special attention.  In this scope you want to make sure you capture any special periodic processing, e.g. daily, weekly, monthly, quarterly and annual processes to be tested

Business Process Procedure Documents

In conjunction with your functional scope, you probably have business process procedure documents that provide detailed step by step instructions on how to execute job functions.  You can use these as a tool to verify whether business process steps have changed.  In the event that the steps have changed it is clear what documentation needs to be updated.

Technical Objects Scope

Similar to the functional scope you should have a catalog of technical objects, e.g. reports, custom programs, user exits, SAP modifications (if you went down that path), etc.  This provides a list of objects to examine and evaluate as part of the upgrade.  This is a topic covered in depth in a separate blog posting.

Test Plans, Scripts, Procedures and Tracking

Now that you have a functional and technical scope defined you can also revisit any test plans you have.  Testing comes in many flavors (click here to discuss some flavors) and you probably have prior test artifacts for functional testing, end-to-end testing, security and authorizations testing, etc. which are worth a review.  On top of this any regression test scripts and automated test tools may be re-deployable in support of upgrade testing

On top of this most projects have established procedures for tracking issues, resolution steps, and progress reporting.

Testing Organization

In conjunction with your test plans you probably have documented roles and responsibilities, test team organization structure, escalation routes and sign-off procedures.  Again, reuse all that you can.

Partner Systems, Interfaces, Batch Processing, Performance Metrics and System Outputs

Very few SAP installations are islands of functionality, instead there are numerous partner systems that interface with SAP as well various outputs in both electronic and hardcopy forms.  An inventory of these items provides another checklist for testing and identifies both internal and external partner systems you need to include in your upgrade test cases.

System performance is often critical for interfaces and batch processing and any historical activity that identified and tested these elements provides a potential guide for ensuring no degradation of these things as a result of the upgrade.

SAP Upgrade Go-Live

Again the experience from other go-live events may form a good basis for building the upgrade production implementation plan.

Supplement these artifacts with additional content for new functionality and modify for anything that has changed because of the upgrade.

Get Organized for Your SAP Upgrade

By no means am I saying that everything you have built and accumulated over the lifetime of your SAP installation is going to lend itself easily to being recycled in support of your upgrade activities.  However, I am saying that you put in a lot of work to get to this point, you already have a good idea of how to test SAP, you know the quirks and nuances of your organization, so don’t feel like you need to start from scratch.  Cast a careful eye over what you have in your project inventory and see what make sense to apply and what to discard.

And if your SAP project inventory is not a robust as it could be, think about how to strengthen it ready for the next time you have go through an exercise like this.

Head over to live.dataxstream.com on Tuesday, October 13, 2009 to get up to second updates from the show.  We will be getting our liveblog on starting at 8am PDT (that’s 11am for you right-coasters) for the general keynote session.  We’ll also be liveblogging from SAP TechEd 09 Demo Jam at 8pm PDT on Tuesday.  The Demo Jam promises to be a great time, so plan to join us online after you put the kiddies to bed!

This is our first foray into liveblogging.  Hopefully it will go off without too many technical glitches.  We hope you’ll enjoy following the events with us!

In my previous post I discussed various types of testing and alluded to what each type entails.  Implicit in each of the test execution activities was the assumption that the necessary preparations were complete.  The testing you are doing will determine the kinds of prerequisite preparation work you need to do and there’s no escaping the need for some upfront work.

I always think there is a level of theoretical abstraction that goes with project management because in an ideal world you can imagine a mechanistic approach where you have your tasks and your deliverables and as long as you sequence them correctly your project will complete.  Reality has a way of distorting theory and throwing a few challenges into a project.  I’ve not worked on many (any?) large projects where a the timing and coordination of deliverable completion has been perfect, so every project has to make a judgment call on whether enough of each deliverable set is available to meaningfully support the next set of activities.

Enough of the theoretical abstraction: let’s discuss an example.  I once worked on a project where the team wanted to do some real world simulation testing, basically a day-in-the-life test (DITL) in a pre-production environment.  The testing was to include functional configuration, reports, automatically executing interfaces, end user security and authorizations, master data extracted and converted and loaded from legacy systems, and overnight periodic processing.  Unfortunately, certain aspects of the design weren’t complete–report specifications varied from non-existent to in-development; interface triggers had not always been included in the design and construction; no data conversion exercise had achieved more than ~60% success; and the batch scheduled had not been defined. So, aside from these shortcomings everything was good!

Any one of these issues in isolation could probably be managed and worked around during testing–after all, most of us can get by without a report for awhile, but in the end so many piece parts required for the DITL testing were incomplete that the testing was seriously delayed.  In many respects the project became a slave to the timeline and the quality of the deliverables was allowed to slide until this testing activity late in the project lifecycle.  A more thorough and dispassionate ongoing review of each of the components required for testing would/should/could have revealed their status and enabled a better deployment of resources to get the deliverables designed, built, and individually tested.  Instead the project went through a period of triage to assess which were in the worst condition, which would take longest to fix, and which dependencies existed between the parts.  The happy ending is that some weekend work and some dedicated brute force and intellectual effort resolved the situation.

The Takeaways

1. When you get parachuted into a project situation and you are told that you need to go execute an activity, take the time to layout your assumptions and push to get them validated.  It is far better to spend a couple of days on due diligence than having the situation implode all around you.
2. If the required parts are not complete, you need to make a judgment call on whether you can proceed with testing on a smaller scale, go ahead regardless, or wait until everything is ready.  Generally, I’d recommend testing whatever you can, but only if you are proving out something that hasn’t already been shown to work in an earlier type of testing.
3. If you proceed with testing before all the parts are ready, you need to build in iterations of testing – a kind of regression testing – to ensure that as each new finished part (code, configuration, etc.) is introduced it does not break anything previously tested.
4. Be prepared for increased overall project phase elapsed times when you have staggered completion of deliverables that need to be part of your testing activities.

I listened to a presentation by Robert Enslin. He is the President of SAP North America. Listed under Keynote speaker when you first login.

We are hearing a lot about businesses not wanting to spend. ERP projects being put on hold until the economy turns around. But what Mr. Enslin was saying was on target: As a business one has to choose to prepare to emerge on top when the economy changes around or to be shaped by circumstances and hope for the best. Mr. Enslin of course would encourage choosing to “move forward with business regardless of the state of the economy.”

Sounds great but how are business decision makers supposed to do this? He called it clarity. Market strategies are changing minute by minute. Antiquated systems cannot get decision makers the information they need fast enough. Clarity is the ability to see clearly what is happening in every aspect of operations. “Best run businesses must see clearly, think clearly and act clearly.” In addition the business community anticipates additional pressures from the government as well as stake holders for transparency.

So how does a business achieve clarity? He identified 6 strategic areas.

1. Manage Cash
2. Run Lean Operations
3. Drive Compliance Activities
4. Get Closer to Best Customers
5. Retain Top Talent
6. Protect and Nurture Your Brand

He also noted that companies must move away from a cost focused mentality and toward value focus. To do this they need to identify and set strategic priorities and enable the strategy to achieve them with the intelligent use of IT. An agile IT platform is increasingly relevant, as the margin of error gets smaller and smaller.

SAP can help with Value Methodologies. Mr. Enslin identified 3 components here:

1. Discovery
2. Realization
3. Optimization

Discovery; start the discovery with benchmarking against peers. The ASUG SAP Benchmarking Program with benchmark by Industry, Region or Company Size.

Realize more Value. For a large business Suite 7 was released last November to 300 customers and released early this year (2009) for general availability. Mr. Enslin calls it “innovation with minimum disruption.” The enhancement package for Suite 7 recently released allows access to new functionality without upgrading.

Optimize Value. Here Mr. Enslin takes the opportunity to introduce SME offerings: Business All in One, Business by Design, and Business One.

Mr. Enslin cites G.T. Solar an All in One client: G.T. Solar was a $50 million revenue business without a central IT program. They implemented SAP Business All in One in 16 weeks, and over the last 2 years have seen 900% revenue growth.

The message is timely. We do not dispute the times, the economy or the uncertainty business is faced with; SAP offers tools to help businesses not only navigate through these times but to move forward regardless of them. DataXstream can help you choose which tools best fit your business needs and help your business realize the value of its SAP IT investment.