How do you reward failure?

I was a participant in a recent survey facilitated by the Corporate Executive Board’s Enterprise Architect community forum regarding “How do you reward failure?” My response to the survey triggered a bunch of emails from other members to me noting how much they liked my response so I thought it might be worthy to share on my blog.

I've played various portfolio management roles here in Microsoft ranging from portfolio management to project delivery in Business organizations and Business Support organizations. The roles I’ve performed are Portfolio Manager, Business Architect, Enterprise Solution Architect, Solution Architect, Program Manager, and Project Manager. Each of these roles have responsibilities to encourage/reward failure early in the lifecycle of any project. The assumption I have for rewarding failure is to encourage canceling in-flight projects that won’t deliver the intended business value and save the organization time and money to re-invest in projects that deliver greater business value. Here’s how I’ve done it:

• As a Portfolio Manager: Every portfolio has project failures. The trick is to find them and kill them early. I only measure failure if a project team failed to meet defined KPI Targets once they have passed a Baseline milestone. The assumption here is that post a Baseline milestone, the project’s Steering Committee and project team have accepted all risks and committed to moving forward to deliver a solution to the defined project KPI Targets normally captured in the project charter. I celebrate project cancellations by communicating to the team and to the steering committee via a 'thank you' note describing how the team made one of the most difficult decisions possible and for all the right reasons. I usually tailor an email describing how the cancelation saved the organization time and money by not moving forward with a solution that wouldn't deliver to use the maximum business value and that we can now re-focus our efforts on a more ‘strategic’ solution opportunity. By the way, ‘strategy’ refers the project charter’s defined KPI Targets that directly associate to a Business Organizations or Business Support Organization managed by business performance management processes. See here for details. Another important point in this role is constantly prioritizing the project portfolio based on business strategy (ie prioritized business objectives) and canceling projects that now fall below another project investment that delivers greater business value within a given budget. So, even in the situation where an in-flight project that is on-time, on-budget and poised to hit all critical business requirements but won’t deliver more business value than another un-resourced project, its time to serious consider divesting in the in-flight project and routing those resources to the higher priority project. Of course, don’t do this without careful thought to the people dynamic; most folks may not want to shift focus to a business domain they don’t have expertise on, people have an innate need to finish what they start to feel and achieve the sense of accomplishment, and constant change can begin to frustrate project teams.NOTE: In the situation of a Business Support organization’s project portfolio, frequent redirection of resources can lead to chaos quickly due to the bullwhip effect. To avoid this, the project portfolio must be integrated into business performance management processes directly connected to the Business Organization’s business strategy.
• As a Program Manager and Project Manager. Implement Agile concepts into the project delivery lifecycle. This allows teams to plan early, plat often, and conversely fail early by recognizing signals of failure then course-correcting. As a Program Manager and Project Manager, I frequently step back and assess progress toward our defined objectives in our charter. When progress isn’t being made fast enough in terms due to over-budget, slippage or simply not meeting the critical business requirements, it’s time to re-plan the project that sometimes results in canceling the project altogether. When this happens, I like to take the team out for a celebratory event (dinner, drinks, whatever) for successfully making the decision to cancel a project that was doomed to fail.
• As a Solution Architect . Do the background analysis to help justify why cancelling a project early or retiring a failed solution helps the business in terms of describing how the solution simply won’t meet the business requirements and targeted system quality targets. This can happen via causes such as; technology non-fit, poor software design, misalignment to the Enterprise Solution Architecture, or highly complex business requirements. This analysis normally feeds into the Project Manager or Program Manager project team roles. Anyway, help the team celebrate making the right decision to cancel or retire solutions based on the analysis.
• As a Enterprise Solution Architect. Do the background analysis to help justify to the project Solution Architect why cancelling a project early or retiring a failed solution helps the business in terms of describing how the solution is not aligned to business strategy in regards to misalignment to Architecture Principles and Standards (think application integration patterns, information mastering policy, vendor product policies, etc) that are founded on business strategy expressed in Principle Justifications. One important piece of advice when playing the Enterprise Solution Architect role in this situation, participate in the failure as a project team member. Do not take an “outsiders position”. That leads to ivory tower syndrome and distrust. The fact is that everyone is on the same team when it comes to project failure and success. We are all aimed at improving business performance.
• As a Business Architect. Do the analysis and help justify why cancelling a project early or retiring a failed solution helps avoid an underperforming business in terms of reducing costs, improving productivity, simplifies strategy execution, etc. Always paint the picture in a positive light based on engineering rigor tracing back to defined business objectives. See here for details. Again, participate in the failure as a project team member. Do not take an “outsiders position”. That leads to ivory tower syndrome and distrust. The fact is that everyone is on the same team when it comes to project failure and success. We are all aimed at improving business performance.

I’d like to add something here. I don’t think that every org should have a standard set of roles that are copy’n pasted from some industry team model. Each company and organization within a company will have a very different situation than another. For example, one company may be in the throes of economic turmoil and require a focus on scaling down the infrastructure to reduce costs. In this example situation, an EA team may not need to have a dedicated title of “Enterprise Solution Architect”, “Solution Architect” or “Business Architect” but rather have the titles necessary to focus on the discipline that relates closest to the area being addressed; “Infrastructure Architect” in this example. Of course, all scale-down situations like this need a dash of the other Architecture disciplines to build out the related artifacts to ensure engineering rigor is performed. For example, a situation may not require a full-time Information Architect. Fine, however, the Architect roles that are full-time must perform a bit of information architecture rigor to build their artifacts. I suppose I’m just highlighting this to you so as not to fall into the trap of assuming each named architecture skill or discipline requires a dedicated architect title in an arch team or that if there isn’t a titled architect in the team, none of related artifacts are necessary.