This might be old news for software folks.  But for project managers and others, it’s something worth repeating:

Don’t strive for perfection, strive for “good enough”

While perfection is absolutely necessary in sports, the Olympics, and other highly competitive things, in software, it’s something to be avoided.


Because software is never perfect. There are always bugs, missing features, too many features, confusing navigation for some, and non-intuitive workflows with too many steps for some users.  You aren ‘t going to please every single user.  If you strive for that, your software will become a sort of frankenstein-looking thing and not very good for anyone.

Instead, shoot for “good enough”.  Good enough that the main functionality promised by the software actually does work, even if its not beautiful, has some bugs, and isn’t “perfect”. Bottom line: get something out into the real world for real testing by real users.  Get feedback, and iterate.  That’s it.

You’ve heard the saying “if you wait for the perfect time to have kids, you will never have them”

Same thing applies to mobile forms software implementations.  If you wait until the perfect moment to begin implementing a mobile forms solution, it will never get done.  I’ve seen this phenomenon repeat itself many times:

  • An entity will express interest in moving from paper-based field forms to digital
  • Several vendors get invited to chat and demo their product
  • The entity becomes paralyzed evaluating existing solutions, considers building their own solution, another crisis consumes their attention, and in the end reverts to their tried and true paper-based field forms
  • Two years goes by and the process repeats, usually with someone else at the helm because the other person is no longer employed at the company

Remove this barrier for faster implementations

A large barrier to a successful mobile forms software implementation is the way an organization rewards and penalizes its people for success and failure.

Putting yourself in the person’s shoes spearheading a software implementation, its easy to see the problem: For example, if I’m in charge of getting software adopted by our field crews—in addition to all of my regular work—I’m going to make sure that it succeeds.  If it fails, I’ll get blamed for that failure and possibly lose out on my annual bonus, or worse.  And if I succeed at it, I’ll get a pat on the back or some tiny token of appreciation.  Probably nothing to write home about, except that I get to keep my job.

You can see that the safer path is to evaluate a bunch of software tools, send a report to upper management weighing the pros and cons of each platform reviewed, but in the end actually do nothing.

Reward effort, not outcomes

Don’t take my word for it, take it from Sundar Pichai, Google’s CEO.  In this article, Sundar is quoted with the following:

“You have to encourage innovation. Companies become more conservative in decision making as you grow… be okay with failure and reward effort, not outcomes.”

 What does this look like for mobile field work software implementations?

It means making a decision and pulling the trigger on a software tool.  It means spending some effort and time deploying that software tool to a small team of folks that can kick it around in a real-world scenario and who can provide feedback for improvements.  It also doesn’t have to be perfect.  It can be just good enough to iterate on and improve it via a feedback loop.  This was discussed in a previous article here.

What if it doesn’t work?

No big deal.  It’s not like you are going to die if a software implementation doesn’t work out.  It’s just software.  If things don’t work out with the implementation, maybe because of the tool itself, or maybe because of the way it was implemented or who tested it, just rip out the solution, learn from that experience, and try again…this time with the knowledge of what didn’t work the previous time.

And if it “sort of” works?

Iterate.  Get feedback from real-world use, improve the forms, improve the workflow, simplify, and re-deploy on a continual basis.  That’s how you get from “sort of works” to “works good enough” to eventually “its perfect”.

Want to give XForms a look?

Click/tap the button below.