Uncertainty: The Elephant in the Room–Part 2

In a previous article on uncertainty, we talked about how uncertainty is viewed by the “customer” of IT versus how it is viewed by the information technologists (e.g., value-added reseller or VAR, IT department) themselves. We mentioned how the “buyer” or the “customer” may feel the only uncertainty for them is the questionable performance of the IT provider.

In this present article I hope to bring out some of the ways traditional methods of project management and corporate management may actually contribute to uncertainty rather than diminishing it. We will speak of this in the context of IT projects, but it actually holds true in almost any project environment (whether or not management recognizes that they have and manage “projects”.)

Pretending about numbers

In out business dealings we like to think that our dealings—both internally and externally—are driven by numbers and facts. What management almost always fails to acknowledge is that a great percentage of our dealings are as much driven by intuition as they by numbers. In fact, intuition frequently ends up driving the numbers.

Take for example the VAR who brings a prospective deal to his project managers (or equivalent) and asks them for an estimate for the services on a project that includes development, training, deployment and post-go live support. The project management (PM) team does its due diligence and comes back with an estimate: “We think it’s going to take $278,000 in services to get this done right.”

The sales managers and executives put their heads together and, purely out of intuition, say, “We can’t sell this project for that much money, but we really need the work right now.” Then, based on the sales department’s intuition and clout with the executives, the PM team is “encouraged” (read: “pressured”) to reconsider their estimate to see if they can’t get the project done for $232,000—which the salespeople believe is the number the prospect will “bite on.”

To make a long story short: the deal gets done and the client is quoted $232,000 in services for the project.

Now, even though the final number was not predicated on numeric calculations and numerical estimates—no, indeed, it was based almost entirely on intuition—there is nothing imprecise nor “intuitive” about the $232,000 figure that was written into the agreement.

The intuitive number now bears pretends to be a precise calculation—an “estimate” or a “project budget.”

In so doing, the reseller has just introduced at least $46,000 in uncertainty into the project. At a typical billing rate, let’s say 250 man-hours or about six-and-a-half man-weeks.

There are no “price complaints”

Several decades ago I had the privilege of working with the national sales manager of an organization with which I was doing considerable business. The gentleman told me something that I will never forget. He said, “There is no such as a ‘price complaint.’ There are only ‘value complaints.’”

I bring this up because the “pretending about numbers” scenario I mentioned above happens more frequently than most folks in the IT business care to admit. But, I don’t believe it has to happen.

Why is it that, most of the time, folks in the IT business never have any real discussions about the “value”—the hard ROI—that their solutions will deliver?

I believe that they do not have those discussions for a couple of very elementary reasons:

1. The customer doesn’t ask. Of course, one of the reasons the customer doesn’t ask is because they’ve heard all the typical “rules of thumb” benefits already. Another reason is because many executives and managers do not even believe in ROI from IT. They consider it a “cost center” and just throw money at it whenever they think it might help. These managers and executives frequently see adding new “IT stuff” or replacing their ERP systems akin to pouring an engine additive into their car. They expect if they do that their engine (their company) will run smoother, faster, longer and get better mileage, but they have no idea how to measure the benefits of “smoother,” “faster,” or “longer.”
   
2. The IT folks don’t know how to calculate it. No, I’m not saying that the executives and other folks in IT don’t know the formula for “ROI.” I’m saying that they are (generally) unwilling or unable to walk their clients or prospects through the process of developing the performance metrics by which the results of their combined (i.e., IT or VAR together with the firm or business unit affected) efforts will be measured.

If both parties—the customer and the IT service provider—are unwilling to confront the subject of real ROI from IT investments openly, objectively and with the aim of mutual agreement on the intended measurable results for the investment, then how can the VAR (or IT department) expect to build “value” in the mind of the buyer to support the “investment” required?

In my opinion, they can not. So, instead, they reduce their “estimates” and cut corners to make it fit into someone else’s “intuitive” budget constraint that is generally predicated entirely on “cost” and almost never on anything like a hard ROI.

Isn’t it time to stop doing business this way? It’s just adding more to the uncertainty in every project. No wonder there are so many IT project failures—or self-proclaim or assumed “successes” with no substantiation—all around us.

Let me know what you think.

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.]

Considering Project Accounting for Increased Profit

Many folks confuse the terms “project management” with “project accounting.” These terms are not synonymous. As might be inferred from their distinctions, project accounting is all about tracking the monies associated with projects. Project management is related to managing project tasks, time and resources.

While there are some software applications that handle both the project accounting (PA) and the project management (PM) aspects, most common applications handle only one side or the other. For example, Microsoft® Project™ is a very commonly used application for project management. It is worthless, however, for anything related to project accounting.

Why aren’t project management and project accounting found in the same application?

In most organizations, the fact that project management recording and project accounting transactions do not occur in the same application typically poses few hurdles to operational effectiveness. The reason for this is simple: typically the personnel intimately involved in managing tasks, time and resources (i.e., the project managers) are not the same folks who are intimately involved with handling the accounting aspects of the project (e.g., calculating, printing and sending the project invoices, making payments to project vendors, or assuring that expense or payroll transactions are processed on time). Therefore, the ability to share data via simple integrations or even via ad hoc queries or reports is quite frequently sufficient.

In fact, not infrequently, organizations actually prefer to have project managers and their activities kept separate from project accounting and its related activities. Doing so functions as a double-check and adds control in itself.

“We don’t do projects?” we hear you saying

You don’t think you’re in a “project”-type industry? Well, maybe you’re right. But consider these possibilities:

• Internal projects – Does your organization do internal projects for which you’d like to track costs accurately, even if you never bill anyone for the services? Do you do advertising campaigns? IT projects? Opening new locations? If so, then it is possible that your business could benefit from the additional controls provided by a project accounting solution.
  
• Engineer-to-Order – If you are a manufacturer in an engineer-to-order (ETO) industry, then project accounting might be applied to track your costs leading up to the manufacturing. Professional services and related costs and expenses can be tracked and managed using project accounting’s capabilities.
  
• Installation or After-Market Service – If your manufacturing or distribution operations extend themselves into the fields of installation, configuration or after-market service, then chances are project accounting is not the right solution for you. In such cases, you should read the section on Service Management.

What can Project Accounting do for you?

There many time-saving functions brought to you through the project accounting capabilities that dramatically reduce the time, energy and effort that would otherwise be required. Here is a sampling:

Profit Recognition

Projects may recognize profit/(loss) in several different ways. Most PA solutions allow users to assign the profit recognition method by project. The typical profit recognition methods include:

1. Manual
2. Cost-to-cost percent
3. Percent of revenues
4. Non-WIP
5. Project completion
6. Percent of elapsed time

“Percent of elapsed time” is a profit-recognition method commonly used with prepaid date-limited service contracts. If this is a common method in your firm, be sure to investigate Service Management solutions as well. In some circumstances, service management may be the more appropriate solution to apply.

Project Billing Methods

Project accounting software typically offers several options for billing and projects may be of different billing types:

1. Time and materials
2. Fixed price
3. Fixed price plus

When a project is designated a “time and materials” billing type, most project accounting systems allow the materials items to be passed through at cost to the customer, or billed with a mark-up add to designated materials and other non-labor charges.

Billing for Employee Time

Businesses that bill their clients for employee time spent on various projects often face the daunting task of keeping the billing correct based on agreements with their various clients. Not infrequently such agreements may involve complexities that would require considerable time and care if attempted without the support of a project accounting system.

For example, clients may negotiate different rates for different specific employees when working their projects. Indeed, they may end up negotiating different rates for the same specific employee on different projects—several of which projects may be underway at any one time with the same client. As you can imagine, assuring that project billings are assigned the right rate for the right resource on a project by project basis could become a difficult task. Project accounting systems handle such billings effectively and simply with little effort.

Add to the potential complexity described above the ability to also bill different rates to different projects or different customers based on the employees’ titles in their assignments to different projects and you can readily see that manually tracking all of the potential combinations could become a nearly impossible task. Here, for example, employee Jim Smith might bear the title “Project Manager” on one project for one client and, as the Project Manager be billed at $225 per hour. However, due to Jim’s lack of experience in another type of project, he may bear the title “Developer” on that project and be billed to the same client (or a different client) at a rate of only $150 per hour.

Increasing throughput and profits

Now, you might say, “I don’t need all that complexity in my projects. We’re content with billing just one rate per project, one rate per client, or one rate per employee across all projects and clients.

Our question in response is this: “Why wouldn’t you want to make more money tomorrow than you are making today if you could do so without adding significantly to your operating expenses by doing so?”

We ask this because this is precisely what a project accounting solution could do for you and your firm.

Chances are your client’s aren’t stupid. They know that a good and effective project manager is more valuable to them than a heads-down programmer or a project secretary or, perhaps, a QA staffer. Right now, you are likely charging the same for each of these, which mean you must be using an “averaged” rate.

By adding project accounting’s flexibility, you are also adding the low-cost option of further segmenting your market and closing more deals. You can charge clients more or less based on how your crack sales team identifies the prospect’s or client’s view of “value.” Two projects that are virtually identical in their execution may have two significantly different values to two distinctly different clients. Consider the following chart:

Project ID	Est. Project Cost	Est. Project Revenues	Est. Project Profit
A	$ 165,000	$ 260,000	$ 95,000
B	$ 165,000	$ 220,000	$ 55,000
C	$ 165,000	$ 200,000	$ 35,000

Here we see virtually identical projects on the “cost” side. However, three different clients perceive the “value” of the efforts differently in their businesses. One is willing to pay $260,000 for the work; another is willing to pay $220,000 for it; and third sees only $200,000 in value and won’t pay a cent more.

If your PA system only allows you to charge these clients one rate—or if you don’t want to burden your accounting department with manually managing different billing rates per client—you may be tempted to turn down Projects ‘B’ and ‘C’.

Why give up the profits?

But, if your firm has the capacity to do projects ‘B’ and ‘C’, and no more profitable project prospects stand in your way, why would you turn down an extra $90,000 ($55,000 plus $35,000) in project profits simply because your accounting system makes it too difficult to manage. (Actually, that is not the reason such profits are all too frequently passed by. Instead, it is because executives and the sales team—hemmed in by preconceptions about their accounting limitations—never think of making these offers. Instead, they offer their ‘bids’ using the firm’s standard costs and markups and end up losing the deals for Projects ‘B’ and ‘C’.)

Leveraging new capabilities for new profits

In short, leveraging the new flexibilities delivered by a project accounting solution may allow your firm to dramatically increase revenues and profits through market segmentation. However, doing so means bringing to your firm new ways of thinking (as seen above) and an understanding how newly delivered capabilities can, in fact, be applied to create new markets or extend existing ones. This means finding the right implementation partner is essential.

It is imperative that you not make the common mistake made by some many executives and managers when considering the purchase and implementation of project accounting software. Typically they spend more than 90 percent of their time and effort in what the process of “software selection,” carefully considering a long list of features and functions. Then, when this is all done, they simply take whatever consulting firm and consultants come along with the software. We believe this is a wrong-headed approach and many firms to make investments in software with little return on their investment.

There are three critical aspects necessary for a project accounting implementation leading to rapid and high return-on-investment:

• The ability to unlock “tribal knowledge”
  
• The ability to reduce complex problems to simple solutions
  
• The ability to help your organization “design” new ways to leverage new capabilities for increasing throughput and profit

If the software reseller cannot bring to your firm these critical elements, perhaps you should look elsewhere.

The New ERP – Part 41

We are wrapping up our discussion of Sue Bergamo's article entitled "Is Your Implementation in Trouble?" Bergamo listed seven "high level categories [in troubled ERP implementations]…. in the order from the highest to lowest number of responses" from her informal LinkedIn survey. Here is her list:

1. A misconception of business expectations
   
2. The lack of top level leadership involvement in the project
   
3. Business processes were not correctly redefined and continued to be inefficient
   
4. The impact of the organizational change was not addressed properly and caused a major upheaval in the company
   
5. The vendor wasn't managed correctly and over-promised, then under delivered [sic]
   
6. Project management was weak and over-customizations lead to increased scope and time
   
7. The integration of diverse applications was harder than anyone expected
   (Bergamo 2010)
   

In the process of our review we are drilling-down on Bergamo's symptoms list and setting them in the context of the New ERP – Extended Readiness for Profit while contrasting them with traditional ERP – Everything Replacement Projects to see if using the New ERP approach would have mitigated the failures.

6. Project management was weak and over-customizations lead to increased scope and time

This is another no-brainer when it comes to traditional ERP – Everything Replacement Projects versus the New ERP – Extended Readiness for Profit. One simple reason is this: the amount of "real estate" to customize.

Think about it. If your organization is going through an Everything Replacement Project there are dozens – if not hundreds – of places in the new technology that could become a target for customizations. However, in a New ERP – Extended Readiness for Profit project, the effort is so targeted and so narrow in scope that there is just not much opportunity for "scope creep."

But, there is another reason as well.

If you will take time to go back (to prior portions in this series), you will discover that the vendor selection and "proof of concept" portions leading up to an implementation under the New ERP approach are likely to expose an requirements for customization early in the process. In fact, such customization or modification necessities will probably be revealed before the purchase agreement is consummated. This is as it should be.

7. The integration of diverse applications was harder than anyone expected

Even though this is where the New ERP – Extended Readiness for Profit should be most vulnerable, this issue is where the New ERP really shines unlike every other approach.

Why?

This is simply because the New ERP approach takes as its number one priority the matter of EAI (enterprise application integration). EAI is fundamental to the New ERP.

Since, under the New ERP scenario, your organization will not be tearing out the central technology engine (core accounting and related modules) and trying to re-integrate several – or even dozens – of necessary applications across the enterprise, the challenge becomes much less complex. The effort you undertake will be concentrated. Your resources will not be diluted. And the work can be planned and accomplished expeditiously.

Furthermore, looking again to the solution and vendor selection process (see earlier posts in this series), the question of integration of the targeted solutions being brought to bear through the New ERP approach – its ease or difficulty – should be and would be addressed prior to making a final decision on the solution(s) and vendor(s) to be employed.

In summary

In this series we have compared and contrasted traditional ERP – Everything Replacement Projects with the New ERP – Extended Readiness for Profit in addressing seven factors that have lead many organizations to failure or dissatisfaction with their ERP system and implementation as reported by Sue Bergamo in her article "CIO Update: Is Your ERP Implementation in Trouble?"

It should be clear to you and your management team now the many advantaged afforded you by applying the New ERP methods. This is a great way to avoid troubled ERP implementations.

©2010 Richard D. Cushing

Works Cited

Bergamo, Sue. CIO Update: Is Your ERP Implementation in Trouble? Feb 01, 2010. http://www.cioupdate.com/features/article.php/3862056/Is-Your-ERP-Implementation-in-Trouble.htm (accessed Feb 02, 2010).


 

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]