Wednesday, December 2, 2015

Custom Software (Part 3): Custom Process vs Best Practice

"Our needs are very unique, most systems won't work for us."
"We have a complicated model and process, it is hard to explain."
"We are too busy, we need to hire more staff to keep up."


Back in the 1980's, I used my first operations software. We all knew who, or more correctly, what was in charge. The software dictated how we used it. When we wanted to decide the best way to do things, we look at the software manual or asked support how the software worked. Software was built based on the most common functions and best practices (or at least the best practices of the software company).

We would all complain about how the software worked.  But the software choices were limited, so we didn't have much of a choice. Plus our use of the software was focused on record keeping. So when we wanted more from our technology, we had to go custom. Custom was the only other choice. If you wanted to do something different you had to build it yourself.

Flash forward to today

Technology has changed, as have our expectations. Today we expect flexibility with our technology, it should adapt to our unique needs easily. Don't give us a canned solution constrained to work the same way for everyone. Personalization. Customization. Consumerization. And any other ization you can think of which makes it all about me and how unique I am (or as unique our org is).

Enter the cloud. Today platforms exist which give you the freedom to configure the software to match you process without customization. You simply make some choices on features, configure workflows, redesign screens, add fields and make it your own. Amazing capability, flexibility, adaptability and any other ility you want to add all with clicks not code by almost any user without IT help.

But we haven't changed our process to select, implement or leverage these new tools.  We run our demos and selection process telling the vendor to only show us the "out of the box" functionality.  But when it is a platform configured to match your process, what does "out of the box" even mean? Whose box? Think outside the box. And the choice is no longer build or buy (you can rent and rearrange). Now your demos, selection and implementation processes rely on your understanding of your process, needs and capability. Comparing features won't cut it.

Custom Process vs Best Practice

In my new role I have heard more and more people ask how Best Practices are integrated, enforced or implemented in the technology. They want someone to tell them the best way to do a process based on their expertise in the solution and in their industry. So it seems like we have come full circle, lets get back to software with controls built around best practice? I have always, always, always hated the term best practice. I mean seriously, best for who? by who? in what scenario? ugh. I always preferred the term model practice, meaning here is a model that has worked for others.

So let me get this straight. In yesteryear we complained that software was too limited by function. Today we complain that software needs to have more "out of the box" functionality. What? I think the real problem is a lack of understanding our own business process. period.

Yesteryear's software dictated business process. Today's software allows you to configure to match your process. But are we ready for that responsibility?

So what?

So far this post seems to be a way for Steve to get on a soap box, relive his history and just generally rant.  Well it is my blog.... (insert smiley emoticon or something)

But seriously. I think this conversation focuses on the software too much. At some point a nonprofit has to take responsibility balancing wanting more flexibility in software with their own ability to define their process and ability to act on it.  It all comes down to knowing who you are as an organization,  how you work and your capacity. The technology is not the problem, nor should it be the focus.

The more flexible a software is the more you will need to know your process and the more tech skills it will require. The more "out of the box" functionality the more the software will dictate your process and lessen your need for internal tech skills. Way over generalized and inaccurate in a number of scenarios, but you get the idea.  And I am not saying one is better than the other.  There are countless examples where the "out of the box" solution is the best choice.

Where I Would Start

Define you processes. Not enough nonprofits take time to document and define their processes.  And if you don't have time or capacity to do this, stick with solutions with pre-built model practices. If you can't define your process, flexible software will exaggerate the lack of definition, so just don't do it. I don't mean to imply that lacking the time and capacity is a bad thing, it is just important to acknowledge where you are.

Then before you choose software, take time to understand the type of solution best fits your org's skills, needs and capacity, then do a first selection round on match. Then when you do the second round, tell the vendors your biggest struggles, what you hope to accomplish with the solution and what success looks like.  Then ask them to demonstrate how they would address it, rather than feature comparison.

 This post is a part of a series of posts, to get more context read the first post.