Cheap, Fast, and Good. Can Nonprofits have them All?
Friday, February 5, 2010 at 02:52PM | by Michelle Murrain 
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.
Receive monthly updates
13 Comments | by Share Article nptech
Reader Comments (13)
Another time delay factor that I want to add is that many nonprofit orgs work with people in need or in crisis, and so nonprofit staff can easily get pulled away from something like a web design project to put out a fire. Because a human in need should always come before software, of course. It's another challenge for our sector.
That said, it's been my experience that "identity crisis" is usually the rate limiting factor on projects. It's funny, once organizations file away their mission statements, they forget how to describe themselves publicly. In addition, web projects (which typically fall into two categories: communications or community building) expose the fact that many organizations haven't thought deeply about the conversation they want to have with the public, their funders or the communities they serve. This isn't an issue specific to not-for-profits, as many private sector organizations also grapple with this issue.
I think one of the keys to a managing a successful technology project is to understand that technology does not exist in a silo. Rather, technology is an enabler – it extends the capabilities and capacity of organizations. My suggestion for not-for-profits is to explicitly define/decide what you do and what you want to do. Once you've successfully accomplished this, you can then plan – with the help of your consultant – how technology can enable your efforts.
These are pointers for clients that my experience with the project really drove home:
* Always ask your questions. It helps the consultant you are working with get a sense of where you are in your process, and whether they have been sufficiently clear.
* Design is tough. Tell the designer what you are looking for and trust that they have the chops to answer those needs in their design. Then consider the way a design mockup does or does not address those needs.
* Be prepared to do a lot of in-project learning with your team. Staff buy-in takes time and is aided by shared ownership.
* Your other work doesn't stop because you're re-branding, or refreshing your website. Look for ways the new technology and the new way of framing and communicating the importance of your work can help you do that work better.
* Documentation is time consuming, no fun and absolutely critical. It doesn't start and stop with the consultant. As you continue to use your website, document your best practices either in a private section of the site, or in some other shared repository. The way you use your site will change, make sure you update your documentation - those are the breadcrumbs you'll need to keep yourself on track.
However, it continues to frustrate me that nonprofits believe they somehow get away with the 'Oh, we're only a lil ol' charity' routine and continue to thrive. Being a nonprofit organisation is not an excuse to be '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.' Private sector companies who are accountable to shareholders can't turn round at the end of a failed project and say 'Well, we went into it not really knowing what we wanted, how much it would cost, or how long it would take, so really it's a miracle we've got anything at all.' And if they did, the CEO would not be around for long!
Having said that, if you recognise that you're not aware of these factors, then at least you're heading in the right direction - a 'known unknown', as it were, rather than an 'unknown unknown'. However, if you then recruit a consultant / agency / freelancer / whoever to help deliver your project for you, because you're not experts in that field, you need to trust them to know what they're talking about and guide you through it based on their expertise. If you don't trust them, you haven't hired the right person.
And finally... if the project is stalling because internal resources are being pulled off to work on other things, one of two things is happening:
1. Your project doesn't have enough priority or buy-in at a high enough level to keep resources allocated to it. Either you need to get that buy-in and reprioritise internal work, or accept that it's not the highest priority for your organisation right now and adjust your expectations
2. You don't have the right people working on the project. A fundraising officer, communications director, or media assistant isn't necessarily a project manager - and just because they might end up managing the site, doesn't mean they should be managing the implementation of the site
No nonprofit, for-profit, vendor, etc. can expect the consultant or hired party to do all of the work. You simply cannot expect to sign a contract, go away for X months and return to a complete project. With any data project the staff investment can often match the time spent by the consultant. Any consultant who promises minimum time investment from the client during a data migration project is misleading.
I've seen far too many projects fail or nearly fail because the management at the npo did not allocate and anticipate the appropriate time investment from staff.
@Walt - "Standing on the shoulders of giants" is actually what I do everyday using open source software (as well as donated Salesforce, which is standing on giants of a different sort), and I agree that it makes a huge difference in terms of the quality of software and functionality that a nonprofit can get. But the lack of license or acquisition fees doesn't mean a project will be cheap - there is configuration, customization, design, data or content migration - that's why we call those products "Free as in Kittens."
@Kelly - thanks for these useful pointers for organizations.
Opensource has the right philosophy, but it needs to be applied at a higher level:
The best way to get something fast, cheap and good is to find something similar to what you need and ask the allied organization that's already done it. I see lots of small nonprofits that are very similar to each other with very similar needs, spending far more on tech than is needed, failing to pool resources and work together.
I wonder if funders could help the process, asking nonprofits to a) ask other nonprofits for advice before starting, b) make a stipulation of the grant that the recipient be open to sharing. Maybe NTen or somesuch could have a list of mentor-organizations?