SAP ROI — Enterprise Architecture & Business Solutions

3.      ERP or SAP Process issues 

Let me start with a caveat to this section.  No matter how good, thorough, experienced, or conscientious a consultant or a core team member is, there will always end up being a few process gaps, and an occasional completely missing process discovered at go-live.  Now that the caveat is out of the way, there are many reasons for the process problems: inexperienced consultants, company employees who miss some of the process exceptions, inadequate training, insufficient integration testing, lack of user acceptance testing, and other reasons. 

The bulk of the items causing process problems generally fit into three core areas, 1) design or blueprinting, 2) change management, and 3) testing. 

SAP / ERP Design and Blueprinting 

Your business probably developed numerous processes and exceptions over many, many years.  Some of those processes were also developed as the need arose, and in an ad hoc manner and may have many inherent inefficiencies.  SAP projects are generally tasked with replacing all of those years of collective knowledge and processes, as well as any “broken” processes in six months to a year, and on very large projects in maybe a couple years.  That is no small task and to be successful it truly takes an experienced consultant.  As I’ve previously written about, this is one of those areas that all of the fakes end up costing your SAP project and your company big money.  And I mean big money over and above what you pay them.
 
A good blueprint should translate your scope into all of the key business processes that your company does, and then the key process components needed to support those processes.  I generally prefer a blueprint that has inputs (or some type of process trigger), the process itself, and then the outputs.  It should also contain the key master data requirements, any necessary FRICE (Forms, Reports, Interfaces, Conversions, and Enhancements) development objects, and the key business areas affected.  If there is sufficient time in the Blueprint phase, the Blueprint itself should also begin to capture some of the key change management issues.

Poor blueprints (missing processes, too generic, too high level, etc.) cause serious project delays and flared tensions by constantly dragging your project back into “Design” mode when you should be in full project execution.  It takes up the time and effort of other integrated teams, and generally causes a “drag” on the overall project.  Obviously this burns up budgets too.  Worse still, a poorly designed Blueprint is often blamed on the company, the department, or the key resource on the project who is responsible for that area.  Unfortunately those “smokescreens” are often used by consultants who are not that skilled at extracting the necessary information needed for a good blueprint.  It’s always easy to “blame” the client through the backdoor by putting the responsibility on a core team member, or some other portion of the company / client team.
 
If there is a genuine issue with a team member, an experienced consultant should raise this issue during the process when it is encountered.  Frankly, if it suddenly comes up AFTER the blueprint is due, it should be seen as nothing but an excuse by the consultant.

ERP Project Testing 

Another area to begin addressing processes is during testing.  Any integrated application like SAP should include at least 4 primary types of testing.  No matter what name is used, they are generally individual transaction tests (sometimes called “unit tests”), transaction strings or processes within the same module like Sales and Distribution (“module tests”) and then full-blown cross module tests that test entire process chains from start to finish (true “integration tests”), and then finally tests that involve the wider user community often called “user acceptance tests” or “day in the life” scripts, etc.
 
During testing, while it is important to follow the scripts to be sure that all of the proper “boxes” are checked off, it is equally important to test more.  “Integration tests” and “user acceptance tests” serve as the last opportunity to find and address process gaps.  Sadly some consultants (and some consulting firms) see this as an opportunity to absolve themselves of responsibility for potential problems or shortcomings.  As a result, they will often strictly enforce that the script must be followed to the letter and no deviation is allowed and no exception processing is allowed.  There is a legitimate need to control the process to ensure that the work is done and that the known processes work sufficiently as designed, however there should also be some mechanism to address gaps or exceptions.  One simple method to accommodate this is to create a space on the signoff sheet that directly solicits comments about any process gaps and any exception processing that might be needed.  Final signoff of the testing should not be signed off until this commentary is converted into additional testing scripts or some manual process defined to address the processes.

For final integration testing you may wish to pick random documents from your current business operations to run those through the system with the converted data.  This will give you the best test to ensure things are working correctly.  For example, you may wish to choose 10 or more each of the sales orders, purchase orders, production orders, reports, etc.  The key is to use something that is meaningful and can be verified back against your current system.  

ERP Project Change Management 

Unless you completely re-design and re-write SAP to do all of your processes exactly the way they were done before, there will be change management issues to deal with.  And unless you also re-write the user interface, there will still be training and user acceptance to accommodate.  If you’re going to re-write everything, why bother with a packaged system application at all?  On the other hand, if you are putting in a package application such as SAP, Oracle Apps, or others, there are change management issues to deal with.
 
Change management generally encompasses a few key areas:  Training, communication, organizational change, process / job changes, and post production support.  Some change management is necessary on every project and if your company handles change reasonably well it may not be a struggle.  However, if your company has many employees who have done the same job for a long time, without much change taking place within the organization it will take a tremendous amount of “hand holding” to get them through even small adjustments. 
 
You will need to assess your own organization and its ability to absorb change for whether change management resources should be budgeted.  From a project perspective however, one of the key things to be wary of are consultants who want to add new functionality without understanding the impact on the organization. 
 
Business Change Management analysis case in point:  I was at a client where SAP’s Handling Unit Management functionality was the best fit I had ever seen.  They had high dollar custom made steel transportation racks that needed to be inventoried and returned, the packing was consistent and uniform, their production volume was not intense as a sheer number, and they already had wireless bar codes with some warehouse automation.  From a functionality standpoint it was almost a “no brainer” and a great ROI on the automated tracking, inventory, and return of the units.  However, a more careful look at the organization showed a very different picture.  The staff responsible for maintaining the data and processing the transactions had not been reliable with data maintenance or with processing in the past.  Also, because of the organization there was virtually no chance that would change in the future.  

A less experienced consultant with limited project or change management experience would have seen this as a great opportunity to throw some “gee whiz wow” new functionality at a company.  They keep billing for the new work (a scope change), they would be needed almost indefinitely for production support, and they’ve got a great candidate to blame for why you have to keep paying them.  Sadly I’ve seen this scenario played out over and over again.  On a recent project I saw this with the implementation of SAP’s Customer Service and Solution Database functionality.  The company had an “ugly” but mature and working solution, they were downsizing the customer service area, the SD scope for the project was already pretty significant, sales were beginning to slow, portions of the business were being spun off, and employee morale was already low.  The consultant convinced them to “replace” their solution database and customer service functions from a CRM application that they did not even retire.  So there weren’t even any software license savings.  The consultant got to stay on, support an unnecessary process (the legacy app was not going away and worked fine), and was needed for post production support.  

 The process related issues will quickly separate experience from inexperience.  There are lots of good consultants out there, and then there are lots of less than satisfactory fakes in the market as well.  Unfortunately it is it the “good” consultants who are often penalized for smooth and successful go-lives by early roll offs.  Meanwhile fakes and less skilled consultants are rewarded by extensions to support poorly designed processes and inadequately prepared user communities at go-live.  The old adage rings true here that “you get what you pay for” as long as you have a way to separate the genuine articles from the fakes.  In the end, there are many hidden ways you end up paying as much or more for inexperienced consultants, not the least of which are the many hidden ways their SAP implementation approach impacts your business.  A truly seasoned consultant may cost a little more up front, but at go-live with the quality of delivery and the overall satisfaction of the solution it can pay dividends for many years.  

 In essence, the need for careful process understanding can not be underestimated.  The amount of change your company can absorb, the impact of processes being brought into a package application like SAP, and the cost to your implementation budget should all be considerations. 

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
http://www.r3now.com/planning-for-a-smooth-go-live-part-1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
http://www.r3now.com/planning-for-a-smooth-go-live-part-2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
http://www.r3now.com/planning-for-a-smooth-go-live-part-3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
http://www.r3now.com/planning-for-a-smooth-go-live-part-4
(custom development, costs and consequences of inexperienced developers)

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• The Real Reason Executive Participation Creates IT Project Success
• SAP as a Change Enabler

Scope, scope, scope.  Over the years, hundreds of articles, documents, and warnings about scope setting, scope control, and scope management with ERP and IT projects have been written.  We’ve heard it all before.  Project scope is one of the biggest ERP project risk factors, yet few articles offer practical insight on setting or managing scope.  From an SAP perspective, all of the tools and resources have been provided to do the job correctly, right from the beginning, even before an RFP is issued.

Since the mid-late 90′s, SAP has provided an extensive implementation toolset that is not well understood by many, and is even less utilized to its fullest potential.  First there was the ASAP Methodology (Accelerate SAP), then ValueSAP (an enhanced ASAP toolset), and finally Solution Manager.  ASAP and ValueSAP were external to the SAP application, but Solution Manager is built in and incorporates the tools and resources available in the SAP ASAP “toolkit”.  Since SAP has over 20 Industry Solutions, and literally tens of thousands of implementations, they have EVERY major process covered, to a tremendous level of detail, in spite of what competitors might claim.  As a result, using the supporting tools correctly, there is little reason why anyone should be very far off in their scoping efforts.To get more insight and get specific details of the project scoping tools and resources SAP offers, as well as more details on how to do this scoping exercise see the article entitled “ERP and SAP Business Case for ROI, Business Benefit, and Success. It provides information on up front project activities, including preparation for your ERP implementation, upgrade, or enhancement RFP.  The resources listed there can be obtained directly from SAP free of charge for carrying out some of the “Discovery” and “Evaluation” phases of your ERP project.

Where do you Begin Your SAP Scoping efforts?

A well written, comprehensive scope document is critical to the success of a project.  Even before the project begins, that initial scope can make a huge difference in RFP’s and setting the right tone and direction for a project.  A good scope helps to determine realistic expectations and can make the difference between an on time, on budget project, or one that busts the bank. 

When embarking on an ERP implementation, such as with SAP, many companies “don’t know what they don’t know”.  In other words, how do they successfully translate their business requirements into a meaningful template to determine budget requirements, do an RFP, or ensure that their project has a good foundation.  Having little or no experience with SAP terminology, or the depth and breadth of the SAP application, few companies are able to put together a thorough RFP to be able to truly compare vendor proposals.  As a result there are times that a company may end up with a far less than optimal implementation partner.  Where a well-defined scope and carefully structured RFP process helps weed out less than optimal implementation partners, poorly defined scope could cost much more than just a blown budget.

What to Consider in SAP Scoping

Obviously there are budgets and limits to what can be done in an implementation. The ideal situation for many companies is to determine a Phased scope right from the beginning. [1]  You should know, even before submitting an RFP, whether or not you will add additional products or enhancements in future phases.  If you are certain you will be adding on functionality in the future such as CRM (Customer Relationship Management), SRM (Supplier Relationship Management), APO (Advanced Planning and Optimization), SEM (Strategic Enterprise Management), BI / BW (Business Warehouse), or other advanced functionality, it is important to know this right from the beginning.  Even though this additional functionality may not be part of the initial project scope, it should be considered during the blueprint phase to ensure that there isn’t a significant amount of additional engineering to accommodate the extra functionality and applications later. 

You may also see some benefit from the SAP core ERP functionality such as QM (Quality Management), PM (Plant Maintenance), PS (Project Systems) or other SAP functionality but it may not be cost effective to implement in the first “Phase” of your SAP project.  Depending on your needs and actual requirements of the business (not the technology) it may or may not make sense to implement some of these additional SAP functions in the future, but a detailed exploration of your scoping requirements will reveal this.

Some of the critical considerations for your company’s implementation or upgrade are whether or not you will need non-SAP “bolt-ons.”  These should be considered and budgeted for right from the beginning.  Consider making a direct request to the vendors during the RFP process about how they will handle the following items, and what additional costs might be required:

• Training
• Structured Compliance (SOX, ISO, TS, etc.)
• Training Documentation
• Change Management
• Fax Ouptut
• E-mail Output
• Taxes
• Bar Code Interface
• Data Transformation Middleware (for legacy system interfaces)
• EDI / XML or other electronic exchange
• J2EE (or other Java Platform for online functionality
• Web Extensions

If you are already past the RFP process, it is crucial to be sure that any or all of these areas, and any other “specialty” solutions are addressed during the blueprint phase of the project.  Each of these items may require additional software or expertise that may or may not have been budgeted.  A well done initial scoping requirement, along with a thorough RFP will help to ensure that you are truly comparing vendor bids in a more realistic fashion.

Where to begin the SAP Scope Effort

A good scoping effort should address every process that your company needs to implement.  Your scope does not need to address the details of every process, but it should address every major process and each major sub-process. SAP provides two outstanding tools for doing this (again, for other tools that are available read the article referenced above for more details):

1)  A business process scoping spreadsheet (this is an older ValueSAP scoping spreadsheet which should be sufficient for RFP preparation) updated with the ECC 6.0 version on 4/22/2010.  Please note, this is a Microsoft Excel spreadsheet, it is fairly large so it may take a few moments to download, and then your virus scan software will probably check the file.  Please be patient when opening the file by clicking on the link.
2)  A comprehensive online help system

The new SAP Solution Manager has all of this built into the application, but before setting up a test or demo system the Solution Manager application doesn’t do much good.

3)  Define a timeline for completing the initial RFP or Project scoping (expect anywhere from 2 – 12 weeks depending on your company’s complexity and size)
4)  Identify the key business resources that will be needed for the effort.
5)  Avoid analysis paralysis and stick to the scoping timeframe (the blueprint phase of the project is to finalize scope).
6)  Define any external system requirements or special “bolt-ons” that might be needed.

Finally, if this is a scoping exercise to support an RFP, be realistic in your expectations of both scope and budget.  If there is a significant amount of advanced functionality that you would like to implement, consider putting it in a future phase under a separate budget.  When doing the scoping work, consider using Phase numbers in your scoping exercise.  For example, a “1″ for the crucial core functionality, a “2″ for important additional value added functionality but that might need a separate project phase, and a “3″ for nice to haves but reserved for some yet to be defined future phase.

One of the keys to realizing benefit from an SAP implementation is in getting the application up and running as quickly as possible. 

The more effort you put in early in the process, the clearer expectations are set and the more satisfied you will be with the end result.

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

[1] I’m a fan of the “phased” project approach because it allows the company to develop some internal competency and skill with the product before adding on additional integrated functionality.  It also allows for a company or organization to do an honest assessment of the implementation vendor and their consultants by the time the project is completed to see if they ever want to do business with that vendor again.  Sometimes, for better or worse, once the vendor selection is made you may end up tied into that vendor for the duration of the project.

Having said this though, one of the side effects of this Phased approach which must be planned for is that many system integrators will “abandon” previously implemented sites as soon as they have to move on to the next one.

Related Posts:

• Planning For a Smooth Go-Live: Part 3
• ERP and SAP Business Case for ROI, Business Benefit, and Success
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• SAP Customer Responsibility for SAP Project Success
• SAP System Vendor Project Success Criteria 1

SAP as a Change Lever

SAP can deliver amazing results or mediocrity, but that depends on you!

If your company has decided to implement or upgrade SAP the results you achieve depend on several things.  Some of the keys to business results and SAP success depend on your business reasons for the implementation and your commitment to excellence in staffing your SAP project.  That excellence in staffing is not just your internal resources but also the vendor you select to guide you through the process. 

SAP as a Corporate Lever for Change

The key to optimal results from SAP or any major IT investment, especially an ERP system, is to use the technology as a lever for change.  If your focus is on the technology, or the ERP system rather than the business, all you’ll have in the end is just another system, more integrated and requiring more discipline, but just an IT system.  In the end, you’ll never realize the promise of what a properly implemented global ERP application, such as SAP, can do for your business.

“The software is less important than the changes companies make in the ways they do business. If you use ERP to improve the ways your people take orders, manufacture goods, ship them and bill for them, you will see value from the software. If you simply install the software without changing the ways people do their jobs, you may not see any value at all—indeed, the new software could slow you down by simply replacing the old software that everyone knew with new software that no one does…  To do ERP right, the ways you do business will need to change and the ways people do their jobs will need to change too. And that kind of change doesn’t come without pain.

The important thing is not to focus on how long it will take—real transformational ERP efforts usually run between one and three years, on average—but rather to understand why you need it and how you will use it to improve your business.”

Christopher Koch, The ABC’s of ERP.  CIO.com, November 17, 2005.

This focus on business processes and process change while using ERP as a change lever automatically helps to ensure greater company ”ownership” and control of any ERP project.  The whole reason a company undertakes a major IT strategy, such as a global ERP system like the SAP application, is for business benefit. 

Past the Marketing, what do you hope to GET from an SAP implementation?

 Too often in the consulting sales cycle the focus is on your “pain points.”  Pain points are an important ingredient for an ERP implementation but it should rarely be the single driving factor for implementing ERP.  Depending on your IT infrastructure and what SAP will replace, there may be ROI opportunities, and real cost savings available, but the big “GET” with an SAP implementation is the opportunity to transform the business.  It is important to go beyond just cost reductions.

If you go into an SAP implementation with your eyes wide open about some of the cultural changes with SAP, you will benefit tremendously.  The software will enforce a measure of discipline breaking down silos, breaking down walls, and requiring more inter and intra departmental cooperation. It’s important to know up front that there will be cultural and business process changes.  That type of business transformation is not easy but it is important to compete in today’s economy.

It is precisely because of the business process revolution that executive sponsorship, senior management involvement, and the very best talent for the project team the company has to offer are critical for SAP implementation or upgrade success.

After the “pain points” and the “cultural changes” along with the importance of senior management involvement, what do you hope to get from your technology investment?

Properly thought out, properly planned, and properly implemented, SAP gives you the opportunity to effect a business process revolution where true order of magnitude changes are possible. SAP techology can enable your company or organization to make changes in how you manage your business, address market and competitive pressures, and at the same time enhance your value proposition.

While replacing numerous legacy systems, their interfaces, and the maintenance costs associated with those legacy systems can be a tremendous justification for an ERP or SAP implementation for some companies, here is a list of the Top 10 Reasons for an ERP implementation:

Benefit

Improved management decision making

Improved financial management

Improved customer service and retention

Ease of expansion/growth and increased flexibility

Faster, more accurate transactions

Increased revenue

Cycle time reduction

Improved inventory/asset management

Fewer physical resources/better logistics

Headcount Reduction

Hawking, Stein, and Foster – Revisiting ERP Systems:  Benefit Realization.  From the Proceedings of the 37th Hawaii International Conference on System Sciences (IEEE, 2004) citing from Davenport, et. al., (2002).

Notice that most of the expected benefits are forward looking and competitive in nature.  Unfortunately many companies have not implemented their SAP systems with this forward looking benefits approach.

In recent years, as SAP customer participation in public information sharing events has increased (ASUG, Sapphire, etc.), many SAP clients are seeing more and more benefit.  This benefit seems to be realized only with “Wave II” internal initiatives to add on additional automation functionality and reporting.  SAP’s “New Dimension” products like CRM, SRM, BI/BW, APO, and other technologies are making some difference for some companies, but even they aren’t fully delivering on business expectations.

Every SAP implementation or upgrade should become an opportunity to evaluate the transformation of your business.  Challenge your implementation partner and your own internal resources to make every SAP implementation or upgrade an opportunity for improvement.  Decide up front whether you will dedicate the time, budget, and energy to implementing more advanced and “benefit laden” functionality in the initial implementation or whether you will work to get the “core” package installed and then do a “Wave II” add on project after the business has had a little time to stabilize. 

I personally tend to favor a staged or “phased” approach because it gives the business an opportunity to evaluate the implementation vendor’s capabilities, develop some internal competence or expertise, bring some knowledge into the organization, and generally evaluate the company or organization’s ability to absorb the change.

How to use SAP as a change enabler to Transform your Business

Determine from the very beginning, even before the project begins, what the key performance indicators for your business are.  SAP has done a great job of compiling an example list of KPIs that they include as part of their ASAP methodology.  Right here on this site I’ve written extensively about the process and alignment of KPI indexes for business success.

What are the critical measures for each department within your business?  What are your goals and what are the crucial employee performance measures that are used in their reviews?  Look forward, what is the direction of your company, your marketplace?  What should you be positioning yourself for?  What benefits do you hope to get from your implementation or upgrade?  These and many more questions like this must be answered clearly before you even begin your formal project planning.  This should become your project charter.

Armed with this, you can make the most intelligent decisions about scoping your SAP implementation.  SAP is a massive application and contains some sort of solution to address nearly any performance measure or business benefit imaginable.  And while it may not be a 100% perfect fit for that particular measure, the application can be molded and shaped to fit nearly any requirement.  Between the intelligent use of reporting tools and SAP’s generous “user exits,” pre-delivered enhancements options, or a standard SAP bolt-on, you can implement an application that will enable significant changes in your enterprise.  Davenport, et. al., classify ERP potential three ways, Integrate, Optimize, and Inform.  Basically, the process of implementation, improvement, and then data analysis in an ERP application.

The key to ROI is getting to the data analysis stage as quickly as possible.  I call this transforming the management culture from an operational and task orientation to a strategic and analytical culture focused on competitive advantage.  To make that transition, it is crucial to ensure that your implementation partner provides consultants who are more than just SAP application consultants, they must be true business analysts.

Some of the steps to getting there include doing more of the up front work surrounding your ERP or SAP business case.  A proper business case will help ensure a far better vendor selection process, a better business blueprint, a better managed project, and more likelihood to deliver on-time and on budget with real business benefit.

You need Solution Experts for your SAP, ERP, or IT Implementation or Upgrade Project

To transform the culture, you must have SAP consultants who are also business savvy.  They must be business consultants who understand when it is time to “push back” because even though there may be a technical solution, there is a deeper business process issue that needs to be addressed.  You need real consultants who won’t just design technical “band-aids” but who have the experience and the skill to look at a problem and understand whether it is a technical issue or a business issue related to people or process (i.e. analyze people, process AND technology).  A true solution expert will help to resolve underlying business process problems, look for ways to make them more efficient or productive, and then apply technology to the process to automate it.  A solution expert is a business consultant first and knows how to apply technology to business processes.

If you are successful in partnering with a firm that provides solution experts and not just technicians, you will go far in realizing many of the benefits that SAP promises in a shorter period of time.  Not everyone on the entire project team needs to be a “solution expert” although that would be ideal, but many of the team leads should be heavily skewed toward being “solution experts” and not just SAP technicians.

Using SAP or other Technology to Transform Business Processes – practical suggestions

Key areas for solution experts to focus on during any SAP implementation or upgrade are growing your business or generating revenue combined with efficiencies or cost reduction.  When you begin any SAP project these two key factors should be built into the project planning process.  Otherwise, why are you doing an ERP project anyway if not for some business benefit?

Right from the beginning of the project this communication must be set, and the communication repeated and reinforced throughout the project.  Weekly team meetings should emphasize these key business benefit components and rewards recognizing and encouraging these benefits should be liberally used.

1)    Plan right from the beginning of the project (implementation or upgrade) for business growth / revenue generation and efficiencies / cost reduction.  Build it into the project charter.

2)    Gather all of your companies departmental or individual performance goals along with any key company metrics…  From these derive a set of KPIs.  Additional sources for deriving KPIs might be reports.  What are the commonly used (rather than ignored) reports that people use to do their jobs?  Are there any spreadsheets still “hanging around”?  All of these are good candidates for deriving KPI’s from.  Either for enhancing revenue or reducing cost.

3)    No matter how much effort it takes, be sure to read the resumes proposed by the implementation partner.  Ensure that most, if not all, of the team leads are real SAP solution and business experts, not just SAP technicians.  Pick your implementation or upgrade team carefully, you’ll be spending a lot of time and money on them and you’ll be entrusting your business to them as well.

4)    Use good project management techniques.  Glitz and glamor during the sales cycle won’t deliver an SAP solution.  Make sure your implementation partner has a REAL methodology, tools, templates, and resources to ensure a successful project.  Once you decide on an implementation partner, insist on a project plan and then publish it.  Even if it has to be frequently adjusted or modified, it gives targets and goals to aspire to.  If your implementation partner project manager doesn’t provide a project plan, or if they want to keep it hidden, get it corrected quickly or GET RID OF THEM IMMEDIATELY!  That may be a dangerous method of them trying to avoid some measure of accountability and responsibility.

5)    With a true focus on business benefit, be prepared to spend more time in the project preparation and blueprint phases with your implementation partner and a few key resources.  Get the scope and the project focus right from the beginning and it will make a HUGE difference!

6)    When contractors must be used, be sure your implementation partner uses the screening methods to find the right SAP consultant.

The next edition will focus on rapid but effective project scoping.  There is a simple project scoping method which will allow you to effectively scope even an initial implementation and then use it for a more effective RFP.  In a future edition I’ll cover effective RFP writing.  How to be sure your implementation partner candidates are proposing apples to apples.

Related Posts:

• The Real Reason Executive Participation Creates IT Project Success
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• Business and IT Alignment – Integrating Technology and IT Spend with Business