Common tools, uncommon results
The concept is simple: Take the proven principles of project management as embodied in the PMBOK® Guide, and merge them with the powerful yet ordinary tools commonly found on desktop PCs. Add the discipline to actually use the principles routinely; then add a leavening of good judgment with a dash of common sense. Combine with good staff. Enjoy extraordinary results that contribute directly to the bottom line.
There's a famous story about NASA spending billions to invent a “Space Pen” that could write in zero gravity while the Soviet Space Program figured they could do it a lot faster and cheaper by using common pencils. Well, that story is not true, broken pencil points of electrically conductive graphite floating around in a space vehicle are just not a good idea. But like the person who dreamed up this story most project managers are wise to the critical importance good value plays in creating success for teams, value for customers, and profits for sponsors.
If you are interested in this talk, you, like myself, are most likely interested in finding value in the tools you and your team already know how to use. How about making a deal right at the start? If this talk shows you how you can do some of the more important project management tasks with tools you already own, will you agree to (1) Give it a try in the next few weeks and (2) Tell at least two other people about “Common Tools”? But you probably won't answer that yet if you are like me. And I think you are. We both think “Show Me” is more than a clever motto. We share at least two other interests. Getting projects done successfully and increasing our ability to gain value from products we have already paid for. I'm going to provide you with the know-how, samples and checklists so you can go back to work and shine even in these tight times. These ways of using our common tools aren't known by everyone; no one is funding large advertising budgets that clue everyone in. But don't underrate word of mouth. As soon as you tell your friends, and they tell their friends, etc. many project managers will be realizing uncommon results. So what are we waiting for? On with our story.
We will start by defining ‘Common Tools’. We're trying to maximize value here so let's just consider software applications that most people already have installed on their computers. Here's a short list:
Everyone has these but let's add a simple guideline. We can only use capabilities likely to be found on 90% of installed applications. This rules out some of the fancy bells and whistles we might find in more recent versions from our favorite vendors in Redmond or the Silicon valley. So a basic rule is “No new toys.” You might already have OfficeWonder2010™ installed on your new machine but just reflect a minute. You want a project system your forgotten associate in NoWhere Center, East Emptiness can use without an expensive upgrade. A little self-discipline is required.
Organization and Communication
It's probably true in your organization: most communication is either verbal (meetings, hallways, cell phone, voicemail) or by email. We can't do much with the verbal information; much of it is ‘in one ear and out the other.’ Verbal communication is also subject to differing interpretations and fading memories. So let's focus on the documented exchanges, emphasizing the ubiquitous email. First we'll organize it so we can find what we want, when we want it. And then we'll look at the specific content needed to answer all those questions in the checklist.
Mailbox or Folder Organization
For each project you need a system for organizing all the information so you can find it quickly. You also want to know where you can get the most done with the least effort. Exhibit 2 is a screen shot of a web-based email system. We've created six sub-mailboxes to collect information generated during different phases of our project. A similar file structure could easily be built in any windows directory as subfolders.
Suggested Folders or Mailboxes
We also need a way to automatically place our emails into the correct mailbox or folder. Most email systems have pre-processing rules that can search for specific text strings and move an email package into a specific mailbox or folder depending on what's found. These rules search the To:, From:, and Subject: fields. Some of them can also search the body of the message but for simplicity and speed we will focus our rules on the subject field. For this to work we need a naming convention that will tell us (A) What is in the message, (B) Where it should be placed, and (C) Something about the Status. Ideally this all happens without opening the message until it is needed.
We start with a descriptive name followed by the mailbox (folder) name and a status indicator enclosed in brackets. We use the brackets so the pre-processing rules that are going to sort our message streams can identify the pertinent data. Our teams exercise care with the names and spelling within the brackets the email preprocessor can properly select and distribute the incoming messages without losing important information.
Suggested Status Indicators (a few, more appear later in the paper)
Exhibit 2 shows this in a web-based email system. Exhibit 3 demonstrates it in Microsoft Outlook®. In this system we could use features like “Categories” and “Due by” notification but that violates our basic guideline. Use your own judgment on this…it's your project and your infrastructure, just remember the goal is to get as much as you can with what you already have in place.
High volumes of email can be overwhelming. A few simple rules will help you keep it under control. First rule is to keep it simple. As Joe Friday in the TV series Dragnet used to say, “Just the facts, Ma'am.” Keep the subject lines clear and to the point. Remember that the best email is the one you don't have to open until you need the contents. Disciplined addressing also is a big help in reducing unnecessary busy work.
• To:—Use only if ACTION IS REQUIRED
• CC:—For Your Information copies
• BCC:—Generally bad form except to limit exposure to large distribution list (e.g., when you don't want everyone to know the address of everyone else).
• Fewer is Better
• Reply All is Not Good (except for small groups, < 7 members, perhaps a core project team).
Goals and Roles
Why sections on Goals and Roles? Just like the master craftsman a skilled project manager needs not only the tools but also the knowledge of when and how to use them. So the following two sections briefly describe what we are going to accomplish with our tools and the types of roles we need to fill to be successful.
Core Concept, Delivery of Value Counts
All members of the project team must know that project work adds value by producing a useful product. The value is realized when the product is accepted for use by the next person, department or function in a continuous value stream. Effort that does not directly contribute adding value or which is not required to get value-added work done is waste. Project Management is primarily concerned with assuring that all project work adds value. Team roles are organized to assure this occurs effectively and efficiently.
The key to this value stream is acceptance of the completed deliverable by the next user or consumer. Deliverable acceptance happens at all levels; individual work packages, component deliverables, and the final project product as a whole. It is important that all participants understand that acceptance does not happen on submittal of a deliverable. It occurs when the next person in the value chain accepts the deliverable. This is why clear definition and agreement on specific completion criteria is essential at all levels. We use our common tools (email, word processor, spreadsheet) to assure agreement and tracking of this process.
Well Defined Roles Help
Project Manager (PM)
The PM assists in the process of identifying, monitoring and managing the value stream from original initiation to final acceptance and project closeout. This requires the multiple skills of a Facilitator, Mediator, and Arbitrator.
Project Coordinator (PC)
The PC is an information administrator assuring timely and accurate knowledge of the status of the value network. Management then uses this information to determine where active intervention is required to assure the project will be completed “On Time, On Budget and Within Scope.”
Deliverable Owners (DO)
Deliverable Owners are the individuals responsible for completion of specific deliverables, which may be work packages, large components or the entire product. To accomplish this work they need to receive inputs, manage work and deliver outputs suitable for the next user in the value stream. They have two roles: one as the producer and another as the consumer.
As a producer the DO is focused on the output of his or her effort. This requires a complete and correct understanding of what it means to be done (Completion Criteria) and what is required to get the work done, (Cost and Time Estimates).
As a consumer the DO is concerned with what he or she will be receiving, when it will be available and whether it will be suitable. Attention is on submittal and acceptance of inputs from other producers, which requires agreement and commitment to all incoming completion criteria.
“Common Tool” Documents by Phase
Conversations are fleeting, memories vague and changeable. Certain knowledge must be captured, documented, transmitted and archived at each stage in our projects. Here is a list of the project documents that we can produce and use with our ‘common tools’.
We don't specify the contents, which can be found in many of the better project management books on the market. Our favorite is: Verzuh, Eric 1999. The Fast Forward MBA in Project Management. New York: John Wiley and Sons.
Ready, or Definition Phase
Every important document used during the definition stage can be created using common tools. Here is a partial list.
• Project Statement of Purpose email or word document
• Charter email or word document
• Statement of Work email or word document
• RR&A spreadsheet.
Aim, or Planning Phase
There are several things that need to be accomplished during the planning phase but nothing is more important than a clear understanding of What will be delivered to Whom, When and at what Cost. Negotiation, agreement and commitment to production of specific, measurable Deliverables are the basis of all success. Exhibit 4 illustrates the give and take often necessary in arriving at a firm agreement on acceptable completion criteria. Our common tools document needs to be designed to record and quickly communicate progress in this process. Most importantly it needs to highlight where negotiations are not proceeding so the PM can provide timely facilitation or mediation and bring closure.
We need several status indicators for our deliverables as our completion criteria definition is elaborated. Here's a list to get started:
• Counter proposed
• Confirmed (by “Consumer”)
• Inputs Identified (by “Producer”)
• Estimated (Time and Cost)
• Baselined (When approved by PM, Sponsor and Customer).
Each of these communications is easily documented by a threaded email message or evolving word document attachment. Status codes are added to the email Subject field allowing for easy sorting and selection of the real planning bottlenecks. Message-Name[Mailbox_Status]
Risk management also benefits from our common tools. Data is collected similarly to Deliverables using threaded email or evolving word documents. In this case the focus is on possible future events rather than the specific deliverables we are committing to produce. We status our communications accordingly.
• Risk identified
• Risk quantified (may include qualification)
• Risk mitigation plans (if action is required this will generate additional deliverables)
• Risk contingency plans (detailing what we plan to do if the risk becomes an actual problem).
The Work Breakdown Structure is a core tool to good project management but it doesn't require an expensive, specialized tool. Post-it notes and a large wall are an excellent way for a team to develop a WBS together. A good reference is Stracker, David. 1997. Rapid Problem Solving with Post-It Notes. Fisher Books. We have also successfully used the MS Organization Chart® function found in Word® (Insert, Objects).
For a large project (over 25–35 work packages or deliverables) you will most likely want that specialized project management software if only to calculate and update the critical path. There is no other way to go once you get past 50 or so deliverables. These packages can be worth their weight in gold, and then some for large enterprisewide efforts and high-risk initiatives. BUT (and this is a big but) most of our projects are much smaller. Much of the critical PM work on the larger projects requires simplicity not complexity. We recently worked on a multibillion-dollar program that had invested in the very newest enterprisewide PM systems requiring many specialists and consultants, which had not published the most basic project elements including: charters, statements of work, responsibility matrices. They didn't even have clear, openly negotiated completion criteria for the component deliverables. All these could have been, and eventually were, produced using common tools. Don't let the new and flashy software product distract your from the basic discipline required for good management.
I have seen well formed schedules developed using a spreadsheet program. If you have good in-house spreadsheet expertise and don't wish to climb the steep learning curve that comes with some of the pricier PM software consider using what you already have to calculate your smaller schedules. One source of useful spreadsheet formulas and techniques is Padwick, Gordon. 1999. Special Edition Using Microsoft® Outlook® 2000. Indianapolis, Indiana. Que. Padwick includes a CD, which contains a schedule spreadsheet that performs resource loading and generates Gantt charts.
We are not saying, “Don't use special purpose PM applications.” We are saying, “Use what you have and know first. Get the basic necessary work started, then use the fancy SW when nothing else will do the job.” If you have identified and documented the deliverables including their required inputs, firm completion criteria, cost and duration estimates, you will find that the implementation cost for the PM software drops precipitously and the value-added rises comparatively.
Fire, or Implementation Phase
During implementation we want to know what is getting done and more importantly what is not getting done so we can focus management attention where it will do the most good. We also need to know what issues are surfacing that might limit our ability to complete the project. We need to know how to ask for help from Executives outside the project team and we'd like to track proposed and approved changes. This can all be done using our common tools.
Control requires knowledge. The information comes from the individuals closest to the source, the Deliverables Owners. They routinely send sortable status messages to our folders or dedicated mailboxes.
As a deliverable Producer each owner is responsible for routinely updating cost and time estimates for all remaining work (e.g., weekly). If these estimates are within a previously set limit (~10–15%) the status is set to “normal.” If they are outside these tolerance limits the status is set to “Exception,” flagging areas needing attention from the PC and PM.
As a deliverable consumer each owner routinely reports when a deliverable (input) is submitted, returned for rework and accepted. These dates are compared to the established need dates derived from the master schedule and flagged as “normal” or “Exception” based on size of variance.
All members of the project team are expected to submit an issue message whenever they recognize any event that could impact final delivery to the Customer. These issues are categorized for severity (expected harm) and urgency and flagged accordingly. The project manager routinely reviews this issues log, making corrective action assignments as required for project success.
All the monitoring and statusing won't do any good if exceptions are not followed up with vigorous corrective actions.
Individuals experiencing unacceptable variances must take action to identify and limit project impacts, particularly those that threaten project completion On time, On Budget and Within Scope. Once a corrective action is required the project is already at risk so the need for vigorous monitoring and close supervision in significantly increased. A recovery plan needs to be prepared, documented and communicated. This then requires close monitoring until the variance is brought within tolerance or it becomes clear that the risk to the project is unacceptable. The same communication tools are used but the messages are placed in a special classification for frequent discussion and review.
Once a deliverable or issue, at any level, requires corrective action it is necessary to begin planning a request for outside help. Preparation includes identification of the type of resources (or decisions) that may be needed, possible sources of those additional resources and the identification of an escalation deadline. The escalation deadline is a Date Certain when failure to close a corrective action requires issue escalation to a management level outside the PM's control.
Don't assume that escalated issues will be fixed. It is your (PM/PC) responsibility to make sure there is a clear understanding What needs to be done, By Whom and When. Executive management also needs to know what Consequences to the program will follow if the escalated issue is not closed by its need date. This doesn't require a fancy SW application. It does require well-analyzed and documented issues, a good log, clear status indications, and obvious need dates. Build systems that provide this similar to the ones we have already discussed.
Requests for change can be submitted on a standard form via email or word document. We indicate their status in the title or a subject line so we can easily build a log simply by placing the requests in a common folder or dedicated mailbox. Analysis of impact to Time, Cost, Scope and Risk can be added to the standard form, which is distributed in a standard, clearly labeled manner to members of the Change Control Board. This ensures they can organize these files themselves. When decisions are taken change notification is performed using the same forms and tools. Directing modifications to, or creation of new, deliverables implements approved changes.
Score, or Closeout Phase
“It's not over til it's over.” Attributed, like so much, to Yogi Bera.
Simply a word or email listing of all the completion criteria spelling out (1) what needs to be done, (2) how it will be measured, (3) who has authority to determine it has been done, and (4) having a place for initials indicating formal acceptance.
Just as “Beauty is in the eye of the beholder,” so, “Acceptance is in the perception of the customer.” If we've done our job of understanding, building and managing the value-add stream throughout the project final acceptance will be time for a good celebration and often the opportunity for initiating a new project. The key point is that acceptance occurs when the customer is satisfied, not when we have submitted the deliverable.
The key to success is in organization and standards. Areas you need to focus on include:
• Folder or mailbox structure
• Naming conventions
• Status indications
• Sorting and selecting capabilities and rules
• Medium (email, word processor, spreadsheet, etc.)
• PM Components (SOW, Deliverables, Change log, etc.)
• Reporting frequencies (Deliverable status, Issues & Change request reviews, Corrective Actions, Escalation Monitoring, etc.)
• Roles and Responsibilities for system development and maintenance.
“In a crisis, you don't rise to the occasion. You sink to the level of your training.” (John Rennie, Editor In Chief, Scientific American, September 2000.)
You will save using common tools. Your team will know the tools and how to use them. They won't however know the standards or how to employ them successfully. Don't scrimp on the required investment in training. Provide it to all who will participate in your new project management system. It will pay off many times over its original cost.
“Tell me and I forget, Show me and I will remember, Involve me and I will understand.” (Attributed to Confucius.)
Remember One Thing
That's the short form, a 7–8-page paper and a 45-minute presentation. Now you have some ideas that will help get actual projects done, that will add real value to your employers, your sponsors and their customers. All you need to do is try it. But let me give you one more useful hint Experience has clearly shown if you don't get started in the next two or three weeks you probably won't ever get started. So pick a good project, decide which tool(s) already on your computer you are going to use and go get started. And tell others what you've learned; we can all use some more value from things we already own and know how to use.
And look us up if you'd like more help, we're there for you.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA