Project Adoption, and Finding Success in Failure

01/03/2018 by Chris Toohey

As a coporate enterprise application developer (meaning I work for the company that I write applications for vs. writing applications for resale/external markets), my project adoption rates may shock you.

My adoption:abandon ratio is often 1:1. For every project that becomes a daily workhorse for the business, there's a project that's either half-heartedly adopted or outright ignored.

I wanted to take a few moments to cover some factors that I've seen affect project adoption, and how you can turn a dead project into a win.

Contributing Factors

Let's first discuss two possible contributing factors that impact project adoption:

Lack of Communication

This is by far the most detrimental and nuanced contributing factor to project adoption.

Here's a few random thoughts around lack of communication and how it can negatively affect your projects.

• Users like to know how their day-to-day operations will change. They often fear any change they themselves are not steering.

• Users who do the work often understand the business - and thus the specific needs and demands of the business - far more than you ever could.

• Users may become frustrated that a solution was dropped in their lap without communication, especially lack of communication by means of little to no training.

These are just three of countless ways that a lack of communication can ultimately impact the adoption of your project.

My Advice

I can't tell you how many times I've had a conversation with someone that responded, "I didn't know I could do that!". That's a breakdown in communication from me to them.

Remember, communication is bidirectional. You can't say "I sent an email when I deployed it" and expect that to be enough communication for a project rollout. It's been my experience that people don't read long emails outlining your amazing new project and how they can use it.

You need to start the project, work the project, and complete the project all while communicating with your potential adopting users. If possible, you'll want to secure as many project champions as possible/appropriate and get not only their input on the project (which I also advise you listen to, and fold as much feedback into your project as possible to ensure success), but so you have someone shutting down complaints from the user community when you're back in your office coding.

Your project champion should - and if you're effective, will - feel as though this is their project. You'll use their desire to succeed to push adoption.

Lack of Budget

Was this a project that would have been outsourced / gone SaaS but there's "no budget" or it was decided that you're the "cheaper" option?

You may think I'm disparaging this type of project, but I'm not: this type of project can provide you with the best opportunity to make an impact on your company.

Notice I didn't say "positive" or "negative" there, tho? That's because it's the best opportunity to look like a rock star or a bumbling chump.

Projects with a lack of or loss of budget can be huge wins for the corporate enterprise application developer.

The whole process more than likely started with discovery and vetting the business processes surrounding the project. If you're lucky, there's even an RFP floating around that breaks down exactly what the business needs from this project to consider it a success!

However, if there was a "project champion" for some SaaS solution, they're likely to read the situation as "[they] didn't get what [they] wanted, so we settled for doing it in-house".

-- not to mention that a perceived lack of cost could result in slowed adoption, a lack of motivation to make project deliverables from business owners who would otherwise be held to date by a contract, and countless other distractions and pitfalls chalked up to "well, we're only doing this in-house now...". I've seen too many projects go Adoptional: that is, a slowed adoption which often results in abandonment which is the direct result of a "hurry up and wait" that somehow snuck into your target audience.

My Advice

I'll keep this one simple:

1. You need to knock this project out of the park.

   Not only do you need to deliver on this project, but you need to over-deliver. You need to consider their wants as needs and their needs as business critical demands.

2. You need to win over the "project champion"!

   This person will make or break your project. They need to look like a superhero when you deploy, and like a visionary when there are any support issues (as those will invariably come up).

These projects give the "in-house developer" the most opportunity to show off, but you need to deliver more than wow here.

You will have the best chance for success if you communicate, develop "with the door open" (that is, while collaborating with the "project champion"), and deliver.

How to turn a failure into a win!

Some projects - no matter how well they're managed, how effectively you communicated, or how "on-board" the "project champions" were, fail. But even in project failure we can have success.

I subscribe to the idea that there are - as Christopher Booker points out in his 2004 book - [The] Seven Basic Plots [Amazon affiliate link]. In other words, there are only seven basic plots out there, and every story is derivative on those plots. I also think there are only so-many-unique types of applications. And like the countless stories that come from one of those seven plots, there are countless applications that come from that theoretical finite list of unique types of apps.

For an example, I see your "Corporate Policy and Procedures" application as a "Document Library"... with business and company-specific feature functionality add-ons.

I use an incremental development model when working on my projects... or at least my interpretation of an incremental development model -- your mileage may vary.

When I start actually developing my application I use one of my "starter templates" to quickly establish a core that I can build on.

In other words, I grab my "Document Library" starter template, which gives me lots of core application functionality like document version control, workflow, history tracking, and I start adding the specific-to-the-project features and functionality.

Additionally, I tend to build my application methods and functions using a naming schema that allows for copy/paste portability to any other project that needs a similar method or function.

The point is, even a failed project will have a function or UI/UX component that you can reuse in a future application, or that can be added to an updated "starter template". You can quickly turn a failure due to lack of adoption into a success if it means a faster turnaround on your next project.

Conclusion

You may notice I didn't talk about any particular platforms or technologies. I did that by design, as I don't think project adoption rests on the platform or technology used per se.

I wanted to keep this as platform-agnostic as possible, as I believe these adoption failures (most of the time) have nothing to do with the technology but rather everything surrounding the technology.

Failures happen. It's how you use that failure - from learning why it failed, ensuring (if possible) that it doesn't happen again, and scavenging anything useful from the husk of your project - that will make you a successful developer.