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."
It still strikes me as an excellent idea and goal that should be consistently strived toward. It is especially relevant for those of us (all?) who are constantly challenged to "do more with less". We have more work to do, and we are working longer hours. With today's technology, most of us are on all the time so we have the ability and often the need to do work during hours that used to be non-working time. How many of us find ourselves checking emails when we are engaged in personal activities or with family? (My wife tells me that checking email in bed is not an aphrodesiac!) So this principle of maximizing work not done is helpful and could result in us reclaiming some of our personal time.
It is clear how this principle is applied at the agile team level. We don't write elaborate requirements documents or spend time building functionality that will not be needed or used. But how does this principle of maximizing work not done aplly to the Agile PMO? What is the work that can be avoided? Here are some of the most obvious ones (more to come):
#1 - Adopt Agile Portfolio Techniques
- 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
#2 - Cut Out the unnecessary PMO Overhead
- 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.
#3 - Adopt Lean/Agile Approaches wherever it can work for projects
- 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.
#4 - Practice Continuous Improvement at the PMO Level
- 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.
I am sure there are other ways that the PMO can maximize the work not done. Your thoughts?
Anthony
Comments