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.

Overview

I am currently working on an SAP implementation project that is just starting its realization phase.  One of my first tasks, as a member of the technical implementation team, is to review completed functional specification documents for RICEF objects.  These documents, written by functional subject matter experts, are supposed to detail business requirements that address gaps, and which need to be incorporated into the system being implemented. The purpose of the review is to make sure that the functional specification documents are complete, accurate, and contain the approval signatures required to move on to the technical design phase.

In my career, I have had the pleasure of working with some first-rate functional analysts who know how to draft an excellent functional specification document in a timely manner.  It is this type of performance that helps to move a project along in the right direction, on schedule, and within budget.  Likewise, I have had the not-so-pleasant task of working with not-so-first-rate functional analysts, who draft functional specification documents that are not clear, inaccurate, and incomplete.  The risks here are ultimately manifest as project delays and cost overruns.

The Good…

A really good functional specification document contains enough detailed information about the business process to enable a technical designer to use it as the foundation for drafting a complete and accurate technical design document.  The functional specification document should not only highlight the presence of a gap, but should demonstrate how the business process, accompanied by automation, will close the gap.  This document must also indicate the abnormal processing requirements – what should happen when that report or interface does not run, what are the recovery steps, how are key employees notified of the problem, etc.  The content of a functional specification document must be tuned to the flavor of the RICEF object that it is describing.  Since they perform very different tasks, a report specification document should be very much different from an interface, conversion, enhancement, or form functional specification document.  Using functional specification templates helps to insure the appropriate content for each type of RICEF object.

… and the Not-So-Good.

I am sometimes astonished by the sparse content that is actually offered up for review.  “We need a report” really does not tell me a whole lot about the business process that I am supposed to automate.  Nor does it even hint at the report purpose, content, layout, user interface, execution mode, authorization requirements, or error handling.  And likewise, “Build me an interface” does not even begin to describe the direction, payload content, mapping, frequency, error handling and recovery steps.  It would be so wrong for me to attempt to build a technical design on such meager functional definitions.   One of my favorite cartoons shows a development manager standing in front of rows of programmers saying “You guys start coding.  I’ll go and find out what they want”.

I am further astonished by:

a)      the project managers who apply pressure to accept inaccurate and incomplete functional specification documents, to give the impression that the project is actually moving forward and making meaningful progress.

b)      the functional analysts who whine incessantly when their paltry functional specification document is not accepted.

A functional specification document that does not meet expectations must be upgraded until it does.  But bouncing a functional specification document back and forth like a ping pong ball between the functional team and a technical reviewer is inefficient and wasteful.  I find that the best way to quickly firm up a weak functional specification document is to thoroughly research all of the issues that I found in the document, formulate proposed solutions where possible, and then schedule a face to face collaborative meeting with the functional analyst and the business process owner(s).  This type of collaboration can save hours, days, or even weeks of wasted ping-pong posturing, and that is always best outcome for the project.

Off-Shore Technical Resources

This face-to-face quick resolution scenario typically cannot happen if you have an off-shore technical contingent in play.  In this case, it is absolutely imperative that the functional specification document be most accurate and complete to mitigate the risk of excessive time loss.   Why is that?

Off-shore resources are sometimes time zone shifted eight or more hours ahead of where the project is located.  If a functional specification document is released for review, it will not be analyzed until we have left for the day.  If the off-shore reviewer has questions or raises issues, we will not see these questions or issues until the next day when we arrive at the project site.  When we respond to the questions or issues, the off-shore team will not see our response until we have left for the day.  And so on.

Under these conditions, a poorly written functional specification document with issues takes days instead of hours to resolve.  This leads to unnecessary project delays and cost overruns.

When One is Really Many

That 3PL interface, which was scoped and planned by the business process owners as a single RICEF object named “The 3PL Interface”; and for which only one interface functional specification document is written, is actually many RICEF objects.  We need to move purchase orders, inventory receipts, advance ship notices, inventory picks, and cycle counts between the two interfacing partners.  Each of these represents a different payload, different mapping, is triggered by a different point in the business process, has separate error handling and recovery procedures, and requires a separate RICEF development object.

That single enhancement functional specification document, which addresses all of SD pricing, has the potential to extend into many different user exits.  I just finished coding an ABAP proxy that was functionally specified as one interface.  In fact it was four.  The requirement was to search the database for sales and invoice data starting with either an invoice number, sales order number, customer name, or company name.  Each of these search techniques required the development of a separate method.  The only pieces of code that were shared among the four search techniques were the input parameters and the output return table.

The point here is to make sure that the project planners understand the real complexity and effort required on the development side, and to make sure that the project plan and budget reflects these more realistic metrics.  This really goes a long way to stop everyone from wondering, “It’s only one interface!  What is taking development so long?”

Great Expectations

So what is a reasonable set of expectations for a really good functional specification document?  What is it that we are asking the business analyst to do?

First, let me describe what I do not expect.  I do not expect a business analyst to write code, build tables, design efficient database retrievals, or to decide that one BAPI, function module, class, or IDOC is better than another.

Here is what I do expect:

A clear definition of a business process that is repeatable, and which actually works.  As a pre-automation test for data conversions, I always require the functional analyst to manually enter one of whatever, using the standard SAP transaction for which a conversion program is to be built. Many times, they can’t because the system is not configured correctly, the supporting data is not present, or any number of other reasons which cause the transaction to fail.  An interesting observation is that there is much indignant huffing and puffing during this manual entry “test” process.  But when the manual test fails, I simply remind them that I cannot automate a broken or non-existent business process.

A clear definition of what should happen under abnormal or failure circumstances.  This must include error handling, notification, recovery and reprocessing steps.

A business process that can efficiently be automated.  Requiring a search of sales order header text for the phrase “This is a red order” is a very bad design for automation purposes.  While such a design is technically possible to build, it will certainly be inefficient at run time, and may not always produce all of the red orders.  This is because the key value is a free-form phrase that can and will be misspelled, and abbreviated, along with countless other mutilations of the key phrase “This is a red order”.  There are much better business processes and technical implementations that will more efficiently and more accurately find all of the red orders in your system.

An explanation of the need for development.  Exactly what is the gap, and how will automating the business process close the gap?

Screen shots from SAP transactions depicting data that is to be retrieved or stored.  From the screen shot in the transaction, I can usually determine the exact table and field in the SAP database.  Note that some business analysts are very adept at identifying the actual underlying table and field name.

Clear and concise details with respect to data mappings, formulae, data transformations, conditional processing, etc.  If I come to an intersection and it is unclear whether I should continue to go straight, turn left, or turn right, then the functional specification document needs a bit more detail behind it.

How to insure Consistency in Functional Specification Document Review

Design a separate functional specification document review checklist for each flavor of RICEF object.  Distribute these checklists to the functional specification writers so that they know what the expectations are.  Using a checklist will help to make sure that your review process is consistent and accurate.  Improve these checklists over time.  My Form functional specification checklist document now includes the following check:

Is it physically possible to print the specified content on the specified form using the specified font style and size?  Was an actual printed mock-up provided as proof?

- but only after I had received a functional spec for a form that required four inches of print content on a one inch label.  And somehow, the business analyst who wrote this particular request erroneously thought that it was my problem to solve.   After all, writing code is magic!  Isn’t it?  In this case, I pushed back and insisted that an actual printed mock-up be produced – one that I would then agree to automate.

Summary

A good functional specification document will help tremendously in moving a project forward in the right direction with minimal cost and risk.  A poor functional specification document has serious potential to cause project delays, and  schedule and cost overruns.  The best goal for the project is to achieve a good functional specification document, using whatever means required.

Now, put me behind a keyboard in front of a computer application which I have never seen before. My user experience is all over the map – somewhere in the continuum between most excellent and very poor.  Some application user interfaces are extremely intuitive, well-designed and easy to navigate, logically follow the business process flow, and provide real meaningful help when needed.  Other application user interfaces are extremely difficult to navigate, are not intuitive, do not follow a logical business process flow, and offer little or no meaningful help. And sometimes in these difficult user interfaces, not only has the location of the steering wheel been moved to a totally unsuspecting location, but its appearance has been changed so that, even when I see it, I do not even recognize it as being the application’s steering wheel.

A well-engineered user interface is no accident.  It doesn’t just magically happen.  It must be woven into the fabric of the design and the code; and it should never be shoe-horned into the application as an after-thought.   It takes a lot of up front planning, designing, testing, functional effort and technical effort to produce a really good application user interface.  And yes, designing, building, testing, and implementing a good user interface for your application will extend the delivery time of whatever it is that you are building.

Why is a well-designed and ergonomic user interface so important?  You could have built the best application ever developed.  But if it is unusable, it will never get very far.   Countless hours are lost every day as thousands of frustrated users spend extra time and effort wrestling with poorly designed user interfaces, rather than focusing on their jobs.  And when the frustration levels reach a certain trigger point, the users will seek out and find alternative ways to perform their duties.

Here are a few examples of some very interesting user interface experiences that I have personally encountered.

Let’s Punish the User

I thought we had gotten over this one a long time ago, but I was bitten by it recently while I was completing a web form.  Here is the scenario:

I am completing a screen form containing several fields, and I make an entry error in one of the fields.  When I try to submit the data, the application rejects the submission, and sends me a message indicating where the error field is, and then clears all of the fields on the screen and makes me re-enter all of the data again.

Bad User!  And, because you made a mistake, you get to start the entire form all over again …   and again … and again … and again …

When Help is not Help

I am especially fond of this one.  I need help, so I look for the HELP ICON.  I find the HELP ICON (because it looks like a help icon should look, and it is located where a help icon is typically located … well, sometimes it is) and I press it.  The anticipation of actually getting the help I need is overwhelming.     And the help information finally appears on my screen and reads something like this:

The exact details of what you want to know are located somewhere in our behemoth website.   Now, we could tell you exactly where and actually help you to solve your problem very quickly,    but we’re not going to, because then you won’t have spent hours wandering aimlessly through our website’s colossal labyrinth.  And while you are in there, don’t let the Minotaur get you!   Please go to www.needleinthehay.com.

Well, at least they said “please”.

The Errant Error Message

I can’t tell you how many times I have made a data entry mistake, only to be “helped” by this not-so-helpful error message:

Incorrect Entry

This is irritating.  If I don’t know why it is incorrect, I can’t fix it!  If the application is intelligent enough to determine that the entry is incorrect, it certainly is intelligent enough to tell me which of its check rules were violated (in plain user-oriented language please).

I really like this one:

Program Error 1776

This truly tells me everything I need to know!!!  Maybe the developer knows what error 1776 is, but I don’t.  Maybe I can find the meaning of error 1776 at www.needleinthehay.com. (I hope the answer is not too close to the Minotaur’s lair.)

Hey developer – can I have your phone number so I can call you every time I see one of these messages?  Maybe then you will get the hint and stop the madness!

I’ve fallen in and I can’t get out

Sometimes, I manage to navigate to a screen that has no obvious means of escape.  So I’m trapped until I can figure out the top-secret mouse click or keystroke combination.  Should I place the blue orb on the green pedestal?  I guess I really should have left a breadcrumb trail.  Or maybe the developer was a ZORK player!  Let’s try XYZZY!!!

Just Give me a Good Example

Like pictures, a good example is worth a thousand words.  Good examples are worth their weight in gold.  A really good example can get me to where I want to be – understanding what I need to know – much more quickly than an entire chapter of words.  Good examples are hard to come by.  They require lots of thought and planning.

Here is an example of a bad example:

2  @  2   =  4         where ‘@’ is some arithmetic operation.

OK – did we add or multiply here?  Who knows?  This is totally ambiguous, and a bad example.

Here is an example of a better example:

2  @  3   =  5         where ‘@’ is some arithmetic operation.

It is obvious here that the “arithmetic operation” was addition.

The Cluttered Screen

One of my favorite games as a child was the type of puzzle where a group of objects is hidden somewhere in a very busy picture.  The names of the hidden objects are listed on the side of the page, and the object of this type of puzzle is to “find the hidden objects” that are on the list.

Some user interface designers and builders are very adept at hiding items on their incredibly busy user interface screens.   Perhaps in their youth, like me, they liked to play with “find the hidden objects” puzzles also.  The problem here is that they are designing “find the hidden objects” puzzles into their user interfaces!  Is it really necessary to squeeze in every data field and push button onto a single screen?  Is the perception here that a single screen, no matter how extremely busy, is somehow easier to use?

My end-user work instructions tell me that if I push the “show details” button, I will then know the meaning of life, the universe, and everything.  But where is the “show details” button?  I am really good at playing “Where’s Waldo”!  Just give me an hour or two and I will find it!

The Plethora of Scattered Screens

The opposite of the tightly packing everything onto a single cluttered screen is the scattering of the user interface among way too many screens.  It becomes a memory exercise to remember the user interface elements that I have already touched, and a scavenger hunt to locate the interface elements that I haven’t found yet.  Let’s see … what was that part number that I entered on screen 152?  Or was it on screen 376?  And where do I go from here to get the order number?  Does anyone have a roadmap that I can follow?

Maybe if we could consolidate the enormous number of screens down to a few that represented logical work flow groupings, I could spend less time screen hopping and be more productive.

Let’s Get Colorful and Fontsy

They use several different font styles, sizes, and colors.

I suppose that’s OK, isn’t it?  It really wasn’t too difficult to read the sentence above, was it?

Consistency is Key

Let’s examine the rental car scenario that I posed at the beginning of this blog.  The reason that I am able to quickly enter the car and drive away is because a recognized user interface standard has been established and consistently applied to all automobile makes and models.  Among the various cars that I am faced with, the gas pedal always looks like a gas pedal, and is always located on the driver’s side floor to the right.  Likewise for the steering wheel, the brake pedal, and most other major user interface elements found in a car – they all adhere to standards of look and feel and placement.

It should not be too surprising then, that the not-so-ergonomic user interfaces that I have encountered do not even recognize that a standard might even exist. The really difficult user interfaces mix things up, and change the appearance, behavior, and location of controls from screen to screen.

Summary

The ergonomic user interface – the one that is intuitive, provides real help when needed, follows an organized logical workflow, and is easy to use are important components of a really great application that end users will want to use because it actually will be the best way to do their job.

Here are a few guidelines that I use whenever I build a user interface:

1)      Totally and completely understand what the business requirements are, and what the user needs to accomplish.  This is the first and most important step to building a good user interface.

2)      Design the user interface to follow the workflow.

Organize and logically group functions together.

3)      Determine if standards exist and consistently use them everywhere.

Position controls in expected and predictable locations.

4)      Give feedback to the user in a timely manner.

Don’t wait until screen 3 to inform the user that there is a problem back on screen 1.

5)      Craft meaningful error messages in user-oriented language.

Temper the messages appropriately – if everything is hot, then nothing is hot.

6)      Make sure that the “help” you provide really helps.

Ask the user to confirm before deleting anything.

Use list of values help whenever possible.

7)      Use default values whenever possible.

This avoids potential data entry errors and makes the user interface more efficient.

For example, if I work in warehouse 2, I should not have to enter that information every time I ship an item.

Display default values in pre-populated, grayed-out fields; but add a pushbutton to allow for the rare occasion when the user must override the default value.

8)      Keep training documents current.

As a developer, you may not own the training documents – but someone does.

There is nothing more frustrating than a training document that does not match the actual program behavior screen for screen and mouse click for mouse click.

I hope that this blog can provide some useful hints for building effective and efficient user interfaces.  Please reply to this blog if you have any most interesting user interface stories that you would like to share with our readers.

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.

The choice to upgrade your company’s SAP platform is a very important business decision.  Many criteria need to be considered when determining if an SAP upgrade is the right move and, if so, what type of upgrade needs to take place (ECC 6.0, Enhancement Packs, etc.).  A successful SAP upgrade requires the determination of your upgrade requirements, proper planning, and an assessment of technical and functional risk.  Below is a sample of our SAP Upgrade Checklist white paper:

Determine Your Upgrade Requirements

1. What are the business reasons for upgrading? Support from the business for an upgrade project is most important.  If there are no business reasons for upgrading, then you should probably not do it.  Included here are the business risks incurred by not upgrading.
2. What are the technical reasons for upgrading? Included here are the technical risks incurred by not upgrading.  (Posture increasing maintenance fees for old versions or complete support withdrawal as a business risk – not a technical risk.)

For the complete list, download the full white paper:

SAP Upgrade Checklist

Related Links:

1. SAP Upgrade Project Plan
2. SAP Upgrade Project Management Considerations
3. Contact Us

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!