One of the concepts that resonated with me during my agile training was the concept of maximizing work not done. This is the tenth of 12 principles behind the Agile Manifesto. In it's entirety, the principle reads as:
"Simplicity--the art of maximizing the amount of work not done--is essential."
- Don't start projects that are not needed or not properly resourced. This seems obvious but it is surprising to me how often this occurs. I was recently on a large high-priority business program for an organization. There was a crisis (isn't there always?) and 5 key resources were pulled from the program to work on a new crisis project. This put both projects at risk. There are other cases where people work on projects that are not approved (rogue projects) at the expense of approved and prioritized work. This is sometimes just a lack of coordination, but it can also result from people going off on their own and working on what they want. This makes it really hard to kill projects.
- Eliminate multi-tasking as much as possible. Numerous productivity studies have shown that assigning one resource to many different projects is wasteful. Most resources can be dedicated to one team. This has an added benefit over time of building teams that work efficiently together.
- Related to the prior concept is to staff projects properly. One of the largest sources of waste at the portfolio level are projects that are starved for resources. How many times have you turned up for a project meeting only to have key personnel missing due to multi-tasking or reassignment. This is a time and morale killer for everyone involved. The fits and starts that projects go through while trying to get resources assigned or reallocated to them is wasteful. A more agile approach is to keep the project team intact and bring the work in an organized (i.e. backlog) to the team.
- Time spent re-organizing teams to work on projects. This includes kicking off new teams and projects, forming and storming stages of team development. Sanjiv Augustine of Lithe Speed and Sally Elatta of Agile Transformation have both spoken or written on this top
- Most (OK, maybe not yours) PMOs require a number of forms and reports that once prepared, will never be read by anyone. PMOs have gotten a bad rap as a hurdle or roadblock to progress. Whether that label is deserved or not, the reality is that there is often bureaucracy and paperwork that is requested from teams that doesn't go anywhere or mean anything. Check to make sure that every form and report has a purpose and keep asking the question why. Replace those status reports buried in email trails with information radiators that provide clear and transparent progress reporting.
- In a recent "Lean Project Management" presentation at the PMI Chicagoland chapter, speaker Philip Gisi suggested that if you are in doubt about the usage of a particular report, prepare it but don't distribute it as you normally would. If no one asks about it, it is probably waste and no one would miss it if it disappeared. I did this exact thing for a weekly program level status report and found that no one even blinked or asked about it after a month. Since we had other means of reporting data, I quietly dropped the report. When we needed to report to management, I begain to rely directly on reports about the backlog (burnups or user stories) or we demonstrated working code. After a few months, we largely abandoned the concept of weekly reporting in favor of reports that came directly from our agile tool and did not have to be prepared separately.
- Preparing for program reviews or stage gate reviews can be un-necessary. At a recent consulting client, the program-wide reviews held every other month were a killer for the team. Key leaders would spend the 1 or 2 days prior to the review preparing and then 1-2 days in the review itself. Most of the time in the meeting was spent posturing and spinning the information (the program was nearly a year late) and not really used to address key issues. Each team reported status slightly differently and in some cases, they presented only to themselves. It was a feel good exercise that really didn't accomplish anything.
- Eliminate duplicate data entry. Time reporting and status reporting are two easy examples of duplicate data entry.
- Don't create work in process. Any type of inventory is consider waste in a Lean project. This includes those large requirements documents, analysis documents, or other work that is potentially throwaway, or requires someone to read and digest as a separate step.
- Work to standardize and optimize the processes that are being used in the organization. Continually work toward making the PMO itself leaner and meaner, rather than building more and more of a beauracracy.