Tuesday, September 15, 2015

Custom Software (Part 1): Complicated or Complex?

INTRO- This post is the first of three about custom software. You can read the opening post here.
"Our needs are very unique, most systems won't work for us."
"We have a complicated model and process, it is hard to explain."
If you have worked for a nonprofit, you have heard (and probably said) these statements. But before dig into what I think lies behind these statements, lets agree on my definitions of Complex versus Complicated.

Complicated - difficult to analyze, understand, explain, etc. (from reference.com) I interpret this to mean the methods are not clear, defined or purposeful enough to be explained. 
Complex - so complicated or intricate as to be hard to understand or deal with (from reference.com) I interpret this to mean there are many defined, intricate parts aligned to meet a need requiring multiple solutions to address.

Not sure I have expressed my thoughts on the distinction clearly. Basically, I think we over complicate many things as nonprofits (and companies and personally, not unique to nonprofits).  We build our process over time, tailored to staff, tied to grant\funder requirements and to meet our immediate needs. We react. This creates complicated process. Difficult to explain, because it is cobbled together. Difficult to understand, because it was designed to meet a range of needs instead of focusing on the process. Difficult to analyze, because there is no purposeful pattern or outcome.

Some things are simply complex. Solving big problems like homelessness, poverty, education, etc is complex. My last organization, The Cara Program, had a complex program model, not complicated.  The program to return people to work had a number of elements including admissions, transformation training, professional training, personal coaching, placement, retention and advancement. Each element was intricately designed to support the overall outcome of lasting change, but each element requires unique skills, steps, metrics and management.  Trying to explain the structure in general is easy for the staff, not complicated, because everyone gets how it all works together.  But if you tried to dig in and understand how The Cara Program operates, it is complex.

Is the distinction more clear? (or at least my thoughts on the distinction-I know people will nit-pick this apart!)

What does this have to do with Custom Software?

All of this complicated process translates into a messy software selection process.  Often one of the things immediately cut or never even considered during software selection is process mapping. We jump straight to the needs assessment. We get everyone together and start listing out everything the software has to do, without even understanding why we do it or how it could be done differently. We do it now, so the software has to do it.  Therefore, our needs are complicated and none of the solutions out there will meet our needs. We must need custom software....   oy,

I would ask yourself, if there are no solutions out there which do it exactly how you do it, are you doing it wrong? Do you need to keep doing it that way? If you changed, would your outcomes change? There are times when innovation and custom software is required, but those times are limited especially with the new platforms available today.

What I would suggest you do before simply stating your needs are complicated.
Documenting your processes before selecting new software gives you a chance to figure out how you work. But it also gives you a chance to ask why and to look for what is important versus what can change.  It is easier to simplify a process when you understand it, along with how it all works together.

Understanding your process and goals helps you understand what you should simplify and what is necessitates complexity can help avoid complications. This is not about software, it is about finding the most effective way to meet your mission.

The next post will focus on Custom Software = Custom Problems.

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

2 comments:

Jeff Bundy said...

Very nicely done. You speak from a position of experience -- LOTS of experience in this area. You also point out the "what" can change; I would also like to note that often it is also appropriate to consider the "who" can change. Looking forward to the next segments.

Steve Heye said...

Jeff, Thanks and glad you like it! This has been a post I have been thinking about for years. I totally agree about the "WHO" can change. Often so much of this is about the people and the culture, which could be a whole series of posts of their own. Maybe I will make it a bonus post to this series. I was trying to limit my scope to the software and how we use it, just to keep the post concise, but I guess I never said that.