SWOT Analysis and Theory of Constraint in Information Technology Projects Asghar Sabbaghi1 Indiana University South Bend South Bend, Indiana 46634, USA and Ganesh Vaidyanathan2 Indiana University South Bend South Bend, Indiana 46634, USA Abstract This study focuses on the potential cost and benefit analysis of Information Technology projects. The purpose of this study is to synergize the role of Strengths, Weakness, Opportunities and Threats (SWOT) analysis and the Theory of Constraint (TOC) approach in the planning and execution of Information Technology (IT) projects. Due to limited resource availability and much needed timely delivery of projects, organizations consider a number of trade-offs during the entire lifecycle of an IT project. The selection of projects using evaluation and selection tools from the myriad of proposed projects, particularly when all of them promise value to the organization remain highly challenging. By minimizing trade-offs, proper selection of projects may be achieved. This study will use the combined effects of SWOT analysis and TOC to measure the potential benefit and cost tradeoffs. Such measures can be used to examine the effectiveness and efficiency of IT project management. A Five-step TOC thinking process framework that will enable project management teams to develop an integrated strategy is also discussed in this study. Keywords: Project management, SWOT analysis, theory of constraint, effectiveness, efficiency, planning 1. Introduction Advances in information technology and intensified competition in the marketplace have contributed to the timely delivery of products and services. This in turn has contributed to increased benefits and reduced costs of IT project management. Depending on the size, scope, and complexity of a project, a number of conflicting elements challenge IT project management. Project delivery may address the equally important need for reliability in delivering the project as promised, as well as its cost and benefits. The recent developments in IT have also brought significant ramifications with regard to the critical requirements for effectiveness and efficiency in IT project management. Given the critical importance of project delivery and reliability as well as the economic rationale in project planning and implementation, the future of any business will be determined by how well projects are managed today. In general, short period cycle times may lead to substantial incremental earnings while the penalty for long project cycle times may mean missing market opportunities altogether. In addition, multi-project organizations may often tend to launch projects as soon as they are understood. These organizations launch the projects concurrently with existing projects, simultaneously with other new efforts, or without sufficient regard to the capacity of the organization. This would commonly lead to an array of projects with conflicting priorities. Project resources and managers are responsible for sorting these priorities. Of particular concern in this regard is that the priorities established within a functional area may not be in synchrony with other areas, or more importantly with the company-wide priorities. According to Standish group report (1999), Corporate America spends more than $275 billion each year on approximately 200,000 application software development projects. A great many of these projects will fail for the lack of skilled project management (The Standish Group International, 1999). The projects in this study are classified into three resolution types: (1) Success: The project is completed on time and on budget, with all features and functions as originally specified; (2) Challenged: the project is completed and operational, but over budget, over the estimated time, and with fewer features and functions than initially specified; and (3) Failure: The project was canceled before completion. According to this report, only 26 percent of the projects were completely successful, while 46 percent of them were “challenged” and 28 percent were considered to be failures (Standish Group, 1999). The failed projects cost almost $75 billion in 1998. Bounds (1998) reported that only 26 percent of IT projects were completed on time and within budget. According to Yeo (2002), approximately 31 percent of two hundred thousand software development projects undertaken by U.S. companies in 1999were cancelled or abandoned before completion, representing a loss of almost $62 million. It was also reported that only 13 percent of IT system projects were considered successful by sponsoring managers, while only 16.2 percent of software development projects were completed on time and within budget (Yeo, 2002). It can be argued that smaller projects are more manageable and it is usually easier to ensure their success, and thus, smaller projects are more likely to succeed than large projects. On the other hand, one can argue that larger projects would have more funding and resources and therefore should have a higher probability of success. However, we argue that while the smaller projects may be more manageable, project management can be the critical factor in ensuring the success of the projects, regardless of the size. Some of the critical factors to project success are user involvement, executive support, and a clear statement of business objectives. In this context, SWOT analysis and the Theory of Constraints provide a comprehensive framework that can address the effectiveness and efficiency of project planning. Wei, et al., (2002) proposed a resource constrained-based project management model for project planning, implementation and control. The research does not include Theory of Constraints as a tool for effective project selection. Another model used SWOT analysis to make decisions on effective use of resources for housing projects (Ziara and Ayyub, 1999.) The methodology considered both the options and constraints of relevant socio-economic factors in the planning and construction of urban housing-project developments. A selection of R&D projects models consist of integer decision variables for both the number of researchers allocated and project selection. Researcher allocation and project selection are subject to several linear and nonlinear goal constraints (Taylor, et al., 1982). In this study, we have provided a framework for effectiveness and efficiency of IT project planning using SWOT analysis and Theory of Constraints. There is a potential for further research using both these tools to address the selection of projects in a more efficient and effective manner. 2. SWOT Analysis Over the years, there has been much emphasis on gaining efficiency in project management. Existing tools such as CPM and PERT reduce both project lead-time and the required resources to complete a project. However, the objectives of the project, plans, and required resources assigned have been taken for granted. Therefore, insufficient attention has been paid to analyzing the relevance of the project objectives within the context of broader, company-wide goals, and to the effectiveness in project planning and implementation. How can one distinguish effectiveness from efficiency in project management? Table 1 displays a brief distinction of effectiveness versus efficiency and the possible outcome under various scenarios. In Table 1, we can define effectiveness as the extent to which the output of a project meets the objectives of the project. We can define efficiency as the ratio between the outputs achieved, i.e., the success of the project in achieving its objectives with the input of the project, i.e., the utilization of resources. The term “objectives” deal with whether or not the organization will benefit from the project. The key element to remember about project management is that a development project that fails to address the right objectives cannot succeed, even if those objectives were realized very efficiently. SWOT analysis is an effective framework for analyzing the Strengths, Weaknesses, Opportunities, and Threats of an organization (or a project) that helps to address the effectiveness of a project planning and implementation. The acronym comes from an old term from the strategic planning field that is concerned with the content and the objectives of the project, and with identifying the right things to do. What is right depends on the specific interface between the project, the objectives it serves, and its environment (target groups, market, law and regulations, etc.). Strengths would define any internal asset (expertise, motivation, technology, finance, business model, etc.) that will help to meet demands and to fight of threats. What are we good at in project management? How are we doing competitively? Moreover, what are our resources? Weaknesses describe internal deficits (lack of motivation, lack of transport facilities, problems in distribution of services or products, low reputation, etc.) that hinder the organization in meeting its demands. In this context, one may consider the following questions: what are we doing badly? What annoys our clients most? Opportunities describe any external circumstances or trends that favor the demand for an organization’s specific competence. For example, what changes in economic, political, or technological factors (development of new markets for high quality products, new technologies that favor our product, etc.)? Do we expect to see in demand in the near future? The project’s success probability depends on whether its strengths not only match the key success requirements for operating in the target environment but also exceed of those of project threats. Threats define any external circumstance or trend (establishment of strong competitors, government deficit, or regulations that limit free distribution of our products or buying our services, etc.) that will unfavorably influence demand for an organization’s competence. Table 2 summarizes some of the key questions and typical answers in each area. Dell Computer Corp. can be viewed as an example of how an IT company can use a SWOT analysis to carve out a strong business strategy. Dell recognized that its strength was selling directly to consumers and keeping its costs lower than those of other hardware vendors. As for weaknesses, the company acknowledged that it lacked solid dealer relationships. Identifying opportunities was an easier task. Dell looked at the marketplace and saw that customers increasingly valued convenience and onestop shopping and that they knew what they wanted to purchase. Dell also saw the Internet as a powerful marketing tool. On the threat side, Dell realized that competitors like IBM and Compaq Computer Corp. had stronger brand names, which put Dell in a weaker position with dealers. Dell developed a business strategy that included mass customization and justintime manufacturing (letting customers design their own computers and custombuilding systems). Dell also stuck with its direct sales plan and offered sales on the Internet. In short, SWOT analysis provides a framework for better understanding of framework conditions (strengths and weaknesses) from external framework conditions (opportunities and threats)? For example, an information technology department needs to determine the strengths and weaknesses of its people the project objectives by focusing on the following questions: What are our objectives? What do our customers want? How do we distinguish ourselves from competitors? How can we improve our services? How can we distinguish internal and its technology. It also needs to ensure that the IT strategy complements the company's business goals. The department head needs to ask: What is each staff member good at in project management? What are they not good at in project management? Project leaders also must consider opportunities and threat  or customers and competitors. How attractive is the market or direction they are considering? What is their market share and cost structure? Effective project management requires a development of a mission statement for the project, i.e. what is to be achieved? For example, an IT project to install a number of computers and relevant software tools can be viewed to enhance productivity in an organization. According to Horn, Neiman et al (1994), it is useful to start with critical factors in the project’s environment, i.e., opportunities and threats. In particular, they argue that opportunities and threats shall not only be formulated based on existing conditions but also by future trends. 3. Theory of Constraints The Theory of Constraints (TOC) is a management philosophy (Tolerate 1980), where the organization may be considered as an interdependent series of processes rather than an independent business unit. TOC offers a methodology for achieving system optimization rather than process optimization. The theory can be characterized as a set of concepts, principles, and measurements that focus on the ultimate output of the whole system, not just that of a component part of it. TOC views any organization as a system, as an integrated whole instead of a collection of related parts with the primary emphasis on the output of the entire system, i.e., “Throughput.” Throughput is defined as the difference between the value of output (sales) and direct cost (variables such as raw material, parts, etc.) and thus as the rate at which the system generates money through sales. Therefore, on one hand, TOC promotes the use of global system-wide measures rather than local measures and the performance of any unit within the organization is measured as to its contribution to the organizational goals and objectives. The focus of the TOC philosophy is that any organization (or system) has a constraint (or a number of constraints) that dominates the entire system. The secret to success lies with managing these constraints and the system. On the other hand, TOC moves the performance measurement from a cost-oriented to a throughput-oriented paradigm. Throughput provides a more meaningful and effective measure of improving organizational performance, and does not necessarily prescribe cost cutting and downsizing strategies. In Table 3, we can define effectiveness as the extent to which all constraints are identified and managed in projects. We can define efficiency as the extent to which all weak links have been strengthened i.e., the utilization of resources. The term “objectives” deal with whether or not the organization will benefit from the project. Deming (1993) described the danger of sub-optimization as follows: Anything less than optimization of the whole system will bring eventual loss to every component of the system. He noted that the obligation of any component is to contribute its best to the system, not to maximize its own production, profit, sales, or any other competitive measure. Some components may operate at a loss themselves in order to optimize the whole system. Sub-optimization may result from a lack of awareness or an assumption that maximizing the performance of each component part of the system will automatically maximize the performance of the system as a whole. According to Deming, this is not a valid assumption. Another reason cited for sub-optimization is analytical thinking (Dettmer, 1998). Analytical thinking breaks complex problems into smaller, more manageable sub-problems that may be analyzed separately. After solving each sub-problem, often in isolation from the rest, the pieces are reassembled into a whole again. This analytical thinking is based on the assumption that if we make each part of a system perform to its maximum capability, the system as a whole will benefit. This approach may be useful in analyzing sub-components and, thus, there may be a certain appeal to the idea of disassembling and reassembling again. However, as systems become more complex, the interaction and interdependencies of components (particularly organizations and people) would define the performance of the system as a whole, and the effectiveness of analytical thinking become questionable. In TOC, an organization is viewed as a system and components of the system under management subordinate their efforts to the larger system of which they are a part. However, the primary focus is on the constraints that hinder the organization from achieving its goal. More specifically, the organization is compared to a chain (Figure 1) or a network of chains (Figure 2). In this analogy, one weak link limits the performance of the entire chain. This weakest link is the system’s constraint that has to be targeted for improvement, be carefully examined, and efficiently addressed. Once the weakest link is strengthened, the next weakest link becomes the constraint that limits overall system performance. Therefore, at each stage, improving the performance (throughput) of the chain requires strengthening the weakest link at that stage. It may be relatively less complex to locate physical constraints, such as limitation of resources or technology to support production/ operation/ distribution processes, because they are tangible. In most cases, however, the real constraints to improving a system’s performance are not physical but policy constraints. They are rules, plans, procedures, measurements, or other guidelines that are less tangible and at the same time prescribe the framework for operations and management of the internal organization, and its interface with external environment. They can manifest themselves in training and be the benchmarks and measurements that are used to assess success or failure. In Goldratt’s view, the policy constraints are usually much more devastating than physical constraints, and nearly every physical constraint results from some policy constraint. It is also more difficult and challenging to identify the exact policy constraints, as it requires a complex chain of cause and effect that can be traced back to a root cause. Furthermore, in larger organizations, the policy constraints often go across multiple functional units and require addressing those constraints and breaking them at higher levels of the organization. Therefore, due to the relative complexity of policy constraints, Goldratt (1992) proposes a more elaborate process, requiring three major steps: 1. What to change? Where is the constraint? 2. What to change? What should we do with the constraint? (Develop and validate new ideas to break the constraint that would deliver the desired results, and at the same time minimize the adverse side effects.) 3. How to change? How do we implement the change? (Convert those ideas into effective action and reality.) These three questions provide the framework for the TOC Thinking Process. Furthermore, this thinking process is logic based, and thus not confined only to physical constraints, manufacturing systems, or for-profit organizations. It is applicable to any system, as long as the goals of the system can be clearly defined. In order to apply this thinking process, there are four criteria (Dettmer, 1998) to be satisfied: 1. Motivation to improve the system, 2. Thorough knowledge of the system that needs to be improved 3. Some degree of authority, or at least influence, to initiate change, and 4. Understanding of the TOC Thinking Process methodology. 4. Five-step Thinking Process: A Framework Using the rigor and logic of cause-and effect, the five-step thinking process (shown in Figure 3) would enable the management team to solve a problem and/or develop an integrated strategy, beginning with the symptoms and ending with a detailed action plan that coordinates the activities of all those involved in implementing the solution. The five-step thinking process is illustrated in Figure 3. Current Reality Tree (CRT): This step examines the cause and effect logic behind the undesirable effects in the system. The CRT process starts with the observed Undesirable Effects (UDEs), and builds, with strict logical rules, a model of the system. It helps management to identify the system constraint or what to change. The Management team making CRT must have knowledge of the system and it would help if the team agreed on the problem. Evaporating Cloud or Conflict Resolution Diagram (CRD): This step reveals hidden conflicts and underlying assumptions behind the UDEs. It can lead to breakthrough solutions. It helps a management team to begin to answer “what to change to,” and helps the team to agree on the direction of the solution that will work. Future Reality Tree (FRT): The FRT step is used to confirm the solution and to identify potential negative side effects. FRT construction starts with the Injection from the CRD step, and uses the logic and UDEs from the CRT to develop the future system. This would enable management to remove negative effects and see if a solution will work. As part of FRT construction, the UDEs are turned into Desired Effects. Prerequisite Tree (PRT): This step is used to outline how to cause the change. It helps management to identify obstacles, sequence, and milestones and to overcome the obstacles in implementing the solution. Transition Tree (TT): This is a detailed step-by step implementation of the solution. This is used to cause the change. It would help management to see the plan of action for overcoming obstacles and implementing the change. 5. TOC Solution in Project Management: A System Approach Applying TOC to the areas of project management provides a whole system view of the challenge. In the TOC approach, the set of tasks that determine when a project can be completed is the Critical Chain. They are called a chain, rather than a path, since they take into account resource dependencies. Thus, the faster the critical chain tasks are completed the sooner one can finish the project. Therefore, the TOC-based solution for managing a single project, whether stand alone or as part of a portfolio of projects, is known as critical chain scheduling and buffer management. It provides part of the answer for the priority aspect of the question "What should I work on?" which, if not addressed appropriately, drives multi-tasking behaviors in multi-project environments (Goldratt, 1997; Newbold 1998; Patrick 1999). In managing a project, the emphasis is on the delivery of tasks that make up the project. A task is defined as a set of activities performed by one or more resources on a project. For each task, the inputs are from one or more resources outside of the task, and its output is required for one or more resources outside of itself. A task cannot begin work until all required preceding inputs are received. A task is not complete until all required outputs are not only finished (according to the task completion criteria) but also passed on to all subsequent resources requiring the output of task. It is assumed that if these tasks are done on time, the project will be completed on time as well, and thus there is more focus on getting the task done. In this traditional approach, the Critical Path Method (CPM) of scheduling is defined as a project management method of calculating the total duration of a project based on individual task duration and their interdependencies. In other words, we determine which path of work will take the longest, and thus manage all others to fit within this longest path. However, the common project focus is on each individual task’s duration and resource requirement. Thus, the variation in an individual task’s demand for resources would cause variation in resource demand during the project’s execution. TOC considers a project as a network of required tasks that move toward a set of clear objectives intended to be completed under budget and on schedule. As shown in Figure 4, for a project with goals such as developing a new IT service for sales management, certain prerequisites are needed. These prerequisites are the precedents for the goal, i.e., what is needed to achieve the goal. These precedents become the successors for their prerequisites. In order to achieve the goal from the prerequisites, there may be some underlying assumptions to clarify all needed dependencies between the predecessor and the successor. This process is repeated a number of times until the start task is reached. The result is a network that describes what must be in place in what order and what is the logic behind these successive tasks. Austin and Peschke (1999) have suggested a 5-step process in building a TOC project network. Traditionally, in CPM or PERT, given the focus on individual activities, there is a strong tendency to include contingency time and other resources within each activity. This estimate, and often an over estimate of contingencies, are justified to account for uncertainty due to individual activity that commonly causes variations in the activity as well as special cause variation that is specific to some local condition. This is argued to protect against Murphy’s Law: “If anything can possibly go wrong, it will go wrong.” The amount of these contingencies are not usually well specified, and they are justified to meet the deadline with a high level of certainty and to reduce the risk. Furthermore, managers or co-coordinators at each level within the organizational hierarchy could build in their own reserves on top of the reserves built in by people reporting to them. In addition, in this approach, as Goldratt argues, there is a tendency to misuse the safety time created within the estimated times for each activity. There is often a perception among the employees that when safety time is built into the estimates they do not need to worry about starting on time, and thus, according to Parkinson’s Law, “work expands to fill (and often exceed) the time.” Therefore, starts may be delayed, and this, known as “student syndrome,” would leave everything to the last minute. Even if starts are made on time, there is a tendency not to go at full steam, particularly when there is pressure to do other tasks. Consider, for instance, an IT project in the Reliable Company that consists of six activities (A, B C, D, E, and F). Table 4 shows the activities and the PERT/CPM solution to manage the project. Figure 5 displays the network of the activities for the project. Figure 6 displays the measure of required time and other resources for completing the project under the PERT/CPM and TOC approaches. Goldratt believes that a consequence of the three time estimates used in PERT and their weighted mean being used for scheduling by CPM will be a tendency to overestimate the times and other resources to give a reasonable degree of certainty of completion. As he noted, the uncertainty existing in every project is the underlying main cause for most problems. Furthermore, the allocation of resources (funding, people time, skills, equipment, etc) to various activities is viewed as a separate stage of project management. In particular, many of the resources required for individual project tasks are often sub-contracted, where these resources may be committed to other tasks or projects at any time. Thus, the nature of disturbances associated with most project specific tasks may further complicate the availability of resources. In particular, in PERT, all activities, whether or not they are on the critical path, will receive similar treatment with regard to uncertainty, and thus they will have similar safety time and resources. However, TOC removes all these contingencies from individual activities and aggregates them into a buffer for the entire project, as the commitments regarding the completion date are only made at the project level (Figure 6B). In other words, the safety associated with the critical tasks can be shifted to the end of the chain, protecting the project premise (the real due date) from variation in the critical chain tasks. This concentrated aggregation of safety, which can be smaller than the sum of the parts, is known as the “project buffer.” The project team members who work on the project are expected to make realistic estimates of time and resources communicate their expectations on activity duration and attempt to meet those estimates. To prevent non-critical activities from delaying critical ones, “feeding buffers” are placed where non-critical paths feed into the critical chain to protect the start of the critical chain tasks. The feeding buffers, which again can be smaller than the sum of the parts due to aggregation, contain most or all of the contingency reserves, relating the relevant non-critical path. Proper management of the feeding buffers prevents the critical chain from changing during the project execution and leads to a rigorous project plan. As a result, the project promise will be protected from variations in the critical chain by the project buffer, the critical chain is protected from variation in non-critical work by feeding buffers, and consequently the project is protected against Murphy’s Law. In short, TOC would relocate the safety time and resources in strategic positions such as project buffer or feeding buffer. This will have the effect of reducing the length of the critical path as shown in figure 6A and 6B. The decision to cut the overall safety time and resources is subject to the level of confidence that appropriate team members of the project have in this process. However, it is recommended that the first emphasis should be placed on finishing on time before looking for a reduction in overall time: in TOC language, they go for “exploit” before “elevate.” This TOC approach, by allowing a “whole system” view of the project, identifies the critical chain and the project buffer that protects it from inevitable uncertainty. Task’s duration estimates no longer have to be long enough to have a high probability of completion. Shortening the task duration estimate, therefore, avoids major impact of Parkinson’s Law (work expands to fill the time allowed) and Student’s Syndrome (delaying the start of a task due to having more than enough time to accomplish it) at the task level. It also removes detrimental pressures and associated behavior of artificial task deadlines from the concerns of project resources. The buffers, and their consumption and replenishment during the actual project execution, can provide guidance in assessing the chain of activities that is in the greatest jeopardy of delaying the promise of the project. This can provide a clear direction for the attention to be paid to the most critical constraint of the project and the most beneficial use of a resource. For example, if a project buffer is sufficiently unused, the project premise can still be protected from distractions and disruptions on critical tasks that may jeopardize the project. On the other hand, if a project buffer were sufficiently used, this would indicate a heightened risk of the project promise and the priority for attention in adjusting the allocation of resources to address the critical tasks associated with that project. Buffer management thus would help project managers focus on maintaining the premise of the project (effectiveness) during its execution, keep it on schedule and under budget (efficiency), know the important priorities, and make the necessary adjustments. Therefore, the critical chain approach of concentrated protection would bring about a dual benefit. First, it helps to protect the project appropriately with minimum impact on the estimate of overall project duration. Second, it would help us to monitor risk effectively throughout the course of the project. The following section will discuss the system of buffer management as an important ingredient of TOC and as an effective method for multi-project management. 6. The TOC Multi-Project Method Organizations often tend to launch multiple projects concurrently in order to take advantage of valuable new opportunities. However, the demand of these multiple projects would impose conflicting priorities on the constraint capacities, resources, and policies of the organization. This, in turn, decreases the chance of success of these projects. In particular, project managers from various functional areas within an organization may argue for the functional importance of their own projects and for higher priority. On the other hand, as Patrick (1999) notes, if a resource divides its attention between different tasks before handing off task deliverables, this would prolong all the projects involved, since all of that resource's successors on each project will have to wait longer than necessary due to time spent on other projects' work. The projects will also be impacted by the variability of not only their own tasks, but also of those associated with the other projects that are interleaved within them. Therefore, most projects will take significantly longer than necessary, in both their premise and their execution. TOC and its principles, when applied to multi project systems, provides guidance on assessing the capacity of such systems and related mechanisms for the synchronized launch of projects and improves the effectiveness of their execution. The TOC method consists of five steps: (1) Prioritize the organization's projects, (2) Plan individual projects via critical chain, (3) Stagger the projects, (4) Measure and report the buffers, and (5) Manage the buffers, These steps together overcome the challenges of physical and policy constraints, and help to address the priorities among the projects and the activities within each project. 1. Prioritize the organization's projects: During the first step, the projects must be prioritized at the organizational leadership level. Only at that level would one be able to properly evaluate the potential contribution of each project to the organizational goals and objectives and determine the optimum order of priority among the projects. However, if the value of this step is left to middle managers or, worse, to individual project managers, this would increase the chance of sub-optimization, and consequently failure of effectiveness. 2. Plan Individual Projects via Critical Chain: As was discussed earlier, there is a strong tendency in any functional area to overestimate the contingency time and resources for each task within a project partly to protect against Murphy’s Law, and partly to avoid negative consequences for themselves. Unfortunately, a direct outcome of embedding such “contingencies “ within individual estimates of task duration is that the estimate of the overall duration of a project grows beyond the limits acceptable to management, customers, and the bottom line. Therefore, management usually responds with what we might call backpressure. Typically, this means that management mandates cuts in all estimates of task duration, usually in a rather arbitrary manner. The battle that results between management and staff, of course, rages on. However, the system approach in TOC would concentrate on the areas of the project’s network where the protection is the most effective. There are two such areas: first, and perhaps the most important, is at the end of a project's Critical Chain, known as the Project Buffer, and the second, called the Feeding Buffer, is placed between every Critical Chain task and any non Critical Chain task that feeds the Critical Chain task. The purpose of the Feeding Buffers is to protect the starts of those Critical Chain tasks that require inputs from non Critical Chain tasks, so that by protecting the starts of the Critical Chain tasks from the untimely availability of the required inputs, with the Feeding Buffers, we prevent the project's longest chain of tasks from becoming longer unnecessarily. The TOC approach would help to effectively protect each project execution, as well as to efficiently manage the buffers in a Multi-Project environment. 3. Stagger the Projects: The TOC approach staggers the projects based on the availability of one resource that is commonly required by most of the projects within an organization and more heavily used relative to other resources (Newbold 1998). This is called the drum resource or synchronizer. The role of the drum resource is to set the pace at which projects are launched into the system, and to regulate the flow of work-in-process around the full capacity of the most restricted resource. The production rate of this drum resource typically provides the pace for the rest of the system, and thus the work-schedule for this drum resource is used to determine the rate at which projects are allowed to enter the system. Therefore, the drum resource is never overloaded. Given the relatively heavy load of the drum resource, other resources, while they are part of the solution, will not be overloaded. Furthermore, not all the projects are consistently in use of the drum resource. Therefore, there are times when the stagger is insufficient to protect other resources from peak loading and pressures to multitasking. In order to address this problem, additional stagger is added between the projects, known as the Capacity Buffer. This would serve to protect the level of a cross-project, to insure that on average there are enough resources to schedule for all the projects, and to efficiently protect them from any disruptions and delay. Obviously, by properly identifying the drum resource and effectively using capacity buffers, staggering the projects of the organization can be an important step in multi-project management. TOC, in particular, tends to focus on maximizing the flow of work through a system rather than balancing capacity. This higher-level view of system capacity rather than resource capacity leads to the conclusion that it is enough to keep as little as one resource effectively utilized to manage and maximize the throughput of the system. 4. Measure the Buffers: As we discussed earlier, proper attention on buffer measurement and reporting throughout the execution of each project is vital to the success of completing the project. This task will become even more critical in multi-project environments as it affects the reality check of the overall schedule for the organization. In particular, the size of the buffers is often viewed by those who report as an implicit measurement of their own performance, and thus there may be a tendency to a biased report of the safeguarding buffers. Therefore, a timely, unbiased buffer report will be an important tool for maintaining focus throughout the organization. 5. Manage the buffers: While a timely, unbiased buffer report plays an important role in maintaining proper focus throughout the organization, it plays an even more significant role in setting priorities correctly. Project managers must constantly report the status of the projects and the status of various buffers, interpret them properly, and communicate them to the appropriate managers in the organization so that they can identify the problems and the need for possible reprioritization. For example, suppose a resource is in critical need of multiple tasks and one needs to determine which one of these tasks is the most urgent. All is needed is to look at the buffers associated with the various tasks, and examine which task is associated with a project buffer since it always has priority over tasks that are associated with feeding buffers. Similarly, when two or more tasks are all associated with similar buffers, then the task whose buffer is in greater jeopardy is clearly given the highest priority. Management of the organization's global buffers and their timely and comprehensive reports would help the management team to identify the flexibility in the assignment of resources, and to set the priorities that protect all the projects of the organization from undesirable disruptions and delay. More specifically, if such a report indicates that one project is in serious trouble, the same report also shows where the right resources can be borrowed without jeopardizing the premises set for the projects. 7. Concluding Comments Traditionally there has been much emphasis placed on gaining efficiency in project management. CPM, PERT, and Gant charts have been developed to facilitate the planning and execution of projects on time and within the budget. On the other hand, project managers have taken the effectiveness of project planning and execution for granted. In other words, there has not been sufficient emphasis placed on how to achieve effectiveness in project management. In particular, a project manager needs to clearly identify the project’s goals and objectives in support of the organizational mission and vision statements so that the project team could focus on the effectiveness of project planning and execution before looking for efficiency measures. SWOT analysis is an effective method for identifying the strengths and weaknesses and examining the opportunities and threats in project management. TOC takes a system approach in managing a project, using throughput as an effective measure of performance evaluation. It identifies the constraint that dominates the entire project at any given time and allocates resources to break the constraint and to achieve the project’s objectives. Thus, TOC Time Management technique (Critical chain scheduling) contributes significantly to the effectiveness as well as to the efficiency of project management. Furthermore, TOC has been extended to allocate resources to multiple projects that share common resources. This application maximizes the number of projects that an organization can handle while maintaining the principles for reducing project duration on each individual project. TOC can also be effectively applied to other areas such as project risk management and project cost management. 8. REFERENCES Austin, K. M., and Peschke, R. E. (1999). How to Build a TOC/Critical Chain Project Network, APICS CM-SIG Symposium Proceedings, March 22-23, 1999, Phoenix, Arizona. Bounds, G. (1998), “The Last Word on Project management, “ IIE Solutions. Deming, W. E. (1993). The New Economics for Industry, Government, Education, Cambridge, MA: MIT, Center for Advanced Engineering Study. Dettmer, H. W. (1998). Breaking the Constraints to World-Class Performance, Milwaukee, Wisconsin: ASQ Quality Press. Goldratt, E. M. (1992). The Goal, 2nd Revised Edition, Great Barrington, MA: North River Press. Goldratt, E. M. (1997). Critical Chain, Great Barrington, MA: North River Press. Horn, L., et al. (1994). SWOT analysis and strategic Planning-A Manual, (GFA, Eulenkrugstr, 82, D22345 Hamburg, Germany). Newbold, R. (1998). Project Management in the Fast Lane, Boca Raton, FL: St. Lucie Press. Patrick, F. S. (1999). Getting Out From Between Parkinson's Rock and Murphy's Hard Place. PM Network 13 (April): 57-62. Standish Group Internation (1999), “Chaos: A Recipe for Success”, The Standish Group International. Taylor, B. W., et al. (1982). R&D Project selection and manpower allocation with integer nonlinear goal programming, Management Science, Vol. 28, Issue 10, pp1149 –1158. Wei, C., et al. (2002). Resource-constrained project management using enhanced theory of constraint, International Journal of Project Management, Vol. 20, Issue 7, pp 561-567. Yeo, K.T. (2002), "Critical Failure Factors in Information System Projects", International Journal of Project Management, Vol. 20, No. 3, April, pp. 241-247. Ziara, M. M. and Ayyub, B. M. (1999). Decision Analysis for Housing-Project Development, Journal of Urban Planning & Development, Vol. 125, Issue 2, pp 68-83. 1 sabbaghi@iusb.edu 2 gvaidyan@iusb.edu