Making critical chain and financial reporting work together

Critical Chain Project Management (CCPM) implementations, often result in significant improvements in terms of project lead-time reduction, on-time delivery, resource efficiency, and overall project throughput increase.

While all project-based businesses are able to achieve the above benefits, those that derive all or most of their revenue from delivering projects (e.g.: automation, aerospace, construction, etc.) can see dramatic bottom line results. All of these organizations have the need to better manage projects and to provide accurate financial reporting & forecasting. CCPM provides an effective way to manage projects on time and in shorter lead-time, however, it often greatly complicates the financial processes.

In order to effectively execute projects, CCPM focuses organizations on scheduling tasks to minimize multi-tasking and improve project flow. In order to enable financial reporting & forecasting, organizations are forced to schedule resources to align revenue recognition with the labor and material expenditures.

Due to the dynamic nature of project environments, task priorities often change creating an obvious challenge associated with resource scheduling.

Most project-based organizations have existing processes and tools in place to ensure accurate financial reporting and forecasting. In fact, they often have one or more tools to enable time / labor tracking, budget analysis, revenue / margin recognition & forecasting, material tracking and project scheduling, etc.

When companies implement CCPM, not only do they shift the organizations focus to Task Scheduling from Resource Scheduling, they often introduce additional tools / software to enable the CCPM behavior. In many implementations, a good change management technique is to remove the old systems and processes to prevent people from migrating back to the old behaviors. However, in CCPM implementations, many of the legacy systems and processes are required to support the financial reporting and forecasting. So they can't be removed. In fact, resource scheduling has to be maintained along side task scheduling.

To solve this implementation challenge this paper will explain how to better manage this conflict as follows:

1. Estimate task durations AND resource effort during project planning and execution
2. Schedule tasks AND schedule resources but provide continuous impact on project / chain delay
3. Show impact of fixed resource dates on project buffer (penetration)
4. Determine the impact of fixed resource dates on resource load / organizational capacity and associated delays
5. Link task, resource AND effort to financial reporting and forecasting software tools

Introduction

Critical Chain Project Management, a proven and very effective project management methodologies, often results in significant improvements in terms of project lead-time reduction, on-time delivery, resource efficiency, and overall project throughput increase. The power of CCPM approach is derived from focusing on project schedule as the main critical factor of the three project management objectives: scope, quality, and time. The narrowed focus on project schedule can have a dramatic impact on cost control and scope achievement. In fact, the companies that can better manage schedule and reduce project lead-time will be able to dramatically lower overall project costs and deliver better (higher quality) content.

While all project-based businesses are able to achieve the above benefits, those that derive all or most of their revenue from delivering projects (automation, aerospace, construction, etc.) can see dramatic bottom line results. Most project-based organizations have the need to not only better manage projects but also to provide accurate financial reporting and forecasting. For them, CCPM approach provides a very effective way to manage projects, on time and in shorter lead-time; however, it often greatly complicates the financial processes.

This paper will describe CCPM methodology and how its successful implementation reduces costs and minimizes project lead-times. It will also demonstrate how CCPM requirements create conflicts for the financial reporting and forecasting needs of the project based organization. In addition, it will explore potential solutions and requirements necessary to achieve bottom line benefits and satisfy financial reporting requirement at the same time.

Why Our Projects are Often Late, Over Budget, and Under Scope

Most project environments are characterized by high degrees of uncertainty. Uncertainty in content, in vendor performance and often in internal skill sets. Because of this uncertainty, the common complaints related to successfully managing projects include (Patrick & Warchalowski, 2013):

• Original due dates are not met;
• Too many changes to scope or timing;
• Resources (internal and external) are not available when needed;
• Necessary components are not available on time – material, information, specifications, approvals, etc.;
• Disagreements about priorities among projects;
• Budget overruns; and
• Too much rework.

In our experience, when we show the above list of complaints to companies from a variety of industries, the common comments are: “we have them all,” or “that's just the way project environments are,” or “yep, it's always been that way.”

Fortunately for us all, Eliyahu Goldratt was not satisfied with the above explanations and published his groundbreaking book, Critical Chain, in 1997. In this book, Goldratt identifies the primary root causes underlying all of the above common complaints and presents his solution to dramatically improving project performance — critical chain project management (Goldratt, 1997). Central to Goldratt's examination of the problem and his proposed solution is that it is not the uncertainty in projects that must be reduced (as projects are by definition uncertain) but it is the way we manage the uncertainty that must change. So what is the root cause as to why projects are often late, over budget, and/or under scope?

For a single project environment, the root cause is that companies do not ensure that task gains offset task delays. In other words, companies do not structure and manage their projects to take advantage of gains in task performance (tasks that are completed in less time than planned) in order to ensure they cancel out the many delays in task performance (tasks that take longer than planned). In fact, most companies are unaware of this that they actually waste task gains.

For a multi-project environment, the root cause (in addition to the root cause related to single projects) is that resources are forced to multitask among tasks and projects so much so that productivity is lost, quality suffers, delays go unresolved, queues of work build up, and lead times extend greatly.

We will devote the next part of this paper to an explanation of Goldratt's description of these root causes and his critical chain project management approach (Patrick & Warchalowski, 2013).

Root Cause #1 – Task Gains Don't Offset Task Delays (Single Projects)

Most companies structure and manage projects according to the following generic project planning approach: break the project down into a series of logical tasks, identify the important dependencies (which tasks must be complete before the next can start, etc.), determine task durations and assign expected start and end dates to each, assign resources to tasks, insert key milestones that must be met, and execute the plan to achieve the task and milestone dates in order to complete the project on time/budget.

As previously stated, projects are uncertain. This means that task durations are estimates (some better than others depending on the level of uncertainty), and as a result, the actual time to completion may be more than the estimate (a task delay) or less (a task gain). Many tasks take longer than expected due to a variety of reasons including: waiting on vendors, materials, information, approvals, specifications, resources, etc. Companies do an increasingly better job managing these and other issues that cause delays, but the reality is that due to the uncertainty inherent in projects, these delays will always occur. Likewise, many tasks take shorter than expected. Sometimes good project management techniques help companies achieve better task management.

In order for a project to be done on time, the task delays must be offset by the task gains. It is simple math. If projects are not completed on time (or equally require extra budget to be done on time) something must be happening to the task gains. Goldratt (Goldratt, 1997) determined that task gains are wasted because of companies’ inability to properly manage the following:

• Student syndrome - people put off work until later (they usually don't start right away).
• Parkinson's law - work expands to fill the time available.
• Integration points - if two tasks must come together before a third can start, both must be early in order to take advantage of the gains (but only one must be late to pass on the delay).
• Resources with multiple tasks - if Resource A completes his or her task early and passes it on to Resource B, the gain is passed on only if Resource B can start immediately (but usually Resource B is busy working on other tasks).

As a result of the above four factors, most task gains are wasted; therefore, task delays accumulate causing projects to be late and/or over budget.

Root Cause #2 – Bad Multitasking (Multiprojects)

In many project environments, the same resource works on more than one project at a time. This often results in resources being forced to multitask among different tasks and among different projects. In this case, by multitasking we mean starting a new task before an existing task is complete. This happens for a variety of reasons. One such reason being that a resource (Resource A) is working on a task and then requires the input from Resource B. Resource B is busy working on something else, so Resource A must wait for Resource B to respond. In the waiting period Resource A naturally works on a different task (could be the same or a different project) until resource B responds. The net result is that the initial task that Resource A was working on is delayed. Even worse, when Resource B finally responds and provides his or her input back to Resource A, Resource A may need to re-review what he or she was doing and why in order to get re-oriented to the task (all dependent upon the amount of time that has passed) (Patrick & Warchalowski, 2013).

The way we often explain this concept to different executive teams is to ask them to perform a short exercise. We ask them to complete two tasks. Task 1 is to write out the word MULTITASKING. Task 2 is to write down the numbers 1 through 12. Once complete , we ask them to record how long it took to complete both tasks. Then, we change the rules and ask them to complete both tasks at the same time. In other words, write the letter M, then write the number 1, then write U, then write 2, and so on until they are complete. Again we ask them to record how long it took to complete both tasks. Typically, the second scenario takes on average 40% to 50% longer to complete. (Scenario 1 - both done in approximately 12 seconds, Scenario 2 - both done in approximately 18 seconds).

Similarly, Robert Newbold describes in his book, The Billion Dollar Solution (Newbold, 2008), the Confetti Game. In this game, executives tear two different color pieces of paper into 30 smaller pieces -one color followed by the second color. After recording their time, the task is performed a second time, only now they must alternate between the two colors every three moves. Again the time is recorded. In our experience running this exercise with executives, the second scenario often takes groups more than 50% longer than the first. (Scenario 1 - both done in approximately 90 seconds, Scenario 2 - both done in approximately 135 seconds). One additional measure taken in the Confetti Game is the counting of the number of torn pieces. Inevitably, the number of players ending up with 30 pieces of each color in Scenario 2 is usually 50% less than in Scenario 1.

In both exercises, the participants quickly realize that the poorer performance in Scenario 2 is due to their own multitasking. What they often do not realize is the implications behind the results. The implications are as follows:

1. A 50% longer lead time to complete two projects when multitasking means that it is possible to complete three projects of equal size in the same time when not multitasking. A 50% capacity increase with the same resources.
2. Quality always suffers when multitasking is present versus when it is not. When quality suffers rework often occurs, which not only adds to cost, but also extends the lead-time and reduces capacity. In practice, software developers and design engineers often complain how interruptions can greatly slow down their progress (sometimes to the point of requiring them to start over) as well as not ending up with the optimal code or design.
3. When multitasking, the first project completes very close to the completion time of the second project. When not multitasking, the first project completes often 50% sooner.

From a practical perspective, multitasking often creates the following problems in organizations (Kendall & Austin, 2013):

• Management and support group attention is harder to get - causing task to be delayed,
• Problems take longer to discover - wasting time until intervention occurs, and
• Resource managers are very busy and do not take the time to clarify tasks before assigning them to people or making sure tasks are actually ready to begin.

In summary, multitasking in project environments often leads to longer project lead times, more rework, lower organizational capacity and as a result, increases project cost and reduces competitiveness.

Critical Chain Project Management Methodology

So far, we have explained the primary root causes for why projects are late and/or over budget — task delays do not offset task gains and resources are engaged in too much multitasking. To be clear, if companies can solve these two root causes, they will succeed in reducing their project lead times.

Goldratt's critical chain approach (Goldratt, 1997) provides a way to solve both of these root causes, as summarized in our three-step methodology:

1. Stagger the release of projects into execution in order to limit the number of active projects in the pipeline.
2. Buffer project plans in order to better protect against uncertainty.
3. Prioritize task execution based on project completion versus buffer consumption.

Stagger

Resources usually multitask for two reasons:

1. They do not have what they need to finish their current task, and
2. They have ‘other available tasks’ to work on.

So, they stop working on one task (e.g., send off a request for whatever is missing) and pick up another task and so on. The more ‘other available tasks’ they have, the larger the queue of started (but not finished) tasks. In other words, multitasking creates multitasking. We call it a vicious cycle. The best way to break this vicious cycle is to limit the number of active projects in execution in accordance with the organization capacity to quickly flow projects to completion (Kendall & Austin, 2013).

Rather than trying to limit the number of projects at each phase of a project or limit the number of projects to each resource group, the organization should pick a staggering point around which to make this decision. The staggering point is either the key project phase that often limits the number of projects an organization can quickly complete or a resource group that is often in very high demand. It differs by organization.

A good way to determine the location of the staggering point is to answer the question “what are tasks waiting on the most?” (Kendall & Austin, 2013):

• If the answer is one type of resource group that is usually specified in project plans, then the organization should stagger the release of projects around this resource group in accordance with their capacity.
• If the answer is varying resource groups that are often not specified in project plans (i.e., management and support resources), then the organization should stagger the release of projects around a project phase (typically some kind of integration phase).

In parallel with implementing the stagger step, organizations need to implement a full kitting process, where a detailed process of what is required to start a specific task, phase, or chain of a project is established and adhered to. The basic rule of full kitting is to not start on work until adequate preparation is complete. (Adequate preparation means the task, phase, or chain can be fully completed once started.) Once successfully implemented, staggering and full kitting greatly reduce the bad multitasking that occurs in most project companies.

Buffer

In most project plans, tasks have both expected start and end dates (in accordance with their estimated durations). These durations are based on either historical actuals or forecasted projections and have embedded in them a certain amount of waste and safety. The waste comes from the organizations’ past multitasking experiences and task delays. The safety comes from people's admirable desire to be good and reliable people. People are not going to provide task estimates that have only a 50% chance of success. Instead they will choose an estimate with a much higher likelihood of success in order to be seen as a reliable professional.

To ensure that companies have a better chance of taking advantage of task gains, project plans should be developed in a way that removes the task safety from each task and accumulates it at the end of the project so that all tasks can have a chance of using it. Thus, all of the safety is used to protect the entire project not each individual task. The accumulation of the task safety at the end of the project is called a Project Buffer. This is accomplished by asking resources for aggressive durations for each task, assuming that “everything goes right” during project execution. This process takes a while to perfect and requires a degree of trust between management and the resources.

The notion of identifying the critical path should be extended to include not only the longest chain of task dependencies, but also resource dependencies. Resource contention should be resolved at this time. This newly identified longest chain of both task and resource dependencies is called the critical chain., The duration of the Project Buffer can be determined once the critical chain has been identified, which is usually half the duration of the critical chain.

It is important to communicate and reinforce that the project buffer is meant to be consumed during the execution of the project. In other words, the project lead time is expected to be the sum of the critical chain duration plus the project buffer duration.

Finally, chains of tasks that enter into the critical chain require their own buffers (feeding buffers) inserted at each integration point to ensure that these chains start early enough to avoid unnecessary delays to the critical chain.

Prioritize

Project progress is determined by comparing the completion rate of the critical chain against project buffer consumption. Furthermore, since the duration of the project buffer (PB) is typically half of the critical chain (CC) duration, it is expected that 0.5 day of PB is consumed for each 1 day of CC completion. This ratio, known as the Flow Index, divides the CC complete by the PB consumed. The target is 1. Any value greater than 1 means the project is completing CC faster than it is consuming PB (a good thing). Any value less than 1 means the project is completing CC slower than it is consuming PB (a warning of potential trouble).

Also, the same ratio of flow index determines the number of chain delay days a given project is currently experiencing. For example, Project A has an aggressive CC duration of 100 days and a PB of 50 days (total project lead time is expected to be 150 days). If 50 days of the CC are complete and 30 days of the PB are consumed (i.e., 80 days have elapsed since the start of the project), then the flow index is .833 (.5/.6) and the chain delay days are 5 days late (as the project should have only consumed 25 days of the PB). Expressed as a formula, the chain delays days = (flow index target - current flow index) x PB consumed (in this example chain delay days = (1 - .833) x 30 = 5 days).

In order to drive project and task priorities during execution, the flow index and chain delay days are used at both the project and task levels to determine overall priorities across projects and within a project. At the project level the project with the lowest flow index has the highest execution priority requiring the most focus. The same can be said at the task level based on the task with the highest chain delay days. By calculating these measures for every active task, the relative priority of every task across all projects is known and used to drive task execution decisions and resource allocation decisions.

In order to capitalize on the real advantages offered by the buffer and prioritize steps, the organization needs to change the way it manages and schedules resources. The movement towards building project plans using aggressive durations, resolving resource contentions at the time of designating the critical chain, and prioritizing using flow index and chain delay days requires the organization to schedule tasks not resources. Scheduling tasks means assigning the optimal number of resources to tasks in order to complete the tasks as fast as possible, even if this is not the most efficient way to utilize the resources. The objective is to keep the tasks busy and moving, not to keep the resources busy.

Similarly, projects should be managed more like a relay race than a train schedule. In a relay race, the next runner starts as soon as the preceding runner is complete. Likewise, under the critical chain approach, the next task starts as soon as the previous task is done (the next resource must be ready even if it means the next resource might occasionally stand idle waiting for the preceding task to be completed). You do not want the next runner in a relay race to miss the baton hand off because s/he was busy getting ready for another race. Under the train schedule approach, if a task is finished early, the next task often does not start until its prescribed scheduled start date because the next resource is not ready to start.

Once successfully implemented, the buffer and prioritize steps allow for more task gains to offset task delays - the mechanism necessary to deliver more projects on-time, on budget and on-scope.

So far we have explained the basics of the CCPM methodology. We will dedicate the next part of this paper to an explanation of the Financial Reporting and Forecasting process.

Financial Reporting and Forecasting Requirements for Project Based Organizations

Many large project based organizations, especially those that derive all or most of their revenue from delivering projects (automation, aerospace, construction, R&D, etc.), must provide accurate financial reporting & forecasting. Many of these organizations are publically traded and their ability to forecast financial performance is critical. In order to accomplish this, organizations are forced to schedule resources to align revenue recognition with the labor and material expenditures in order to calculate business profitability.

Scheduling resources requires predicting at what point in time a given resource will be engaged to perform a specific task as well as how long it will take to complete the task. The most common way of accomplishing this objective is by developing a project management plan including defining the scope, creating the resource schedule, establishing the cost and budget, and defining risk management process.

Revenue Recognition Methods and Their Implications:

There are a number of revenue recognition methods that are being used by project-based organizations. According to Investopedia US (2014), here are some examples:

Sales-Basis Method:

Under the sales-basis method, revenue is recognized at the time of sale, which is defined as the moment when the title of the goods or services is transferred to the buyer. The sale can be made for cash or credit. Under this method, revenue is not recognized even if cash is received before the transaction is complete.

For example, a monthly magazine publisher that receives $240 a year for an annual subscription will recognize only $20 of revenue every month (assuming that it delivered the magazine).

Implication: This is the most accurate form of revenue recognition.

Percentage-of-Completion Method:

This method is popular with construction and engineering companies, who may take years to deliver a product to a customer. With this method, the company responsible for delivering the product wants to be able to show its shareholders that it is generating revenue and profits even though the project itself is not yet complete. A company will use the percentage-of-completion method for revenue recognition if two conditions are met:

1. There is a long-term legally enforceable contract.
2. It is possible to estimate the percentage of the project that is complete, its revenues and its costs.

Under this method, there are two ways revenue recognition can occur:

1. Using milestones - (e.g., number of stories completed, number of miles of railway built)
2. Cost incurred to estimated total cost - Using this method, a construction company would approach revenue recognition by comparing the cost incurred to date by the estimated total cost.

Implication: This can overstate revenues and gross profits if expenditures are recognized before they contribute to completed work.

Completed-Contract Method

Under this method, revenues and expenses are recorded only at the end of the contract. This method must be used if the two basic conditions needed to use the percentage-of-completion method are not met

Implication: This can understate revenues and gross profit within an accounting period because the contract is not accounted for until it is completed.

Cost-Recoverability Method

Under the cost-recoverability method, no profit is recognized until all of the expenses incurred to complete the project have been recouped. For example, a company develops an application for $200,000. In the first year, the company licenses the application to several companies and generates $150,000. Under this method, the company recognizes sales of $150,000 and $150,000 of expenses related to the development (assuming no other costs were incurred). As a result, the net income would be zero until the total cost is offset by sales.

Implication: This can understate gross profits initially and overstate profits in future years.

Installment Method

If customer collections are unreliable, a company should use the installment method of revenue recognition. This is primarily used in some real estate transactions where the sale may be agreed upon but the cash collection is subject to the risk of the buyer's financing falling through. As a result, gross profit is calculated only in proportion to cash received. For example, a company sells a development project for $100,000 that cost $50,000. The buyer will pay in equal installments over six months. Once the first payment is received, the company will record sales of $50,000, expenses of $25,000 and a net profit of $25,000.

Implication: This can overstate gross profits if the last payment is not received.

Of all of these methodologies, the percentage-of-completion method is the most common. The best way to describe is to consider an example: (Investopedia US, 2014)

Construction Company ABC, obtained a $50 million contract to build a five-building resort in the Bahamas for Meridian Vacations. Company ABC estimates that each building will take a full year to build. Meridian Vacations has agreed to pay Company ABC according to the following schedule: $5 million in year 1, $10 million in year 2, $10 million in year 3, $10 million in year 4 and $15 million in year 5. Company ABC has estimated that the total cost of this contact will be $35 million, with expenditures over the five years as follows: $5 million in year 1, $4 million in year 2, $10 million in year 3, $10 million in year 4 and $6 million in year 5. Equal monthly payments will be made to Company ABC, and Meridian will have a 30-day grace period except for the last payment in year 5. Project payments and costs are represented in the Table 1 below:

Table 1: Contract payments and costs ($ in millions)

Using the percentage-of-completion method, as a first step 1 we need to forecast the revenue Company ABC will declare each year. In order to generate yearly revenue figures we need to extrapolate the annual cost as a percentage of the total cost (Table 2). Armed with this information, the percentage of completion is multiplied by the total expected revenue (Table 1) for the project for each period.

Table 1: Yearly Revenue Forecast ($ in millions)

Assurance of payment principle drives the formula to determine the revenues to be recognized at a given point in time:

(Services Provided to Date / Total Expected Services) x Total Expected Cash Inflow

This formula ensures that the payment is collected only for services that have been delivered (or time spent).

Step 2 of the process is to declare costs. Within this accounting methodology, the expenses estimated should remain unchanged. It is often difficult within a project environment to keep expenses constant; however, under this assumption the company Income Statement would look as presented in Table 3 (for simplicity, taxes are excluded).

Table 3: Income Statement

In order to estimate above costs, the organization needs to define its material and people related expenditures. These expenditures are generated by a project plan that ,identifies tasks and activities at the resource / skill level. Most of the costs are generated by multiplying resource effort time by its hourly charge rate to calculate the overall task / activity cost. All resource costs are tallied and added to the material cost to determine an overall project or organization time period cost. Whenever these activities take place at a different time than originally estimated, the project generates a financial variance impacting its expected profitability. Since a high level of uncertainty characterizes project environments, there is a continuous effort related to project scheduling and re-scheduling driving new financial reporting and forecasting requirements.

The Conflict

In order to effectively execute projects, CCPM focuses organizations on scheduling tasks to minimize multi-tasking and improve project flow. In order to enable financial reporting & forecasting, organizations are forced to schedule resources to align revenue recognition with the labor and material expenditures.

The above can be summarized in the following diagram #1:

The overall goal is to have a successful project-based business. Two key business objectives need to be accomplished simultaneously in order to realize this goal: enable effective project execution and perform accurate financial reporting and forecasting Each of these objectives require a specific action: (1) task schedule is necessary to enable effective project execution, and (2) resource schedule is imperative to perform accurate financial reporting and forecasting Due to the dynamic nature of project environments, where task priorities often change, an obvious challenge is resource scheduling. In other words, we need to subordinate resources to task priorities to improve project execution and we need to subordinate tasks to resource schedules in order to perform financial reporting and forecasting. Making resources available when a task becomes a priority often negatively impacts their detailed schedule established while forecasting revenue. These two actions conflict with each other since neither can be performed successfully at the same time.

Most project-based organizations have existing processes and tools in place to ensure accurate financial reporting and forecasting. In fact, they often have one or more tools to enable time / labor tracking, budget analysis, revenue / margin recognition & forecasting, material tracking and project scheduling, etc.

When companies implement CCPM, not only do they shift the organization's focus from resource scheduling to task scheduling, but also often introduce additional tools / software to enable the CCPM behavior (Concerto, CMS RoadRunner, etc.) In many implementations, a good change management technique is to remove the old systems and processes to prevent people from migrating back to the old behaviors. However, in CCPM implementations, many of the legacy systems and processes are required to support the financial reporting and forecasting so they cannot be removed. In fact, resource scheduling has to be maintained along side task scheduling to satisfy the financial side of business.

Direction of the Solution

Since we have demonstrated that both objectives, effective project execution and accurate financial reporting and forecasting, need to be satisfied simultaneously, the direction of the solution is to provide organizations with the ability to schedule both tasks and resources but reflect the impact of these decisions on project buffer penetration. Visibility of project buffer penetration is paramount, since we need to ensure that CCPM methodology is driving bottom line results.

In order for this to be enabled, a five step process needs to be created in project-based organizations implementing CCPM:

1. Estimate task durations AND resource effort during project planning and execution. For example, a five day task may require 80 hrs. of effort (2 engineers - 40 hrs. each)
2. Schedule tasks AND schedule resources but provide continuous impact on project / chain delay days. For example, delayed availability of one of these engineers (1 week vacation) may delay a chain by a week.
3. Show impact of fixed resource dates on project buffer penetration. For the above example, the critical chain task this delay may penetrate the project buffer by five days, for other chains it may not.
4. Determine the impact of fixed resource dates on resource load / organizational capacity and associated delays. The impact of detailed resource schedule needs to be visible in the context of the entire organizational capacity.
5. Link tasks, resource availability / capacity AND effort to financial reporting and forecasting software tools. Elongation of the critical chain (and associated project lead time) will impact accuracy of financial reporting and forecasting.

The Solution Leads to Results

Based on the number of CCPM implementations and work with many different clients, we have seen companies realize great results in a short period of time. Many of the companies we have worked with successfully reduced their lead times and lowered their project costs between 20 to 40 %

In Advanced Multi-Project Management (Kendall & Austin 2013), Appendix B provides a list of approximately 75 case studies of companies realizing benefits from implementing the approaches described in this paper. Benefits include:

• lead time reduction of 50% or more;
• on time delivery of over 99 %;
• up to 50% more projects delivered; and
• cost savings in the millions of dollars.

However, we have also seen the need for a better solution to satisfy the financial reporting and forecasting side of the business. This process, so critical to the success of larger organizations, needs to be simplified and supported by better CCPM software tools.

Conclusion

CCPM implementation often allows organizations to achieve significant bottom line results and provide it with a significant competitive advantage. The competitive advantage may include getting products to market faster, quoting shorter lead times than competitors, and realizing internal benefits sooner. It may also consist of delivering more projects with the same resources or lowering the overall labor cost per project.

CCPM implementation sometimes creates conflict with the financial reporting and forecasting needs of the project based organization. While CCPM needs to schedule tasks and subordinate resources to it, the financial reporting side of business relies on the predictability of its original cost estimates and rigid schedule of resources. Task scheduling and resource scheduling support different business objectives but must be accomplished simultaneously to support business growth. In order to accomplish both requirements, the organization needs the ability to schedule both tasks and resources at the same time and reflect the impact of these decisions on the penetration of project buffer.

Implementing this solution in a relatively short period of time (within four to six months) often requires software support, a proven implementation methodology and a solid understanding of the principles of critical chain.

About the Authors

Jack Warchalowski, P. Eng., MBA, CMC — Jack focuses on strategy development and implementation for a variety of engineering, manufacturing and project management clients. Jack is a Certified Management Consultant and a Professional Engineer. He holds an MBA degree from the Wilfrid Laurier University, Canada and a Bachelor of Applied Science in Mechanical Engineering from the University of Waterloo, Canada. Jack is certified by the Theory of Constraints International Certification Organization.

Duncan Patrick, MBA, CMC – Duncan works with clients to assist them design and implement Theory of Constraints (TOC) based solutions focused on accelerating project execution. Duncan holds an MBA degree from Western University, Canada and a Bachelor of Commerce degree from The University of Calgary, Canada. Duncan is certified by the TOC International Certification Organization.

CMS Montera provides management solutions and software to Accelerate Projects and Optimize Operations for clients in Engineering, R&D, Manufacturing and Project Management.