Failure? What Kind of Software Company Thinks Failure Can Be a Good Thing?

Failure?  What Kind of Software Company Thinks Failure Can Be a Good Thing?

The cold truth is, all enterprise software implementations fail to a certain extent, and they do so in two fairly predictable ways. Either they miss the mark to some extent during the implementation because the needs have shifted in that time, or changing business requirements require a complete refresh, upgrade, or migration (Oh My!).

If you look at failures as a learning opportunity isn’t it better to fail small? If you were learning to snowboard wouldn’t you want to take some small tumbles rather than run straight down the hardest slope on the mountain?

Fail, Learn, Fix, Repeat

In the first scenario you can’t blame the implementation team entirely. Over the course of an implementation, business needs continue to change, and often customers can’t articulate what they actually need until they have the system configured and then say “Oh… not that.” Inevitably the PLM 2.0 project begins to make usability or functional changes, or even reconfigure the entire data model. By this time, the customizations are mature, the code is rigid, and changes are expensive, time-consuming, and typically over budget.

Agile software implementation is gaining popular support in a lot of forward-looking companies. You can read more on that here. While Agile implementation will get your company closer to the ultimate goal, it absolutely embraces failure. During a sprint the customer can evaluate the added features while they are still young and malleable. This is the epitome of failing early, failing often, and failing cheap. It is also failing forward because the ultimate product is the realization of a changing business goal.

Examine your Mindset!

So why isn’t everyone using Agile deployment? The answer lies in the prevailing mindset that failure is to be avoided at all cost. I had an opportunity to hear Dr. Eve Meceda talk about fixed vs. growth mindsets

Dr. Meceda describes a spectrum of thought processes ranging from Fixed to Growth mindsets. Traditional project Management follows a very “Fixed Mindset” methodology where you believe you can anticipate and plan for every little activity and variable, and risk. People on the “Growth Mindset” end of the spectrum are more likely to take bold actions, evaluate the outcome, admit failure, and rapidly change trajectory to get on the right path. Growth Mindset leaders admit that they don’t know what they don’t know and are comfortable in that space. They think on their feet, respond to changes rapidly, roll with the punches, and are poised to adopt Agile Methods.

You can fail your way to success!

Agile deployment also goes a long way toward minimizing risk. In his blog, Don’t be a Dinosaur, Mark Reisig talked about various PLM deployments and the risk of finding out massive hurdles late in the project. Migrations are recognized as virtually impossible, technology that looked good at a demonstration turns out to be half baked, and various crucial puzzle pieces just don’t fit together “Out of the Box” as advertised.

There are serious dangers of jumping in blind with both feet only to find the pool is 2 ft deep. While it is dangerous for the company, it is also perilous for the decision makers and their long-term job prospects who choose to throw good money against bad decisions. One glaring example was cited in a recent article by in Engineering.com: “virtually everyone who had some responsibility for the company’s 2016 decision to invest in … the replacement for its old mainframe solution, has resigned, been fired or switched jobs.” Is it worth the risk? Instead of jumping in blindly to find the pool is shallow, why not take the stairs?

When your PLM doesn’t meet your needs any more

The average PLM system is several years old and it’s very likely that your processes have evolved significantly in that time. Your discovering that your PLM simply isn’t working for you anymore. This typically launches a massive project to upgrade your legacy system or migrate to another tool altogether. Rinse and repeat every 5 years or however often your provider releases a new version. Of course, Aras doesn’t ascribe to this methodology.

At the ACE 2019 Conference, John Sperling, SVP of Product Management, discussed releases in Innovator from the previous year as well as our internal shift to an Agile release schedule for Innovator using Scaled Agile Framework (SAFE). Almost a year later we have proven our continuous delivery pipeline launching new functionality to both our core code, and various connector releases available to our users.

It’s understandable that this methodology might be alarming to some people thinking “Oh no! Does that mean I need to constantly do migrations? Ouch!" Well, there are two pieces of good news on that front. First, Aras will perform upgrades for you as part of your subscription. That’s right. It’s included in the cost of your subscription. That means that the implementation and customization can continue through sprints without the massive disruption of moving to the next generation platform and all of the re-coding of customizations that has historically gone with that. The second piece of good news is that our roadmap is public, both past and present, so subscribers can choose when they want to upgrade according to which functionality being released that they want to take advantage of.

Are you ready to be a Resilient Thinker?

In Bruce Bookbinder’s recent blog How Resilient Thinkers are Saving PLM he mentions attributes of successful PLM implementors. They are adaptable, evolvable, and transparent. In addition to the wisdom and experience necessary to run a PLM program, another attribute I would add is that they are bold. They are leaders with the passion and a drive towards excellence, even if that doesn’t go in the right direction 100% of the time. After all, wouldn’t you rather be a little bit wrong while there is still time to fix the issue than get to the end and miss the target entirely?