Process vs. Technology - Getting the Right Combination

I think one of the all time great quotes as it relates to technology was from none other than Bill Gates: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency."  (No wonder he's the second richest person in the world).

I somewhat experienced the meaning of this quote firsthand as a volunteer BA for a local athletic organization that was in need of a website upgrade. We developed a solid business case that was approved by the Board of Directors. We sent out a survey to our user community, and received a high response rate.  We developed a complete set of user stories and use case/storyboards that were the outcome of three elicitation sessions with a focus group.  The web developer provided a beautiful site per exactly what was specified.  User acceptance testing was well defined, organized, and executed.  The site went live on time and within budget.  Everything seemed to be going perfect.  But once we went live, a very important feature (the mailing list) has been temporarily abandoned due to confusion about what process is needed to leverage it.

If everything seemed to go well and we did all of the right things, then what went wrong?

Looking back, I think what happened is that we went right from our business objectives to what we wanted the website to provide us from a solution standpoint.  If we could go back and do it all over again, I would probably have suggested that we first step back and ask a few simple (but important) questions:

1.What business policies should the system enforce?
2.What is our current business process, and what are its "pain-points"?
3.What improvements can we realistically make to this business process using new technology, but also given our constraints (i.e. timeline, money, people, etc.)?

Sometimes these questions aren't always easy to answer without first performing a level of due diligence.  That said, I think its fairly safe to say that in order to get the most out of automation, there are three elements that should be taken into consideration up front:

1.Business policy
2.Business process
3.Feasible solution capabilities

All three are important, and need to be in alignment with each other.

For example, is our business policy: “All parents of an athlete who is paid for the upcoming season are to receive important email communications from the club secretary”?  Or is this our business policy: “All families of an athlete who is paid for the upcoming season are to receive important email communications from the club secretary?" It’s important for us to define this, because each of these policies will very likely drive out two very different mailing lists - one with mostly two people per athlete, the other with primarily one.

Once we have our business policy in place, the next step would be to develop the business rules.  For example, we could state:

1.“All parents who would like to be added to the mailing list must first register with the website”
2.“All parents who would like to be added to the mailing list must first send in payment for the athlete"
3."All parents must not be subscribed to the mailing list without their knowledge by a third party"
4."All email address on the mailing list must be accurate and cannot contain typos"

Having this cohesive set of rules in place can then help us answer some leading questions. For example:

1.Who really needs to be on our mailing list?
2.Is there one type of mailing list, or are there multiple?
3.How frequently will these mailing list(s) need to be refreshed? (i.e. Once per season?  Once per calendar year?  Never - it just continues to grow, and we let registered users determine if/when they want to unsubscribe)?

The value of this exercise is that we can then begin to think about what could be handled by way of automation, and what our new process will look like.

Asking ourselves some additional questions can then help us further envision the solution scope:

1.Do we have (or can we implement) the processes that can leverage what we want from the solution?
2.Do we have the resources to implement and support the solution we are asking for?
3.Do we have the funding to pay for them? (Especially when weighed against other competing needs that might have more benefit to the organization as a whole).

For example, perhaps we could have integrated the website with a more sophisticated mailing list software that provides a "confirmed opt-in" or "double opt-in" (which automatically sends an e-mail message to the address and requests a response so the recipient agrees to be on the list). Additionally, users could have the ability to unsubscribe own their own whenever desired. But if we always need to perform business rule #2 above (regardless of the technical solution in place), then perhaps going through all the work (and spending the additional money) to implement a more sophisticated tool like this might be overkill.

So perhaps having a very simple mechanism like this might do the trick:

1.Website admin exports the entire list of registered users (at the end of the "open enrollment" period), and sends the list to the secretary
2.Secretary verifies registered parents vs. athletes that are paid for in the upcoming season
3.Secretary sends the verified list back to the website admin
4.Website admin uploads this filtered list into an email group on the back end

Additionally, if someone drops out of mid-season, the process might be as simple as sending a request to an unsubscribe inbox, and then this step is handled manually as a one-off.

Although this type of solution would probably not be feasible for a decent sized company that leverages an email marketing list with thousands of subscribers - it might work quite well for a school athletic team with a modest budget and only about 100 or so people who are on the email list per season.

Lesson Learned: Sometimes when business users state what they want, it isn't exactly what they need to accomplish their goals.  Likewise, sometimes as BA's we may assume that as requirements are elicited, that business users will understand and communicate all of the implications to their business process. To help us develop some common ground, it might be useful to first take the time to capture our business policies and rules, followed by an assessment of what processes changes make sense in light of the solution capabilities that are feasible.