When a nonprofit organization is beginning the process of doing a software implementation (such as a new website, or a new CRM or donation management product,) it is often unaware of the things that might underly whether such a project will succeed, how long it will take, and how much it will cost. Since nonprofits focus on their mission, and not software projects, that is an unknown to them, and understandably so.
In software development or implementation projects, this triangle (shown below) is often talked about. Software projects can be fast (that is, done quickly), done well, and/or cheap. But you only get to pick two of those. A project can be good, and cheap, but it won't be done quickly. It can be fast and cheap, but it won't be good. It can be fast, and good, but it won't be cheap. 
The truth is, in my experience in doing or observing dozens of nonprofit related projects over the years, most often, it's hard enough to get one of these. In general, "good" is the one that people want the most - they want a well-designed, user-friendly product, with lots of features that work together well. Maybe they even want to integrate that with another system.
And, of course, being nonprofits, they don't have a bankroll to spend on a project, so "cheap" is often an important goal. In my experience, these ("good" and "cheap") are probably the two that are the most difficult to get into the same project. "Good" - especially in the parlance of a nonprofit, means "easy to understand", "easy to use", "intuitive." And, unfortunately, those are always the kinds of things that take the most time, expertise, and cost to provide.
You've probably noticed that software projects are like construction projects. They are always late. I haven't yet figured out why this is. Sometimes, it is unrealistic expectations. But I've been doing this work for more than 10 years, and you'd think that by now, I'd have figured it out. These are my theories on what factors might be responsible:
- Identity Crisis - this is especially true for web design projects, but can also happen in other kinds of projects. The act of trying to figure out what an organization wants in a website design, or in a specific kind of functionality, leads to an examination of internal communication or business process, or thoughts about external perceptions, that become either paralyzing, or require a level of internal organizational process work that just takes time.
- Multi-Project Juggling - this is largely on the vendor side, but can also happen on the client side - trying to juggle mutliple projects, and deadlines, especially when Murphey's law hits, and several deadlines happen all at once. Something has to give.
- New Emerging Complexities - once a vendor actually sees the data, or the content, and realizes that there is more complexity than was imagined - the time it takes to figure out what that means for the project.
- Holidays - if a project spans the period between Thanksgiving and New Year's, expect not much to get done between those times. Really.
In my experience, the two biggest mistakes nonprofits make in terms of implementation projects are to underestimate how much they will cost (or, more accurately, underestimate how much functionality/quality they can get for their budget,) and underestimate how much time (and internal staff resources) they will take to accomplish. When you are planning your next project, keep this in mind.
*Michelle Murrain is a partner at OpenIssue, a firm that provides and delivers planning and implementation services in Open Source and SaaS-based CMS and CRM information management systems. She also blogs at the Zen and the Art of Nonprofit Technology.
You should follow Frogloop on Twitter.
COMMENTS