Lily Snyder

I heard on NPR that scientists are starting to publish their studies that failed to replicate. This is unexpected, as scientists usually only share their successfully replicated studies.  In the scientific method, a study is verified when it can be replicated by another research team. So, it was surprising when they found that “two-thirds of the experiments did not replicate, meaning that the scientists who repeated these studies but could not obtain the results that were found by the original research team.” By trying to replicate studies the scientists found, “that figuring out the truth is really hard.”

Listening to this segment, I couldn’t help but think about failure and IT projects.

In the software development world, there is a technique called fail fast. Failing fast means that problems show themselves immediately and fail visibly. This visible failure allows the team to fix a few small bugs instead of trying to fix a very big problem where no one knows how deep it goes. Failing fast is also encouraged because it keeps developers from getting stuck in analysis paralysis, where no one can make a decision due to fear of the effect it may have.

So, we have the benefits of investigating “failure” in the scientific community and we have failing fast in software development, but what does it mean to fail from a project management standpoint?

One point of view from the NPR interview I found interesting was that instead of saying that a study “failed,” the scientist interviewed said that maybe both studies were right. That under one condition the study passes but change the conditions just slightly and it cannot be replicated. This is very true for IT projects. You may try to apply the exact same technique for one customer where the project was a success, but applied to a different customer, the project leans towards failure.

Consider this:

You successfully implemented an IT project where your team used an Agile methodology. The customer enjoyed participating in the Agile process and accepted the idea of working software over comprehensive documentation. You take this success to start an IT project with a new customer but they are struggling. The new customer begins to think that you don’t understand their needs and aren’t delivering what they asked for.

What are the conditions? This customer has never used Agile before. The industry they are in requires detailed documentation first and getting approval before moving forward to make sure the design is in compliance. You determine that the customer would be more comfortable with a Waterfall approach. Could Agile have been used on this project? Yes, but if the customer isn’t comfortable learning it or trying it then it will fail.

Even though we have all these tools such as the PMBOK Guide, Project Management certifications, lessons learned, and Microsoft Project, we are not guaranteed to succeed. Projects are made of people and each person is their own unique “condition” to the study. By recognizing that, along with failing quickly within the project, we can hopefully bring it to a successful outcome.

In the way that the scientific community provides anonymous safe havens to post failures and lessons learned, companies should offer the same space for their employees’. Lessons Learned is a major step at the end of a project, but by providing a searchable archive of lessons learned, by project type, we can hopefully avoid future failures.

Have you ever experienced a project failure? Let me know in the comments below.