What does technology project “success” mean to you?

I’m sure many of you are familiar with the common Venn diagram of “project management success.”

PMI (Project Management Institute) and others advocate that a project is successful if it is on-time, within the budget, and of high quality (or, at least, meeting the project’s original standards for quality). Of course, this is true when compared to the alternatives of over budget, late or of poor quality.

But, in the business world, we shouldn’t undertake projects—any kind of improvement project—for the sake of the project itself. So, while this might a satisfactory view of the project manager’s or the project team’s performance, it really doesn’t tell us very much about the net effect on the business.

Another popular Venn diagram used relative to technology deployments is the processes-people-technology one.


Here the aim is assure that the technologists involved in the project carefully consider the business processes that must be supported by the technologies deployed. Furthermore, the IT folks should also understand the people involved and they will desire to apply and benefit from the new technologies.

However, once again, we should be reminded that a business enterprise should never undertake any kind of improvement project merely to automate business processes for automation’s sake. Nor should they undertake an improvement project with the sole aim of people-pleasing.

In a for-profit organization, there are proper metrics to use for IT decision-making, but these are not the ones.

Consider, for example, the business that spends $150,000 on an IT project. The project is deemed to be “a resounding success” based on the following results:

1. The project was completed on time
2. The project was completed under budget
3. The project met all of the initial quality requirements
4. The project’s technology deployments properly supported the intended business processes
5. The project’s new technologies were well accepted and utilized by the people involved
6. The company was no worse off after this major undertaking (and everyone has heard the horror-stories of huge IT failures)

So, the project management team all got big pats on the back and a few VP’s got bonuses and all the stockholders and stakeholders are pretty happy about the whole “successful project” thing.

But, my question is: Should they be happy?

They just spent $150,000 with an admitted ROI (return-on-investment) of a big fat ZERO!

To me, that’s just not good business!

There is a Venn diagram that I, personally, have never seen, but it is the one Venn diagram that makes sense for business investments of every kind because it includes the three factors that should always be considered for “success.” Here it is.

Here are the questions that should be asked about every improvement project—IT-related or not:

1. How much does the project increase Throughput (where Throughput is defined as revenues less truly-variable costs directly linked to producing the revenues)?
2. What affect does the project have on Operating Expenses? Do they go up or down? If so, by how much? Is the change “real” or a calculation based on “savings” when no one will actually be laid-off or no additional Throughput will consume the man-hours “saved”?
3. How much will our Investment change? Besides (as in our example) the $150,000 we will invest in the project itself, will our inventory go up or down? Will we need to invest in new buildings, or can we sell off some capital equipment and increase our cash?

When you have the answers to these questions you will have the answer as to whether your technology project was just a “project success” or a “business success.” And, while the numbers may not be precise, knowing that they are approximately right will give you far better understanding of your company’s success or failure than not considering them at all.

What do you think?

[Cross-posted at Kinaxis Supply Chain Expert Community.]

On Seeking Success

In a recent informal poll I conducted, I asked "Which ERP success is most important to your organization in the long run?" I offered the following options:

1. An ERP project that is on-time and within budget
2. An ERP project that increased throughput (i.e., revenues less truly variable costs)
3. An ERP project that reduces inventories or the need for other investments
4. An ERP project that reduces operating expenses

I was somewhat dismayed when the results were that fully two-thirds of respondents count success in ERP as a project that reduces operating expenses. The only worse answer, in my opinion, would have been "An ERP project that is on-time and within budget."

Here's why I believe that is true.

First, consider that I can dramatically reduce the operating expenses of any business enterprise virtually over night -- saving the organization, perhaps, millions of dollars every year -- and I can guaranty those results. All I have to do close the business. That automatically reduces operating expenses to zero.

If an organization is seeking "success," and they are making progress in that direction. It would seem to me that they would want more and more of whatever it is that they are calling "success." That would just make common sense, would it not?

But executives and managers that pin their "success" hopes on "reducing operating expenses" want only "partial success." Few of them are really endeavoring to reduce operating expenses to the "ultimate prize" of zero dollars.

What is worse is that they constantly face the law of diminishing returns. If they reduced operating expenses last year by five percent, the chances that they can reduce costs this year by another five percent are pretty slim, and even if they do, this year's five percent will still be a smaller actual dollar amount than last year's five percent. And next year will require even more effort for less dollar-savings.

However, for people caught in cost-world thinking, this does not seem foolish. They see no contradiction or futility in these efforts (sadly), ususually because that is all they know or have been taught to think.

On the other end of the spectrum are those one-in-three executives and managers who have discovered that real and enduring success comes from the "throughput" side of the business. If you can increase T (Throughput, which is Revenues less Truly Variable Expenses) this year by five percent -- all else being equal -- then you have made gains. In fact, if operating expenses have not increased, then that five percent increase in T falls directly to the bottom line just like a five percent reduction in operating expenses does.

What is even more exciting is the fact that there is no law of diminishing returns at this end of the enterprise. If you are able to increase T by five percent next year, that five percent will bring more dollars of profit to the bottom line than last year's five percent increase did. And next year's five percent will make an even larger contribution to stakeholders in the business.

Success on this end of the business -- if repeated year after year -- leads to real success, not "closing the business" (as "ultimate success" in reducing operating expenses does).

So, why are not more managers and executives seeking ERP success differently?

ROI is a Responsibility – Part 2

As I said in Part 1 of this series, I have, of late, been challenged in my thinking from two quarters: first, in a LinkedIn discussion I had an entrepreneur tell me that entrepreneurs had to be too much "right-brained" and could not be cornered into decisions based on such things as calculated ROI (return on investment).

And next by this excerpt from a May/June 2003 article by Jacob Varghese:

"Basing IT priorities on ROI rankings is a fool's game, a game in which the biggest liar wins. By relying solely on ROI figures to approve a project or decide between projects, managers are shirking their responsibility for understanding how technology will affect their businesses. ROI numbers do not ensure that technology initiatives will be in line with business strategy. The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative. ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered. And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits." (Varghese 2003)

"ROI numbers do not ensure that technology initiatives will be in line with business strategy."

Of course, Mr. Varghese is absolutely correct in this. It is quite possible to calculate an ROI for a project that has nothing to do with your business strategy. In fact, this is eminently possible if you use formulas provided by software vendors and resellers. All you need for some of those formulas are numbers like:

• Number of employees
  
• Number of salespeople
  
• Current Revenues
  
• Number of orders per month
  
• Number of SKUs and so on, ad nauseum. 

Unfortunately, one of the things that you will note about these numbers supplied to standard ROI formulas used by salespeople is that everyone has employees, everyone (or almost everyone) has salespeople, everyone has revenues, and so forth. None of these figures say anything about your business strategy or what will actually make your business better.
If you use these kinds of generic formulas to calculate the ROI of your IT initiatives, then there is no assurance whatsoever that the there will any alignment between IT efforts and your business strategy. So the answer is, do not use such ROI calculations. Go back to Part 1 in this series and see how you and your management team should calculate ROI in order to compare business opportunities that may be supported by IT investments.

"The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative."

Now here is where I'd have to ask Mr. Varghese for the definition of "success." If you ask the typical software vendor or VAR (or, unfortunately, maybe even your own IT manager) the definition of the "success of [a] technology initiative," you are likely to get an answer along these lines: "If the project is completed on-time, within the budget, and delivers the quality anticipated to the end-users, then the project is a 'success.'"

What is missing in this all too typical definition of IT project success is anything having to do with delivery of business value. If that is true – if your IT manager does not relate every effort to delivering business value that is a failure of executive management. Either they hired the wrong kind of person for the job, or they have not taken time to convey across the whole organization – IT staff included – that every expenditure of time, energy or money should be focused on delivering business value.

If, on the other hand, your executive management team is "responsible for implementation" of each IT initiative and if they have prepared their ROI calculations for the project as I have described in Part 1 of this series, then they will have and know everything they need to help guide the project to full business value-delivering success.

"ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered."

I confess that Mr. Varghese has me confused at this juncture. If "planning is as comprehensive as possible and the totality of impact has been considered," then what is wrong with using the ROI figures altogether? I think most readers will concur with me that the ROI in the example presented in Part 1 of this series is "comprehensive" and considers "the totality of impact." So, if such numbers exist, why not use them in a comprehensive way to set IT priorities?

"And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits."

I certainly concur with the general notion that, if proof of concept can be achieved without expenditure of the full budgetary allowance for any given IT initiative then, by all means, get to the proof of concept and make a go/no-go decision at that point. This is common sense.

However, planning, that goes well beyond the IT department, should be responsible for all of the other things that must occur in order to "realize planned benefits." Technologies are tools and only tools. They represent costs, expenses and investment and do not, in themselves, ever represent revenues, Throughput or profit to the organization. It is up the business organization itself to leverage the tools in order to achieve more of the firm's goal – to make more money today and in the future. Executives and managers must have laid the functional groundwork during the planning that was used to calculate the ROI (see Part 1). They must already know what must happen to reach the estimated increase in Throughput, for example. That factor is not in the purview of the IT department.

[To be continued.]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

The New ERP – Part 28

Strategic alignment is the "best determinant" of success

According to writer and researcher Meridith Levinson, "Many factors influence project success and failure…. But new project management research from training company Insights Learning and Development, the Project Management Institute and a strategic execution consultant suggests that the single most important factor influencing project success is the project's link to the organization's business strategy and the project manager's understanding of how the project supports the business strategy." (Levinson 2009) [Emphasis added.]

This should be an encouragement to any executive or manager who has been following along with us in our development of The New ERP – Extended Readiness for Profit. I say this because we have emphasized the following THREE SIMPLE STEPS:

1. Discover what needs to change, which we have helped you do by applying the Thinking Processes (TPs) and leading you and your management team to the creation of your own Current Reality Tree (CRT). By looking to the roots of your CRT, you were able to see clearly those few things (usually fewer than a half-dozen) that need to change in order for your business to reach more of its goal of making more money tomorrow than it is making today.
   
   
2. Work through what the change should look like. Here again, we suggested that you apply the Thinking Processes to build a Future Reality Tree (FRT) and Transition Tree (TrT). These two logical trees will help you and your management team understand with considerable clarity what the changes should look like if your "system" is going to improve.
   
   
3. Last, how to effect the change must be considered and, actually, if you have built your Transition Tree, you already have determined how to go about making your changes. It is worth mentioning, however, that sometimes the evidence at the "roots" of the CRT is so plainly evident that it is not necessary to build either an FRT or a TrT. (We do not advocate this approach, but some matters are so plain and so easily changed, that the actual work can be documented later, or a new CRT is drafted immediately following the implementation of the "simple" changes.)
   

You will note immediately that, having applied the TPs, you and your management team have already addressed the next element Levinson mentions: "Strategic value alone is not enough to ensure project success…. Project managers need to understand the business strategy and how the project supports it." (Levinson 2009) Having built your logical trees (i.e., CRT, FRT, TrT), you have the tools in your hand to quickly, accurately and effectively communicate "how the project supports" your business strategy of ongoing improvement to anyone involved in any part of the improvement projects that might be set forth.

A strategic road map for the improvement project

Here is a terrific side-benefit you get by having used the Thinking Processes to guide your New ERP – Extended Readiness for Profit project up to this point: For no additional investment of time, energy or money you and your team have a ready-made road map to keep yourselves and your project leads on target with the projects.

Levinson states that under traditional ERP scenarios, "[P]roject managers lack 'the context required to flag when the project is veering from its original intent and course-correct towards the intended outcome,' [write Suzanne Dresser and Mark Morgan, authors of a report published by Insights Learning and Development and the Project Management Institute]. And that's when cost and time overruns begin and when projects start to veer from business requirements." (Levinson 2009)

Your Thinking Processes diagrams provide not only the crystal-clear rationale for your efforts, the logic has already helped your management team set unambiguous metrics by which to compare outcomes with desired results. No fumbling around is required or allowed. Furthermore, the budget that you team has set is equally unambiguous.

Summary

In short, if alignment of IT projects with "business strategies" is, indeed, the "best determinant" of project success, you and your management team are well on their way to success if you have been following along with us in applying The New ERP methods. Plus, you have provided for yourself and those involved at every level with a clear, concise road map to keeping the entire effort – or even multiple efforts – on target for the desired ROI (return on investment) and within a budget that makes sense.

References

Levinson, Meridith. Business Strategy: The 'Best Determinant' of Project Success. Nov 17, 2009. http://www.cio.com/article/508018/Business_Strategy_The_Best_Determinant_of_Project_Success (accessed Nov 17, 2009).

The New ERP – Part 20

Getting to the "system" view of the organization

We will talk more about this when we get to the matter of customizations and modifications; however, if the organization is brought together to see that what is needed is an improvement in the effectiveness of the whole organization – i.e., the "system" – in order to achieve more of the goal of making more money, then many of the petty so-called "requirements" may quite naturally fall away.

When I am applying the New ERP – Extended Readiness for Profit with my clients, I frequently have a very frank discussion with the management team about our holist (or "system") view of the organization. In the course of these discussions, I try to point out that, in general, the goal of any improvement is to achieve at least one of the following three things for the whole system:

1. Increase Throughput (T)
   
2. Reduce Inventories or demands for new Investment (I)
   
3. Cut or hold the line on Operating Expenses (OE) while sustaining substantial growth
   

The caveat to that statement is that achieving that end as the result of any given change in the system (i.e., the organization) will not necessarily mean that the level of effort in every functional area will be decreased. In fact, although it is rare, it is possible that a change may lead to some increase in level of effort in a department or departments that already have excess capacity.

I find that, if the executive management team has created and has a full understanding of the impact of their own Current Reality Tree (CRT) – and maybe a Transition Tree (TrT) – the executives' use of the CRT (and TrT) in explaining what needs to change and why to the whole organization usually results in excellent buy-in on the matter of any workload redistribution that may result.

Getting to the "system" view of technology deployment projects

While we are on the subject of seeing your organization as a "system" – that is, from a holist point of view – we want to compare another important difference between the traditional – Everything Replacement Project approach to technology deployments with the approach we take with the New ERP – Extended Readiness for Profit.

The traditional method applied in most IT deployments under management internally or by vendors or resellers is what we call the aim-and-shoot approach. In a (usually vain) effort to minimize risk, the general concept is to get all the details "nailed down" before management turns vendors and resources loose on the work. Executives and managers who hold to this approach sincerely believe that they are acting in the best interests of their firm. Managers from vendors and resellers also generally hold with all sincerity that this approach is the "safest," if nothing else. But let us take a look at just what risk it is that this approach seeks to minimize.

As we said, the way the traditional approach is formulated, the project leadership attempts to "nail down" or "cast in concrete" all the pertinent details as early in the project as possible. Frequently, executives and managers on both sides try to get every detail settled before the final agreement is signed for services. From that point, their thinking is, all they have to do is follow what has been defined to the letter and they will hit their "target" of success at the end of the project.

It is possible that taking this approach minimizes the risk of cost-overruns. (Although, there is a virtual plethora of data available from the experience of thousands of companies over the last 25 years that militates strongly against this concept that this approach actually does reduce the frequency or size of cost-overruns.) More importantly, however, is the very fact that applying the term "cost-overrun" strongly suggests that the project is being measured solely by "cost" and not by "value delivered." Rather than thinking about the value created through increasing T, or reducing I or OE (if you don't know what T, I and OE mean, yet, then go back and read some earlier posts in this series), such managers and executives can conceive of no concept greater than "cost" by which to set goals and measure "success."

Let me assert right now: Any project that is ON-TIME, ON-BUDGET, and of HIGH QUALITY is still a failure – not a "success" – if it fails to increase the system's production of T, or fails to reduce the system's values of I or OE while sustaining significant growth.

[To be continued]