In the recent film, Up in the Air, George Clooney’s character delivers a seminar that asks the question, “What’s in your backpack?” George asks the attendees to envision they are going on a mountain hike, and to pack all of their belongings into a backpack. George has the attendees envision packing their cars, all of the furniture and knick knacks in their home, and then the home itself. George concludes by asking attendees how full their backpacks are, and if they can still envision hiking the mountain with all of these items on their back. George brings home his point at the end, pointing out that many of our possessions and legacy items hold us back from being effective and happy on our “daily hike”.
I personally do not want to give up my home, my car, knick knacks, or even my pets in real life, but I do agree with the “light backpack” perspective when it comes to project management. Many times we carry too much baggage from our previous experiences, or from the overhead of our Project Management Lifecycle. Let me provide an example.
Last year I worked as a project manager on the delivery of a new Content Management System. The goal was to go live with the critical functionality in 4 months. My goal was to work quickly with the team and the customer to identify the critical features and the key risks we needed to manage.
When I started packing my project manager backpack for this project, I wanted to put in an outline of the processes we needed to use, a high level schedule, a method for tracking daily progress, an environment for frequent communication and status sharing, and a method for demonstrating and adapting as the project proceeded.
My project is assessed to determine what practices I must use and which documents I must complete.
I was excited about this project when it started, and I felt confident in the tools I was going to put into my backpack. Unfortunately my company had rules for what I had to put in. I had to complete a Project Tier Assessment. The assessment asked questions such as project cost, business unit impact, and external customer impact. Based on my entries, the spreadsheet calculated a score, then summed the score by area to determine my tier.
Once my tier was assigned I was sent a spreadsheet with the required documents and processes the project had to follow. Here are approximately ½ of the required documents and processes:
• Business Case
• Business Partner Identification Checklist
• Project Tier Assessment
• Executive Summary
• Technical addendum to Exec Summary
• Initiate Gateway Checklist
• Project Document Location Form
• Project Financial Control Tool
- Project Cost Estimation Worksheet
- Technical Assessment (Part 1)
- Technical Scoring Model Template
• Risk Assessment
• Business Needs Tool
• Business Needs Checklist
• Gap Analysis
• Resource Planning Tool
• Value Delivery System (VDS) Report Out
• Requirements Package
• Organizational Training Plan
• Plan Gateway Checklist
• Project Communication Plan
• Project Plan
• Project Schedule
• Project Status Report (Most recent)
• Issue Log
• Issue Escalation Reports (If applicable)
• Location Summary
• Resource Responsibility Matrix
• Resource Planning Tool
• Team Roster
• Design Integration Summary
• Implementation Plan
• Implementation Gateway Checklist
• Integrated Test Case
• Integrated Test Plan
• Integrated Test Results Report
• Project Change Requests (if appl.)
• Benefits Realization Gateway Checklist
• Post-Implementation Checklist
• Product Benefits Validation Form
As mentioned, this was about ½ of the required documents and processes. How would you feel about carrying this backpack into your next project? Not to mention that each of the required forms was very detailed, and required the signature of various executives.
In defense of my employer, the company had failed an audit many years earlier, which had lead to the new, beastly Project Management Lifecycle. Regardless, most projects are about making or saving money. The overhead required for this project would marginalize or nullify the anticipated benefits.
What should you do if factors beyond your control are requiring you to overload your backpack? First ask this question – does every document and process have a customer? If I do this, who will use it and what value will it provide?
When I say customer I am going beyond the end user or paying customer. Customers can include internal oversight committees, external regulators, or even vendors. The main point is to make sure you are not doing a step just because you were told to do it the day you started, or because “that’s the way we have always done it.” Dig a little deeper when you cannot see the value of a step.
Second, push back when you find “no value” steps. On the project above, I met with the Project Management Lifecycle team several times and asked to skip certain steps and documents when I could not find a customer. Most of my requests were approved and I was allowed to skip many documents that did not add value to delivering a Content Management System.
In summary, it really isn’t about packing light or heavy, it is about packing at the correct level for a given project and it’s unique needs.
An excellent blog topic Greg.
This is a common problem we PM’s face.
I second Greg in saying PUSH BACK….don’t be afraid to ask the PMO if you can remove a doc from the backpack….tell them why….and as long as it isn’t a compliancy doc – they usually say ‘ok’.
I’d add a 3rd option: Only fillout parts of docs that apply to your project. just say “not applicable” or write the absolutely “what is needed”. Don’t write a disseration. Write for your audience – which is typically auditors.
Donna Reed
The Agilista PM
PMI Agile Community of Practice Rep
Donna – you hit the nail in the head: The Auditors are driving PM methodology. Add that driver to the mentality of a bureaucratic client (no one has control, and everyone has a perspective that must be addressed), and you have a documentation-fixated PMO. Generally, using the litmus test that every document must have a client, is a good idea. Regretably, a very bureaucratic organization will have lots of such “clients.”
Frankly, a good way to couteract inappropriate documentation is to price each deliverable, and require that it not add more than n% to the overhead cost of a project. Of course, we need some kind of standard for reasonable percentages for overhead costs. I have to admit that I have not seen any analyses of cuch things.
Hank Mayers