- Email: [email protected]
Do you manage a project, or what? A reply to “Do you manage work, deliverables or resources”, International Journal of Project Management, April 2000
International Journal of Project Management 20 (2002) 325±329
www.elsevier.com/locate/ijproman
Do you manage a project, or what? A reply to ``Do you manage work, deliverables or resources'', International Journal of Project Management, April 2000 M. Lamers * Railinfrabeheer, Moreelsepark 1, Postbus 2038, 3500 GA Utrecht, The Netherlands
Abstract In the paper, some of the assertions in the editorial entitled ``Do you manage work, deliverables or resources'' of the recent April issue of the International Journal of Project Management are questioned. Here it is maintained that the WorkBreakdown Structure (WBS), is an essential instrument for Project Management and that it should not be considered as the result of the marriage of the ProductBreakdown Structure (PBS) and the Organization Breakdown Structure. WorkPackages are important for integration of the corners of the Iron Triangle. Next, to illustrate this, purpose and composition of both WBS and PBS are elaborated upon. Using PBS and WBS as a stepping-stone, this paper concludes by putting the project management concept in the broader perspective of the generalized requirement for `trees' as instruments for project management. The larger, the more complex the project, the more galaxies of project variables will strain project management. Redressing of such galaxies into hierarchically structured trees will then be necessary for project management to remain on top. # 2002 Elsevier Science Ltd and IPMA. All rights reserved. Keywords: Project management; Project trees; Iron triangle
1. In response to the editorial itself ``Do you manage work, deliverables or resources'', the editorial of the April issue, 18 (2), of the International Journal of Project Management, provokes a much-needed discussion. We do not use the WorkBreakdown Structure (WBS) properly, i.e. the work tree, to the extent that it gets confused with the ProductBreakdown Structure (PBS), the product tree. What are the dierences, and are these dierences important? Are both the PBS and the WBS required or is the PBS all we really need? I suggest that the WBS is required as well. Moreover, projects may even be in need of breakdown structures in addition to those two. The subject of project management requirements is wrongly reduced to a question about PBS and WBS. A project comprises more entities that may need to be controlled, and thus need to be controllable, than only work, deliverables and resources. This will be addressed at the end of the paper. 1.1. ``It is actually similar to batch manufacturing.'' A project is predominantly non-recurring. That is why it is a project. The comparison with manufacturing * Fax: +31-30-235-9036. E-mail address: [email protected] (M. Lamers).
is less ®tting. Batch manufacturing associates with recurring processes, whereas management of a project, in contrast, is non-recurring. Non-recurring processes are less deterministic since they contain more uncertainties. Hence, they are in need of more control eort, and thus possibly also in need of more (top level) control-variables than recurring processes. 1.2. ``Hence the WBS is the two-dimensional matrix formed by the PBSOBS. . .'' The WBS is not to be seen as only a two-dimensional matrix, which happens to be the result of the union of PBS and Organization Breakdown Structure (OBS). The WBS is a structure in itself developed after the generation of the PBS, with as little organizational prejudice as possible. In fact, it is a prominent tool for project integration. 1.3. ``However, if you look carefully at their original de®nition of WBS, what they de®ed was a Product Breakdown. . .'' I doubt whether it was ever an either-or question; that is whether the WBS, i.e. the work tree, was in fact meant to be just a product breakdown, a bill of materials. Why
0263-7863/02/$22.00 # 2002 Elsevier Science Ltd and IPMA. All rights reserved. PII: S0263-7863(00)00053-3
326
M. Lamers / International Journal of Project Management 20 (2002) 325±329
the urgency for one-tree happiness? Why would that be the ultimate symbol of a good project? Also, I've noted time and again, starting in the early 1970s, that titles of WorkPackages of a WBS were often incorrect. They did not, or still do not contain a verb. Often not even a verb-derived noun like management, but worse, just the name of a constituent product. Two reasons may explain the improper titling of workpackages. The ®rst, most legitimate one is that the WBS should be based on the PBS. This implies that the PBS should precede the WBS, which is also natural to begin with. First know what you're talking about, before you start talking. Even in the early phase of a project when there's no formal PBS yet, a System Concept exists. The System Concept can be regarded as the predecessor of the PBS. It will show up at the second level of the PBS. 1.4. ``Unfortunately, many people since have interpreted the words, Work Breakdown, literally. . .'' The unfortunate thing is the opposite, many people do not interpret these words literally enough. This is the second reason for WBSs to be insuciently correct. It shows, as already mentioned earlier, that apparently we are more inclined towards products than towards processes, more to goals than to means. This yields a WBSdisposition by not using verbs where they should be used, in the naming of WorkPackages. This phenomenon also shows in the naming of schedule-activities, which proves that at least we are consistent in our inclination. All in all, a WBS often makes the impression of a dilapidated PBS. Hence arises the editorial confusion. The editorial attacks head over heels an assumed culprit in order to be provoking, without due regard for a relevant de®nition of the project management problem. The editorial is an example of symptom ®ghting by being controversial and provocative on a derived problem only. This invokes the danger of leading the audience astray because of inadequate initial conditions of the wanted discussion. 1.5. ``Next, you should develop an Organization Breakdown Structure'' and ``. . . you decide ®rst what the components are, then who is responsible. . .'' The sequence PBS, then OBS, then WBS (because of the reasoning embedded in PBSOBS=WBS) is an erroneous reasoning. The WBS is not to be regarded as an ersatz-PBS. The proper line of thought is, ®rst the de®nition of the product, then the de®nition of the processes required to generate the product, then the control of those processes, and only then, the organization to exercise the processes and their control with. Clearly some iteration is involved and some acceptance of initial (e.g. organizational) conditions. But that is why project
management has been `invented', i.e. to create a distance from existing organizational mechanisms of organizations. This then leads to the, non-commutative, expression WBS/PBS=OBS. Which by the way also `literally' shows the PBS as the basis of project management. 1.6. ``People manage people. . .'' and ``The work of a project gets done en passant.'' ``People manage people. . .'' is too much of a truism, like ``People love people''. Both are cultural phenomena, which means that they are dicult to control, and we have to devote a lot of thinking about them. We cannot leave these subjects to our genes. In the case of management, a more accurate expression would be ``People manage working people.'' This then suggests that we have to pay attention to their work, to the work to be done. And then: work to be done never gets done ``en passant''. If it is done en passant it gets done also ``en manquant'', ``en payant'', and ``en retardant''. 1.7. ``Nobody ever manages the work of a project'' The pinnacle of the editorial. It would be too simple to retort that to be the reason why projects fail to achieve their targets, run late and/or cost too much. But it can easily be one of the reasons. Human achievements need human work. In fact, people do nothing but work, it is our `destiny' and if properly done the desired results, products `happen to be' the outcome of the concerted eorts. 2. Project-trees, WBS and PBS in particular Viewing the polemics above also as a starter to the following, attention is now directed to a less biased discussion on the project-functions of the PBS and the WBS. The latter however, the target of the editorial scrutiny, is discussed ®rst. The discussion is concluded with a generalization of the subject project-trees. 3. The WBS 3.1. The purpose of a WBS First, I present an analogy. You have to make speed to cover a distance. This is not only an unquestionable law from physics, but also operationally relevant if you are planning a trip, that is when you want the trip to proceed in a controlled fashion. Then it is not enough to be aware only of your destination. You must also know the speed to get to the destination in the allotted time, which feasible speed, the ®rst derivative of distance, is required. Similarly, consider verbs to be the ®rst (partial)
M. Lamers / International Journal of Project Management 20 (2002) 325±329
derivatives of nouns. The analogy now becomes: managing your project requires planning your project (trip). In order to obtain your end result (destination), expressed in nouns, use must be made of activities (speed), the ®rst derivatives of nouns expressed in verbs. If this analogy holds, we then have established the need for a WBS, or at least we have created a tempting plausibility.1 With the WorkPackages of the WBS, we then have a means to integrate the three corners of the Iron Triangle, (see below). Using them we can establish unambiguous relations between Scope, Time and Money by having the entities of the three corners share the WorkPackage as a common attribute. Thus, we get rid of uncertainties, misunderstandings and misinterpretations about what belongs to what belongs to what. The Iron Triangle is the symbol for the true Project Management task: to balance the three corners of the triangle, Scope, Time and Money. The corners represent the three primary aspects for which the project will be judged. Each of the aspects can be associated with a budget of consumables. This simply applies for Time and Money, but with some force-of-mind also Scope can be regarded in this manner. Uncertainties are inherent with Scope and they need to be reduced to zero, or suciently close to it, at the end of the project. Project Management then becomes the task of balancing the consumption of the known budgets of Time and of Money, which are easy to run out of, with the `unknown' budget of Scope-uncertainties, which is easy to underestimate and which is not easy to overcome. 3.2. Scope The one main purpose of the WBS is to be able to generate WorkPackage Descriptions for the end-WorkPackages, the WorkPackages at the bottom of the WBS. A WorkPackage Description basically consists of three ®elds, the required input to be able to perform the activities, the activities themselves and the resulting output. The product is de®ned in terms of deliverables: speci®cations, reports, drawings. These deliverables are called out in the input- and output-®elds of WorkPackage Descriptions and they are 'de®ned' by the work to be done as described in the activity-®eld of the WorkPackage Description. 3.3. Time The WBS only establishes hierarchical relations between WorkPackages. The time plan establishes their relation in time. This assumes that WorkPackages are considered the only legitimate line items of a time plan. The various aggregation levels for which a time plan is 1 Taking the analogy even further, it can be viewed that as speed is the derivative of distance, verbs are the then the derivatives of nouns.
327
made correlate with levels of the WBS. The line items of a time plan are the WorkPackages. A product has no throughput-time; an activity has. 3.4. Money The entities of the hierarchical budget and cost structures are de®ned so as to correspond to WorkPackages and can thereby also directly be related to the time plan. This transparent relation enables the reliable establishment of budgeted cost for work performed, the so-called earned value, and its comparison with actual cost for work performed for timely tracking of cost variances. 3.5. The composition of a WBS Two main characteristics rule the composition of the WBS. Firstly, related activities are brought together in Workpackages, and secondly, the input±output relations couple the WorkPackages since the output of one WorkPackage serves as input of another WorkPackage. The latter characteristic makes the structure WBS a system. A number of derived rules follows from this. Workpackages are divided into subordinate WorkPackages. Once a WorkPackage gets subdivided into lower WorkPackages, it's subdivided all the way. The higher WorkPackage is emptied, implying among other things that, thereafter, no hours can be spent against that WorkPackage. Workpackages are de®ned such as to minimize inter WorkPackage relations (clearly the minimum can never be zero: wrong project). 4. The PBS 4.1. The purpose of a PBS The PBS may have a twofold purpose. The ®rst, `inevitable' purpose is to serve as a means for uniquely identifying, by name and number, all the products comprising the end product. Thereby, a source of confusion and misunderstanding is avoided. This in itself may already be a sucient motive to generate a PBS. For instance, the PBS can then be used to develop a WBS. Once, however, the project has a PBS, the second purpose can be realized. This purpose is to provide a common reference for explicitly tagging all kinds of (meta-) characteristics of the products to the products. These meta-characteristics, attributes, can take a wide range. To name a few of the possibilities: WorkPackagenumbers; drawing numbers; contractor name; project phase; release status; pending change request; responsible individual; schedule criticality; budget-reference; etc. This enables production of all kinds of attribute-pro®les to support status recording, to create reference-equality
328
M. Lamers / International Journal of Project Management 20 (2002) 325±329
for project members, to provide for a correct basis for decision making, for verifying progress, and much more. In contrast, the tagged PBS does away with the multitude of all those individual lists in desk drawers, which are not up-to-date, which are in con¯ict which each other, in short, which are unreliable. Without intensive control and proper means thereto like the PBS, it will show that much of the information used in a project is too much in violation of the required characteristics of `data' like consistency, accurateness, completeness, actual, traceability, coherence, veri®ability. In fact, the PBS can be seen as the pivotal tree amidst the other trees adopted by a project. All trees link with the product tree to provide the data for the speci®ed product-tags.2
The numbering of the products as constituents of the PBS must also be dealt with. It may be dicult to obtain agreement on, unless an existing numbering system can be adopted. As in the case of establishing conventions for drawing numbers and part numbers, too many customers compete for too few number-characters. Also, the meanings of number ®elds often do not withstand time. Usage of largely meaningless identi®cation numbers and delegating the provision of meaningful information to attributes in a database overcomes this problem.
4.2. The composition of a PBS
To conclude, we take the discussion one step further and expand the WBS/PBS-issue to a general one. The larger the project and the greater its complexity, the more entities, parameters, variables, must be used for explicit control of the project. The task gets formidable; the project management-equation becomes more non-linear because of the interdependency of such control-variables. Selection and development of the tools needed to equip the project with, becomes a matter of concern itself. Thus it is often met with reluctance, objection or neglect since it appears to draw attention away from the principal task: responding to the direct problems of the project, as they appear every day. The question is what kind of tool(s) do we need for solving which main project management problem? Where the main problem is: a project of some size is characterized by a large number of variables that occur in vast quantities, often in the hundreds, thousands, tens of thousands. There are many constituting products, many workpackages, many requirements, many drawings, many plans and reports, many budget-items, many time plan items, many participating parties, many individuals, many actors in case of infrastructure projects. Each such galaxy of variables has to be readily accessible. Instead of only discussing about PBS and WBS, or even about PBS or WBS, it may be required, depending on the project, to plant more trees in the project-park. For instance a speci®cation tree may be required. Another example is the drawing tree that may be needed to ensure and maintain consistency between the various types of drawings under the impact of changes. Again, this is only necessary in case there are many types of drawings. Only when using the tree-concept can it be assured that both the individual variables as well as their collection have the properties the project demands. The variables themselves need to be actual, correct, accurate, valid, reliable, available, traceable, unambiguous, and veri®able. The collections have to be complete, consistent, coherent, accessible, navigable, and linkable to other collections. This is a formidable task the more so,
A PBS is constructed by decomposition of products into subordinate products. Decomposition takes place according to the formula ``consists of''. Thereby, a partwhole structure is obtained with hierarchical parent± child relations. This basic rule would suce to produce a PBS. However, four topics make the construction of a PBS less easy than it would seem. Care must be taken to avoid inclusion of other important project-entities, which are not part of the con®guration, as products. For example, permits and certi®cates are not part of the PBS. They should be treated as attributes. The division of the second level of the PBS is in¯uenced by a number of considerations and viewpoints. These are the structure of the system diagram from which the PBS is derived, the organizational breakdown of the project, or the parent organization(s), the layout of the WorkBreakdown Structure. The theoretical line of thought, System diagram ! ProductBreakdown Structure ! WorkBreakdown Structure ! Organizational Breakdown Structure, from systems and subsystems, via disciplines, to departments and oces, is often restricted by existing practices and apparent conveniences. In case of large trees, say eventually consisting out of hundreds to thousands of products, products need classi®cation to prevent proliferation of names. It may prove to be dicult to match existing names with more rigorous conventions without singularities for naming. A solution could be to use attributes (tags) for nameclassi®cation. 2 However, this linking poses a problem. Ideally all trees are integrated in a computer database system, then they are linked to each other in an automated fashion, i.e. data have to be entered or changed, only once, at one spot. If ProductDataManagement-systems are not available or if the PDM-system is not capable of incorporating all trees, more manual intervention is required. This introduces more error sources, one of the important being: no additional, manual intervention: forgetting or neglecting to inform or to update at ancillary positions.
5. The generalized question of Project Management
M. Lamers / International Journal of Project Management 20 (2002) 325±329
or rather, in particular, because the variables have an unavoidable characteristic; they change. That's what a project is about; change is the `purpose' of a project in particular in its early phases, less and less in its later phases, until none at its completion. The postulate of this paper is that (hierarchical) structures, breakdowns, trees, are needed for those variables which ful®ll two requirements, ®rstly, it occurs in great amounts and secondly, it is to be used as a control-variable of the project. A tree with its inherent property of providing overview in order to remain on top, then allows: 1. to keep variables up to date; 2. to keep (variables in) the various trees in consistent relation to each other; 3. to assure traceability; 4. to trace the impact of changes; 5. to be able to make the proper decisions on change proposals;
6. 7. 8. 9.
to to to to
329
implement all the (consequences of) changes; generate attribute-pro®les; provide custom-tailored information; and128 provide foundation for reporting.
6. Summarizing in brief 1. The PBS is the tool to provide unique identi®cation of products, to tag project-attributes. 2. The WBS is the logical sequel to the PBS; WBS=dPBS/dt. 3. The WBS is the mechanism to generate WorkPackages, and the WorkPackage descriptions thereafter. 4. WorkPackages are the ingredients to integrate the corners of the Iron Triangle. 5. Trees in general are the structures to provide and maintain overview and traceability of galaxies of project-variables.
www.elsevier.com/locate/ijproman
Do you manage a project, or what? A reply to ``Do you manage work, deliverables or resources'', International Journal of Project Management, April 2000 M. Lamers * Railinfrabeheer, Moreelsepark 1, Postbus 2038, 3500 GA Utrecht, The Netherlands
Abstract In the paper, some of the assertions in the editorial entitled ``Do you manage work, deliverables or resources'' of the recent April issue of the International Journal of Project Management are questioned. Here it is maintained that the WorkBreakdown Structure (WBS), is an essential instrument for Project Management and that it should not be considered as the result of the marriage of the ProductBreakdown Structure (PBS) and the Organization Breakdown Structure. WorkPackages are important for integration of the corners of the Iron Triangle. Next, to illustrate this, purpose and composition of both WBS and PBS are elaborated upon. Using PBS and WBS as a stepping-stone, this paper concludes by putting the project management concept in the broader perspective of the generalized requirement for `trees' as instruments for project management. The larger, the more complex the project, the more galaxies of project variables will strain project management. Redressing of such galaxies into hierarchically structured trees will then be necessary for project management to remain on top. # 2002 Elsevier Science Ltd and IPMA. All rights reserved. Keywords: Project management; Project trees; Iron triangle
1. In response to the editorial itself ``Do you manage work, deliverables or resources'', the editorial of the April issue, 18 (2), of the International Journal of Project Management, provokes a much-needed discussion. We do not use the WorkBreakdown Structure (WBS) properly, i.e. the work tree, to the extent that it gets confused with the ProductBreakdown Structure (PBS), the product tree. What are the dierences, and are these dierences important? Are both the PBS and the WBS required or is the PBS all we really need? I suggest that the WBS is required as well. Moreover, projects may even be in need of breakdown structures in addition to those two. The subject of project management requirements is wrongly reduced to a question about PBS and WBS. A project comprises more entities that may need to be controlled, and thus need to be controllable, than only work, deliverables and resources. This will be addressed at the end of the paper. 1.1. ``It is actually similar to batch manufacturing.'' A project is predominantly non-recurring. That is why it is a project. The comparison with manufacturing * Fax: +31-30-235-9036. E-mail address: [email protected] (M. Lamers).
is less ®tting. Batch manufacturing associates with recurring processes, whereas management of a project, in contrast, is non-recurring. Non-recurring processes are less deterministic since they contain more uncertainties. Hence, they are in need of more control eort, and thus possibly also in need of more (top level) control-variables than recurring processes. 1.2. ``Hence the WBS is the two-dimensional matrix formed by the PBSOBS. . .'' The WBS is not to be seen as only a two-dimensional matrix, which happens to be the result of the union of PBS and Organization Breakdown Structure (OBS). The WBS is a structure in itself developed after the generation of the PBS, with as little organizational prejudice as possible. In fact, it is a prominent tool for project integration. 1.3. ``However, if you look carefully at their original de®nition of WBS, what they de®ed was a Product Breakdown. . .'' I doubt whether it was ever an either-or question; that is whether the WBS, i.e. the work tree, was in fact meant to be just a product breakdown, a bill of materials. Why
0263-7863/02/$22.00 # 2002 Elsevier Science Ltd and IPMA. All rights reserved. PII: S0263-7863(00)00053-3
326
M. Lamers / International Journal of Project Management 20 (2002) 325±329
the urgency for one-tree happiness? Why would that be the ultimate symbol of a good project? Also, I've noted time and again, starting in the early 1970s, that titles of WorkPackages of a WBS were often incorrect. They did not, or still do not contain a verb. Often not even a verb-derived noun like management, but worse, just the name of a constituent product. Two reasons may explain the improper titling of workpackages. The ®rst, most legitimate one is that the WBS should be based on the PBS. This implies that the PBS should precede the WBS, which is also natural to begin with. First know what you're talking about, before you start talking. Even in the early phase of a project when there's no formal PBS yet, a System Concept exists. The System Concept can be regarded as the predecessor of the PBS. It will show up at the second level of the PBS. 1.4. ``Unfortunately, many people since have interpreted the words, Work Breakdown, literally. . .'' The unfortunate thing is the opposite, many people do not interpret these words literally enough. This is the second reason for WBSs to be insuciently correct. It shows, as already mentioned earlier, that apparently we are more inclined towards products than towards processes, more to goals than to means. This yields a WBSdisposition by not using verbs where they should be used, in the naming of WorkPackages. This phenomenon also shows in the naming of schedule-activities, which proves that at least we are consistent in our inclination. All in all, a WBS often makes the impression of a dilapidated PBS. Hence arises the editorial confusion. The editorial attacks head over heels an assumed culprit in order to be provoking, without due regard for a relevant de®nition of the project management problem. The editorial is an example of symptom ®ghting by being controversial and provocative on a derived problem only. This invokes the danger of leading the audience astray because of inadequate initial conditions of the wanted discussion. 1.5. ``Next, you should develop an Organization Breakdown Structure'' and ``. . . you decide ®rst what the components are, then who is responsible. . .'' The sequence PBS, then OBS, then WBS (because of the reasoning embedded in PBSOBS=WBS) is an erroneous reasoning. The WBS is not to be regarded as an ersatz-PBS. The proper line of thought is, ®rst the de®nition of the product, then the de®nition of the processes required to generate the product, then the control of those processes, and only then, the organization to exercise the processes and their control with. Clearly some iteration is involved and some acceptance of initial (e.g. organizational) conditions. But that is why project
management has been `invented', i.e. to create a distance from existing organizational mechanisms of organizations. This then leads to the, non-commutative, expression WBS/PBS=OBS. Which by the way also `literally' shows the PBS as the basis of project management. 1.6. ``People manage people. . .'' and ``The work of a project gets done en passant.'' ``People manage people. . .'' is too much of a truism, like ``People love people''. Both are cultural phenomena, which means that they are dicult to control, and we have to devote a lot of thinking about them. We cannot leave these subjects to our genes. In the case of management, a more accurate expression would be ``People manage working people.'' This then suggests that we have to pay attention to their work, to the work to be done. And then: work to be done never gets done ``en passant''. If it is done en passant it gets done also ``en manquant'', ``en payant'', and ``en retardant''. 1.7. ``Nobody ever manages the work of a project'' The pinnacle of the editorial. It would be too simple to retort that to be the reason why projects fail to achieve their targets, run late and/or cost too much. But it can easily be one of the reasons. Human achievements need human work. In fact, people do nothing but work, it is our `destiny' and if properly done the desired results, products `happen to be' the outcome of the concerted eorts. 2. Project-trees, WBS and PBS in particular Viewing the polemics above also as a starter to the following, attention is now directed to a less biased discussion on the project-functions of the PBS and the WBS. The latter however, the target of the editorial scrutiny, is discussed ®rst. The discussion is concluded with a generalization of the subject project-trees. 3. The WBS 3.1. The purpose of a WBS First, I present an analogy. You have to make speed to cover a distance. This is not only an unquestionable law from physics, but also operationally relevant if you are planning a trip, that is when you want the trip to proceed in a controlled fashion. Then it is not enough to be aware only of your destination. You must also know the speed to get to the destination in the allotted time, which feasible speed, the ®rst derivative of distance, is required. Similarly, consider verbs to be the ®rst (partial)
M. Lamers / International Journal of Project Management 20 (2002) 325±329
derivatives of nouns. The analogy now becomes: managing your project requires planning your project (trip). In order to obtain your end result (destination), expressed in nouns, use must be made of activities (speed), the ®rst derivatives of nouns expressed in verbs. If this analogy holds, we then have established the need for a WBS, or at least we have created a tempting plausibility.1 With the WorkPackages of the WBS, we then have a means to integrate the three corners of the Iron Triangle, (see below). Using them we can establish unambiguous relations between Scope, Time and Money by having the entities of the three corners share the WorkPackage as a common attribute. Thus, we get rid of uncertainties, misunderstandings and misinterpretations about what belongs to what belongs to what. The Iron Triangle is the symbol for the true Project Management task: to balance the three corners of the triangle, Scope, Time and Money. The corners represent the three primary aspects for which the project will be judged. Each of the aspects can be associated with a budget of consumables. This simply applies for Time and Money, but with some force-of-mind also Scope can be regarded in this manner. Uncertainties are inherent with Scope and they need to be reduced to zero, or suciently close to it, at the end of the project. Project Management then becomes the task of balancing the consumption of the known budgets of Time and of Money, which are easy to run out of, with the `unknown' budget of Scope-uncertainties, which is easy to underestimate and which is not easy to overcome. 3.2. Scope The one main purpose of the WBS is to be able to generate WorkPackage Descriptions for the end-WorkPackages, the WorkPackages at the bottom of the WBS. A WorkPackage Description basically consists of three ®elds, the required input to be able to perform the activities, the activities themselves and the resulting output. The product is de®ned in terms of deliverables: speci®cations, reports, drawings. These deliverables are called out in the input- and output-®elds of WorkPackage Descriptions and they are 'de®ned' by the work to be done as described in the activity-®eld of the WorkPackage Description. 3.3. Time The WBS only establishes hierarchical relations between WorkPackages. The time plan establishes their relation in time. This assumes that WorkPackages are considered the only legitimate line items of a time plan. The various aggregation levels for which a time plan is 1 Taking the analogy even further, it can be viewed that as speed is the derivative of distance, verbs are the then the derivatives of nouns.
327
made correlate with levels of the WBS. The line items of a time plan are the WorkPackages. A product has no throughput-time; an activity has. 3.4. Money The entities of the hierarchical budget and cost structures are de®ned so as to correspond to WorkPackages and can thereby also directly be related to the time plan. This transparent relation enables the reliable establishment of budgeted cost for work performed, the so-called earned value, and its comparison with actual cost for work performed for timely tracking of cost variances. 3.5. The composition of a WBS Two main characteristics rule the composition of the WBS. Firstly, related activities are brought together in Workpackages, and secondly, the input±output relations couple the WorkPackages since the output of one WorkPackage serves as input of another WorkPackage. The latter characteristic makes the structure WBS a system. A number of derived rules follows from this. Workpackages are divided into subordinate WorkPackages. Once a WorkPackage gets subdivided into lower WorkPackages, it's subdivided all the way. The higher WorkPackage is emptied, implying among other things that, thereafter, no hours can be spent against that WorkPackage. Workpackages are de®ned such as to minimize inter WorkPackage relations (clearly the minimum can never be zero: wrong project). 4. The PBS 4.1. The purpose of a PBS The PBS may have a twofold purpose. The ®rst, `inevitable' purpose is to serve as a means for uniquely identifying, by name and number, all the products comprising the end product. Thereby, a source of confusion and misunderstanding is avoided. This in itself may already be a sucient motive to generate a PBS. For instance, the PBS can then be used to develop a WBS. Once, however, the project has a PBS, the second purpose can be realized. This purpose is to provide a common reference for explicitly tagging all kinds of (meta-) characteristics of the products to the products. These meta-characteristics, attributes, can take a wide range. To name a few of the possibilities: WorkPackagenumbers; drawing numbers; contractor name; project phase; release status; pending change request; responsible individual; schedule criticality; budget-reference; etc. This enables production of all kinds of attribute-pro®les to support status recording, to create reference-equality
328
M. Lamers / International Journal of Project Management 20 (2002) 325±329
for project members, to provide for a correct basis for decision making, for verifying progress, and much more. In contrast, the tagged PBS does away with the multitude of all those individual lists in desk drawers, which are not up-to-date, which are in con¯ict which each other, in short, which are unreliable. Without intensive control and proper means thereto like the PBS, it will show that much of the information used in a project is too much in violation of the required characteristics of `data' like consistency, accurateness, completeness, actual, traceability, coherence, veri®ability. In fact, the PBS can be seen as the pivotal tree amidst the other trees adopted by a project. All trees link with the product tree to provide the data for the speci®ed product-tags.2
The numbering of the products as constituents of the PBS must also be dealt with. It may be dicult to obtain agreement on, unless an existing numbering system can be adopted. As in the case of establishing conventions for drawing numbers and part numbers, too many customers compete for too few number-characters. Also, the meanings of number ®elds often do not withstand time. Usage of largely meaningless identi®cation numbers and delegating the provision of meaningful information to attributes in a database overcomes this problem.
4.2. The composition of a PBS
To conclude, we take the discussion one step further and expand the WBS/PBS-issue to a general one. The larger the project and the greater its complexity, the more entities, parameters, variables, must be used for explicit control of the project. The task gets formidable; the project management-equation becomes more non-linear because of the interdependency of such control-variables. Selection and development of the tools needed to equip the project with, becomes a matter of concern itself. Thus it is often met with reluctance, objection or neglect since it appears to draw attention away from the principal task: responding to the direct problems of the project, as they appear every day. The question is what kind of tool(s) do we need for solving which main project management problem? Where the main problem is: a project of some size is characterized by a large number of variables that occur in vast quantities, often in the hundreds, thousands, tens of thousands. There are many constituting products, many workpackages, many requirements, many drawings, many plans and reports, many budget-items, many time plan items, many participating parties, many individuals, many actors in case of infrastructure projects. Each such galaxy of variables has to be readily accessible. Instead of only discussing about PBS and WBS, or even about PBS or WBS, it may be required, depending on the project, to plant more trees in the project-park. For instance a speci®cation tree may be required. Another example is the drawing tree that may be needed to ensure and maintain consistency between the various types of drawings under the impact of changes. Again, this is only necessary in case there are many types of drawings. Only when using the tree-concept can it be assured that both the individual variables as well as their collection have the properties the project demands. The variables themselves need to be actual, correct, accurate, valid, reliable, available, traceable, unambiguous, and veri®able. The collections have to be complete, consistent, coherent, accessible, navigable, and linkable to other collections. This is a formidable task the more so,
A PBS is constructed by decomposition of products into subordinate products. Decomposition takes place according to the formula ``consists of''. Thereby, a partwhole structure is obtained with hierarchical parent± child relations. This basic rule would suce to produce a PBS. However, four topics make the construction of a PBS less easy than it would seem. Care must be taken to avoid inclusion of other important project-entities, which are not part of the con®guration, as products. For example, permits and certi®cates are not part of the PBS. They should be treated as attributes. The division of the second level of the PBS is in¯uenced by a number of considerations and viewpoints. These are the structure of the system diagram from which the PBS is derived, the organizational breakdown of the project, or the parent organization(s), the layout of the WorkBreakdown Structure. The theoretical line of thought, System diagram ! ProductBreakdown Structure ! WorkBreakdown Structure ! Organizational Breakdown Structure, from systems and subsystems, via disciplines, to departments and oces, is often restricted by existing practices and apparent conveniences. In case of large trees, say eventually consisting out of hundreds to thousands of products, products need classi®cation to prevent proliferation of names. It may prove to be dicult to match existing names with more rigorous conventions without singularities for naming. A solution could be to use attributes (tags) for nameclassi®cation. 2 However, this linking poses a problem. Ideally all trees are integrated in a computer database system, then they are linked to each other in an automated fashion, i.e. data have to be entered or changed, only once, at one spot. If ProductDataManagement-systems are not available or if the PDM-system is not capable of incorporating all trees, more manual intervention is required. This introduces more error sources, one of the important being: no additional, manual intervention: forgetting or neglecting to inform or to update at ancillary positions.
5. The generalized question of Project Management
M. Lamers / International Journal of Project Management 20 (2002) 325±329
or rather, in particular, because the variables have an unavoidable characteristic; they change. That's what a project is about; change is the `purpose' of a project in particular in its early phases, less and less in its later phases, until none at its completion. The postulate of this paper is that (hierarchical) structures, breakdowns, trees, are needed for those variables which ful®ll two requirements, ®rstly, it occurs in great amounts and secondly, it is to be used as a control-variable of the project. A tree with its inherent property of providing overview in order to remain on top, then allows: 1. to keep variables up to date; 2. to keep (variables in) the various trees in consistent relation to each other; 3. to assure traceability; 4. to trace the impact of changes; 5. to be able to make the proper decisions on change proposals;
6. 7. 8. 9.
to to to to
329
implement all the (consequences of) changes; generate attribute-pro®les; provide custom-tailored information; and128 provide foundation for reporting.
6. Summarizing in brief 1. The PBS is the tool to provide unique identi®cation of products, to tag project-attributes. 2. The WBS is the logical sequel to the PBS; WBS=dPBS/dt. 3. The WBS is the mechanism to generate WorkPackages, and the WorkPackage descriptions thereafter. 4. WorkPackages are the ingredients to integrate the corners of the Iron Triangle. 5. Trees in general are the structures to provide and maintain overview and traceability of galaxies of project-variables.