NTC Seattle - Another Day

Day two at the NTC. Got to meet a couple more of the bloggers I enjoy following: David Geilhufe of Social Source, and Sonny Cloward of Vermont NonProfit CommunIT, at a session on open communication technologies. Lynn Stott, who has the terrifying task of overseeing the redesign of Techsoup's website, also facilitated. It was a great opportunity to listen in as NPOs discussed their experience introducing blogs, forums, or other avenues of community input on their sites. Three pieces of valuable information I took away from this session were - 1) As the online community grows, it will become more self-policing. There is a point in the growth curve where it may look like things are spiraling out of control, with inappropriate postings and hostile comments by "trolls" on the increase - but when the site hits critical mass, such abuse will diminish as users set norms and take increased responsibility for the culture of the site. 2) As your site grows, leaders will emerge who can be given administrative rights as volunteers to delete posts, reorganize threads, and ban repeat offenders from posting. 3) An effective way to test out open content without undue risk to your established, more conventional site is to create a secondary site for the more experimental activity at a different URL. Numerous organizations described setting up "Sandbox" sites of this sort, and rolling them into the main site or discontinuing them based on there success. Sad to say, Beth Kanter, who I met face-to-face for the first Wednesday, had to leave early because of the death of her mother-in-law. Doria and I had a chance to take a pic with her, and our thoughts are with her and and family. Tags: nptech, web2.0, ntc

NTC Seattle

Taking a break from the NTC conference in Seattle, staring across the harbor from our 27th floor room in the Westin... the best thing so far has been meeting face to face people in the technology community I've known virtually for a good while... people like The West Coast Michael Stein, Deborah Finn, Beth Kanter, and Laura Quinn. And I got to have a good chat with Shaun Sullivan, the CTO of Blackbaud. We've also been asked to make a presentation of MEMBERS ONLY at the office of a local Seattle org later today - as an entrpreneur, I am very gratified, but I hate to miss a session here! More later.

What's the problem?

Sitting in drizzly Seattle. Tomorrow is the NTC conference, but today is just a lazy day off for me. Thought I'd polish up and post this blog entry on problem solving that's been hanging around half written... One of the things I notice working with our users is that some IT folks are born problem solvers and troubleshooters, and some aren't. I often wonder if technical troubleshooting skills can be taught, and what the best way is to do that. I've also been thinking about this issue because, as I pulled together some marketing material for our NTC Science Fair exhibit, I noticed as I have before that when we ask our clients for "blurbs of praise" to use on our web site or other materials, they do not so much emphasize the features of the software as our ability to help them solve real problems that come up in their work. I realize we are talking about two kinds of problems here. One seems more creative - a user has a business problem and we use technology to devise a solution. The other seems more reactive - its just maintenance. A technical problem appears, and needs to be resolved. But the more I've looked at these issues, the more I realize there is a core to problem solving that applies across the board. And there is no clear line between the two. Donald Gause and Gerald Weinberg wrote a cute little book a while back ago that tries to teach problem solving. It's worth a read by anyone who earns their living by solving other people's problems. And that includes both consultants, and on-staff IT people who need to solve their user's problems. They start by warning that the professional problem solver often sets out trying to offer a solution without having identified what the problem really is, or who really has a problem. When the client is an organization, there may be many people waiting for the solution, but each actually has a slightly different problem. Which one do you solve? Shigeo Shingo is another writer who can change the way you approach problem solving. He was a Japanese expert in manufacturing efficiency and a top Toyota executive and had some radical approaches to problem solving. For example he thought it was just as easy to try to cut the time a six hour process takes to three hours than to five and half hours. If you ask a team to think about a more challenging solution, he always found, they think more creatively and ask more penetrating questions. Like Gause and Weinberg, he was also very big on helping people realize the danger of trying to solve a problem before they had identified it. One of his most remarkable stories: he was called in by a plant manager who complained that no matter what they did, a certain machine broke down every few days, stopping the line for hours. They'd repaired it and replaced it half a dozen times, but it just kept breaking down. Shingo asked the manager if the solution was worth a day of his own time. "Oh, I've already spent much more than a day on this." So Shingo asked him to devote the next day to sitting in a chair on the plant floor in front of the problem machine, and do nothing but watch it go through its paces without making any attempts to intervene. After staring at the machine as it repeated its few motions over and over again for four hours, the manager understood exactly why the machine always broke down and had the correct suggestion for a minor redesign that resolved the problem. Although many days had already been devoted to "solving this problem", almost no time had been spent trying to ascertain what the problem really was. Shingo's emhpasis on "just sitting" with your problem may seem to be a particularly Japanese approach, but we see it in other very practical guides to problem solving as well. Charles Kozeriok has a web site devoted to PC repair that empasizes mental state in technical troubleshooting. I have personally seen many times (and often with myself as the subject) the difference between a person in the right mental state and one who is not, in the ability to identify and correct system problems. It can easily be the difference between a problem that is fixed in minutes and one that languishes for hours or days. Key to this mental state is getting beyond the sense of urgency. Being in "panic mode" makes it extremely difficult for you to work on solving the problem, and in many cases the panic will turn out to be unwarranted anyway....Panicking can also lead you to jump to a solution to the perceived problem before you really understand it, which can make matters worse. So once you've calmed down, what next? Coming soon - Michael's Rules for Technical Troubleshooting. We'll see they focus almost entirely on the central issue we've talked about here - clarifying the problem. Tags: nptech, troubleshooting

Links Roundup: March 1-15

Monitoring the Buzz: A Washington Post report on March 3 discussed how corporations are using sophisticated software applications to take the temperature of the blogosphere buzz about their products and services. If you haven't read it yet, Michael Gilbert's January article "Asking the Wrong Questions" is well worth the read. He takes up a theme dear to my heart - making sure that technology planning is about your organization, not about the bits and bytes. His pithy analogy: "Shoe sales folks rely on questions about feet, fashion, and walking (or running or standing), not questions about shoes." Products: On the non-profit tech lists I 'm part of I often see questions go by about selecting online conferencing software. I've been very happy with Citrix GoToMeeting, but I haven't done a comprehensive comparison of the available products. Matt McKenzie has, though, and you can find it here. The corporate interlocutors of many non-profit organizations are the CSR (Corporate Social Responsibility) groups within major companies. Kami Huyes recently looked at a few CSR efforts in her Communications Overtones blog. She also points us to the The CSR Wire, which distributes CSR related press releases and is a great resource on initiatives in this arena. Consulting: Steve Shu uses his blog to share insights into management consulting. In the Nickel Tour, he discusses the value of a complete tour of a client's facility as an information gathering method. And now for something completely different: an odd little English blog about breakfast joints. Tags: nptech

Keeping it simple

Just before Thanksgiving, I was holding forth about the hidden costs that organizations subject themselves to when they make their business practices and the software applications that support them needlessly complex. One of the very direct costs is in the increased difficulty these organizations encounter in training staff and in documenting procedures and systems. Yet I've always found that users are happier to spend a dollar to add a feature to their software environment than to train on using what they already have. Nontheless, software users know they need to do something more about training. Recently I had the very enjoyable task of working with Malin Coleridge at TechSoup to develop a questionnaire on the "Technology Challenges" faced by non-profit organizations. (By the way, 880 organizations responded - thanks to everyone who took the time to do so!) Last week Malin sent me the results. I don't think the Soupsters have posted them yet, but here's one datum we found: 73% of all respondents agreed or agreed strongly with the statement We need to develop a process and materials for training new users on our computer systems. How I read this: Systems have become so complex that training folks how to use them has grown into a daunting task, and just over a quarter of the non-profits responding felt they had this task in hand. It's not surprising: a recent study by a Dutch researcher showed that 50% of all consumer product returned as malfunctioning were actually working perfectly - they were just too complex for the customer to master. I see this in the Information Systems domain every day - users call us to report defects in the software when it is really working according to spec. This is true even when the function in question was developed closely with the users. Last week I was musing out loud here about that old developer's joke, "it's just what I asked for but not what I want". More to the point, maybe it's not what they really needed. Maybe it was too complicated, and reflected a business practice that is more convoluted and offers more options than serve any useful purpose. In the consumer study, the designers were blamed for the complexity of design. But maybe they do it because this love of complexity is widespread. At any rate, it seems clear to me that the IT conversation needs to be expanded, so that board members, end users, technology advisors, and developers all feel free to bring questions of organizational procedure into the discussion. Slowing the growth of complexity and making sure users are trained and have access to information about the system and organizational proceedures need to be listed among the goals of any further development work. Tags: nptech, complexity, training

Google Acquires Writely Developer Upstartle

Writely blog mistress Claudia Carpenter confirmed it in the Writely Blog on March 9th: Yes, we've been acquired by Google, and we're really excited about this for many, many reasons. And if you still doubted it, the byline on the Google Blog entry of the same date is pretty explicit: Jen Mazzon, one of the four Writely founders, is blogging as part of the Google Writely Team! To be clear, Writely is still in beta, and it's far from perfect. Upholding our great user experience means everything to us, so we're not accepting new registrations until we've moved Writely to Google's software architecture. So if you haven't tried out Writely yet, you're on hold until the move to Google is complete. I've been using it for about six months and it has a lot to recommend it. Most important, I think, is its collaboration model that let's you pick which individual users can share each document, creating a level of flexible security difficult to implement on your Windows LAN. And the docs can be uploaded from, or downloaded to, your desktop. In the wake of Yahoo's purchase of Flicker and del.icio.us, I think purchase puts an end to the vision some held that web2.0 would spell the end of the software giant dominance as "two, three, many small ventures offered innovative wares over the net. But it does seem Microsoft is going to have a tough battle to establish control of this space. And that's gotta be good for the rest of us. Tags: google, web2.0, nptech

Business 2.0 looks at The Next Net

Over coffee this morning I read some interesting new product reviews. After dismissing the term Web 2.0 as "defined and redefined into near meaninglessness by squadrons of aspiring entrepreneurs, marketers, and other fortune hunters," Erick Schonfeld adopts the term The Next Net to mean - well, Web 2.0. Writing for CNN's Business 2.0 last week he selected his 25 web companies to watch in the near future. Many of these are among the developers of the "new web" apps I've tried out over the last six months - Writely, 37 Signals, Digg - while others are companies with offerings I hadn't encountered yet. Usefully, Schonfeld divides his Next Net offerings he reviews into five categories, revealing the wide range of applications we've lumped together under the web 2.0 rubric - from social media to platforms for building real business apps. Quite a few of the products are the type of free or low cost tool we've gotten used to in the web 2.0 world: individuals sign up, easily create an account, and data can be shared with other users. But some are a different order of application altogether. For example, Newsvine is a read-write news site with a revenue sharing model for its members. Eurekster is a swiki - a customizable search engine you can tailor to your particular community and subject matter and host on your site. This site too offers a way to to make money from its use. This monetization of the web seems to be a big thing in the products the article selects. But Zimbra is a different beast: a web-based email system trying to enter the enterprise email space. Offering both client and server components, Zimbra couples web-based email with the calendaring functionality of outlook and a variety of workflow management capabilities. Zimbra, as well as some of the other products reviewed, is challenging not just what we think of the web, but how we conceive of our core business applications. The article is worth a read - and the products worth your own review! Tags: nptech, web2.0,

Responsible IT conversations

In my last post, I was pondering the problems in the communication process between users and technology assitance providers - problems that are so pervasive they have given rise to a whole series of internet jokes. The jokes all portray the technologist as the long-sufferering recipient of inadequate communication - if only the users could say what her or she means, everything would be fine. The techy whines that users are changing are requirements between communications, doesn't know a thing about computers, and fail to accurately convey what they want, or what problems are occuring. The problem with this picture is the techy's passivity: she assumes that the user alone is responsible for articulating his concerns. Only after they are articulated will the techy become responsible for providing a solution. But what if both parties accept full responsibility for both sides of the conversation? On the one hand, the technologist needs to accept that it is indeed difficult for users to be clear about IT issues, and be willing to invest time and effort into pulling out the complete picture when a support request is being made. It's part of the assistance we provide. The technologist also needs to accept that requirements will indeed shift inconveniently during a project, and that while there is no way to prevent this, there are many ways to adapt to it. Indeed, the current emphasis on "agile" methodologies is based in part on recognizing that requirements are always in flux. But the users could improve the IT conversation by taking additional responsibility as well. Just as the technolgists share responsibility for articulating the request, the users share responsibility for resolving it. And I really am just talking about responsibility, not of technical acumen. I can't tell you the number of times a user has said to me "I tried to do this, but I got a message". What did the message say? "I don't know, I didn't read it". Another form of responsibility is to take an active role in knowledge support relating to the Information System - user training, documentation of procedures and systems, and so on. We had a user call us from Boston once to ask if we knew which of the computers on their new rack was the database server. We had no idea that they HAD a new rack. Oops - I've fallen back into telling stupid user stories - but you see, they have nothing to do with intelligence or knowledge. They have nothing to do with stupid users, and everything to do with the organization taking ownership of its own system. This also means taking ownership of requirements shift. The Executive Director of a client once asked one of our programmers when we'd be able to quit making adjustments to the software. "This has been going on for years! When will this system be done?". My colleague answered him, "As soon as you quit growing and stop getting all these new ideas!" But it's easy for users to see each change they request as fixing an inadequacy in the system. This is the wrong conversation to be having. Quite a while ago, Chuck Bryan compared the typical technology conversation to the kid's swimming game Marco Polo. The person who is “It“ closes their eyes and yells out “Marco,“ and other players yell out “Polo. The “It“ player moves in the general direction of “Polo“ and then calls out “Marco“ again. By this time, the “Polo“ player has moved, and yells out “Polo“ in a new location. All I'm suggesting is the Polo's should admit they are moving. And Marco should open his darn eyes! Tags: nptech, agile, tech_support