Uncertainty: The Elephant in the Room

Not long ago I was fortunate enough to have a conversation with two very fine gentlemen in the software business. They were part of an organization well-recognized for its leadership as a reseller and a developer providing an ERP (enterprise resource planning) solution for Tier 2 and upper-crust SMB firms.

As part of the conversation, I mentioned the fact that uncertainty is “the elephant in the room” throughout the IT (information technology) business.

What I meant by that is this: while the sales process is underway, it all too frequently happens that the two parties have differing views of the uncertainty involved in any project that might be undertaken as a result of their conversation. While they hold these differing views, however, they almost never speak openly and explicitly about the uncertainty itself.

My experience shows me that these two parties hold views of the uncertainty that take shape somewhat along these lines:

• The Client or, more correctly, at this stage in the process, “the prospect” may believe that there is very little uncertainty about which to be concerned. After all, he and his organization have tried to be forthcoming with the reseller. They have answered all the questions the resellers’ folks have raised from the first day they met, and they have done so as directly as possible.
  
  Because “the prospect” feels this way, the only “uncertainty” he may feel about any proposed agreement is whether the reseller is capable of delivering on all the promises he has made over the course of the negotiations.
  
  Also, since “the prospect” will hold the checkbook during the project execution, he feels pretty sure that he can force the reseller into assuming whatever uncertainty might remain in the anticipated project.
  
• The Reseller has been through this many, many times. He is well aware that every project is full of uncertainty. A short list of the uncertainties in the reseller’s mind might look like this:
  • Have we asked enough questions?
  • Have we asked the right questions?
  • What don’t we know that we should know about this company and how it works?
  • Can the modifications we anticipate be completed in the time we have estimated?
  • Will the prospect’s company allow this project to proceed in the time we have estimated, or will their inefficiencies, indecision or other operational problems cause us to incur unanticipated time and expenses?
    

Accidentally induced uncertainties

W. Edwards Deming once summed up very succinctly the uncertainty included in all human communications. Following a meeting between two parties, as one party was exiting the room, Deming turned to the manager he was consulting and said, “We know what we told him, but we don’t know what he heard.”

Communications between two human beings are full of such foibles. The fact that the reseller’s salesperson does not believe that he has made any “promises” upon which the reseller cannot readily deliver does not mean that the prospect has not heard “promises” that are very different from what was intended by the salesperson.

Under such circumstances, there is—more likely than not—no intention by the reseller’s sales team to mislead the prospect. Neither, most likely, is there any intent by the prospect (now, client) to somehow misconstrue what was said in order to take undue advantage of the reseller.

Nevertheless, such accidentally induced uncertainties too frequently lead to cost overruns, hard feelings between the reseller and the client, and—sometimes—even to failed projects.

Why don’t we talk about it?

My question is simple: When it comes to IT projects (or any kind of projects, for that matter), and whether it is a relationship between an external IT provider or an internal customer relationship, why do we so often ignore “the elephant in the room”?

Why are both the customer and the supplier both so reluctant to speak explicitly about the uncertainties that almost inevitably affect a project of any significance or size?

Let me know your thoughts. Thanks.

ERP Vendors and Customers: The Blind Leading the Blind

Writing in CIO UK magazine online, David Henderson’s article entitled “Why IT vendors must raise their game” makes several salient points. Not least among the points raised is the fact that “too many IT vendor sales personnel don’t really understand my underlying business processes and investment criteria….”

For me, however, the issue is somewhat stood on its head. Far too many business enterprises with which I have been involved have precisely the same problem internally. CEOs, CFOs and CIOs in many businesses buy new technologies without understanding their own underlying business processes and by what criteria they should invest.

What executives and managers should know

Executives and managers seeking ways to improve their business enterprises (read: make more money tomorrow than they are making today) too often buy new technologies out of “hope” or “desperation,” rather than with a clear and concise understanding of

1. WHAT needs to change in order for the business to begin making more money tomorrow than it is making today;
   
2. What the change should LOOK LIKE; or
   
3. HOW to effect the change (including what role any new or upgraded technologies might play in delivering the improvement).

Since they do not have the tools to concisely analyze what needs to change in order to make more money tomorrow, then they cannot know what the change should look like or how to bring about the change effectively. So, in the absence of clarity, they grope about in their darkness hoping that some change – any change – will bring them their desired end of higher profits.

Blind leading the blind

Like the blind leading the blind, the technology vendors and resellers who do not fully understand their prospects’ underlying business processes or appropriate criteria for investment (in fact, they understand them less clearly than the executives and managers, in many cases), console the yearning executives with platitudes and “rules of thumb” about how their latest and greatest “gee-whiz” technology will “reduce costs by X percent” and “improve sales by Y percent.”

Of course, this is precisely what the executives want to hear. Like the Sirens of old, the vendors and resellers lead many to spend. Even if they don’t fully believe what they are hearing from the vendors and VARs, the executives and managers frequently do not take time to calculate with any precision just how or why the new technology should, could, or would produce a return on investment (ROI) in their particular organization and circumstances. Instead, they close their eyes and ears to any negative thinking and, In the absence of any better ideas, these executives take out their checkbook to purchase the latest and greatest of new technologies. Of course, the correct general ledger account to which this “investment” should be charged is “Hope and Earnest Expectation.”

Serendipity

Sometimes good things come of this method. According to the industry literature, we can say that about one out of three such “investments” lead to noticeable improvement. Many times, however, the measure of improvement cannot be known with certainty. A growing company that shows improvement after some implementation cannot know which results may have occurred even in the absence of the new technology. A far greater share of SMBs (small-to-mid-sized businesses) simply assume they are “better off” if they are not clearly “worse off” following the deployment of some new technology. Some merely breathe a sigh of relief after some trying implementation period and, like a good Calvinist, say, “I’m glad that’s over,” without ever looking back to measure their return on investment.

My argument, however, is that “hope” and “serendipity” are not strategies and, while a few companies come to excel and even to dominate some markets for a short period of time based on little more than serendipity, it is not a sound strategy for long-term growth in any enterprise. For executives and managers return on investment should be seen as a primary responsibility. This responsibility should not be handed over to the technology vendor or VAR (value-added reseller). Neither should it be left to chance.

As W. Edwards Deming said so clearly: “It is management’s job to know.”

It is management’s job to figure out WHAT needs to change in order to start making more money tomorrow than the firm is making today. It is management’s job to come to a clear understanding as what that change should look like when it occurs. And, it is management’s job to define an unambiguous roadmap to effecting the necessary change. Then, it should be management’s job to measure and report on the return on investment yielded by their own keen insight.

Need help with this? Contact me at rcushing(at)GeeWhiz2ROI(dot)com and let’s talk.

©2010 Richard D. Cushing

5 Things SMB Decision-Makers Aren't Getting Right Yet About ERP

5 Things SMB Decision-Makers Aren't Getting Right Yet About ERP

Despite more than a quarter-century since the arrival of 'ERP' on the scene, far too many executives and managers are still struggling to get things right.

Click the link above to read the article in full.

Two Peas in a Prison

Have a good laugh at the expense of “Big ERP.”

Watch “Two Peas in a Prison” and then remember that the New ERP – Extended Readiness for Profit is what you really want.

Learn more about the New ERP – Extended Readiness for Profit by reading right here at GeeWhiz to R.O.I.
Thanks.

Generating Business to IT Alignment for successful packaged software (COTS) implementations

You've decided on the software you need, the business side has bought into it, and you've even picked your integrator. Now the hard work begins: Making sure that your software deployment strategy sets your company up for success, and that means making sure Business, IT and the Implementation Partner are in alignment.

First, we need to understand that Business, IT and the Implementation Partner are coming from different perspectives. Every party has a knowledge gap to address. Business best understands their existing business model and the underlying success drivers. The Implementation Partner understands the packaged software and has multiple years of implementation experience. IT best understands how technology supports the existing business model as well as how best to utilize existing corporate IT technologies. Alignment is generated only when a common understanding of the business model, packaged software and technology capabilities are shared by all three parties. When this alignment occurs there is effective communications and faster decision-making. Decisions move implementations forward.

Following is a recommended set of steps to develop a common understanding for effective collaboration during the COTS implementation:

1. Document existing business processes

It is an area that I see many packaged software implementations lack. The typical challenge I get is "Why document my existing business processes if I know they are changing?" Here are my reasons:

• Business users may not have a consistent understanding of their existing business model. Going through the exercise of documenting business processes will highlight these differences and driver deeper understanding.
• Documenting the existing business model will enable you to highlight the EXACT organizational changes that will occur. How can you manage organizational change when you do not have a clear understanding of what's changing?
• Business process maps can be a key source of information to quickly educate IT and the Implementation Partner on the existing business process model.

2. Educate IT and the Implementation Partner on the existing business model

Business should take a formal, iterative process to educate IT and the Implementation Partner on the existing business model. The entire project team should be involved in this training and should progress from a solution-level overview to a detailed business-role level "day-in-the-life" review. Following is a suggested approach for conducting this training:

3. Complete packaged software training BEFORE the Implementation Partner arrives

Just as it is important for your Implementation Partner to understand your business model and your business language it is important that Business and IT have an understanding of the packaged software and its language. Effective communication is a two party effort. Taking the required packaged software training before the arrival of your Implementation Partner will enable you to more effectively work together.


4. Have the Implementation Partner conduct supplemental packaged software training

Education is an iterative process - you will never learn everything you need to know for supporting packaged software in a classroom. Packaged software providers provide foundational training. I always say that the Implementation Partner completes your packaged software training. Implementation Partners have hands-on experience with configuration and maintenance of packaged software solutions.

5. Implementation documentation should be more business-oriented

Nothing encourages alignment more than being able to think like your end customer. Too often we create project documentation that focuses more on technology than business reasoning and justification. There are times were I am guilty of moving too quickly from what needs to be done to how will it be done without completely understanding why does it need to be done. At the end of the day we build software to drive business results.

Summary

Business to IT alignment is a strategic goal that can only be reached by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust. Implementing packaged software is an opportunity to generate greater alignment by developing a common language for effective collaboration. When alignment is achieved then decision-making is effective.


Adapted from the book Maximize Your Investment: 10 Key Strategies for Successful Packaged Software Implementations by Brett Beaubouef.

Changing the game for ERP/COTS implementations

I think we've all learned that implementing ERP/COTS using a traditional approach of (1) focusing on custom software and (2) having a purely requirements-driven approach results in greater Total Cost of Ownership (TCO). ERP/COTS can make for an expensive custom solution. What is required to change this trend is to evolve our implementation approach. Following are my top strategies for changing the game for ERP/COTS implementations:

(1) Focus on Business Results. Too often we focus on software scope and not the entire business solution (People, Business Processes, Technology). A challenge I make to my project team is to focus on all three components that drive business results. Also, spend time/effort on gathering requirements that drive value-add business results. Not all of the customer's existing business results drive real business value.

(2) Ask customers to formalize knowledge transfer on their existing business model. Every customer's implementation is unique and it is important that every member on the project team has a common understanding of the customer's existing business model. This knowledge transfer will enable implementation partners (consultants, IT) to better align with the explicit and implicit expectations of their customer. Implementation partners need to speak the language of their customers. Being in the same meeting or having the latest chat technology does not guarantee alignment nor collaboration.

(3) Implementation partners need to enable customers to lead during the implementation. This requires us to have a formal knowledge transfer plan and a progressive leadership style: Directing, Coaching, Facilitating, and Supporting. A new measure for success: the implementation partner leavers before the go-live because the customer is self-sufficient.

(4) Perform business solution modeling. Use prototyping for defining requirements and modeling to validate requirements/configurations. Use multiple validation techniques (peer reviews, modeling, testing) to identify potential problems.

(5) Implement to the current business process maturity level. Technology alone does not mature a business process. Meeting the customer where they are at will (a) reduce the challenge of emerging requirements, (b) reduce implementation risk, and (c) put you in a better position for a quick win.

(6) Minimize customizations and maximize enhancements. Every customer will have unique requirements that must be addressed via software. Some of these requirements add no material value to desired business results (customizations) while other requirements have a material impact to desired business results (enhancements). This is not meant to be a negative commentary but it deals with the reality that a customer's existing business process is not 100% efficient nor 100% effective (Lean Six Sigma). A key strategy for the project team is to focus on the requirements that drive enhancements and eliminate non value add customizations as quickly as possible (before Fit/Gap).

(7) Negotiate for success. This requires changing the customer's expectation of business software. If the custom expects a custom software solution then the results will be additional gaps, costs, and disappointments. Implementation partners need to understand the potential areas in the ERP/COTS software where software changes can be cost-effective. Negotiation will be required to foster adoption and yet not eliminate the inherent advantages of ERP/COTS.

(8) Accelerate decisions by generating more knowledge and less information. At the end of the day, decisions (not documents) move implementations forward. Sometimes we get caught up in generating too many detailed documents without ensuring they generate value-add results (decisions).

In summary, the key to effective ERP/COTS implementations is to have an implementation approach that maximizes the advantages and minimizes the challenges associated with ERP/COTS software.

Adapted from the book "Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations" by Brett Beaubouef.

Maximize Your Investment with Packaged Software Implementations

Brett Beaubouef recently published a book entitled Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations. This book, published in December 2009, is a welcome addition to ERP literature if, for no other reason, than that there is a dearth of literature in the field regarding COTS (commercial off-the-shelf) or packaged ERP software implementations altogether. Beaubouef's work helps bring an end to that.

Beyond that, however, Beaubouef's writing is closely aligned with my thinking, as well. Plus, the vast majority of SMBs (small-to-mid-sized business) will end up implementing some form of COTS software. Most small businesses are simply not good candidates for "Big ERP," anyway.

Here are some salient quotations worth cogitating upon and that will, I trust, encourage you to go out and buy the book in order to gain more valuable insights:

• Customers are more concerned with implementing successful business solutions, not just installing software products and technologies.
• Flexibility in a business solution starts with a flexible implementation approach.
• The ideal COTS software implementation approach would focus on maximizing the “out of the box” value that packaged software can provide to a customer. The implementation approach would naturally filter out requirements that did not provide quantifiable business value, and keep the focus on the customer’s value-added strategic requirements.

As the preface says: “This book is aimed at enterprise architects, development leads, project managers, business systems analysts, business systems owners, and anyone who wants to implement packaged software effectively.”  That’s a great target audience because so many implementations lack real business-value effectiveness, even when the software is otherwise “successfully” deployed.

If you fit into any of the categories listed in the preceding paragraph, my advice is to buy the book.  I did!
Contact me at rcushing@geewhiz2roi.com.


Works Cited
Beaubouef, Grady Brett. Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations. Birmingham, UK: Packt Publishing Ltd., 2009.