Introduction
Many project managers have experienced spending dozens of hours preparing estimates, status reports, and Gantt charts, only to have them ignored by key stakeholders. While this may be frustrating for the project manager, more importantly it can place the project’s outcome at risk. What if there was another way to communicate with key stakeholders rather than stepping page-by-page through a deck of slides or handing out printed reports? What if there were ways to actively engage the stakeholders mentally and physically during planning discussions that resulted in an improved amount of understanding and increased retention? This paper describes one team’s strategy to address those issues.
What Is the Goal?
For most projects to succeed, it is important for the key stakeholders and the project participants to have a very similar understanding of what it to be achieved, under what constraints, and often which tradeoffs have been decided upon to achieve success. If our stakeholders do not understand the project, or the project management process makes it difficult for them to understand the decisions that are being made, we lose the opportunity to gain from their insights while there is still time and budget remaining. Likewise, some of our most important stakeholders do not have time to become project management experts. Therefore, it is important to make key project management information obvious to them at a level where they can help make important decisions.
A Strong Work Breakdown Structure Can Help Clarify a Common Vision
When a key stakeholder, or key project participants, use the same words but have a very different image in their head problems and risks are likely to arise. Improving communication is one of the reasons that the Practice Standard for Work Breakdown Structures—Second Edition (Project Management Institute [PMI], 2006) declares that work breakdown structures should be deliverable-oriented. When a broad set of project stakeholders can understand the work breakdown structure (WBS), their ability to participate in project management processes increase significantly.
The WBS provides the foundation for integrating the work package and intermediate deliverables with all other aspects of project initiation, planning, execution, monitoring and controlling, and closing.
A deliverable-oriented WBS provides many benefits to the project, including the following:
- Better communication to project sponsors, stakeholders, and team members
- More accurate estimation of tasks, risks, timelines, and costs
- Increased confidence that 100% of the work is identified and included
- A foundation for the control processes within the project.
The deliverable concept and deliverable orientation of the WBS are integral to understanding the proper definition and use of the WBS and the benefits it provides within the larger context of all project management processes. (PMI, 2006, pg.6)
By defining the work packages in our WBS as deliverable outcomes described in common stakeholder terminology instead of as activities described in technical jargon, we provide an important common vocabulary for the rest of our project management processes.
A Simple Idea
Over the years, the Menlo Innovations team has found an effective strategy for defining work packages that stakeholders will understand: write down the descriptions of deliverables on index cards using the stakeholder’s own language. Once the card is created, it is reviewed with the stakeholder who first expressed the need. This simplistic approach removes many barriers and focuses on the most important part of the conversation—the content. If the description is not quite right, then the team writes up a new version on another index card. These cards are labeled with a project code, a unique identifier, and a date. The cards are archived and entered into an electronic repository.
If at a later date other stakeholders disagree with the definition, new cards are written with alternative work package descriptions. New cards are captured, identified, and archived. However, whenever a new card is written, it is really just a proposed change or scope addition. It will not be added to the official WBS until after it has been authorized at a change control meeting.
Changes may be requested by any stakeholder involved with the project. Although they may be initiated verbally, they should always be recorded in written form and entered into the change management and/or configuration management system. Change requests are subject to the process specified in the change control and configuration control systems. Those change request processes may require information on estimated time impacts and estimated cost impacts. (PMI, 2008, p. 94)
A Simple and Obvious Version of Change Control
At Menlo Innovations, the change control board reviews all of the newly created index cards for our projects once per week. Whenever the change control board meets and makes decisions, it needs to understand the impact of those decisions not only in terms of project scope, but also in terms of timeline and budget. In preparation for this weekly change control meeting, the appropriate project participants will gather to estimate the cost and time required for each of the new/updated/proposed work package definitions that have been recorded on index cards.
Approved change requests can require new or revised cost estimates, activity sequences, schedule dates, resource requirements, and analysis of risk response alternatives. These changes can require adjustments to the project management plan or other project management plans/documents. The applied level of change control is dependent upon the application area, complexity of the specific project, contract requirements, and the context and environment in which the project is performed. (PMI, 2008, p. 94)
At this weekly meeting, all the previously approved work packages are displayed on a set of tables and represented by photocopies of the original index cards. All new/updated/proposed work packages are displayed on a second set of tables. The gathered change board reviews all of the new/updated/proposed work packages one by one. Any of the work packages that are approved are moved to the tables holding the authorized work packages. If the newly authorized work package replaces an older work package, then the older work package is removed from the tables of authorized work packages. At the end of the meeting, the project manager updates the official log of which work packages were authorized and which, if any, were removed.
Every documented change request must be either approved or rejected by some authority within the project management team or an external organization. On many projects, the project manager is given authority to approve certain types of change requests as defined in the project’s roles and responsibilities documentation. Whenever required, the Perform Integrated Change Control process includes a change control board (CCB) responsible for approving or rejecting change requests. (PMI, 2008, p. 94)
This strategy for defining work packages and performing change control has unfortunately created more work for our project managers. However, after working this way for only a few weeks, our teams began to see a much more effective interaction with the key stakeholders who would attend and participate in these weekly change control meeting.
Improvements to the Change Control Meetings
To make these weekly change control meetings more effective, the team decided to expand on the strategy of planning the project with physical artifacts. To introduce the concept of size for each work package, the copied index cards were sized relative to the hours of effort that they were currently estimated to require for completion. For example, any work package requiring 16 hours of effort was sized to be five and one half inches tall, whereas any work package requiring 32 hours of effort was sized to be eleven inches tall. Likewise, any work package that was estimated to be 8 hours of effort was only just over two and a half inch tall, and so on. This physical sizing of the work packages gave the team an immediate sense of which work packages were large and which were small.
Another innovation added visualization for the remaining budget. Planning sheets (green in the photo below) were laid out. Each sheet had room on the sheet for 40 hours of effort (approximately 14-inches tall). All of the authorized work packages were laid out on top of the authorized budget sheets. Any work package that did not have budget allocated for its completion then needed to be removed from the plan, or needed to displace another work package from the budget, or the change control board needed to address the budget shortfall.
Exhibit 1. Authorized work packages are laid out on planning sheets to help better visualize the work being planned
This technique has been used successfully over the last 10 years on projects as small as two people working for one day, as well as on projects requiring dozens of team members working for hundreds of thousands of hours. Of course, the larger the project, the more table space and more planning sheets that are required. However, we have found that a plan that requires a large budget is in many ways more impactful when it is displayed across a dozen tables than when it is contained in a report printed on 8½ x 11 sheets of paper.
Exhibit 2. Larger projects require more tables and more planning sheets
Additional Concepts
For the many years that we have used this technique, new issues come up that seem to fall on deaf ears when the project manager communicate them. For example, in one project the team needed to build a new product as well as maintain the old product, using the same team members and one unified budget. Week after week, the stakeholders at the change control meeting would talk about how important the new product was strategically but then they would continue to trade away work packages of the new product in order to perform additional maintenance on the old product. Every week the project manager would report the percentage of the budget that was allocated to the new product and the percentage of the budget that was allocated to maintenance, but no behaviors changed. Finally, the project manager changed communication tactics; all maintenance work packages would be copied on to bright pink paper. At the next meeting, key executives on the change control board saw the amount of pink on the table and were astounded, even though the percentages that were being reported matched the percentage of pink space on the tables. At that meeting, the team began to make very different decisions. Since that point in time, project managers on our team use several different strategies to visually reinforce the important messages that they share with the stakeholders each week at the change control meetings.
We have also found that some stakeholders are intimidated by the name “change control meeting.” As a result, we now call the weekly meeting the “planning game” and each of the work packages are called “story cards.” While this choice does not reinforce the vocabulary of the PMBOK® Guide—Fourth Edition, we are willing to make that trade off if it results in a more engaged more effective set of stakeholders helping our projects succeed.
Conclusions
The next time you look at improving your project management process, it might be a very important to step back and ask what goals you are trying to achieve. If you are trying to make your project managers more efficient, then some of the latest electronic tools that offload status report to the team might be helpful. If you are trying to make a good impression on executives, then an electronic dashboard showing high-level status for all projects might be the best strategy. However, if you are trying to improve project outcomes by engaging project stakeholders and participants more meaningfully and effectively, then you might find that some simple tools that encourage physical collaboration, and some extra effort on the project managers’ part, might ultimately create the best results for your team.
