Archive of Philosophy

How To Carry All Those Nuts

ID: 2016-08-25.1 by tgroden August 25, 2016 Philosophy, Process 0 Comments

My work in data system consolidation is very rewarding; I greatly enjoy the challenges that our clients bring us, and love working with my team at OpenIssue to solve problems for those clients.

A few years back we established a pro bono practice and a series of low cost “kick start” conversion services (using a fixed fee model) and have treated those projects as some of our most important work because they are most constrained, and often the clients are most in need. The ones we love are referral, and fast. The ones we fear start with an RFP. We understand an RFP when its policy driven, but that is not often the case in the small nonprofit world.

We recently reviewed an 18 page detailed specification which described a very complex tool set and information system likely to cost at least $40k to implement and another $10k/year to maintain (at least!). The 2 hours I spent with the prospective client went into the document, and helping them understand their document’s content and its translation into real-world software options.

What they really needed instead was a $5k, two week “quick start”.

We understand (and see quite often) the incentive for a small nonprofit to write a big spec to allow for catching as much as possible (from funders, from software, etc). Low or no-cost systems like Salesforce™ allow groups to move quickly into new systems without the former complexities of server and installation. With the ease of communication with other users and ecosystems of advisors and consultants, why are these groups not simply taking the free stuff? Vendors (like us) will quote (and build) the world for a client – if that is what the client asks for! So is the RFP helping then?

Its tough to get folks to:

See the value in simplicity and speed of transition with SaaS tools
Realize data conversion is complex and should be done by experts

In search of council, I turned to a friend (we’ll call her “S”) and client who was familiar with the RFP process and the prospect’s situation, and I asked “How can we help these folks go after more realistic, and sensible goals?” The reply we got was:

Watching her the and struggle with figuring out systems, reminds me how much time is wasted, and stress is caused for people trying to do awesome work. And how regularly non-profit leaders have to make game changing decisions about stuff they don’t have capacity to understand.

Keep doing what you are doing – providing authentic, nonpartisan (ha!), trustworthy leadership in this space. I’ll chew on how to help the little orgs better, but I think you are already well down the path.

This is officially a “favorite” email ever. Thank you again “S”, and to all our great clients and ecosystem partners and allies.

Here is the prescription I wish I could write for all nonprofits and higher ed groups:

Consider an advisor who has made this type of transition a few times. If we can’t help you – we can find you a few folks who can.
Lean on incumbent tools if they can be improved – as an alternative to switching.
Be honest about your operational needs from a software system (rolodex, lists, email, donations).
Consider the Agile/Iterative model – some of these people have good advice on that:
- Guy Kawasaki -Iterations and fast/frequent work product to garner feedback is more valuable than the “perfect product” (which never appears…)
- Eric Ries – The idea of the “Lean Startup” and “Validated Learning” further supports iterations, and small steps in the right direction – not plans that map the whole journey.
- David Kelley, IDEO – Kelley believes that how quickly you create an initial prototype is directly proportional to how successful a product will be. Essentially, given a set project deadline, the earlier you invite feedback, the more chances you have to revise and improve. He calls this “enlightened trial and error.” (citation source: http://ecorner.stanford.edu/videos/686/Design-as-an-Iterative-Process)

“All models are wrong, but some are useful.” *

ID: 2016-08-25.2 by tgroden July 27, 2015 Philosophy 0 Comments

* Quote from George E. P. Box

A few weeks ago I got a cold call on a Saturday morning (on my cell phone?!) from a guy in Rome (yeah, Italy) in a heck of a hurry to convert an Italian Monastery from Blackbaud’s Raiser’s Edge ™ to Salesforce ™.

He explained that a few volunteers had helped them with the initial conversion but that the data is not completely moved yet, and it does not look right. I am writing this post to try and present this client (not an atypical one may I add) a sort of “way-out” of this corner we hear about quite often.

This conversation is typically led by these questions from the prospect:

Have you done this before?
How long does it take?
How much does it cost?

Our response is always the same (these days); that we have done hundreds of conversions to and from these systems, and that depending on the variables the costs would fit into the following range:

Time range of: 3 weeks to 14 weeks – the average is 8 weeks.
Price range of: $8k to $100k – the average is $20k.

This was not well received. People in this situation want fast action and cannot understand (it seems) why this is going to be so difficult, or take so long. His primary objection was that if we had done so many of these, then why can’t we pinpoint the costs more accurately?

Cutting to the chase; try this model if you (or a loved one) is in this type of pickle:

Problem Story:

Small business moving from one fundraising system to another
Short timeline and small budget
Person driving the transition is neither the primary user nor a conversion specialist

Best Path Forward:

Invest in your incumbent system before jumping, like more/better training, advanced configuration, and possibly enhancements (send a note to our friend Bill Connors, and maybe a plane ticket too — Italy is nice for Westerners to visit ey?)
If that is not fruitful;
- Spend a little money to get a vendor selector who knows the options. This will save you 3-5 weeks of calendar time, 20 or so hours of asking questions that are already well known in the ecosystem, and allow your business to run without interruptions (call our friend Robert Weiner please).
- Allocate 8-10 weeks for the conversion.
- Involve the primary user in the conversion process. Have that person drive the effort if possible — this will save you time and money!
- When you shop for your new system, use examples that are real to test the fit with the new system, like:
  - Walk through adding 10 records – manually. If this is too much for you to do – then you will get surprises later that you will regret (see blog post on “Top 10”).
  - Use that manually entered data to view reports – live – with your sales rep – to get a feel for what you are buying (test drive ey?!)
  - Measure/Assess time and energy costs of this transition – talk it over with your team.
  - Be honest with management; if a new system is a way to avoid proper training and discipline – then expect a replay of this in 18-36 months.
  - Assume you will lose some data, time and possibly people in the change. Hold the project to a realistic pace and measure of success – many projects get bogged down by unimportant concerns; getting it done and on time is the priority!

In our experience, the “fast/urgent conversion” prospects are typically not being championed by system users – they are being led by cost cutting folks. That is going to make the whole thing much harder. The transition needs to have system users involved, or when you are “all done”, user adoption will be difficult.

I later found out that an ecosystem ally had given this prospect my cell phone about 3 weeks back, so it took this guy 3 weeks to hunt around, see that things cost too much, then call me on a Saturday morning to get it done in a rush.

This model (approach to a conversion) works well – and often slows things down; I suppose I am not going to get much traction on this post… 🙂

Layers of Data

ID: 2014-11-16.1 by tgroden Philosophy 0 Comments

Most people who use data on a daily basis just think of data as it relates to their application or software (such as “Contact or Leads”, or “Pipeline Data” or “Giving History”), but from the perspective of consultants consolidating or integrating systems, we have to break it down into patterns and flows, and work inside of (or sometimes establish for the first time) the database of record (DBoR) model to ensure data integrity and business continuity.

We have developed, and consistently leaned-on, an overly simplified lens through which to view all (yes, all/any, seriously) data in all systems; It is our “6 layer” model. It helps us compartmentalize all of the data in any project to allow for pattern identification and integration architecture approaches. Often our clients ask us: “can you glue this to that – then make it report on this”. This approach typically gets them 2 or more vendor products doing as well as they can – but often does not get the client a best of breed integration design. Best of breed does not need to mean expensive, either. More often than not we see out of the box systems (and their recommended approaches for implementation) as the most-expensive approach.

To help our clients consider (and create) their options, we break it all down into these 6 layers:

This 6 layer system is not meant to be a prescription for information consumption, it is meant to help data consolidation designers and teams like OpenIssue separate the “major flows” of data present in all information systems. We always accompany the 6 layer model with the ETA breakdown, as follows:

Entities
Transactions
Attributes

Again, this is not meant to tell anyone “about” their data or information, it is meant to enable consolidation and integration teams to handle the data with all the constraints software and integration tools will force upon clients. By breaking things into layers and types, you can sequence your project better, and also manage your prioritization and budgets.

These approaches and tools help us manage timelines, budgets, and bring options to our clients.

Have I mentioned we love data and transition management? Thanks for reading..

Technology Myths

ID: 2015-03-16.1 by tgroden March 16, 2015 Philosophy 0 Comments

A lot of the work

I do with my colleagues at OpenIssue involves informing people about their technology options and different approaches to adopting these options. Through this process, we discover that clients often have certain “beliefs” or ideas about technology.

Over the years, we have found the following short list of ideas are prevalent in the client (and consulting) ecosystem. When clients can be informed that these are, in fact, technology myths rather than truths, we can help them avoid putting time and money into no-win pathways:

Myth 1: You can have a single system.

There is no such thing as a single system in information processing architectures, especially if it is cloud-based. Many pieces come together to make a user experience possible.

Our work calls on us to architect systems and the connections between them. While not all systems can work together well, in the circumstances they can, we favor improved communication over system consolidation.

Picture a forest and all the things involved that make it function – the trees, the low ground cover in between, the squirrels that spread acorns so that more trees can grow, etc.

It’s important to pay special attention to this myth. When this line of thinking is present in a project dynamic, decision makers can be misdirected towards a false simplicity which is, unfortunately, often supported by unfulfilled vendor promises. This paves the way for becoming a “Beta Tester” (or even Alpha!), which can interrupt your operations and the work that your technology is intended to support. We like to balance customization and new features with business continuity and opportunity cost analysis.

Myth 2: Project requirements are complete.

Project and system requirements are never “finished” per se, nor can they ever be fully “correct”. They are always drafts until the team really dives into the project. At their best, project requirements provide a solid starting point for what ultimately becomes an evolving business negotiation, with a maturing understanding of the project’s goals and outcomes.

We always make room for both reality and change in the execution of a statement of work. It’s something like crossing a narrow rope bridge over a high ravine: I’ll tend to watch each step very closely, and never lose sight of the other side nor the way back.

Myth 3: Budgets and timelines can be fixed.

Timelines and budgets are critical for any project. However, most project timelines and budgets do not stand the test of external change. The best a project team can do is to both have a plan, and also expect it to change.

Just like when you plan to take a long walk on what starts out to be a gorgeous day, it’s important to bring a rain jacket or layers, because the weather can easily fluctuate.

Flexibility and change management can be a difficult when consultants produce “not to exceed” (NTE) agreements in this dynamic environment. NTE agreements offer “fixed costs” and can wrest control out of your hands, and into the hands of the vendor if not implemented inside of an effective communication model.

Compromise should be the outcome. The key here is to remain actively involved in which compromises are made, when they are accepted, and how they are implemented.

At OpenIssue, we employ these and other mitigation strategies to manage this dynamic of changing timelines and budgets: weekly project check-ins, a well-defined escalation plan, and burn rate reporting. Both client and implementation teams need to be at the table and communicating regularly for this to go smoothly.

Our Acronym List

ID: 2014-09-01.1 by tgroden September 01, 2014 Philosophy, Technical 0 Comments

If you want to communicate effectively, it’s important to be aware of your habits. My engineering team and I often speak and write in acronyms (you know…TLAs) and it’s not good practice, at least not outside of a conversation between propeller heads. While they convey specific meaning to us, when used outside of our team, acronyms without definition can negate their potential to make our communication easier to understand.

With that in mind, we set up an official team TLA list and wanted to share it here. Some of these acronyms are truly inspired, others are obscure, to say the least. Send us an email with any comments or additions to this list and we will fold them into our secret language.