Estate Attorney’s on the Phone… Now What?

We all have gotten those calls to our offices – the attorney letting us know our organization is a named beneficiary of someone’s estate, now in probate.  It is a time of profound gratitude, knowing someone has included us in their final acts of generosity.  And it is also often the only time to get some important information from the probate attorney.  Once they have notified our organization in the most basic way, they move on, and getting a return phone call can be tricky.  And then we wait in the dark for a check to arrive, often a year or more later.

So, to make the most of that call, I find it helpful to have a quick checklist list of questions pre-printed and in a handy spot.  Here are the questions I always ask:

“A Room with a View… of Everything” Giving power users tools to relate sets of data across the organization with JCA Answers for The Raiser’s Edge™

A few days ago I wrote about the creative use of JCA Answers by one of our clients, National CASA. Another clever use of Answers for The Raiser’s Edge comes from the Perkins School for the Blind in Boston. Like National CASA, Perkins uses The Raiser’s Edge not only for fundraising, but as a complete CRM to house additional education-related information. Raiser’s Edge has powerful and flexible query tools in RE:Query and RE:Export, and for most users, these modules satisfy their ad hoc query needs. But one group of more data-savvy users finds these tools limiting in their ad hoc report writing needs. These users need all of the fields in Raiser’s Edge, not just most of them.

“Easy as Google” – How one organization got key info out of RE and into users’ hands

One of the best parts of my job is taking time out to chat with the users of JCA Answers. We obviously keep in touch during the implementation process and subsequent support and upgrade conversations, but we also make it a point to check in from time to time, just to see how things are going. These calls typically result in suggestions for future functionality and reviews of past projects. Along the way, I often hear about interesting ways that organizations are using Answers. I am frequently surprised to hear about usages we’d never really considered when we were developing Answers. Over the next few days I thought I’d share two such examples of JCA Answers for The Raiser’s Edge users who have leveraged Answers in unique ways for their businesses.

What To Do When Your Software Is Purchased by Another Vendor

First, how well does the software currently serve your organization’s needs? Is this a system that you’ve been unhappy with for years or have outgrown significantly? Or is it a pretty serviceable system, meeting your business needs at the current time? Either way, it’s time to take a critical look at the system and defining what your needs are (or soon will be) to see if there’s a gap.

Why Projects Fail, Part 3

This is the third and final installment of Why Projects Fail. So far, we’ve covered two important points. First, sometimes projects fail simply because they are hard and people underestimate them. You need to assume a level of difficulty when entering a project that affects an entire organization. Second: plan. Many projects fail because the organization didn’t invest in a plan that was thorough and realistic. Optimism is great, but don’t let it get in the way of making realistic decisions. The remaining reasons that projects fail include:

Project failure is expected
It’s pretty well accepted that most projects fail.  You can find studies that estimate 30% to 80% of projects fail. Isn’t that incredible? Is that okay? Would you be okay if your organization failed at fulfilling its mission 80% of the time?  Let’s face it, this project is part of your mission. Geneca, a software consulting firm, surveyed 600 business and IT executives as part of a study of why project teams struggle. You can guess the outcome based on the name of the report: “Doomed from the start.”  Geneca’s finding was that “75% of respondents admit that their projects are either always or usually doomed right from the start.”

Why Projects Fail, Part 2

Last time, we ended with the question: “Why don’t people plan enough?” For one, planning requires a healthy dose of pessimism, and who likes a pessimist? I’ve experienced this situation many times.  The project team is sitting around the table planning what you are going to accomplish and how.  Everyone is excited and has high expectations for the project.  The team discusses the project objectives: “Fundraisers have instant access to reports and solicitation plans,” “we have a single source of information – the website, ticketing system, finance system, call center, registrar’s system (you name it), are all integrated,” “a policy and procedure manual is actively maintained and used by staff.”  These are all great objectives.  The next step is to talk about how the team will accomplish them.  You create deliverables – the stuff the project will create – to fulfill objectives.

Let’s use the policy manual as an example. A good manual takes time. We estimate how long it will take and then assign resources (i.e., the people that will do it). Often, these resources are client staff. Sally, the head of Development Operations (she is great and really excited about implementing the new system and totally gets the importance of the manual) is the obvious resource for this and she wants to do it. She will need to invest 100 hours over the life of the year-long project. She understands and is on board. But Sally has a fulltime job already as the DevOps Director. 

Why Projects Fail, Part 1

At JCA, we do project work for nonprofit organizations.  We’ve been doing it for more than 20 years for hundreds of nonprofit organizations.  I’ve been doing this work personally with JCA for the last 11 years.  I’ve been involved in a lot of projects, both as a participant and a leader.  I’ve seen success and I’ve seen failure (is that a James Taylor song?).  Every project teaches me something about how to make them succeed, but I must admit, I’ve learned more from the failures than from the successes.  As our COO Steve Birnbaum says, “A barrel of ‘attaboys!’ don’t add up to one ’aw crap.’”

Talking about why projects fail is nothing new.  There are many articles and blogs on the topic, most of which say the same basic thing, and I encourage you to read them.  Most of them are right, and I may repeat a few of those things here.  My goal is to share with you, over the course of this three-part series, what I’ve learned running projects at nonprofits across the country.  There are so many reasons a project might fail, and it’s never the same one for all, but here are some things to think about.

The Price is Right! Brought to you by Business Intelligence

Today: a brief synopsis of airline flights, breakfast cereals, scalpers, non-profits, and how business intelligence is, of course, the answer.

Pricing.  We are confronted with pricing all the time — making a series of value judgments on the relative worth of the item or service in question. Twenty times a day or more, our brain decides “that is a fair price for a TV” or “that’s pretty expensive for a bagel” or “gee, what a deal on a lawnmower!” 

Some industries seem to have more predictable pricing than others. On one hand, you have something like breakfast cereal, with prices that move based on inflation, commodities and oil prices, but are quite predictable. On the other end of the scale are airline tickets, which appear to be based on a complex matrix of energy prices, carrier competition, holiday seasons, sunspots and unified string theory.  Still, whether it is Corn Flakes or a trip to Maui, you see the price and make a value decision on whether to make the purchase.

Until recently, in the non-profit  ticketing business, pricing has hung closer to the breakfast cereal side of the scale – setting prices once a year, typically by tacking a couple of bucks onto last year’s prices.  Historically, non-profits have seemingly assumed that the value of their art doesn’t fluctuate very much. 

“T-Stats Saved My Weekend” and other True Stories

One of JCA’s most successful Business Intelligence initiatives has been T-Stats – the BI tool that JCA developed for the Tessitura Arts Enterprise software.  With today’s blog I thought I’d start by sharing a story from one of our T-Stats users.

It was Friday afternoon, the end of a long week at the Yale Repertory Theatre, and Janna Ellis, Associate Director of Audience Services, was staring down a pile of report requests to help her company chart a new pricing strategy for its season subscriptions.  Anticipating a weekend spent at her desk, she had already warned her husband and daughter that they might be on their own for the weekend.  Looking at the list of analysis tasks in front of her, she expected that she would be creating countless lists of data, running myriad standard reports, exporting to Excel, and then doing further massaging and manual calculating.

But first – she opened T-Stats.

Your Biggest Software Implementation Risk? It May Not Be What You Think.

My friend called me in a panic. “Our kitchen is half-gutted, and it’s a disaster! Our renovation is going horribly – they put in the wood flooring crooked, they built a wall where we wanted a window, nothing works right, and we’re scheduled to host my daughter’s wedding in two weeks! And we’re contractually obligated to pay them even though this is a mess! But I am pretty happy that our appliances all work really well!”

“Oh, my. How did you pick the firm for the renovation?” I asked.

“We chose the firm that manufactured our appliances. We very carefully considered all the options for appliances, and chose this one. They make amazing equipment! So we didn’t consider anyone else for the renovation project.”

OK, so in real life no one would assume an appliance manufacturer could renovate their kitchen. Yet I am always surprised to find that many organizations that work carefully to consider software options for their mission-critical software system default to using the vendor for implementation services.

And yet, the truth of the matter is that vendors who make great software may or may not have services that are right for your organization. Someone who builds a great appliance doesn’t necessarily know how to stain hardwood. The talent required for developing great software is quite different from the skills required for providing professional services.