Proactive Honesty: How to Kill a Failing Project

A Product Management Colleague posed this topic in a recent forum:

It is estimated that only a third of projects are fully successful, even with dramatic improvements in project management methodologies over the past several years. Most of us have been involved in projects that are not meeting the objectives and are consuming valuable resources (people, infrastructure, dollars). And yet, even when indicators suggest that a project is headed for failure, it is difficult to kill the project and reallocate resources to other, more fruitful efforts. I would appreciate any thoughts anyone has on this subject. I would be particularly interested in hearing from those who may have been faced with this situation and successfully dealt with it.

Beyond "Fail Fast"

In my view, the operative phrase is proactive honesty. Ideally, a leader (project manager, product manager, CxO or other) will have established and be tracking to performance points necessary for success. The earlier a problem is detected and surfaced, the greater the chance that necessary corrections can be put in place. Projects that are beginning to move over budget or schedule may benefit from brainstorming among the project teams. This may surface ideas to reduce time and costs and aligns team members behind the project.

As an example, I was once faced with having to cut staffing in half for an already bare bones project. I fully expected to kill the project and reassign team members when I took the problem to my team that afternoon. To my surprise, they came up with ideas and signed up for the extra hours necessary to make the project successful. As a contrasting point, half of this same team had come from a doomed project that had been scuttled just AFTER the development phase completed. They had put tremendous time and effort into the earlier project and suspected that much of their efforts could have been better deployed. Trust in management goes a long way toward insuring timely corrective action and a higher rate of success. Do not kill the messenger and do not be afraid to admit your mistakes! 

A tougher problem occurs when outside competitive forces or a serious “gotcha” shifts the ROI into a losing proposition. Proactively coming to terms with the new reality and moving quickly to redeploy resources to healthier projects is the best course to preserve both money and morale. Even when the change involves layoffs, I found that the morale and confidence of my staff remained high so long as I dealt with the situation proactively, honestly and with compassion.

Reprinted from original post by Pat Scherer in November 2007.

Six Predictors of Agile Team Success

Over the years, I've worked with a broad array of teams to deliver close to 50 software initiatives. Sometimes I've had the luxury of a team that has worked together before, but more often, we've had to factor in the additional uncertainty of newly formed teams. Beyond prerequisite skill competencies, six characteristics aid the assessment of how much the team will be able to take on with good results. These six characteristics also form the gold standard for building agile teams that will reliably out-perform competitors and other organizations:

1. Self-organizing
2. Diverse
3. Adaptive
4. Stable
5. Colocated
6. Team-centric

Best Performing Teams are Self-organizing

A self-organizing team has the ability and authority to manage work as a group and self-assign work from a set of stories and tasks identified for the current period. Team-members work with one another to complete their tasks without the tightly coupled "command-and-control" of a central authority. Team-members are coached through daily stand-ups and team retrospectives to identify and report blocking issues and collaborate on solutions including improvements to their team and process.
The process of self-organizing helps team-members develop important skills including clarifying requirements, estimating work, communicating with team-members and owning results. Eliminating command-and-control removes the bottleneck of a central authority. Broader and more efficient control is maintained through process transparency in the form of daily stand-ups, the kanban board, frequent code check-ins, and demos. This frees up time for Product Owners/Managers to focus on Customer interactions, market intelligence, requirements and removing external barriers to a successful deployment.

Best Performing Teams are Diverse

Organizations in trouble frequently have homogenous teams. A team where everyone is the same age, same gender, same/similar skill set, experience level and temperament is likely to have a lot of holes in their combined capabilities along with significant biases in their understanding and decision-making. Homogeneous teams have a greater tendancy to silo themselves apart from other organizations and Customers.
With diverse teams, there is an opportunity for each individual's capabilities to be multiplied by the team's interactions. Developing respect, trust and the ability to work efficiently with fellow team-mates takes time. For many, this is even harder when the teams are diverse, but I believe the results are worth the effort. A small cross-functional team that I recently worked with turned around a successful concept-to-deployment application in a third of the time originally projected. Process and decision-making were stream-lined through the team's cross-functional disciplines, but other unexpected advantages also came into play. Overlapping secondary skills within the team allowed us to team up on tasks to shorten the critical path, and the success of the final product was in large part a result of the complementary perspectives of the team-members. A senior QA clarified hidden aspects of an old platform we had to support helping us uncover design issues before they hardened into code. The junior member of our team introduced new design elements that enhanced the intuitive nature of the product. Our earliest debates on design, with two fundamentally different views, were not easy. Teams need to persist through their forming, storming and norming phases before teamwork becomes second nature.

Best Performing Teams are Adaptive

The overlapping secondary skillsets shared between team-members allowed us to cover all necessary tasks and team up on critical path items. "T-shaped skills" is the term used to describe having deep expertise in an area combined with secondary knowledge and skills across additional areas. Team resilience and the speed with which a team can adapt to change is largely a factor of T-shaped skills and the redundancy of skillsets. The loss of a key Developer can be devastating to a project unless another team-member can bridge the gap. Recruiting new team-members takes time and ramping them up can be disruptive to projects that are otherwise moving at a fast clip. Unanticipated changes are commonplace in software development. Agility is best created and preserved by recruiting and encouraging the development of T-shaped skills through code-pairing, task rotation, ongoing education, and other teaming activities.

Best Performing Teams are Stable

Some disruptive changes can't be avoided; others can. Why do some companies build disruption into every release by treating ongoing product releases as projects and reshuffling their teams? Why do other companies further handicap their efficiency, code quality and long-term competitive advantage through frequent changes in outsourcing, hiring and firing? Tracking a base set of quality metrics and mapping team velocities across stable, new and outsourced teams can provide a better perspective on real costs associated with each of these scenarios. Companies that want to compete long-term should adjust their practices accordingly.

Best Performing Teams are Colocated (or Have Invested Heavily in Glue)

The social aspects of a team can determine whether it will run efficiently or not at all. Tuckman's famous stages of group development (forming, storming, norming and performing) occur with more speed and certainty when teams are colocated. Communications and group accountability tend to also be better supported with colocation.
When colocation isn't possible, you need "glue" - individuals and tools that help bridge the communications and relationships between organizations. A lesson learned and echoed in Cisco's "Collaboration Work Practice Study" (March 2013) is that collaboration tools alone will not bridge the communications and trust gap - leveraging the "Catalysts and Connectors" within every organization is essential. It may be worth developing cross-team relationships through temporary assignments (an exchange program) and other opportunities for remote team-members to meet face-to-face.

Best Performing Teams are Team-Centric

One of the fastest ways to undermine top-performing teams is to set team-members into competition through practices such as stack ranking. Tolerating lack of respect and scapegoating across organizations will also undermine team efforts. Respect should be preserved at all times. Retrospective discussions should also be forward-focused and positive: how can we apply what we learned last sprint to improving the next one? Accountability and rewards should all be team-based.
How many of these six characteristics does your organization have? Understanding where you are today is the first step required to move your organization toward better performance, success and satisfaction. The Agile community provides many resources to aid your journey.

Introduction to Software-as-a-Service (SaaS) Product Management

In 2011, I led a session at ProductCamp Austin called SaaS Product Management. A poll revealed that the majority of the audience were managing traditional on-premises products and just beginning to evaluate SaaS as a delivery/business model. Here is a background on SaaS and some of the ideas we discussed in the session:

A Brief History of Innovation Leading to SaaS

In the late 1980s, software was packaged in boxes or installed onto hardware which was subsequently shipped. At IBM, where I worked, software was not valued much beyond its role of making the hardware function. Customers purchased a few software packages and made as many copies as they needed for all their PCs. This wasn't regarded as wrong - the term "software piracy" had yet to be invented.

All that changed with the realization that the profit margins on PCs were modest. Something had to cover the costs of developing the software. A succession of mechanisms were invented to control the copies and these, in turn, gave rise to software licensing. Product Managers, like myself, making the transition from shipped software to software licensing, began to appreciate how much easier it was to send software updates and license keys than manage the logistics of physical products.

Meanwhile, a second component leading to the proliferation of SaaS was emerging. The Worldwide Web (WWW), first conceived in 1990, gave rise to the first e-commerce operations in 1994.

We all know companies like Amazon that were there at the beginning. One less famous company, Software.net, was one of the first companies to sell and license software over the Internet. Their concept for an online shopping cart was so popular that it spawned a second company, CyberSource (now part of Visa), that provided e-commerce payment tools to other companies aspiring to do business online.

By 1999, a number of Application Service Providers (ASPs) were providing networked access to applications by subscription. According to Wikipedia, the SaaS acronym was first used in an article called "Strategic Backgrounder: Software as a Service" published in February 2001 by the Software & Information Industry's (SIIA) eBusiness Division. My work with ASPs and SaaS products began in 1999 and has continued to evolve through advancements of internet accessibility, cloud computing, and Agile/Lean development methodologies.

The Impact of SaaS on Product Management

There are substantial differences between successful management of SaaS versus downloaded or packaged software products.

Market intelligence for traditional software and hardware products are typically gathered through customer site visits and surveys. SaaS Product Managers are more likely to utilize online communities and web/service analytics. Top SaaS Product Managers take on public roles as thought leaders for their products and industry.

All the ramifications of packaging, manufacturing, warehousing, transport and display of physical goods goes away with the move to SaaS. In place of these concerns and logistical skills, a SaaS Product Manager must master an extremely transactional marketplace that includes on-demand subscriptions.

Pricing for traditional products typically assumes an upfront payment with opportunities to adjust pricing and support over the life of the product line. Pricing for SaaS is based on volume and lifecycle projections that are inherently uncertain. Payment for SaaS is distributed over time and is at the month-to-month discretion of customers subscribed to the product. Adjustments to SaaS pricing and support must be handled carefully as they can have immediate and disasterous effects on demand.

SaaS often operates in a crowded field of competitive offerings. When product differentiation becomes too difficult to maintain, SaaS Product Managers must find other ways to create stickiness. Driving customer identification with their product and brand is a critical factor in extending the lifecycle of mature SaaS products.

Lastly, the success of SaaS is more closely tied to the SaaS company's ongoing operations and support. This has given rise to the DevOps role as well as a broader Product Management scope to manage the gaps between software development and support for the SaaS infrastructure, customer onboarding and hosting.