July 25

It’s Time To Revamp The NTEN Staffing Survey

cover_techstaffingreport_2014_smallNTEN‘s annual Nonprofit IT Staffing survey is out, you can go here to download it.  It’s free! As with prior years, the report structures it’s findings around the self-reported technology adoption level of the participants, as follows:

  • Stuggling orgs have failing technology and no money to invest in getting it stabilized. They have little or no IT staff.
  • Functioning orgs have a network in place and running, but use tech simply as infrastructure, with little or no strategic input.
  • Operating nonprofits have tech and policies for it’s use in place, and they gather input from tech staff and consultants before making technology purchasing and planning decisions.
  • Leading NPOs integrate technology planning with general strategic planning and are innovative in their use of tech.

The key metrics discussed in the report are the IT staff to general staff ratio and the IT budget as percentage of total budget.  The IT->general staff metric is one to thirty, which matches all of the best information I have on this metric at nonprofits, which I’ve pulled from CIO4Good and NetHope surveys.

On budgets, an average of 3% of budget to IT is also normal for NPOs.  But what’s disturbing in the report is that the ratio was higher for smaller orgs and lower for larger, who averaged 1.6% or 1.7%. In small orgs, what that’s saying is that computers, as infrastructure, take up a high percentage of the slim budget.  But it says that larger orgs are under-funding tech.  Per Gartner, the cross-industry average is 3.3% of budget.  For professional services, healthcare and education — industries that  are somewhat analogous to nonprofits — it’s over 4%.  The reasons why we under-spend are well-known and better ranted about by Dan Palotta than myself, but it’s obvious that, in 2014, we are undermining our efforts if we are spending less than half of what a for profit would on technology.

What excites me most about this year’s report is what is not in it: a salary chart. All of the prior reports have averaged out the IT salary info reported and presented it in a chart, usually by region.  But the survey doesn’t collect sufficiently detailed or substantial salary info, so the charts have traditionally suffered from under-reporting and averaging that results in misleading numbers.  I was spitting mad last year when the report listed a Northeastern Sysadmin salary at $50k.  Market is $80, and the odds that a nonprofit will get somebody talented and committed for 63% of market are slim.  Here’s my full take on the cost of dramatically underpaying nonprofit staff. NTEN shouldn’t be publishing salary info that technophobic CEOs will use as evidence of market unless the data is truly representative.

I would love it if NTEN would take this survey a little deeper and try and use it to highlight the ramifications of our IT staffing and budgeting choices.  Using the stumble, crawl, walk, run scale that they’ve established, we could gleam some real insight by checking other statistics against those buckets. Here are some metrics I’d like to see:

  • Average days each year that key IT staff positions are vacant. This would speak to one of the key dangers in underpaying IT staff.
  • Percentage of IT budget for consulting. Do leading orgs spend more or less than trailing? How much bang do we get for that buck?
  • In-house IT Staff vs outsourced IT management.  It would be interesting to see where on the struggling to leading scale NPOs that outsource IT fall.
  • Percentage of credentialed vs “accidental” techs. I want some data to back up my claim that accidental techies are often better for NPOs than people with lots of IT experience.
  • Who does the lead IT Person report to? How many leading orgs have IT reporting to Finance versus the CEO?

What type of IT staffing metrics would help you make good decisions about how to run your nonprofit? What would help you make a good case for salaries, staffing or external resources to your boss? I want a report from NTEN that does more than just tells me the state of nonprofit IT — that’s old, sad news.  I want one that gives me data that I can use to improve it.

 

July 11

The Future Of Technology

Jean_Dodal_Tarot_trump_01…is the name of the track that I am co-facilitating at NTEN’s Leading Change Summit. I’m a late addition, there to support Tracy Kronzak and Tanya Tarr. Unlike the popular Nonprofit Technology Conference, LCS (not to be confused with LSC, as the company I work for is commonly called, or LSC, my wife’s initials) is a smaller, more focused affair with three tracks: Impact Leadership, Digital Strategy, and The Future of Technology. The expectation is that attendees will pick a track and stick with it.  Nine hours of interactive sessions on each topic will be followed by a day spent at the Idea Accelerator, a workshop designed to jump-start each attendee’s work in their areas. I’m flattered that they asked me to help out, and excited about what we can do to help resource and energize emerging nptech leaders at this event.

The future of technology is also something that I think about often (hey, I’m paid to!) Both in terms of what’s coming, and how we (LSC and the nonprofit sector) are going to adapt to it. Here are some of the ideas that I’m bringing to LCS this fall:

  • At a tactical level, no surprise, the future is in the cloud; it’s mobile; it’s software as a service and apps, not server rooms and applications.
  • The current gap between enterprise and personal software is going to go away, and “bring your own app” is going to be the computing norm.
  • Software evaluation will look more at interoperability, mobile, and user interface than advanced functionality.  In a world where staff are more independent in their software use, with less standardization, usability will trump sophistication.  We’ll expect less of our software, but we’ll expect to use it without any training.
  • We’ll expect the same access to information and ability to work with it from every location and every device. There will still be desktop computers, and they’ll have more sophisticated software, but there will be less people using them.
  • A big step will be coming within a year or two, when mobile manufacturers solve the input problem. Today, it’s difficult to do serious content creation on mobile devices, due primarily to the clumsiness of the keyboards and, also, the small screens. They will come up with something creative to address this.
  • IT staffing requirements will change.  And they’ll change dramatically.  But here’s what won’t happen: the percentage of technology labor won’t be reduced.  The type of work will change, and the distribution of tech responsibility will be spread out, but there will still be a high demand for technology expertise.
  • The lines between individual networks will fade. We’ll do business on shared platforms like Salesforce, Box, and {insert your favorite social media platform here}.  Sharing content with external partners and constituents will be far simpler. One network, pervasive computing, no more firewalls (well, not literally — security is still a huge thing that needs to be managed).

This all sounds good! Less IT controlling what you can and can’t do. Consumerization demystifying technology and making it more usable.  No more need to toss around acronyms like “VPN.”

Of course, long after this future arrives, many nonprofits will still be doing things the old-fashioned ways.  Adapting to and adopting these new technologies will require some changes in our organizational cultures.  If technology is going to become less of a specialty and more of a commodity, then technical competency and comfort using new tools need to be common attributes of every employee. Here are the stereotypes that must go away today:

  1. The technophobic executive. It is no longer allowable to say you are qualified to lead an organization or a department if you aren’t comfortable thinking about how technology supports your work.  It disqualifies you.
  2. The control freak techie.  They will fight the adoption of consumer technology with tooth and claw, and use the potential security risks to justify their approach. Well, yes, security is a real concern.  But the risk of data breaches has to be balanced against the lost business opportunities we face when we restrict all technology innovation. I blogged about that here.
  3. The paper-pushing staffer. All staff should have basic data management skills; enough to use a spreadsheet to analyze information and understand when the spreadsheet won’t work as well as a database would.
  4. Silos, big and small. The key benefit of our tech future is the ability to collaborate, both inside our company walls and out. So data needs to be public by default; secured only when necessary.  Policy and planning has to cross department lines.
  5. The “technology as savior” trope. Technology can’t solve your problems.  You can solve your problems, and technology can facilitate your solution. It needs to be understood that big technology implementations have to be preceded by business process analysis.  Otherwise, you’re simply automating bad or outdated processes.

I’m looking forward to the future, and I can’t wait to dive into these ideas and more about how we use tech to enhance our operations, collaborate with our community and constituents, and change the world for the better.   Does this all sound right to you? What have I got wrong, and what have I missed?

June 30

Career Management In The Social Media Era

Boy! I sure did a good day's work today!

Picture: National Archives and Records Administration

If you believe that your current job is your last job — the one that you will retire from — raise your hand.  You can stop reading.

Now that those two people are gone, let’s talk about managing our careers. Because its a whole new discipline these days.

Gone are the days when submitting a resume was sufficient.  Good jobs go to people who are referred in, not to those with no one to vouch for them. Per the ERE recruiter network, between 28% and 40% of all positions in 2012 were given to candidates that were referred in, but only 7% of all candidates were referrals. That 7% had a serious edge on the competition.

Earlier this year, Google announced that they were changing their hiring criteria, giving GPAs and college degrees somewhat lower priority and focusing more on prior accomplishments and the strength of a candidate’s social network.  This is a smart move.  College costs average to $92,000 for a four-year degree. Google is changing their criteria so that they won’t miss out on hiring the perfectly brilliant people who aren’t interested in amassing that level of debt.

So what does that mean for you and me, the people who aren’t likely in the job that we will retire at? My take is that career management is something that you can’t afford to not be doing, no matter how happy you are at your current gig.  And that it involves much more than just identifying what you want to do and who you’d like to work for.  I’m highly satisfied with my current job, and I have no concerns that I’ll be leaving  it anytime soon. But I never stop managing my career and preparing for the next gig. Here are some of the key things I do:

  • Keep my network strong, and make a point to connect with people whose work supports missions that are important to me.
  • Network with the people in my sector (nptech). I regularly attend conferences and events, and I make a point of introducing myself to new people.  I’m active in forums and discussion groups. Like any good geek, this type of social behavior isn’t something that came naturally to me, but I’ve developed it.
  • Speak, write, blog, tweet. I generously share my expertise. I don’t consider it enough for people to know my name; I want them to associate my name with talent and experience at the things I want to do for a living.
  • Mentor and advocate for my network. Help former employees and colleagues in nptech get jobs.  Freely offer advice (like this!). ID resources that will help people with their careers.
  • Connect to the people that I network with, primarily on LinkedIn. This is how I’m going to be able to reach out to the people who can help me with my next gig.
  • Keep my LinkedIn profile/resume current, adding accomplishments as I achieve them.
  • Stay in touch with recruiters even if I’m turning them down. I always ask if I can pass on the opportunity to others, and I sometimes connect with them on LinkedIn, particularly if they specialize in nptech placement.

As I’ve blogged before, I’m picky as hell about the jobs I’ll take. They have to be as good as my current job — CIO at an organization with a killer mission, great data management challenges, and a CEO that I report directly to who gets what technology should be doing for us. The tactics above played a significant part in my actually landing my current (dream) job.

So this is why you need to start securing your next position today, no matter how happily employed and content you are. Job hunting isn’t an activity that you do when you’re between jobs or looking for a change.  It’s the behavior that you engage in every day; the extra-curricular activities that you prioritize, and the community that you engage with.

June 18

Telecommuting Is About More Than Just The Technology

We’ve hit the golden age of telework, with myriad options to work remotely from a broadband-connected home, a hotel, or a cafe on a mobile device. The explosion of cloud and mobile technologies makes our actual location the least important aspect of connecting with our applications and data. And there are more and more reasons to support working remotely. Per Reuters, the state of commuting is a “virtual horror show”, with the average commute costing the working poor six percent of their income. It’s three percent for more wealthy Americans. And long commutes have negative impacts on health and stress levels. Add to this the potential cost savings if your headquarters doesn’t require an office or cubicle for every employee. For small NPOs, do you even really need an office? Plus, we can now hire people based on their absolute suitability to the job without requiring them to relocate. It’s all good, right?

Well, yes, if it’s done correctly.  And a good remote work culture requires more than seamless technology. Supervisors need to know how to engage with remote employees, management needs to know how to be inclusive, and the workers themselves need to know how to maintain relationships without the day to day exposure to their colleagues.  Moving to a telework culture requires planning and insight.  Here are a few things to consider.

Remote Workers Need To Be Engaged

I do my best to follow the rule of communicating with people in the medium that they prefer. I trade a lot of email with the people who, like me, are always on it; I pick up the phone for the people who aren’t; I text message with the staff that live on their smartphones. But, with a remote employee, I break that rule and communicate, primarily, by voice and video.  Emoticons don’t do much to actually communicate how you feel about what your discussing.  Your voice and mannerisms are much better suited for it.  And having an employee, or teammate, that you don’t see on a regular basis proves the old adage of “out of sight, out of mind”.

 In Person Appearances Are Required

For the remote worker to truly be a part of the organization, they have to have relationships with their co-workers.  Accordingly, just hiring someone who lives far away and getting them started as a remote worker might be the worst thing that you can do for them.  At a minimum, requiring that they work for two to four weeks at the main office as part of their orientation is quite justified.  For staff who have highly interactive roles, you might require a year at the office before the telework can commence.

Once the position is remote, in-person attendance at company events (such as all staff meetings and retreats) should be required. When on-site isn’t possible, include them via video or phone (preferably video). On-site staff need to remember them, and not forget to include them on invites. Staff should make sure that they’re in virtual attendance once the event occurs.

Technical Literacy Requirements Must Be High

It’s great that the remote access tech is now so prevalent, but the remote worker still needs to be comfortable and adept with technology.  If they need a lot of hand-holding, virtual hands won’t be sufficient.  Alternatively, the company might require (and/or assist with) obtaining local tech support.  But, with nonprofit IT staffing a tight resource, remote technophobes can make for very time-consuming customers. Establishing a computer-literacy test and making it a requirement for remote work is well-advised; it will ease a lot of headaches down the road.

Get The Policies In Place First

Here’s what you don’t want: numerous teleworkers with different arrangements.  Some have a company-supplied computer, some don’t.  The company pays for one person’s broadband account, but not another’s. One person has a company-supplied VOIP phone, the other uses their personal lines. I’ve worked at companies where this was all subject to hiring negotiations, and IT wasn’t consulted. What a nightmare! As with the office technology, IT will be much more productive if the remote setups are consistent, and the remote staff will be happier if they don’t feel like others get special treatment.

Go Forth And Telecommute

Don’t let any of this stop you — the workforce of the future is not nearly as geography bound as we’ve been in the past, and the benefits are compelling.  But understand that company culture is a thing that needs to be managed, and managed all the more actively when the company is more virtual.

Category: Management, nptech, software, strategy, techcafeteria, tools | Comments Off
May 21

Why I Hate Help Desk Metrics

image
Photo: birgerking

Tech support, as many of you know, can be a grueling job.  There are a huge variety of problems, from frozen screens to document formatting issues to malware infestations to video display madness.  There are days when you are swamped with tickets.  And there are customers that continually broaden the scale from tech-averse to think-they-know-it-all. I’ve done tech support and I’ve managed tech support for most of my career, and providing good support isn’t the biggest challenge.  Rather, it’s keeping the tech support staff from going over the edge.

In our nptech circles, it would be natural to assume that having good metrics on everything help desk would assist me in solving these problems. Good metrics might inform me regarding the proper staffing levels, the types of expertise needed, the gaps in our application suites, all that good stuff that can support my budgeting and strategy. But once I start collecting them I open myself up to that imminent threat that someone else in management (my boss, the board, or whomever) might want to see the metric, too. They want to see are metrics like:

  • Average tickets and calls per day
  • Number of open tickets
  • Average time to resolve a ticket

Their idea is that these numbers will tell them how productive the tech support staff are, how efficient, and how successful they are at resolving problems.

Every one of these is a unreliable metric.  Alone or together, they don’t tell a meaningful story. Let’s take them one by one:

Average daily tickets: This is a number that is allegedly meaningful as it rises and falls.  If we have 30 tickets a day in January, and 50 a day in February, it means something.  But what?  Does it mean that IT is being more productive?  Does it imply that there are more issues popping up? Is it because more people are feeling comfortable about calling the help desk?  If we drop to 15 in February, what does that mean?  That IT has stabilized a lot of problems, or that the users have figured out that others in the org are more helpful than IT?

Number of open tickets: The standard assumption is that fewer is better.  And while that is generally true, it can be deceiving, because the nature of tickets varies dramatically.  Some require budget approvals and other time-consuming delays.  An assumption that tickets are open because the technician hasn’t gotten around to resolving them is often wrong.

Average time to resolve a ticket:  This one is deadly. Because it is commonly used as a performance metric, and that’s based on the assumption that the quicker all tickets are closed, the better service IT is providing.  The common scenario I’ve encountered where this metric is shared with management is that the tech support staff grow so pressured to close tickets that they regularly close them before the issue is truly resolved.  It creates tension with staff, as the real power of a help desk ticketing system is in the communication that it enables, not the communication that it cuts off when staff are not geared toward taking a communicative approach to issue resolution.

Worse, it takes away the technician’s ability to prioritize.  Every ticket must be closed quickly in order to look efficient, so every ticket is a priority.  But, in fact, many tickets aren’t high priority at all.  People often want to report computer problems that they aren’t in a hurry to get resolved.  When every ticket is treated like a fire to be put out, staff, naturally, start getting resistant to shouting “fire”, and stop reporting that annoying pop-up error that they get every time they log in.  They start living with all of the little things that they have inconvenient but bearable workarounds for, and as these pile up, they grow more and more annoyed with their computers — and tech support.

So what might useful metrics to assess the effectiveness of tech support entail? Here’s what I look for:

  • Evidence that the techs are prioritizing tickets correctly. They’re jumping when work stoppage issues are reported and taking their time on very low priority matters.
  • Tickets in the system are well-documented. We’re capturing complex solutions and noting issues that could be reduced with training, fine-tuning or a software upgrade.
  • Shirts are tucked in, hair isn’t mussed, nobody is on the verge of tears. High stress on support techs is usually plain to see.

The type of person that gravitates to a tech support job is a person that likes to help. There are egos involved, and an accompanying love of solving puzzles, but the job satisfaction comes from solving problems, and that’s exactly what we want our support staff to do. Creating an environment where the pressure is higher to close tickets than it is to resolve them is a lose-lose scenario for everyone.

Category: Management, nptech, software, strategy, techcafeteria | Comments Off
May 14

Working With Proposal Requests Collaboratively

Okay, I know that it’s a problem worthy of psychoanalysis that I’m so fascinated with the Request for Proposal (RFP) process. But, hey, I do a lot of them. And they do say to write about what you know.

The presentation that I gave at NTEN’s conference in March focused on the process of developing and managing RFPs. I made the case that you want to approach a vendor RFP very differently than you would a software/system RFP. I pushed for less fixed bid proposals, because, in many cases, asking for a fixed bid is simply asking for a promise that will be hard to keep. ROI involves far more than just the dollars spent on projects like CRM deployments and web site revamps.

In the session, I learned that Requests for Information (RFIs), which are simpler for the vendors to respond to, can be a great tool for narrowing a field.  It’s important that clients are respectful of the fact that vendors don’t get paid to respond to proposals; they only get paid if they win the bid, and showing respect on both sides at the very glimmer of an engagement is a key step in developing a healthy relationship.

Since the conference, I’ve gotten a bit more creative about the software that we use to manage the RFP process, and I wanted to give a shout-out to the tools that have made it all easier.  There are alternatives, of course, and I still use the Microsoft apps that these have replaced on a daily basis for other work that they’re great at. But the key here is that these apps live in the cloud and support collaboration in ways that make a tedious process much easier.

Google Docs is replacing Microsoft Word as my RFP platform software. The advantages over Word are that I can:

  • Share the document with whomever I choose; the whole world or a select set of invitees. Google’s sharing permissions are very flexible. With Word, I had to email and upload a document; with Google Docs I only have to share a link.
  • I can share it as a read-only document that they can comment on. This simplifies the Q&A portion of the process, while maintaining the important transparency, as all participants can see every question and response.

We recently did an RFI for web development (it’s closed now, sorry!) and here’s what it looked like, exactly.

Smartsheet is replacing Microsoft Excel as my response matrix platform.

Example of a Smartsheet matrix

The first step upon receiving responses to a request is always to put them all in a spreadsheet for easy comparison.  Smartsheet beats Excel because it’s multi-user and collaborative. Since Smartsheet is a Spreadsheet/form builder/project management mashup app, I can add checkboxes and multiple choice fields to my matrix.

For simple proposals, you can also easily use Smartsheet to collect reviewer comments and votes. Just add a few columns (two for each reviewer). This puts the matrix and evaluation criteria all in one place, that can easily be exported to spreadsheet or PDF in order to document the decision.

Surveymonkey has replaced Excel for cases when the evaluation criteria is more complex than a yes/no vote. Using their simple but sophisticated questionnaire builder, you can ask a number of questions with weighted or scaled answers. The responses can be automatically tallied and, as with Smartsheet, exported to Excel for further analysis or published as charts to a PDF.

Consultant Selection Chart

As I’ve ranted elsewhere, making a good investment in software and vendor evaluation has a big impact on how successful a project will be.  Working with staff who are impacted by the project in order to choose the partner or technology increases buy-in and the validity of the initiative in the eyes of the people that will make or break it. And a healthy process insures that you are purchasing the right software or hiring the right people.  These tools help me make that process easier and more transparent.  What works for you?

Category: 14ntc, Management, nptech, software, strategy, techcafeteria, tools | Comments Off
April 26

Debating Proper Project Management Discipline

I just had a fun, spirited debate on Twitter about the definition of a project. It started when a friend of mine tweeted this:

Now, my team at Legal Services Corporation recently finished a project (at least, that’s what I call it) to redesign the Find Legal Aid lookup on our website.  I blogged about that effort, which was kickstarted by the DC Legal Hackers, on LSC’s tech blog.  A few things about this:

  • There was no deadline.
  • It was something that we could have outsourced completely, but we wanted to learn the underlying technologies.
  • It was low priority, and my lead developer had a lot of more critical, time-sensitive  projects on his plate.

So we didn’t set a deadline. We pitched the project to management with clear goals (a charter).  After the initial development was done at the DC Legal Hacker’s first hackathon, we identified the four person team that would work on it internally. We reported on it weekly, during our project review.  And we rolled it out when it was finished.

On seeing Norman’s tweet, I challenged the notion that a deadline is a required element of a project. Mind you, many agile programmers work with the bias that iterating until it’s done correctly is more important than meeting a deadline. I doubt that they can actually sell that to their internal or paying clients often, of course.

So I threw my two cents in:

— Peter Campbell (@peterscampbell) April 24, 2014

which brought this reply from someone that I assume is, unlike me, a certified Project Manager, and therefore better versed and disciplined in the best practices:


So, here I am, coming off of a highly successful development and rollout of our little webapp, being told that it wasn’t a valid project.  The entire tweetstream is copied below, but here are the points that I want to make that go a bit beyond Twitter’s 140 requirement.

  • The Project Management Institute (PMI) awards Project Management Professional (PMP) certification to those who complete the requisite hours managing projects and pass the test. I’ve completed their requisite hours, and I’ve taken most of the test prep classes, but I’ve never gotten around to taking the test. So I agree with Rebel that their definition of a project requires a deadline. But I don’t agree with their definition.
  • As with many certifications, what you have to say to pass the test is not always what is going to work in the real world. My first career was working as a cook/sous chef, which I did through most of my very late teens and twenties.  As with technology, I was mostly self-taught. I’ll never forget one day, when working in a French restaurant in Cambridge, Mass., a fresh graduate of the Culinary Institute of America came on board. He didn’t last his first night on the job.  This guy could make some wonderful, complex recipes, but he was overwhelmed when he hit 15 to 20 orders on the wheel. I get the PMI reasoning, but I’ve adapted it over the years in my nonprofit environments where we don’t have the staff or budget to do things to the letter.
  • I absolutely value the governance of a project management discipline.  I firmly believe that you need to recognize targets and milestones if you want to push forward. My tolerance for “no deadline” is in rare cases like the one above. In particular, I need to have work schedules so that large projects don’t end up piling on top of each other.
  • But the trick to successfully getting a lot of things done well in what we call “a constrained resource environment” (e.g. any nonprofit and most of everything else) is to not let the governance get in the way of getting things done. So I take or leave parts of it, being more formal when there’s more at stake and absolutely informal when it doesn’t threaten our outcomes.

I might get that PMP certification someday, although, at this point, it might be when I retire.  But, with a few exceptions, I have a good track record of overseeing some great accomplishments in my career, and I expect that to continue until the day that I can retire.  And I’ll do it by applying appropriate standards and bucking them when they get in the way of the end goal.

Here’s the tweetstream:

 

April 17

Three Ways To Make Sure that Your Next Big Software Project Is A Success

This post also appeared on the Cloud for Good Blog today.

Buying a new fundraising CRM or replacing your finance and HR systems are big investments with critical outcomes. These are the types of projects can have a huge impact on your ability to accomplish your mission. Poorly planned, chosen and deployed, they will do the opposite. If you’re grasping for a cautionary tale, just look at the recent Healthcare.gov rollout, or the worse related stories in Maryland and Oregon. But successful implementations happen every day as well, they just don’t grab as many headlines.

How can you make sure that big software projects succeed?  Here are three recommendations:

1. Know what you need

All too often, the decision to replace a system is based more on frustrations with your current system than identified improvements that a new system might bring.  And, far too often, those frustrations aren’t really based on the capabilities of your existing system, but, instead, on the way that it was configured.  Modern software is highly configurable.  In nonprofit environments, where administrative staffing is low and people are juggling multiple priorities, the proper investment in that configuration is sometimes skipped. It’s important that you take the time to thoroughly catalogue your current processes and goals; clearly identify your reporting needs; and establish your core requirements before you embark for this sort of project.

Technology automates processes. If you automate bad processes, you get bad technology.  So making an investment in business process mapping, and taking the time to streamline and enhance the way you work with information today will insure that you know what your new system should be doing for you as you configure it.

2. Be prepared to change the way you do things

Ideally, you’ll invest in software that does exactly what you want it to do for you. In reality, there will be limitations in the way that the software was programmed, or the way that it has to be configured in order to integrate with your other applications, that will be out of sync with your preferences. Software doesn’t have a mind of it’s own; instead, it inherits the assumptions and biases of the developers that created it. They might assume, for instance, that you collect donations from individuals and have no need to recognize households in your system. Or they might assume that your average employee turnover is less than 20%, whereas, at a workforce development agency that hires its clients, 50% is more on the mark.  If the best system you can find suffers from some of these limitations,. you will have to either work around them, or buy the second best system, if it requires fewer workarounds, because you do want to minimize them.

Regardless, you’ll want to understand the underlying assumptions in the application and have a strategy for working around them. Some companies will go so far as to commission or design their own systems (commonly called “build” vs “buy”), but you need to weigh the cost of having a supported system vs. a homegrown one, because, unless what you do is truly unique, those will not be worthwhile trade-offs.

3. Hire a consultant for their expertise and compatibility, not their billing rate

We all want to get these projects done for as little money as possible. So there’s a tendency to hire consultants based on the lowest bid. I’d caution against this. major system configuration projects are generally open-ended — determining the exact configuration and number of hours that it will take to get there before the project starts is akin to inviting the whole city to a dinner party and determining the number of plates that you’ll require before anyone RSVPs. So you want to work with consultants who are very efficient at their work, and very conversant with your needs. What you don’t want to do is hand your project to a consultant who doesn’t really understand your requirements, but has their own idea as to how it should be done.  You could well be left with a system that met the budget, but not your needs, or one that exceeded the budget while being reworked to satisfy your requirements. A good consultant will work closely with you.  they’ll spend more time meeting with staff to learn about your needs then they will setting up the project, but they’ll set it up quickly and correctly based on their thorough understanding of your goals and needs. The hourly rate might be double the low bid, but the total cost could be equivalent, resulting in a usable system that will compensate for the initial dollar outlay all that much faster.

Here are slides that I developed for a talk/discussion on creating Requests for Proposals that vendors will appreciate at the recent Nonprofit Technology Conference.  These include some key strategies for making sure that you hire the right person or firm.

In conclusion, how you go about a software project has far more to do with how you conduct your business than it does with the actual technology.  Make sure that you’re investing wisely by taking the time to understand your needs, know where you can compromise, and hire the best partners.

Category: 14ntc, Management, Miscellany, nptech, software, strategy | Comments Off
June 10

The Palotta Problem

uncharitableIf I have a good sense of who reads my blog, you’re likely familiar with Dan Palotta, notable in the nonprofit world for having raised significant amounts of money running the Aids Rides and Breast Cancer walks.  More recently, he’s become a outspoken and controversial crusader for reform in the sector.  He did a much-viewed Ted talk, and he’s written a few books outlining his case that “The way we think about charity is dead wrong”. And he keynoted the recent NTEN conference in Minneapolis.

Palotta’s claim is that nonprofits, in general, are their own worst enemies. By operating from a puritanical, self-sacrificing ethic that says that we can’t pay ourselves as well as for profit companies do, and we can’t invest heavily in marketing and infrastructure, instead prioritizing that every penny go to our program work, we are dramatically ineffective. He is advocating for a revolution against our own operating assumptions and the Charity Navigators, tax codes and foundations that are set up to enforce this status quo.

His message resonates. I watched his Ted talk, and then his NTEN plenary, and tears welled in my eyes on both occasions   They were tears of frustration, with an undercurrent of outrage.  I doubt very seriously that my reaction was very different from that of the other 1500 people in the room.  We are all tired of the constant struggle to do more with much less, while we watch entertainers, athletes and corporate CEOs pocket millions. Or billions.  And this is not about our salaries.  It’s about the dramatic needs of the populations we serve; people who are ransacked by poverty and/or disease. Should reality TV stars be pocketing more than most NPOs put annually toward eradicating colortectal cancer or providing legal assistance to the poor?

But, as I said, Palotta is a controversial figure, and the reactions to him are extreme to the point of visceral.  Even among his most ardent supporters, there’s a bit of criticism.  The key critical threads I heard from my NTEN peers were distrust of the implied argument that the corporate model is good, and frustration that a person who did well financially running charities is up there being so critical of our self-sacrifices.  In fact, since his nonprofit went under amid a storm of criticism about his overhead ratio.  Reports are that it was as much as 57% (depending on how much the reporter dislikes Palotta, apparently). That’s between 17% and 42% more than what nonprofits are told to shoot for, and are assessed against. But the amount of money he raised for his causes was ten times that of any similar efforts, and it does dramatically illustrate his point. How much opportunity to raise money is lost by our requirement that we operate with so little staff and resources?

I’m sold on a lot of Dan Palotta’s arguments. I don’t think that NPO’s have to emulate corporations, but they should have equal opportunity to avail themselves of the business tactics, and be measured by how effective they are, not how stingy. But I still can’t rally behind Dan Palotta as the leader for this cause.  It’s one thing to acknowledge that the nature of the “do-gooder” is one of austerity and self-sacrifice. It’s another to criticize it. Because, while most of us can recognize the disadvantages that our nature tends towards, we’re proud of that nature. It’s not as much a bad business orientation as it is a core ethical life view. The firm belief that relieving the suffering of others is of greater personal satisfaction and value than any financial reward pretty much fuels our sector. So standing on a stage and chastising us for not being more competitive, more greedy, and more self-serving, no matter how correct the hypothesis, primarily offends the audience.

By putting this criticism front and center, rather than acknowledging the good intentions and working with us to balance them with a more aggressive business approach, Palotta is undermining his own efforts. The leader who is going to break these institutional assumptions is one who will appreciate the heart of the charity worker, not one who – despite their good intentions – denigrates us. I applaud Palotta for raising a lot of awareness. But I’m still waiting to meet the people who will represent us in this battle. Palotta has raised the flag, but I’m not convinced that he’s our bannerman.

April 4

The Role of Information Technology At Nonprofits NTC Panel

Just in case this late addition to the Nonprofit Technology Conference Agenda slipped your radar, I want to plug it.

Nonprofits and IT, a “Big Idea” panel, Saturday, 10:30 AM, Ballroom G: http://myntc.zerista.com/event/member/76206

As regular readers of my blog know well, nonprofits have struggled with the integration of technology strategy and leadership in their organizations. Since I transitioned to a career in the sector in 2000, there has been a clear acknowledgement that this integration is critical, but there’s still been a lot of uncertainty as to how it’s done. NPO’s now get that integrating finance, ECRM and donor databases is critical; migrating to the cloud is imminent; and telephones are now computing devices. But they wrestle with questions like “Where does IT report?”, “How much should we pay IT staff?” and “What is IT responsible for? Servers? Web site? Donor database?”

I’ll be sitting on the panel with :

  • Donny Shimamoto, CEO of Intraprise Techknowlogy, a nonprofit-focused consulting firm in Honolulu;
  • Michael Enos, CTO of Second Harvest Food Bank of Santa Clara and San Mateo Counties, CA; and
  • Laura Quinn, CEO of Idealware.

Lindsay Martin-Bilbrey, NTEN’s Program Director, will moderate the session.

We’ll tackle the big questions, like what is the role of the CIO? Will IT be necessary when we’re all in the cloud? And, my favorite (one to debunk!), Should you replace your Chief Information Officer with a Chief Digital Marketing Officer? I know that the members of the panel won’t agree on everything, either, so the conversation should be robust.  We’ll leave plenty of time for audience questions.  If, like me, you consider these questions to be of critical importance, I do hope you’ll join us.

Category: 13ntc, idealware, Management, nptech, strategy, techcafeteria | Comments Off