The Work Is Never Done
“And I thought that was a really universal way of entering an understanding about our country. If we think of our country as being like an old house and we know that the work is never done, and we wouldn’t assume that the work was ever done. You wouldn’t assume that one law and we’re done. One election and we’re done. And why do we think that about an entity as big as our country when we, the owners of old houses, know that is never going to happen with an old house?”
Isabel Wilkerson, On Being interview
Author’s Note: Isabel Wilkerson is discussing the most important area where we cannot “set and forget” - the laws, policies, institutions, and culture of American society. I agree with her 100%. And here, I’m using the same metaphor to talk about something a bit less grand, but still important.
I was recently asked how much time/what work it would take to get our nonprofit tech project - the design, build, and user-adoption of a new tech system - to the finish line (with the assumption that after that imaginary point we would not need to work on it any further). There is no line like that. My answer was that what it would take to set us up for success was a long-term plan for in-house capacity to manage and enhance the data & technology supporting the organization’s mission.
Certainly others have said this before but I’m here to say it again: the era of the “set it and forget it” mantra for technology is in the past. I’d like to argue that there exists not one single technology-supported process in the nonprofit world that stays so exactly the same for a significant amount of time. Something breaks, business process changes, technology changes, there are new opportunities, programming changes, a new grant comes in with a new focus, new staff members bring new perspectives and ideas, the constituents and communities we serve are changing…
The replacement that I have used most often to “set it and forget it” is “maintain and enhance.” More recently I’ve wanted to add another word to the phrase, making it “maintain, enhance, pivot.”
It isn’t just tech-driven process automations that can fall under the sway of “set it and forget it” in the nonprofit data & tech world. Our approaches and philosophies don’t work in the same formats forever. Something that I have noticed not serving me as well as time marches on is the classic 5-step approach to technology development at nonprofits: Discovery, Requirements, Design, Build, Launch. This approach might be still be valid in some cases, but it is in need of an upgrade.
I followed this mantra for many years. I still do some version of it. But it is too often used as a finite tool for “launching” something new, and then getting the hell out of dodge (for consultants) or for considering the work done and not keeping up with monitoring and continually testing and improving on the thing that was launched.
Discovery is just a weird term - we can’t discover all there is to know in a proscribed timeframe and then take that knowledge as unchanging and unchanged by external factors as time goes on. We can do our best to LEARN as much as possible at the beginning, but that learning really needs to be a continued emphasis ongoing, in perpetuity. And discovery as a term sounds paternalistic and colonial. Whether consultants or an in-house tech team is gathering information, it is not discovering something “new” - at best it is learning to speak the language and understand the culture of a user, team, and/or an organization and to form deep and lasting relationships and trust as partners in developing technology tools together.
While it is comforting and helpful to have a to-do list to which we can assign time and effort, prioritize, and gain satisfaction in checking off items from, the word “requirements” sounds so cold and formal. And it sounds so set in stone: required! It really refers to one thing - a spreadsheet or JIRA or Trello board or similar of items that have been decided to encompass the tech project and their prioritization. It helps us all agree on what work is happening. It’s a project plan! And what project plan have YOU been part of that hasn’t had changes made to it over the course of the project? Flexibility and openness to change needs to be part of project planning and every stage. But what about scope creep, you ask? Our project plans should be more like the agile methodology - when something new comes to the light that could be made part of the project plan, it is evaluated and prioritized, and (importantly) other work is swapped out. We don’t pile more and more tasks on top of an already full project - we manage to the amount of work we can do with current capacity.
I don’t have a problem with the design step. I like it. Leave it in there as is. We have to dream it and visualize it in order to bring it into reality.
Sandwiching “build” in-between design and launch just totally simplifies what “building” means for a tech project. The build is not finished when the thing you are building becomes “live” or users start using it. That is the middle of a circular process. Even if you have explicitly stated that your project is “waterfall” and you are releasing a lot all at once - that is STILL in the middle of the circular process. Build, Launch, Use, Learn, Build more, Rinse, Repeat. Building is just never done.
Launching something - what does that mean? That we start using something with real data, real users, real opportunities, real consequences. When something is launch is when we need the MOST attention on it, the most love for it. Because no matter how hard you worked on it, it isn’t done. We’ll find issues and bugs, learn things that we didn’t know or realize before. Users will need ongoing training and support and they need it the most right at the beginning. And there is no planning for timing - the day after launch we might get a huge new grant that changes the direction of the organization, and the technology will need to change to respond to that. It happens!
Like Isabel Wilkerson said - the “work is never done, and we [shouldn’t] assume that the work [is] ever done.”
This is why all nonprofits need long-term capacity support for their data & technology work. There can be defined projects, and different people or consulting firms can always come in to help with these. However, this is additive, not a substitute for non-project based support externally or in-house roles dedicated to the work. This is not a discussion, it is a reality. Because with data & tech, our work is never done, and we should not assume it every will be.
