Skip to content
August 8, 2011 / David Bleeker

How to fail a project… and win

People are surprised when I say that I work to fail a project as quickly and as visibly as possible. This seems to be exactly the opposite of what the Customer or Product Owner desires, not to mention the developers on the project. Let me explain…

Projects represent an investment an organization makes to achieve a specific goal. My job as a development manager is to minimize wasted investment by ensuring that the key risks in a project are mitigated as early as possible in the project. Most risks can be mitigated. My job is to find the risks that can’t and expose them early. Let me give you an example:

One project I was involved in required an integration with a third-party web engine that delivered statistical analysis that we relied on for our internal decision making. At the onset of the project everything seemed to be in order: standards-based integration using XML over HTTP, Java on both ends. The initial project focus was on stubbing out the inputs and outputs to the third party so that development could proceed at pace. So far so good. Once we started connecting to the actual vendor web services we discovered that we could not communicate. After much collaboration we narrowed it down to a difference in version numbers between Java virtual machines. It required that we upgrade our virtual machines to match theirs, something we could not do because of other internal dependencies. A simple task became a major issue that caused unnecessary delays. While this is rare, it points to the types of issues that can creep up and destroy a team’s ability to deliver.

In essence my statement deals with two important areas of software development: a) dealing with risk, and b) transparency in communication with stakeholders. As an Agile leader it is important to guide the team toward successful execution by helping them in both areas. Let’s look at each of these areas in a little more detail.

Dealing with Risk

Early in my career I had a mentor who said, “Overtime is a failure to plan correctly.” If you have been a software developer for some time you probably have had one or two projects result in an amount of overtime. It is precisely this lack of planning that I attempt to address in the first part: “fail a project quickly.”

The great thing about the Agile backlog is that, for the most part, the team is free to rearrange the stories as needed to facilitate development. Depending on the maturity of the developers in the team this can be a good thing. It can also be a bad thing when the team delays implementation of a complicated feature, thereby shifting risk to a later stage in the project.

I guide my development teams to address risk in order of decreasing impact. That means that I want the team to focus on implementing stories in more or less the following order:

  • Those that are most likely to fail. In general, the areas that are most likely to fail involve systems outside the application. These typically involve integrations: web services, queues, publications, files, etc. These need to be tested and validated first. Where possible create automated tests to prove functionality and connectivity throughout the implementation. Other areas to consider: legal compliance and security.
  • Those that will have a large cost impact if they fail. Put cost-driven risks next since they will likely impact the cash going out of the company. Work to reduce cost impact by evaluating alternative approaches early in the project. In general this pertains to licensing models and technology alternatives, amongst other things.
  • Those that will have a large schedule impact if they fail. Since schedules are typically tight, be ever vigilant to eliminate risks that will drive the schedule out. Securing resources from shared teams that are heavily utilized is one example of schedule risk mitigation.

While some could argue that these are risks that need to be ironed out before the development starts, it is not always possible to do so. One should work these elements as early as possible. If there is no good mitigation strategy then flag the issue so that a go/no-go decision can be made.

One side effect of this approach is that projects progress towards simple over time. I have seen teams involved in major projects working with less stress at the end of the project than at the start. The whole team breathes easier knowing that most, if not all, major issues are ironed out before crunch time.

Maintaining Transparency

One can go into a field, turn over any rock and find a dozen project managers who believe that it is essential to shield the stakeholders from details surrounding delays or issues in a project. It’s as if to say that the project manager’s reputation is on the line when a team uncovers an issue. It is rare to find a project manager who utilizes full transparency when communicating with stakeholders. And that is why I like Agile. The Customer or Product Manager is part of the team.

If there is no separation between the development team and the Customer or Product Owner, then there is no sense in keeping information from them. I much prefer to equip my business partners with the information they need to understand the issue, and to be able to defend the team when communicating to the rest of the business. I cannot tell you how many times I have seen project managers vilified because the Product Owner is notified too late in the game that their beloved project is washed up on some distant shore with no hopes of recovery.

The Customer needs to know that you are on their side, watching over their investment and making sound decisions. They need to know that you are not going to waste their money by not paying attention to what you and the team are doing. The best way to do this is to help the team discover the issues that will cause the project to fail, and to eliminate them. All of this while keeping the lines of communication open with the Customer. Ultimately this will result in solid success for the Customer, project team and you.

As always, I would love to know your thoughts on this topic.

Advertisements

One Comment

Leave a Comment
  1. sanchk / Aug 9 2011 3:31 am

    Speaking as someone who’s working in research at a university, I wish people would be more public and open about their failures. I’m working on some nanotechnology research, much of which is fraught with failed projects, but we never publish research or methodologies for our failures, because our grant providers and research publications only look for positive results. This is troubling in a field which is so dependent on experimentation, and which much can be learnt from studying failed projects or negative results.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: