It is hard to point out the beginning of the project management. But much more important than history is current discussion taking place in business to find the best methodology that would support project portfolios management. Productivity of project portfolio is limited by the constraint like the speed of the car is mainly limited by the power of its engine. The problem is that constraints tend to be dynamic and “Assets constrained during one time period may be different from assets constrained in another” (Seider, 2006: 43). Therefore if someone would be able to track and manage current constraint then he would be also capable to maximise the throughput of the project portfolio. It is said that Theory Of Constraints (TOC) was “Developed primarily by Dr Eliyahu M.Goldratt” (Mabin and Balderstone, 2003: 569). Also in his concept of Critical Chain (CC) Dr. M.Goldratt next to TOC assimilated time buffers method to secure project delivery date as well as to control the efficiency of the dynamic CC (Leach, 2000:118). Despite the above mentioned advantages most of the TOC applications could be found not in the project portfolio management but in the manufacturing sector (Mabin and Balderstone, 2003: 574).

The author of this critical literature review possessed ten years experience in project management methodologies consultancy. He has never witnessed (Cottrell, 2005: 142) any successful concurrent application of both buffer management and TOC method in project portfolio. Of course this is neither reason nor contributing argument for inconsistency in TOC or Goldratt’s concept of tasks chain buffers. To say so - it would be just a false premise (Cottrell, 2005: 92). But it could be treated as an assumption that there must be a scientific discussion going on that could explain such a long lasting tendency. Could it be that some theories like TOC in fact commonly acceptable are not applicable to each project situation? Some claims that “no conceptual model currently exists that enables project managers to understand why different approaches exist”, (Pich et al, 2002: 1008). Also nowadays it is hard to remain objective about Goldratt concepts because in literature “papers that seek to study the good and the bad together-exactly what we need! -are rare.” (Trietsch, 2005: 28). Such a situation is risky because project manager could make use of the wrong project management concept.

Change influences the frequency of the portfolio planning cycle. Seider, (2006: 48) recognises reason for change and accepts more frequent planning cycle unfortunately only in the case of adding new projects to the already existing portfolio. As a result here planning cycle frequency is not very high -“biannually for some companies, quarterly for others.” (Seider, 2006: 47). Fortunately to such a solution new projects most probably are not added on a daily basis. Critic could be provided that there might be other reasons for more frequent changes incurred during project life cycle because “The reality of project management is that you never really have the time to create the perfect plan” (Chin, 2004: 10). Therefore adding new projects to a portfolio is not the only reason for CC rescheduling. CC as a sequence of the tasks scheduled on the major constraint will change for instance if new major constraint will be identified. This certainly will determine new start dates for certain tasks in portfolio. And if we remember that “The fundamental response to change is not logical, but emotional” (DeMarco and Lister, 1999: 197) then it could be not a surprise that some team members prefer static, project planning done in advance instead of dynamic schedule!

Further critic on Seider, (2006: 47) point of view on the role of the functional manager in portfolio management could be provided because it should be noted that “project manager and functional manager are likely to claim their work should have the highest priority” (Burke, 2003: 292). Under functional organisational layout - change could initiate new discussion on priorities and could result in a conflict. So what if change could raise the stress level of the project team members and direct toward conflict situations? There are also other reasons that could support change except for adding new projects to portfolio. It is possible that project scope, estimates, priorities could change as well (Kerzner, 2000: 385). All this would affect schedule dates and would imply changes in workload. The conclusion is that change occurs much more often in project portfolio than some authors expect and that the reaction to this could unfortunately be emotional. Each time the constraint will tend to change it is necessary to refocus to a new CC.

There is a certain project management concept dedicated to deal with project scope change in portfolio management - Agile. It is characterised by “agile environment of frequent change” (Chin, 2004: 62). Any project maintains relations to the number of stakeholders and “In the large corporation, product development projects can be complex, cross-functional efforts with many stakeholders” (Chin, 2004: 16). Stakeholders could be represented as project manager, team members, subcontractors.

Projects could be run within the company by the team build-up of the company’s employees. In such a situation changing scope, schedule would affect only one organisational culture and most probably only one project portfolio. So “it often doesn’t make sense to try to create an agile PM environment across multiple corporate cultures” (Chin, 2004: 18). Let us here imagine general contractor acting in building industry and having own project portfolio. General contractor divides project into subprojects and direct responsibility for a certain deliverables to subcontractors. In such a layout these subcontractors are representing some set of the stakeholders. They most probably could have also other contracts scheduled for the other general contractors. Therefore if the change would occur in contractor portfolio it would affect the schedules of the subcontractors and as a consequence could result in conflict with the other general contractor and react on another project portfolio. So this is truth that ”Stakeholders often resist change, so much of the manager's job is to anticipate and soften resistance by creating flexible contracts” (Pich et al, 2002: 1019). But what if such a flexible contract is not possible because it could potentially interfere with due dates stated in the other one already signed by subcontractor? The whole situation could be imagined like a web of hubs-contractors joined by the nodes-subcontractors. If one of the hubs were moved then through nodes so would be the others. One of the prerequisites for the Agile methodology successful application is that it has ”the best chance of success when the project operates under, more or less, a single organizational umbrella” (Chin, 2004: 17). Such a solutions for changing project environment limits number of stakeholders and assures in general one organisational culture. Could any project oriented company fulfil this prerequisite?

A further argument could be that as shown previously, CC management implies change more often due to the rescheduling to the changing constraint. Therefore the acceptance of changing dates could be conditioned by the stakeholder’s decision. Most probably the larger the number of stakeholders taking part on the project portfolio the least probable is efficient acceptance of change by all interested parties. It is not surprising that “Agile PM is more applicable when there are fewer organizational stakeholders.” (Chin, 2004: 17).

Bearing in mind the above arguments it is unavoidable to ask a question. How technically could be the more frequent portfolio project planning cycle supported? For instance how to efficiently sequence work in the new CC based on the new variable constraint like specific employee or a group representing certain limited capacity. It is important to realize that in project portfolio such a CC would consist of the tasks derived from the number of different projects. This is the case where one resource allocation could be done to a few or even more projects. Seider, (2006: 43) refers to a software solutions as to a “clumsy to use”. Criticism of his point of view could be that no references to any research results constituting such an opinion has been given. Also it is hard to find any argument supporting such a conclusion for instance some exemplary case. Certainly software will not manage and direct project portfolio but “it will speed up data processing if the information system has been well designed” (Burke, 2003: 323). It would be quite problematic to readjust CC in projects portfolio and calculate manually these “dozens” of workload interactions, resource allocations, potential paths changes. Depending on the frequency of the planning cycle this manual scheduling work could be simply considered as the waste of time. Especially if attention is paid to the previously shown high tendency for constraint to change. At the top management level CC and capacity planning is done mainly upon adding a new projects to portfolio (Seider, 2006: 48). From that point of view it seems to be fairly possible to use a very simple software solutions, even “paper-pencil” calculations to support such a process. But previously presented contributing arguments show that changes for many other reasons tend to occur much more often. Under such a circumstances due to increasing management workload a very good project portfolio management software is a must!

Could it be that managers tend to avoid the practical approach toward the TOC resource leveling in projects portfolio? If “only about 5% of project managers routinely resource-level their plans” (Leach, 2000: 118) then really one could say that this practise is against TOC management. If the Project Manager is not a very good user of the software tools supporting resource levelling then how could he efficiently support calculations related to more frequent planning cycle in the project portfolio? As already shown, more frequent planning cycle would be influenced by the more frequent change.

Within critical review on a TOC concept presented as being developed by Goldratt a very simple question, certain sign of self criticism could appear. Would it be really possible that previously mentioned Goldratt ideas haven’t been earlier discovered? Do Authors are right by present them as really new? Seider, (2006: 43) points directly to Eliyahu M.Goldratt as a developer of TOC supporting concepts. In fact he gives no remarks to any other potential “fathers” of the methodology. Also Mabin and Balderstone, (2003: 592) show that TOC methodology in project management was developed mainly by Mr. Goldratt. Here as well no other potential authors has been mentioned. This list of journal articles sharing that particular opinion could be extended. But there are also business researchers representing different point of view. They are helping to understand the reasons for that specific title of this critical analysis and also are defining the scope of the future potential further research.

Trietsch, (2005: 27) shows that Goldratt popularised TOC theory at the beginning mainly in manufacturing area! But production activities tend to have more repetitive schedules than projects and so management of the constraint in such a repetitive environment is more predictable and more stable. Even not earlier than “In his third novel Eli Goldratt demonstrates the application of his Theory of Constraints to Project Management.” (Rand, 1998: 181). His first application was many years earlier in production environment.

Also the idea behind the Goldratt buffers concept is that it “has been well known since Goldratt's childhood. It is simply PERT/CPM!” (Trietsch, 2005: 29). It could be truth but then Seider, (2006: 43) and Mabin and Balderstone, (2003: 569) are not right. Programme Evaluation and Review Technic (PERT) “uses a probabilistic approach” (Burke, 2003: 295) to discuss the task duration. Of course if duration in PERT method is only probably then there is a gap in between optimistic and pessimistic task duration estimation. This gap could represent time buffer of a certain task, path or a project. Goldratt’s buffer “uses the uncertainty in the duration of the critical chain tasks to size the project buffer” (Leach, 2000: 118). Does not it sound almost the same? Of course there are authors that claims that in case of PERT “it is well documented that the approach is based on faulty statistical foundations.” (Rand, 1998: 181). But Rand, (1998: 181) cannot be given a credit for his opinion because in his short analysis he has not given any references to any valid statistical data sources constituting this point of view.

If the buffer is determined by estimations then in the following research - motivation systems could be discussed as potentially influencing it. For instance does someone estimate high pessimistic duration to secure himself and at the same moment to increase buffer size? It seems to be logic but without quantitative analysis it cannot be taken for granted.

Trietsch, (2005: 31) also presents that Critical Path Method (CPM) supported by resource levelling would result in the “true critical path in projects” Trietsch, (2005: 33). This true critical path limited by the major constraint is just the CC. So again authors promoting CC and Goldratt concept as something really new unfortunately miss the point.

The whole analysis in terms of methodology was prepared with triangulation in mind to assure that evidence “support and complement each other” (Cottrell, 2005: 143). From the beginning the author became interested in works on application of TOC and buffer concept method due to two most important reasons. TOC was applied at first in manufacturing environment which tend to have more well defined and repetitive schedules, stable constraints than project portfolios. Furthermore, “The lack of criticism associated with the use of the TOC methods” (Mabin and Balderstone, 2003: 590) defines this area as a very interesting subject for an exploration. Despite positive opinions are in fact factors conditioning successful application of TOC and CC concept in project portfolios. So Agile, Goldratt, TOC, buffers management are not applicable in all business cases! Evidence was provided that literature in many cases is in favour of the TOC and that some Goldratt ideas are not really the new discoveries. Moreover the author of this essay did not succeed in his research to find any TOC configuration system for successful application in different project portfolios. Identified gaps in the TOC and CC concept like change problem and motivation/conflict issues, planning cycle frequency, effective software support, subjective buffers estimations, number of stakeholders and organisations are certainly not the only successful conditions in project portfolio management. This analysis will be conducted in order to reveal even more of the areas of controversy.


© MBA Adam Łazarski
alazar@oditk.pl



References:
Burke, R. (2003) Project Management: Planning and Control Techniques John Wiley & Sons: Chichester, 4th edtn.
Chin, G. (2004) AGILE PROJECT MANAGEMENT: How to Succeed in the Face of
Changing Project Requirements AMACOM: New York.
Cottrell, S. (2005) Critical Thinking Skills Palgrave Macmillan: Basingstoke.
DeMarco, T. and Lister, T. (1999) Peopleware: Productive Projects and Teams Dorset House Publishing Company: New York, 2nd edtn.
Leach, Lawrence P. (2000) Critical Chain Project Management Artech House: Boston.
Kerzner, H. (2000) Project Management: A Systems Approach to Planning, Scheduling, and Controlling John Wiley & Sons: New York, 7th edtn.
Mabin, Victoria J. and Balderstone, Steven J. (2003) The performance of the theory of constraints methodology: Analysis and discussion of successful
TOC applications International Journal of Operations &
Production Management 23(6): 568-595.
Pich, Michael T., Loch, Christoph H., Meyer, A. (2002) On Uncertainty, Ambiguity, and Complexity in Project Management Management Science 48(8): 1008-1023.
Rand, G.K. (1998) Untitled book review of “Critical Chain” by E. M. Goldratt The Journal of the Operational Research Society 49(2): 181-181.
Seider, R. (2006) OPTIMIZING PROJECT PORTFOLIOS Research Technology Management 49(5): 43-48.
Trietsch, D. (2005) WHY A CRITICAL PATH BY ANY OTHER NAME WOULD SMELL LESS SWEET? TOWARDS A HOLISTIC APPROACH TO PERT/CPM Project Management Journal 36(1): 27-36.