The Goal: Using Theory of Constraints (TOC) to optimize EPM project delivery

Used in thousands of companies and taught in hundreds of business schools, The GOAL by Eliyah Goldratt is one of the most influential novels within operations management. Set in a manufacturing environment, the book describes a systematic approach to running and improving an organization. Yet, the concepts described are not unique to the Manufacturing industry.

The goal of an organization is to increase throughput while simultaneously reducing both the inventory and operating expense. From an accounting point of view, “Throughput” is defined as the net revenue made from selling a product or service.” Inventory” is defined as the money tied up in fixed assets to enable Throughput. “Operating Expense” is defined as the money spent to produce Throughput. However, these current definitions are not easily transferrable to the operations and management world, specifically Enterprise Performance Management projects.

As identified in our previous blog, Structuring flexibility in your EPM project: A guide for Maximizing Project value, the goal of Enterprise Performance Management “EPM” software is to drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment.

The diagram below shows how the Throughput, Inventory, and Operating Expense definitions can be translated to meaningful terms within the EPM realm.


The goal still remains to increase Throughput while simultaneously reducing both the Inventory and Operating Expense. However, reducing implementation costs does not necessarily mean not hiring a consulting partner or choosing a partner with the lowest bid. As the saying goes, you get what you pay for. Reducing implementation costs also includes optimizing delivery of your EPM project  to reduce inventory and deliver overall project benefits faster. The most commonly used strategy for delivering a project faster is to utilize more resources. However, all organizations have constraints that limit their ability to delivery projects. Unless these constraints are addressed, increasing resources only increases the project implementation costs while leaving Inventory unconverted.

TOC proposes five (5) steps for optimizing EPM project delivery with regard to the organizational constraints and EPM goals:

  1. Identify the project constraints
  2. Decide how to exploit the project’s constraints
  3. Subordinate everything else to the decision made in step 2
  4. Elevate the project’s constraints
  5. Continue to evaluate for new constraints

Identify the project constraints

Projects have many constraints. The key is to identify that constraint that affects project flow more than any other. Common project constraints within the EPM include

· Challenges with metadata and a lack of a common chart of accounts

· Challenges with sources of data and data cleanliness

· Lack of resource commitment and availability

· Unclear or unknown requirements

Decide how to exploit the project’s constraints

Even though many constraints may be important, one primary constraint should be identified and all other activities within the project should be staggered in such a way to squeeze maximum value from the primary constraint without overloading it.

Subordinate to the constraint

The key to this step is to make the primary constraint the focus of attention and eliminate rules and assumptions that inhibit the maximum value that can be provided by the primary constraint. Agreement must be made that additional tasks and activities are not to be interjected above and beyond the capacity of the primary constraint.

Elevate the constraint

Once all other activities have been subordinated to the primary constraint, it is highly likely that the primary constraint will become a further bottleneck within the project flow. At this point, additional time and resources can be added to the primary constraint in order to increase project flow.

Continue to evaluate for new constraints

As may have been recognized, constraints never disappear. They just shift from one area to another. Once the identified project constraint no longer becomes the primary project constraint, Steps 1 through 5 should be repeated again with a new primary constraint in mind.

Even if not utilized, these five (5) steps produce a new way of thinking about EPM product delivery. Used at strategic points, they can reduce project implementation costs while accelerating benefits. When implementing wide-scale Organizational Change, any advantage helps.

Structuring Flexibility in Your EPM Project: A Guide for Maximizing Project Value

The goal of Enterprise Performance Management (“EPM”) software is to drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment. However, the competitive environment is hardly predictable and business objectives change based on environmental feedback. As projects are typically linked to business objectives, functional requirements and needs may change even during the project implementation cycle. If business alignment is a primary objective, then the software must be adaptive enough to accommodate the changes in order to maximize value.

Based on the results of a recent survey of IT Software Project Failures, the second highest ranked reason given for project cancellations was too many requirements and scope changes. Project management is often seen as the solution for achieving project success. The traditional approach is predominantly taught and utilized in most organizations. However, this approach has its limitations. The traditional project approach is best used when

· The solution and requirements are clearly defined

· You do not expect too many scope change requests

· Prior EPM knowledge is available in-house

· You can utilize existing templates.

Given the unpredictability within the competitive environment, and the dynamic discovery and delivery processes inherent in an EPM project, a more flexible project approach that allows for changes in scope is required. This flexible approach works best when

· The solution and requirements are only partially known

· There may be functionality that is not yet identified

· There may be a number of scope changes from the customer

· The project is oriented to new product development and/or process improvement

· The development schedule is tight and you can’t afford rework or re-planning.

Although scope changes are necessary evils within an EPM project, too many scope changes without a surrounding process can lead a project to failure. From the view of a business stakeholder, implementing an EPM project is partly getting what you want and partly discovering what you really need. The more transparency obtained, the more likely business stakeholders will attempt to enable discoveries via new or modified requirements. Not having the appropriate boundaries or structure in place can easily lead to exceeded budgets, delayed timelines, and ultimately a solidly implemented solution with not enough business value.

The key components required are adequate levels of flexibility and structure (otherwise known as structured flexibility).

Structured FlexibilityAs the diagram represents, structured flexibility provides project stakeholders with a wide range of flexibility to aid the discovery and delivery processes. However, a boundary exists that allows the project to remain structured and meet the project time, budget, scope, and quality objectives. The points where structure meets flexibility should be determined jointly by the project stakeholders. Effective methods should be used to ensure adequate communication within and about the structure. The following seven (7) steps, when used appropriately, can serve as a guide for achieving the structured flexibility that can maximize project value:

  1. Develop the initial ground rules for maintaining structure at the very start of the project;
  2. Obtain buy-in for the ground rules from all project stakeholders and modify if necessary to create a common language;
  3. Ensure all project members are aware that a structure exists and what the protocol for operating within that structure will be;
  4. Allow project members to be flexible in their thinking and approach;
  5. Document and prioritize changes and new ideas;
  6. Focus on the highest value items first  (needs not wants); and
  7. Enforce ground rules where and when flexibility meets structure.

Although these steps may appear simple, high levels of project management and leadership skills are required to implement them. Having an objective project management partner helps.

The Workflow Revolution – Changes to Financial Reporting

flatworldThomas Friedman first talked about how globalization impacts business life in The World is Flat.  In this book, he describes the ‘flattening of the world’ as the idea that workers from around the globe could collaborate and work across systems and wide spans of geography.  One specific part of this flattening is a change he refers to as the “quiet revolution in software, transmission protocols” that he calls “the ‘workflow revolution’ because of how it made everyone’s computer and software interoperable.”

I see this amazing transformation offered within financial software today, but many companies don’t completely understand the value or the concepts to implement this approach.

New financial systems today allow for the immediate submission of data.  The best practice applications of these systems allow for the validation, translation and commentary of this submission to be owned by the end users.

When I discuss the applied concept with clients, I speak of this ‘changing conversation.’  Before this workflow revolution, legal entities in remote parts of the globe would prepare financials and fax them, or teletype them, to a corporate office.   A process that was manual, slow and disconnected.

The end users owning the process changes the communication of the business.  The old typical conversation before might have been a submission of some financial data followed by a response that the data is incorrect or incomplete, and then a resubmission – all taking days to complete.  The process was also flawed in that it relied completely on the receiving member being proactive, and finding the errors.  Surprisingly, many companies still use this approach.

The technology exists to solve this problem and provide two major benefits.  First, products today make the validation systematic, hence reliable.  The end user knows immediately if the data is wrong, and can resolve the issues.  The system provide consistency and reliability that cannot be accomplished with people.  Second, the end users can be made aware of potential problems and begin researching proactively.  This proactive approach cuts days from the process and improves data quality.

Within my next blog posting, I will discuss many of the controls I am seeing in these systems like SAP’s BPC and Oracle’s HFM products, and how they improve data quality and speed of reporting.