PCI compliance anxiety ratchets up

In the last few weeks our office phones have been ringing with calls from clients concerned about PCI compliance. A mounting realization that enforcement of these credit card standards is indeed coming, the October deadline to use compliant applications, and widespread confusion about what the standards are and who they apply to, is bringing the issue of credit card security to a boil. [UPDATE: I've created an entire page of PCI information at: http://membersonlysoftware.com/pci ] The background: PCI is an association of the major credit card issuers. The PCI Data Security Standard (PCI-DSS) is a list of twelve security requirements that merchant account holders must meet. According to the standard, "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply." In other words, if you ever send a credit card number through to the bank for processing, you've got to pass muster. Validation of compliance may require an on-site audit, or may be done by self-assessment and a notarized attestation. And while 12 requirements does not sound like much, the sub-points of each requirement make it clear that the standard affects pretty much every aspect of your IT system and your payment processes. The biggest misconception we see among our clients is the idea that if they are using the right credit card processing system or software, they are compliant. Of course there are requirements that payment applications must meet. Failure to use compliant software is a sure path to flunking your compliance audit. But using compliant software does not begin to guarantee that you the merchant are yourself compliant. The entire security of your computer system comes under the purview of the PCI. In addition, any paper systems that might contain account number data are also involved. Failure to use compliant software is a sure path to flunking your compliance audit. But using compliant software does not begin to guarantee that you the merchant are yourself compliant. Let's look at one example. Requirement #1 reads "Install and maintain a firewall configuration to protect cardholder data." You might think the fact that you have an industry standard firewall product installed gets you a pass on this one. But that is just a starting point. The requirement's details indicate that you need a written policy on how any change to the router or firewall configuration is approved and made. a network diagram that shows all connections and all devices and a process to make sure the diagram is up to date. documentation of the business case for all ports that are open and all protocols that are in use. a formal review of all firewall and router settings every six months. But back to the your software applications. Requirement 6 simply reads "Develop and Maintain secure systems and applications." How is secure defined here, and how do you prove it in a PCI audit? Software applications that are sold "off the shelf"" can apply for the PA-DSS certification. (The Payment Application Data Security Standard - this is a separate standard governing just the software that management credit card payments). Software that is customized for a user organization cannot receive the PA-DSS designation. Instead custom software comes under the scope of each user's PCI compliance audit and may require a code review. The best solution for a customized application is for it to avoid ever coming into contact with a credit card account number, and simply delegate all card handling to a certified PA-DSS compliant application. This is a bigger deal than you might think. For example, if you want to capture the credit card number for a donation in page you have carefully designed and branded, you will need to code review and validate this page as part of your compliance even if all it does is pass this number to a PA-DSS certified payment app. But your greatest exposure arises if you store credit card numbers for any reason after the moment of the transaction. For example, many non-profits charge sustaining donors' pledges against their credit cards on a monthly basis; YMCA's often charge for their dues this way. The requirements for protecting credit card data of this sort are daunting. Maintaining this sensitive data in an encrypted database using the latest encryption technology may not be enough if you cannot document your procedures for controlling access to the keys, monitoring physical access to the server, and so on. The best solution, is to hand off ALL credit card storage as well to a PA-DSS certified application that stores the numbers out in the internet cloud, far from your server, and your liability. We've selected to partner with CAMcommerce, for example, whose PA-DSS certified xCharge application is a dream to integrate with and will provide Members Only users with the security they need. All of this demands that custom applications find new ways of interfacing with payment software. For example, a very widely-used method for interfacing with payment applications involves the business application creating a batch file that is submitted to the payment app. This file contains credit card numbers written out in plain text. And the application returns a batch of response data, again with the number in plain text. This approach is certainly not compliant with the new security requirements. Like Y2K a decade ago, PCI and PA-DSS compliance are going to keep programmers busy for a while. Additional Information: The PCI Security site is full of information about the standard and compliance testing. "Navigating PCI-DSS" is a fifty page introduction to the terms of the standard and the meaning and intent of each clause. It's the best thing to read to get a sense of what this is all about. The Full PCI_DSS specification can be downloaded from this page. And when you are ready, you can also find the self-assessment questionnaire here.

Capability Stairsteps

When we begin a new deployment of our software applications at an organization, we always ask the users "How will you know if this project was a success or not?" We're usually expecting to hear things like "Our staff will spend significantly less time putting together monthly reports" or "We will finally have agreement between the membership lists on the website and in the AMS." But at a recent project kickoff the bar for success was really low: "Our staff will actually use the system." Problems with the adoption of new IT tools can rob an implementation of much of its ROI. And the the solution is not simply making sure you've picked the right tool and delivered the proper training. There are specific steps that need to be taken to encourage user adoption. My friend Russ Eisentstat of TruePoint uses the phrase "capability stairsteps" to emphasize the incremental nature of such transitions. These steps may involve partial use of the new tool, use by a subset of the eventual target user community, or both. But before you can climb these steps you need to design them - adoption will not necessarily spread naturally or completely unless the organization creates a plan and monitors it. The example Russ and I discussed related to the use of a wiki to capture organizational knowledge. One of my long-standing contentions is that an enormous amount of organizational knowledge exists in emails between stakeholders. If these emails were simply captured and organized, a great deal of knowledge documentation could be managed with little or no new writing. But both of us had limited success in encouraging our own organizations to use our wiki. What would a stairstep model for adoption of the wiki look like? First we need to put someone in charge! This is a step that is often ignored in this type of change management. Someone needs to take personal responsibility for the effort to develop the wiki into a useful tool. As soon as we have identified the wikimaster, we have at least one more committed user. The next step is to identify the barriers to adoption so we can plan to eliminate them. Russ and I both agreed that the main barrier is the catch 22 of social sites: the wiki is not attractive to users if it is not yet rich with useful information -- but this will not happen until people begin using it. This barrier can be reduced by "priming the pump." Step two is that the wikimaster takes active responsibility for getting the first fifty articles on the site. He can poll users frequently to get them to send him any material that would be apporpriate for inclusion. This spreads some buzz about the wiki without asking people to utilize it themselves in any way. A second barrier: it takes a bit more learning to become adept at posting than just to read the site. So this suggests the next increment. Step three is to encourage the use of the wiki as a passive repository of information, without leaning on people to post. People can still rely on the wikimaster to post their articles, but can begin to turn to the wiki to look for information they might need. Only now do we tackle active contribution - again a step at a time. In Step four might the wikimaster to encourages people to comment on exisiting articles - reminding them of this capability, and having existing champions comment to prime the discussion on this forum. Step five might be then to put in place rules for how others should post their own articles - how to tag them, how to deal with the home page, how new articles are announced, and so on. At this point a training or informational session might be held for new posters. So what I had thought was a one step procedure - "let's start using this new tool" - has become a five step staircase. This model of identifying barriers and building a step to climb over each one in sequence can be used to encourage adoption of systems of all kinds.

Earth Day Roundup

Links to some interesting reading this Earth Day: Green IT. A couple months ago I posted about "Green IT" and the growing awareness that information technology demands fuel and creates emissions like all other energy consuming activities. But this article in the BBC took me by surprise... email SPAM is a major contributor to IT energy consumption, utilizing 33bn kilowatt-hours of energy every year, enough to power more than 2.4m home, and in the process contributing 17 million tons of carbon dioxide to our greenhouse gas burden. Green Education. A bit of good news for all the non-profits making efforts to educate their constituency about green issues: it makes a difference. The EPA reports that there is a measurable improvement in air quality associated with environmental education. Nearly half of the surveyed institutions hosting education programs reported an improvement in air quality at their facilities due to actions taken by students, including doing service-learning projects and fostering community partnerships. Examples include decreased levels of carbon monoxide and mold, and enactment of a policy that decreased car or bus idling. Green Markets? Free-marketeers have been extolling the value of "Cap and Trade" solutions to control emissions... but there is mounting evidence that it is not so simple. An article in the British New Scientist reviews the results of the ETS (Emissions Trading Scheme) currently in place in the EU. The approach works when the price of permits is high. But if the value falls, the incentive to improve emissions falls right with it: As heavy industries mothball factories, energy use drops and demand for permits goes down. At the same time businesses try to raise cash by selling their unused permits, flooding the market and further depressing prices. French energy company EDF recently complained that carbon markets were failing just like the market for subprime mortgages. As a result, all kinds of green energy schemes are grinding to a halt.

What is Green IT?

For a couple of years now we've been seeing talk of Green IT, and as early as 2007 management consulting giants Gartner and McKinsey were addressing Green issues as a major issue facing IT managers. The McKinsey report offers a concise statement of the issue: The rapidly growing carbon footprint associated with information and communications technologies, including laptops and PCs, data centers and computing networks, mobile phones, and telecommunications networks, could make them among the biggest greenhouse gas emitters by 2020. However, our research also suggests that there are opportunities to use these technologies to make the world economy more energy and carbon efficient So Green IT is really two issues: making information technology itself more energy efficient, and going beyond that to using IT to reduce the carbon footprint of other operations. Today's EnergyWise announcement by Cisco underscores the growing concern managers have in both these areas. The EDS blog The Next Big thing devoted eight posts last autumn to an in-depth look at the idea of Green IT and lays out a path that considers both of these issues in detail, focusing on the green data center. Many of these ideas seem more appropriate for a Google or Microsoft than for a medium-sized non-profit or association. Techsoup offers some suggestions for Greening the smaller workplace. These include virtualizing your servers to use fewer boxes, and using your technology to minimze travel. Has your organization grappled with these issues? Have your solutions saved you money, added complexity, or both?

Three common security pitfalls

Security is a growing concern in the non-profits community. The requirements may be legally mandated, as in the case of HIPAA and client health care information. The issue may be competitive -- you do not want to hand out your grant applications to the other orgs in your building before you've even sent them off to funders. And everyone has finally woken up to the need to secure supporters' credit card information and comply with PCI standards. Organizations are putting increasing pressure on vendors of applications and networks to assure security through the use of encryption, https, and user specific access to data fields and tables. But we see three simple security flaws over and over again in the smaller non-profits. Inadequate physical security of the servers. Is your database server sitting in the unlocked phone closet? Is your web server in a room shared by three programmers? I know one group with real privacy concerns who keep the server on a counter in the break room. It doesn't really matter how much you lock your network down with the latest firewall technology and encryption techniques if the servers can be waltzed out of the building without causing a stir. Inadequate password security. I see this everywhere I go - users know each others passwords. It may even become part of standard operating procedure: "to do this, I log in as Eileen." Let your OS help you with this: require users to change their passwords frequently. Require complex passwords. Beat up on people who tell others what their password is. And if you have legally mandated privacy concerns, consider adding biometrics to your user authentication procedure - USB thumb scanners are widely available these days. Improper Disposal of Computers. When the time comes to dispose of a pc, what do you do with it? All your security efforts were for naught if you just sit the machine in the trash. Wipe that drive! Reformatting the drive does not do it - it just clears the directory structure. Any snoop can still read your data after a reformat. There are numerous software packages on the market for just this purpose - a number of government agencies have standardized on cyberCide. You can destroy the drive with a few well-placed drill holes - but the software approach is easier - and then you can still donate the old. Thanks to Sean Henriques for a tweeting a link that made me start thinking about this!

The Summertime Blues

You'll love those lazy hazy crazy days of summer - those days of hot dogs and pretzels and beer... remember that old tune? I can remember listening to it on the radio as we drove to the Catskills in my Dad's old Dodge. But vacations are different now - everywhere I'm reading articles about how we Americans don't really get away from our work anymore when we go on holiday. We go loaded with smartphone and laptop and a plan to get six weeks of special projects done during six days on the beach. I know that's how I made my last trip miserable. But I don't think we should get too new-agey about this one. For the techie in the non-profit or association space, taking a guilt- and anxiety-free vacation is not about state of mind, but about preparation. It's about making sure your organization, your clients, your users, really will be OK during your absence. Its a sort of preparation you need to be thinking about in one way or another before any absence - whether its a day off to paint your kitchen or a month-long trip through India. Prepare your users. Your users depend on you on a daily basis for solutions, for advice, for troubleshooting. The longer your absence is going to be, the earlier you need to let people know about it. Make sure all your key users understand when and for how long you will be out, and give them a good understanding of the limits on your availability during your vacation. Encourage them to think now about needs that might emerge during your time off. Make sure they factor your absence into their timeframes for special projects! And let them know where to turn for help while you are gone. Prepare your backup. The folks who are going to be filling in for you during your vacation need to know exactly where your major projects are at, how to find the information they might need, and who they can turn to for further help. Make sure they know exactly how and when they can contact you, and when you be unavailable. What should you prepare them for? Look through your last years log of issues you've had to resolve. And be careful: documenting your network is useless if you have not made sure the right people know where to find that document. Don't have a backup person? - no wonder you and your coworkers are anxious! Take care of this first. If its not someone on your staff, make arrangements with a consultant. Prepare yourself. Your work pattern needs to change as you get ready to leave. We did a project several years ago for Deutsche Bank in Frankfurt. Frequently our partner Jochen would fly there for meetings. Pressed by the users to make enhancements to the application on a short time frame, he'd crank out code in his hotel room in the evening and install it the next day. Then he'd get on a plane to come back to D.C. Inevitably the user would have some huge issue with what he had done while he was on his seven-hour flight home. None of us back in the office had a clue what the requirements were or what the discussion had been. We've identified this as the Friday Install problem. Now we know to wait until we are in a position to support before we change. When your absence is going to be longer than seven hours, this issue becomes much more sensitive. Make sure you are not adding to the support burden in the days before you leave. And send me a postcard!

Building your Donor base on Facebook - The Nature Conservancy's experience.

There's been a lot of excitement in the last year about social networking in general, and about Facebook in particular. And a lot of talk about the value of social networking for non-profits. But is there really a return on investment for non-profit participation on these sites? Here's a success story. The Nature Conservancy (TNC) is a 501(c)3 organization that works in the U.S. and over 30 other countries to protect ecologically important lands and waters. Using tools readily available on Facebook, the organization has raised almost $48,000 in the first six months of their social-networking effort. They did this by creating a Cause and a Fan Page for the org, and by forming a relationship with an ecology oriented game on Facebook, (lil) Green Patch. Six months later the (lil) Green Patch application is one of the most popular on Facebook, with of 6 million users! Jonathon Colman , TNC's Associate Director for Digital Marketing recently developed a slide presentation that summarizes the organization's experience using Facebook as a marketing tool. You can find the presentation here. The slide presentation raised a number of questions in my mind, so I messaged Jonathon on Facebook and we chatted about (lil) Green things. Me - How did (lil) Green Patch come about? Was TNC involved in the creation of lil green patch or was it already on line when you formed your relationship with it? Jonathon - No, the Conservancy was not involved with the creation of (Lil) Green Patch. It was already on Facebook when we found it by doing a search on our name (hence my first recommendation to organizations seeking to use Facebook for marketing purposes). At that point, (Lil) Green Patch already said that they were going to donate a share of their advertising revenue to the Conservancy, but had trouble connecting with the right people in our organization. I immediately wrote them and we started the conversation. From the very first conversation, we encouraged (Lil) Green Patch and other Facebook application developers to donate to us directly through our Facebook Facebook Cause. Me - Can you explain the business model of the application? How does it make money for you? Jonathon - The application is supported by advertising on the site. It's a share of their advertising revenue that's donated to the Conservancy's Cause at http://apps.facebook.com/causes/2979?recruiter_id=1833869 on a month-by-month basis, depending on the application's usage and ads impressed/clicked on. It tends to be somewhere between $6000-$9000/month. Me - how can a consumer be sure an app actually is providing the social benefit it claims? The other day I got several messages in my inbox accusing another app (oceans-related) of not really having a relationship with any non-profit. Jonathon - This is why we're asking (Lil) Green Patch and other Facebook applications like Stop Climate Change Now to donate to us directly via our Facebook Cause -- it provides a complete change of accountability to the application developers and to the Conservancy. When an application donates via the Cause, it's very simple for everyone to see how much was donated: just visit the Cause and scroll down to the "Hall of Fame". You'll see that, to date, (Lil) Green Patch has given $44,650. Clicking on their name of the amount that they've donated yields a graphical chart containing the people that they've recruited and/or recent donations that they've made. Me - So do you need to have folks on staff to oversee the maintenance and ongoing development of the app? Jonathon - Not at all. The Conservancy is in no way involved with the ongoing maintenance nor development of (Lil) Green Patch. Anyone can participate in this process, actually - There's a discussion board and links to the developers' profiles off of the main application page where you can talk with other users and get in touch with the development team. Me - This is all very exciting. But what skills do you think a non-profit needs to bring on board to develop a marketing program built on social media? Jonathon - My team at the Conservancy has incredibly talented editors, producers, a designer, and even a project manager. I couldn't do anything without them. In terms of social media, I think that organizations need to find people who can bring the right balance of: - Writing for the web (specifically writing for members) - Engaging in search engine marketing and optimization; - Marketing to verticals and other segments - Researching marketing and communities - Testing and documentation - Recording metrics and interpretation of "actionable" data - Taking the "long view" on building a social media program and not expecting success right away The right person could come from a direct mail background or from a marketing communication background or even a business information/analytics background... They just need to have some intuition and be willing to fail a few time sin order to succeed. That said, my background is actually not in marketing, but in technical writing .

A new chapter.

The other day a friend dropped by the office to talk to us about how we manage chapters in our software. For example, he wondered if we assumed that the national organization did the dues billing, and distributed revenue to the chapters? Or the reverse: that chapters collect the dues and send it upstream to headquarters? The conversation led me to think about the forces that make organizational policies so often unwieldy and complex. We've learned that there is no general pattern that governs the relationship between an organization and its chapters. These relationships are not structured by logic but through the working out of real conflicts of interest and mission between national, state, and local bodies. And these conflicts are resolved differently in every case. The challenge for IT is to model the internal reality for the specific organization. Chapters are interesting because they are a very clear-cut example of what goes on in the definition of almost any organizational policy - a process of compromise between interest groups within the org. Streamlining inefficient or irrational policies is so much harder than one would expect because the differences between groups are so rarely spelled out. In the case of chapters, it is just easier to see these interest collisions. It works like this. Not surprisingly, chapters want as much independence from the national as possible. And specifically, financial independence. But at the same time, they would like as much service from the parent org as they can wrangle. So the more successfully independent the chapters become, the harder administrative life is in Washington or New York. For example a national conservation group we work with manages all the dues billing for its chapters and state divisions. These very autonomous chapters and divisions each create their own membership structures and dues levels. Thus the membership database mus t be able to store three membership types for each member: one each for National, State, and Chapter levels. And they must allow a person to hold multiple chapter and division memberships. All of these dues amounts must be reflected on each member's renewal notices. It's clearly an enormously complex system for the national to maintain. But this approach works in the interest of the chapters - and the chapters have the upper hand in this case. So when the policies you are trying to model seem resistant to simplification, remember you are dealing with real conflicts, not just procedural craziness.

Social media and the Surveillance Culture

Living as I do right in the heart of D.C., things like this happen: I had lunch the other day with a friend who is very knowledgeable about the hacker world within in the so-called "intelligence community". This is a world where it's common to get your secret clearance before you are old enough to buy a beer. And a sizable crew of these young folks are deployed to monitor - and participate in on behalf of the agency - all sorts of social media activity. Our conversation focused on Facebook, Second Life, and Skype. "The Agency is deeply involved in Facebook," I was told. This includes both developing techniques to pierce the Facebook's security, and active communication with persons of interest. "Security and Privacy are non-existent on Facebook" my informant told me. The same with Second Life. Organizations hold meetings on Second Life, I put on a sexy female avatar with my breasts hanging out, and I'm just accepted. All the guys have learned to use female avatars and personae on the sites. People will tell you anything" More ominously, I was told they have had some success accessing the computers of people connected to Second Life. As for Skype, the e-bay owned internet phone service: "There is basically no security employed by Skype. You can use an ordinary packet-sniffing software like any network engineer might buy to detect calls from a specific IP address and reassemble them. We've been working on editing them on the fly to change the content of an active conversation." Just something to bear in mind, eh?

Control and Flexibility

Control and Flexibility. These might be two of your goals in in working with your personal trainer. But in configuring your network and key applications, there is always a tension between these ambitions. How much do you lock down to prevent error and occasional malfeasance? How much do you leave open so that each staff member has the greatest ability to work freely and serve your community without running into roadblocks? It's one of the key areas where we see organizational culture influencing Information System design For example, board members and donors are hoping you keep good track of the comings and goings of their dollars. So there is a pressure to lock down access to financial records to one or two highly qualified individuals. On the other hand, if it takes the CFO to issue a five dollar refund check, you've created a real bottleneck. Somewhere between these two is your financial control balance point. This fulcrum won't be in the same place for all organizations. For example, a YMCA with it's hectic point-of-sale environment and fifty or sixty part-time or volunteer front-desk staff will arrive at a different solution from a trade association with a full time staff of ten professionals. The same dichotomy between control and flexibility arises when you start to push out e-commerce capabilities to your community. We see some organizations who are loathe to let a member change his own address. "Do you really work with organizations who do that? What if they make a typo or something?" And at the other extreme, there are organizations who say "If someone calls and wants to register for our workshop, we direct them to the website to enter it themselves. We genlty insist they do it themselves. Staff time is a scarce commodity". Again, your organization needs to find its own comfort point along this scale. You should rethink this balance periodically though - it is not a simple issue. Too little flexibility and you weaken your staff, your donors, and your membership, diminishing commitment they bring into the organization. Too little control and time, money, and energy flow out the door.

Timeboxing Risks

Before I got delayed we were talking about delivering software projects on time. Using the Timeboxing approach, the delivery schedule is the one absolute in the implementation plan. What features will be included in the delivery can slip, but never the date. New requests from the user are added to the queue, but the date is not modified to accomodate them. Unexpected technical problems may delay a feature, but never an install. With this approach, progress may be slower than anticipated, but it never halts, as it can with traditional scheduling, where an installation might be put on hold until all the planned features are completed. We've outlined the benefits to this approach, but there are also some risks. The most critical risk is safety. If Timeboxing is taken to mean that we just work away at the application until the scheduled delivery date, and then install whatever we have, users can get some nasty shocks. A major new feature might be only partially implemented. Spurious messages meant only for the programmers might appear. Untested calculation might charge people incorrect fees. The solution is release planning. Timeboxing is not a come as you are party. Sometime before the due date, the team needs to decide what requests can actually be included. Testing on those items must be completed. Features that are not ready for prime time need to be hidden. Changes that should not be delivered need to be rolled back out. This is where a good version control system comes in. Even the sacred install date can be slid by a day or so - not more -- to assure that the work already done is ready to debut. What this really means is that internally the timebox needs to end a day or two early, so the app can be cleaned up for its public appearance.

The Humane Society's LOLseals

But before we get back to delivering IT projects on time, let's look at some funny pictures. Certainly none of us have been spared the LOLcats phenomenon - where folks photograph cats and give them funny captions. Here's one my god-daughter Leah posted on Facebook, for example: Taking off on the popularity of this craze, my friend Carie Lewis, the dynamic internet marketing manager for the Humane Society of the US - one of the most savvy non-profits around when it comes to interactive and social media - has launched an LOLseals contest on the HSUS website. Take a peak. The idea is to create your own caption for one of the seal pictures. A panel of celebrity judges will announce a winner, who will take home a bunch of great HSUS seal gear. It's a great idea to encourage engagement and awareness of the ongoing plight of Canadian seals. What is exciting about this contest is the way it changes the images used in educating folks about the seals. The Canadian Seal Hunt is still the worlds largest slaughter of marine mammals. And it happens every year. We are all used to seeing images of baby seals being clubbed. This campaign reminds us of how appealing these animals are, rather than forcing us to look at violent images we've learned to shield ourselves against over the years. It gives the community a new way to engage with the issue, a new way to feel about these animals. It can be hard to find a new way of presenting the same old story - HSUS has found a way here.

Timeboxing your Development Efforts

How can you make sure you meet your promised deadlines when implementing software projects at your organization? And without late night pizza-driven coding sessions? One approach is Timeboxing. Timeboxing, quite simply, is an approach to IT implementation planning where the one thing that you do not allow to shift around on you are delivery dates. Everything else may seem totally out of your control. The users have eighteen new features they absolutely need. Your best programmer quits suddenly because she was offered a bit part in a horror movie. You just can't find that bug where new members are going in without their addresses. But you will install SOMETHING on March 18th. When I first read about timeboxing more than a decade ago, it seemed a nearly impossible technique to explain to the user community. Folks in our client organizations had a list of fixes and enhancements they wanted, and they were not interested in seeing a new version until these were done. But software methodologies have grown to emphasize a more iterative approach to development. In these so-called agile methodologies, fixing the schedule for each new delivery makes perfect sense. In the Scrum development model, for example, a new version is typically delivered every thirty days. At the beginning of the cycle, the team agrees on what outstanding requests will be included in this release. But if the work does not proceed as smoothly as planned, some of the requests will be left out to allow the iteration to complete on time. The ones that were not completed will be included in the next round. The advantages of this approach? 1. Users are not left waiting for new features already written as a delivery date keeps moving out to accommodate incoming requests. 2. By getting more features into users hands more quickly, the feedback cycle is tightened and the applications improve more quickly. 3. By allowing feature lists to slip, the "Death March" pressures around deadlines are alleviated, allowing programmers to perform work of a higher quality. Of course there are risks to timeboxing as well. We'll look at what they are and how release planning can mitigate them in the next post. ------ More reading on timeboxing can be found here.

Policing your Online Image

The other day I noticed one of my clients had an account on Facebook and I asked her how she was using it. "Mainly", she said, "to police our staff to make sure they haven't posted anything that would reflect badly on our organization". -- "You could also take the opportunity to post stuff yourself that would promote your organization and mission", I prompted. --"I don't think so." she chuckled. Then I'd have to be on here twice as much patrolling the responses to my posting." With a growing number of non-profit communicators finding a powerful role for the social media in their online strategy, it's disturbing to realize how many of their peers still approach things this way. Another client of our voiced this same fearful approach when I was urging them to set up an intranet for in-house conversation and information among their several hundred employees. "Impossible - who will read each of those postings to keep an eye out for inappropriate language or content?" The fallacy here is simple. These managers believe they currently have control over the organization's image and they don't want to loose it. The fact is, people are already saying whatever they want about them - in private emails, on blogs, on Facebook walls. Marketing guru Seth Godin in a recent post compares classic brand management to what he calls "tribe management".: ...what people really want is the ability to connect to each other, not to companies. So the permission is used to build a tribe, to build people who want to hear from the company because it helps them connect, it helps them find each other, it gives them a story to tell and something to talk about. In other words, when non-profit communicators give up and join the tribe that already exists around their organization, they discover that participating in the conversation is far more powerful than policing it.

VRM: CRM's flip side

Every non-profit now talks about needing to improve their CRM. But thanks to a post by Jay Deragon, I've been doing some reading this week about the emerging concept of VRM, or Vendor Relationship Management -- If CRM refers to software-based tools for organizations to manage their relationships with customers, constituents, and supporters, VRM is the complimentary set of tools, helping those individuals to manage their relationships with companies, organizations, and communities. The idea is appealing - but its actual application still seems quite hazy. The center of the VRM hub-bub seems to be Project VRM at Harvards' Berkman Center for Internet and Society. Their wiki states that CRM systems until now have borne the full burden of relating with customers. VRM will provide customers with the means to bear some of that weight, and to help make markets work for both vendors and customers — in ways that don't require the former to "lock in" the latter. The goal of VRM is to improve the relationship between Demand and Supply by providing new and better ways for the former to relate to the latter. In a larger sense, VRM immodestly intends to improve markets and their mechanisms by equipping customers to be independent leaders and not just captive followers in their relationships with vendors and other parties on the supply side of the marketplace. Any system that will allow particpation of both vendors and customers (or donors and fundraisers, or politicians and supporters...) starts to point toward the more collaborative environments that are being termed "social media" these days. And indeed, we find VRM being discussed on sites like "The Social Customer" blog by Christopher Carfi, which is trying to evolve models of customer service and marketing that assume a more empowered and participatory customer base. We are all both customers and vendors. But what does a VRM/CRM collaboration look like? This still seems an open question. I'm not yet seeing anything much more concrete than Carfi's call for "a robust way for customers to manage their own online identities without getting trapped in any vendor's silo. " CRM systems today are offering concrete Return on Investment to their users. The VRM conversation needs to focus on how to provide concrete measurable benefits for customers if this paradigm is gain traction.

Systematizing User Support

When I started this "Help-Desk" series I wrote: "A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function." But so far all I've talked about is the toolkit: putting a ticketing system in place. What about those improved procedures? Actually, for our little company developing a ticketing system proved to be the key to process improvement: the system made it easier for us to describe, refine, and enforce our approach to support. Turns out it's easier to think calmly and rationally about tickets than about this crisis or that. The key was the Status field in each the ticket. I know this sounds obvious, but it took us a while to realize it: giving each ticket a well-defined status makes the status if each ticket clear. So as we have made improvements in our process, we've added, removed, or renamed statuses, and made changes to the rules governing status change. In the early days of our company, we had a customer support process that Jochen Heyland, our CTO, jokingly describes like this. "When a ticket comes in, determine if it is urgent or not. If it is urgent, panic. Drop everything else and address it immediately. If it is not urgent, just forget about it." I still see this panic-driven approach in play at numerous small non-profits. It arises when no other process is defined and you need to think about how to handle each request as it comes over the transom. How do you improve this? We've moved to a system where any defect reported by a user -- if all goes well -- will pass through 9 statuses. These are Submitted, In review, Approved for action, In progress, Ready to test, In testing, Ready to install, Client testing, Completed. We will also decide if it has Urgent or Normal priority. You might come up with a different process path. That's fine. But having clear terminology for each step helps make the entire process repeatable and controllable. For example, we used to mark an item Completed once we'd tested it and made it available to the user. But we realized that at that point we were still waiting for the user's final words that a problem had indeed been corrected. So we added the Client Testing status. When items languish in this status for too long, we can take action - like calling to see if the problem has indeed been corrected. You also need to define the steps on various side paths. For example a defect report might end up with the status Cannot Replicate. Or a request for consultation or training might need to go through Needs Estimate, Estimate Ready, Estimate Pending Client Approval before it gets to Approved. With this in place, a great deal of your internal administrative work can be accomplished just by calling up a list of items with a particular status. You can sit down as a team and do this. Check what is in progress and see how they are coming along. See what has been approved but not tackled yet -- and find out why. Look for items witht he priority urgent and make sure they jump to the top of the queue. Voila: Order out of chaos.

Turning Help Desk Tickets into Business Intelligence

I was claiming that getting your informal help desk operation organized with a ticketing system does more than streamline that operation - it provides information that can increase your organization's effectiveness. It can have a real impact on mission. So what information do you want to track in your help desk ticketing system? Of course you need to know who reported it, how they described it, when it came in, who worked on it, and how it was resolved. But the key is to know what type of requests you are getting, and how much time you spend on each. The values you allow for request type, and whether you allow for a single type or multiple tags, depend on the knowledge you hope to gain. You are trying to partition your universe here, so that you can learn how many and what kinds of problems each area spawns. You might begin for example with a very simple set of issues. Networking and Hardware Issues. Office Suite Issues. CRM and Database Issues Website Issues Then break out areas you have specific questions about. For instance, if you are trying to verify that you spend far to much time on new user setups, you might want to break that out on its own. Or if you feel you are inadequately protected against vius and malware attack, add malware protection and recovery to the list. Maybe you want to distinguish between problems that had to be resolved by a vendor (like software bugs) and which you could resolve in house. Which types of problems you worked on gains more meaning if you log the amount of time you spent in each ticket. Then you know things like: in the first quarter I spent 10 hours helping people search for documents they misfiled, for a cost to the organization of $400.00 of my time and an estimated additional equal amount in lost productivity. So finding a tool that helps with this problem could be worth up to $3,200 a year to us. Of course you won't know today what questions you want to ask of your data six months from now. So you really ought to allow for multiple topic tags. For example, if a user reports a problem with scanning credit cards, you may want to tag the request with numerous related terms - Point of Sale, Credit Card, Payment Processing, and Accounting. And you probably want to allow for a full text search of the description, in case you are looking for a term you had not thought to use at the time. Now you are really set to answer questions about the support your IT infrastructure has required. Next we'll look at how the ticketing system can help you deliver that support most effectively.

The Non-Profit Help Desk.

Every organization -- no matter how small - needs to have an IT Help Desk of some sort. Actually, every organization already has one, because everyone on staff has figured out "Who ya gonna call?" when hardware or software refuses to behave. A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function. I'm not saying your help desk needs more technical skill. Not at all. As the Wizard of Oz might say, "The non-profit sector is full of help desks that have no more technical skill than yours has. But what they do have that you do not is a Ticketing System. It's remarkable what even the simplest ticketing system for tracking user requests will do for your informal help desk operation. The users benefit because their requests are less likely to slip through the cracks. Having a formal queue of requests reduces the panic element in support, and this immediately makes the system more efficient. for the entire organization. But it's the knowledge you gain over time from the ticketing system that is the real benefit. A ticketing system lets your organization track what kinds of support requests are coming in and who submits them. It allows them to know how much time is spent in the aggregate, and on specific types of support. This information provides real business intelligence pointing towards I.T. improvements that you know in advance will save staff time and thus have a positive impact on mission. What should a Ticket include? More coming up.

One Laptop per Child meets the Competition

A lengthy article in the Wall Street Journal highlights the effect that the One Laptop per Child Initiative has had on the pc industry. The background if you haven't been following: OLPC is a non-profit venture started by the MIT professor Nicholas Negroponte to create laptop computers that could be sold for $100 each and put them in the hands of millions of schoolchildren in less developed countries. The program has had it's critics in the past - educators have worried that the initiative would compete with scarce dollars needed for books and classrooms in the third world, and that the pcs would simply pass through the hands of schoolchildren and be traded on the black market. But the current article points to one of the unexpected results of the initiative... competition from mainstream vendors who do not want to miss out on this possibly lucrative market. In particular, Intel, whose chief rival AMD provides the processor for the OLPC machine, has launched its own "Classmate" laptop, and is winning support from the governments of many countries OLPC expected to sell to. In addition, education ministries in some of the target countries have been wary of the Linux OS and custom-written open source applications on the OLPC, fearing that their students will not learn the Windows and Office applications that are so prevalent in the business world. The result is that low-cost laptops are being sold to schools in many developing countries today, but surprisingly few are OLPC units.

Asthma Free School Zones

One really simple way to use less fuel and improve air quality is to avoid using your vehicle's engine - except when driving. Seems simple enough, but our friends at New York's Asthma Free School Zones have been finding it quite a challenge to get this message across. Focusing on the idling of school buses in front of elementary schools, the organization has been able to demonstrate that the air quality at the schools is measurably worse than just a few blocks away. And statistics show a mounting rate of childhood asthma. So remember - idling gets you nowhere. Here's a recent clip about the organization's work from News 12. For more information, you can contact AFSZ at 212-533-6615