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."

Yesteryear

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.

4 comments:

Peter Campbell said...

I think that where we need to land is with applications built on highly flexible platforms that, "out of the box" are functional and built on best practice-informed assumptions. Not that we're there - Blackbaud and Roundcorner still sell products that are largely unconfigured and then they configure them with you (at significant cost). But I think that we're getting there - a lot of the problem in the sector is that everything out there is either too old or too new.

BTW, I think you meant "Whose box?" up there, not "Who's box?" The box isn't a person. But, if it is, it's name might be Clyde.

Steve Heye said...

Peter, Thanks again for leaving another comment! This post took me a long time to think through and I waited to post until I thought I was close to good, but still had a grammar error... ;-)

I agree, we are getting close and the solutions are not there yet. But the bigger challenge is the orgs choosing and using the solutions are far away from adapting to the changing software landscape (at least from what I have seen).

Peter Campbell said...

It's frustrating. The big system vendors in the space stand to benefit from long, costly installations. It's not necessarily in their best interest to offer out of the box solutions, even in cases where out of the box might work. I am against nonprofits compromising on their best processes in order to meet software assumptions that didn't factor in their needs. But I'm all for nonprofits ditching bad processes that they've practiced forever in favor of best practices. So, if a company with the knowledge that, say, a Blackbaud has about fundraising develops a product that, out of the box, would be very effective for any standard nonprofit fundraising group, then it's on the nonprofit staff to be open-minded enough to change their practices to conform to the (healthy) software assumptions.

Today, however, Blackbaud's "out of the box" products (if any exist) are only suitable for small nonprofits. Blackbaud's enterprise products require extensive customization. And there are lots of nonprofits that still don't understand that rushing/outsourcing the implementation of a key system is the equivalent of shooting yourself in the foot, repeatedly. My mission in life is to convince everyone of them that critical system purchases and implementations should be long, labor-intensive processes that involve a large percentage of the organizational staff. Because that investment will be paid off handsomely when the right system doing the right things for them is deployed. The cost of blowing these purchases/installations is phenomenal. The up front investment that I recommend pales in comparison to the loss of productivity and, in all likelihood, revenue when you put in a bad fundraising CRM or case management system.

That said, there are improvements to be made on both sides.

Steve Heye said...

Peter, I think your comments add more value than my post does... ;-) Thanks for the thoughtful reply and I completely agree. There is work to be done on both sides.