It was that advice that has guided me ever since. It is very easy in the euphoria surrounding the triumph of solving a difficult problem or pulling off the near-impossible project to not spend the time questioning just why you succeeded. To do so seems to be diminishing the success and even doubting that you actually did succeed. On the contrary, an objective review of how you succeeded will greatly help you in continuing to succeed.

When we succeed, we can become victims of three biases, according to Gino and Pisano (April 2011). There is the attribution bias in which we overestimate how our knowledge and actions contributed to the success and we downplay any external factors that could have just made us more fortunate. We also become overconfident in our abilities as we tackle the next challenge. The third bias (and which I believe is most important) is that we don’t ask why we succeeded because the success is proof enough.

To illustrate this last bias, Gino and Pisano (April 2011) recount a study in which students were given a set of math problems to complete. When the students submitted their answers, they were only told if they had the answer right or wrong. The students were given time to reflect before they were given a second set of math problems. The second set was designed so that a key concept in the first set of problems was needed to solve the second set. The students who successfully solved the first set of problems generally spent much less time reflecting before they started on the second set of problems. Thus, many of these students failed to find the answer for the second set of problems. Reflection, whether the student succeeded or not, is the key to continuing to be successful.

So, how do we best learn from success? We should celebrate success but also examine the causes of success. For every project, we should hold a systematic review. Gino and Pisano (April 2011) give the example of Pixar’s review process. Even though Pixar has had eleven hit animated films in a row, the company still goes through an exhaustive review process to determine what made the film successful and how to repeat that success.

Another point to keep in mind is to fully investigate the feedback. Was it immediate or at least can be connected to the actions taken? Is the feedback a true indicator of success or just a random event that looks like a successful outcome? Feedback is an important concept and I explore it in greater detail in this discussion posting.

Two final points. First, “[r]ecognize that replication is not learning” (Gino and Pisano, April 2011). Blindly following the same formula again and again can suddenly turn against us as the nature of the problem changes and what worked before doesn’t work now. And, second, we should always be experimenting. We can always improve how we do something. Plus, we can create variations on our actions that may not apply to the current situation but can apply to a challenge in the future.

Failure is a great teacher but so is success. Learning from our successes will keep us from becoming “one-hit wonders” and give us the string of successful “hits” to be “rock stars.”

Reference:
Pino, F., & Pisano, G.P. (April 2011). Why leaders don’t learn from success. Harvard Business Review. 68-74.

Wicked problems were originally an IT concept but it has spread to other fields as we confront more complex challenges. Definitions of wicked problems vary but the Rittel and Weber’s definition is the most cited:
“ 1. There is no definitive formulation of a wicked problem (defining wicked problems is a problem).
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false, but better or worse.
4. There is no immediate and no ultimate test of a solution to a wicked problem.
5. Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered to be a symptom of another problem.
9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
10. The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).”

Gov 2.0 seems to fit nine of the ten criteria (I have my doubts about point five) but I think the better definition is Conklin’s incorporation of social complexity into wicked problems because of the great number of stakeholders , the multitude of solutions, and the multiple perspectives of Gov 2.0. I believe Mark Drapeau’s diagram of Gov 2.0 best captures this complexity.

So, why should it matter if we determine that Gov 2.0 is a wicked problem? Well, once we know the kind of challenge we face, we can determine the best strategies to confront it. If Gov 2.0 were a tame problem then we know that our standard toolkit of problem solving methods and data analysis are adequate for creating solutions. The tame problem does not change as we attempt to analyze it and we can model the interactions as simple cause and effect relationships. The definition of a tame problem can be easily agreed to as also the solution.

But if we establish that Gov 2.0 is a wicked problem, then we know that even defining the problem will be difficult much less knowing what the solution will be. In fact, with most wicked problems, you don’t solve the problem as much as manage it (climate change is a good example of this). Much of the work is in building consensus among the stakeholders on the wicked problem and developing innovative methods to manage the problem. There is also a substantial amount of work in identifying and containing undesirable effects stemming from the management of the wicked problem.

In dealing with a wicked problem, we need collaboration across government organizations while helping to build up skills for innovation among the employees. Beinecke (2009) argues for a new type of leadership that is transformational rather than transactional. We also have to develop a new perspective on risk management as Krigsman (2010) argues in his article. The Australian Government has produced a great manual on how to deal with wicked problems in government management that is excellent guidance for current Gov 2.0 activities.

Establishing Gov 2.0 as a wicked problem may seem discouraging but the good news is that there is many tools to help us understand and manage wicked problems that emphasizes the benefits of our solutions while minimizing the undesired effects. It also confirms the need for more openness, collaboration, and innovation in government.

References:
Australian Government. (2007). Tackling Wicked Problems: A Public Policy Perspective. http://www.apsc.gov.au/publications07/wickedproblems.pdf

Beinecke, R.H. (2009). Introduction: Leadership for Wicked Problems. The Innovation Journal: The Public Sector Innovation Journal, 14:1. http://www.innovation.cc/scholarly-style/beinecke1.pdf

Conklin, J. (2008). Wicked Problems & Social Complexity. http://cognexus.org/wpf/wickedproblems.pdf

Drapeau, M. (May 24, 2010). What does Government 2.0 look like? http://radar.oreilly.com/2010/05/what-does-government-20-look-l.html

Krigsman, M. (May 7, 2010). ‘Wicked problems’: collaboration, risk, and failure. http://www.zdnet.com/blog/projectfailures/wicked-problems-collabora…

Science Daily. (December 5, 2007). Complex ‘Wicked’ Problems Better Solved Individually Than Through Internet Groups. http://www.sciencedaily.com/releases/2007/11/071130172937.htm

Wicked Problem. http://en.wikipedia.org/wiki/Wicked_problem

Wicked Problems, May 2002. http://www.poppendieck.com/wicked.htm

This is where Process Intelligence (PI) comes in. PI is simply defined as “the ability to understand business processes and knowing how to use them effectively” (Blickle, et al., 2010). It is a combination of several disciplines such as Business Intelligence, Business Activity Monitoring, Process Discovery, Business Process Management, and Analytics. The goal of PI is to use real-time data to anticipate and shape business processes so that organizations can continually improve processes. PI achieves this goal through the establishment and measurement of Key Performance Indicators (KPI) that are the vital signs of the process like blood pressure and cholesterol numbers are indicators of our health.

To understand how to use PI in Gov 2.0 let me talk about Eggers and O’Leary’s (2009) book about big government projects. If We Can Put Man on the Moon discusses why government projects succeed or fail by explaining seven different traps along the way from the idea of a government project to its results. The authors describe a five-step process government projects travel through which is very similar to the PI process.

The Eggers and O’Leary Process:
Idea -> Design -> Stargate -> Implementation -> Results
<——————–Reevaluation——————————>

The PI Process
Strategize -> Design -> Implement -> Compose -> Execute -> Monitor and Control -> (Cycle around to Strategize)

As you can see Idea is to Strategize and Design is Design. There is no Stargate in PI but Implementation pairs with Implement and Compose and Execute while Results pairs with Monitor and Control. Viewing these processes side-by-side led me to the realization that KPIs and PI monitoring needs to be built into the Gov 2.0 project/process from the Idea stage. Doing so can help avoid or mitigate the seven traps that Eggers and O’Leary’s (2009) research found. Taking each trap in turn:

1) Tolstoy Syndrome (confirmation bias) – Decision makers only consider evidence that confirms their preconceptions. Asking how we will measure the success and failure of a project objectively will force decision makers to consider all evidence and to build in KPIs that are true vital signs of the health of the Gov 2.0 project/process.
2) Design-Free Design Trap – Often, the enabling legislation is written to ensure passage of the bill and very little consideration is given to how the project/process will actually work once it is handed off to the government agency or agencies. Again, incorporating KPIs will bring in questions of implementing the proposed project/process once it passes to the agencies.
3) StargateTrap – The project/process passes from the political arena to the operational arena. As Patashnik (2008) points out in Reforms at Risk, reforms are easier to initiate than to maintain because the opponents to the reform will continue to chip away or suffocate the reform. There are many tactics for eroding reform but PI can help by providing objective measures that can counter the usual argument that the reform is not producing the promised benefits.
4) Overconfidence Trap – Agency managers are under great pressure to make the project/process succeed and often have unrealistic expectations about their chances. The idea of even considering failure is unthinkable to most agency managers but ignoring the warning signs can doom the project/process. Clearly this argues for the need of objective measures provided by PI.
5) Sisyphus Trap – Government work can be confusing and ambiguous especially on large government projects/processes. KPIs can be the GPS that tells workers how we are progressing on the journey and can also be the basis for incentives for good work.
6) Complacency Trap – Things are going well so our guard is relaxed. But, unnoticed events can be occurring under the surface that will suddenly cause a major crisis. PI can alert us to these emerging events long before they become a serious problem.
7) Silo Trap – PI is not just about mapping and measuring the processes but is also about understanding how people and organizations interact with the process. PI encourages us to consider our goals for developing a project/process and to bring in all parties to discuss their part in the project/process. By its very nature, this dialogue breaks down the silos that separate agencies and departments.

Gov 2.0 came about because the old ways of government just don’t work anymore in today’s world. We live in an exciting time where the new technologies and the new ways of thinking can create a government that is more engaged and serves our country better in innovative ways. There is a lot of energy and enthusiasm for Gov 2.0 reform and that is desperately needed to keep the momentum going. But the true test is if we can maintain the advances of Gov 2.0 for the long run. Patashnik’s (2008) research demonstrates that reforms can easily lose steam and are difficult to keep alive for more than a few years. Despite our technology and commitment, using the current management methods is likely to doom Gov 2.0 to another short-lived, good intention movement that just didn’t endure.

References

Blickle, T., Hess, H., Klueckmann, J., Lees, M., & Williams, B. (2010). Process intelligence for dummies. Hoboken, NJ: Wiley Publishing, Inc.

Eggers, W.D., & O’Leary, J. (2009). If we can put man on the moon-: Getting big things done in government. Boston: Harvard Business Press.

Patashnik, E.M. (2008). Reforms at risk: What happens after major policy changes are enacted? Princeton, NJ: Princeton University Press.

Traditional project management is still useful. Thanks to TPM, the US Government built Trident submarines, nuclear aircraft carriers, and landed men on the Moon. Much of what made TPM so effective are the innovations pioneered by the Federal project managers such as Earned Value Management and Program Evaluation and Review Technique. But, for TPM to be effective, the goal and the solution must be known in advance and change must be minimized as much as possible.

In the Gov 2.0 reality, change is paramount and rapid while the goal may be well-defined but the solution to achieve the goal is often vague. Timelines are extremely short and so are resources and budgets. Using TPM to manage Gov 2.0 projects is just inviting failure (as the numerous examples in the IT Project Failures blog will attest). For Gov 2.0 and OpenGov to succeed we need new methods to manage these projects and their implementation. That is why I advocate the Adaptive Project Framework.

The APF was created by Dr. Robert Wysocki during his 40+ years as a project manager. He wanted a project management method that could better handle change and allowed for exploring a way to a solution while minimizing wasted time and resources. The best feature of APF is that the project scope is variable and that is what makes it perfect for Gov2.0 projects.

Scope in a project is what work needs to be done during the project (Project Scope) and what features the project product will have(Product Scope). In TPM, both Project Scope and Product Scope is fixed as early as possible. All planning, scheduling, and resource requirements are anchored to the scope and this is why change is so disruptive to the TPM project.

APF uses Cycle Plans and Cycle Builds to incorporate change into the project management process. In the initial planning, the project manager and project customer(s) create a high-level document that defines the project goal and conditions of satisfaction. Then a Requirements Breakdown Structure is built that captures the project product requirements at that time. A Cycle Plan is created that details what requirements will be created during the Cycle Build. The Cycle Build is time-boxed which means that it is a short duration (two weeks to a month).

During the Cycle Build you can have two streams of work. In one stream, some team members explore new features to include in the final project product while the other stream integrates proven features together into the product. As new ideas emerge they are added to the Scope Bank to be part of future Cycle Builds. Any features that are not completed within the Cycle Build are added to the next Cycle Plan. The Cycle Build can also be terminated early if the features are not working or if the current solution no longer fulfills the project goal.

To illustrate the difference, let’s use an example from recent events. Suppose you are working on a project to apply Search Engine Optimization (SEO) strategies to your agency website. You are halfway through the project when Google launches Google Instant. Then Twitter launches a redesigned search service. This requires a major change in your SEO strategies. Now what do you do?

Under TPM you could continue on with the project but your project product will be outdated and ineffective by the time you deliver it. Or you could cancel the TPM project and start all over again. You have wasted time and resources while incurring the additional costs of a new project. This will not look good on the IT Dashboard.

Under APF, the most you have to do is modify the Conditions of Satisfaction document and the Project Overview Statement. You can cancel the current Cycle Build and begin a new Cycle Plan to incorporate the new technologies and techniques into the final project product. Waste and loss of time are minimized while the current project can continue on toward the original goal but with an improved solution.

In my next posting, I will go into detail about Process Intelligence and how that can help address the issues raised by William Eggers and John O’Leary in If We Can Put a Man on the Moon… Getting Big Things Done in Government. I have also added two new pages devoted to collecting resources about Process Intelligence and Project Intelligence to my personal blog.

At the same time I’ve also just finished Wysocki’s Adaptive Project Framework.  APF is used for projects where the goal is clear but the solution is uncertain.  Using iterative build cycles and treating scope as variable APF essentially explores a way to the best solution for the project.

It occurred to me that blending process intelligence with APF might lead to more effective change management efforts – Lean Change Management.  APF will be used to establish the process and then process intelligence will be used examine the process and feed in improvements to the next APF cycle.  Over the next month or so, I will work out the details of lean change management in periodic postings.

“Can we or should we do it?
Will it make our situation simpler or more complex?
Will it help us to solve a problem or cause a problem?”
Should we do nothing?”