The Problem with Changes in Scope
First, we must start with the position taken by the Guide's 5th Edition on management reserves. A close reading of the Guide would seem to indicate that management reserves are appropriated into the cost baseline through the change control process, and that the purpose of these change requests would be to respond to unplanned-for risks that have materialized. In other words, these risks would have been viewed as so unlikely that they were omitted from the contingency reserve planning process, and would be considered unknown unknowns. This could include things like catastrophic weather events.
However, the Guide also makes clear that management reserves cannot be used for scope changes. The Guide's 5th Edition states:
"Management reserves…are reserved for unforeseen work that is within scope of the project."[15] (Emphasis added).
This is also restated in the Guide's glossary.[16] The problem this creates is that the Glossary also defines the Work Breakdown Structure (WBS) as:
"A hierarchical decomposition of the total scope of work to be carried out by the project team…"[17] (Emphasis added).
Thus, if one needs to add a new work package to the WBS (meaning that the scope of the project needs to be enlarged), the Guide precludes using management reserves for this purpose.
The quandary this leaves one with is how PMI envisions one will make changes to the project where one needs to add new work packages, which is synonymous with saying that someone wants to change the scope of the project. It is common for large, complex, or long-term projects - especially projects that are learning and developing new knowledge along the way - to redefine scope as they progress. The development and procurement of new military weapons platforms, such as the advanced tactical fighter, is an example. Congress appropriates money, but the program manager makes many decisions as to what is in scope and what is not throughout the course of the program, and also decides what monies to hold in reserve, where to allocate them, and for what purposes.
It is my belief that, as a practical matter, management reserves are most closely associated with the project sponsor or ultimate customer. If the sponsor/management/customer decides to add a new feature or otherwise expand the scope of the project (i.e., add new work packages), the management reserves could and should be used for that. That is, in addition to providing funding to cover unplanned-for rework or recovering from the realization of unplanned-for risks.
In this latter category, by way of example, there was a tunnel-boring project where progress was one foot per day versus the planned-for 100 feet per day because the geology was different than what had been expected. Rather than force the contractor into bankruptcy because of this unforeseen problem (the contractor was working on a fixed price contract), the project sponsor revised the contract and provided an additional $53 million in funding. That money came from the project sponsor's reserves. In those days, however, I'm not sure that a distinction was made between contingency and management reserves.
In software development, a common type of scope change one encounters would be the need to design and develop an additional report or add another code module (i.e., feature). In manufacturing, it might be to add a feature to a product that is already being designed and built by a project. PMI needs to address whether such changes are to be funded from one's management reserves, a new appropriation, or define yet another category of reserves that are set aside just for scope changes.
As the Guide is currently written, it would appear that PMI's intent was to say that any change in scope must be accompanied by new money, and not come from the management reserve. While this may be true in some cases, it is my experience that such changes frequently come from already-appropriated monies, i.e., management reserves.
Authority to Access Reserves
In previous editions of the Guide, and especially the 4th Edition, the use of reserves and who had control of them was obscure. In the 5th Edition, PMI has bent over backwards to clarify this issue. Now, contingency reserves are explicitly part of the Project Management Baseline, are under the control of the project manager, and address known unknowns.[18] Management reserves are reserved for use by management (e.g., the project sponsor), are only released to the project manager and incorporated into the project management baseline as a result of an approved, formal change request, and address unknown unknowns.[19]
Note too, that the 5th Edition affirms that Figure 2,
above, is the model PMI has standardized on. This is is somewhat
different than the model presented in the Guide's 3rd Edition
(Figure 1, above) and significantly
different than that presented in the Guide's 4th Edition (not
shown[20]). Important to
note is that the Guide's 5th Edition incorporates the contingency
reserve in the cost baseline, or BAC, as shown in Figure 2.
Vocabulary - Unraveling an Alphabet Soup
Perhaps what was most confusing in the 4th Edition was the myriad of terms used, many of which were synonymous with other terms, but the fact that they were being treated as such was not clearly explained. The 5th Edition has rectified this problem by standardizing terminology and rewritten definitions to be more rigorous and unambiguous - even providing additional clarifying statements to make sure there is no misunderstanding.
15. Ibid, p206, para 7.2.2.6
16. Ibid, p545, Glossary
17. Ibid, p567, Glossary
18. Ibid, p206, para 7.2.2.6
19. Ibid.
20. The model proposed in the Guide's 4th Edition was complicated and confusing, at best, and unworthy of repeating in this article since most of the issues have been resolved in the 5th Edition. To see how this was presented in the 4th Edition, please see my previous article, "PMBOK® Guide Fourth Edition - Unraveling Project Reserves" published in March 2010.
|
Cost
Management PMBOK® Guide 5th Edition
