Readings on Project Management

Personally I found the Project Management Body of Knowledge (PMBOK) Guide to be an interesting and thorough analysis of critical components of project management. The PMBOK Guide typically creates a matrix of nine knowledge areas (scope, time, cost, quality, human resource, communications, risk, procurement, and integration) and five process groups (initiating, planning, executing, controlling, and closing.) It is interesting how general principles such as these can apply to a wide range of projects. I think a good point was made in the readings regarding the challenge of choosing the correct level of detail to implement the PMBOK. I suspect it is this challenging choice which leads to under-implementation of PMBOK and similar principles in many library projects.

Scope management is important to avoid project escalation. I thought particularly interesting the example of project escalation documented in the Mark Keil article "Pulling the Plug: Software Project Management and the Problem of Project Escalation." Keil effectively documented how social and psychological factors can contribute to project escalation. I think such social and psychological factors frequently have significant influence on project outcomes. The Bas de Bar videos "Software Project Management in 15 Minutes" provided practical advice for managing such social and psychological factors. Bas de Bar asserts that project stakeholders are key to the success of a technology project. These stakeholders are primarily driven by tacit expectations of a project. It is the task of project management to divine and address these expectations through the definition of requirements. A key tool to define the scope of a project is the development of a work breakdown structure. I think the work breakdown structure would be a useful tool in many library projects.

It seems to me that much of project management deals with the allocation of limited resources. This resource allocation of limited resources is effectively illustrated by the Tradeoff Triangle diagram, as described in the Microsoft Solutions White Paper MSF Process Model V 3.1. The three aspects of the Tradeoff Triangle are resources, schedule, and features. These three aspects are assigned exclusively the respective qualities of fixed, chosen, and adjustable. So, for example, given fixed resources and a chosen schedule, a technology project product's features should be realistically projected to be adjustable. I think that understanding such realities can aid in the management of stakeholder expectations through the definition of realistic requirements.