Keys to success in technology projects

This week Jeff Atwood has a great post in his Coding Horror blog, excerpting from Steve McConnell's 1996 book Rapid Development. He quotes a list of "36 Classic Development Mistakes" that can doom your project. I've had to extricate teams (and I admit it, myself) from many of these over the years. Jeff and Steve are thinking about software development efforts, but any technology project is prone to these mistakes. Avoiding these mistakes are the keys to success. Three biggies I've struggled with are: Heroics. This is probably the most common software mistake of all. A project looks like its going to need four more weeks of work. There are two weeks left to delivery date. Solution? The team works 16 hours days for 15 days. The result? The deadline needs to be slipped after all, a lot midnight code needs to be reworked, everyone is raw and ragged, and developer-user relations are frayed. Programmers are by temperament very prone to heroics, but users can encourage it by reluctance to modify deadlines when necessary. Key to Success: when schedules start to slip, accept reality and make adjustments. Insufficient Risk Management. As the authors of "Waltzing with Bears" note, every worthwhile software project carries significant risk -- or it would already be done. Developers often gloss over risks due to what my wife Doria calls "the hot dog factor" - the assumption that nothing will go wrong because they are real hot dogs. And users hide from risks because they do not want to confront them, plan for them, or call them to their superior's attention. When a problem emerges, it blindsides everyone. Key to Success: you really do need to plan for those unpleasant possibilities. Feature Creep. This one has be written about so often that it is easy to forget about - then you see it happening again. Users and developers put in a lot of hard work together to specify the desired behavior of the some new application. The as release date looms, there are more and more features user's can't live without. It may seem like its just correcting design shortcomings or adding flexibility. But release dates are missed, new bugs are introduced, and unintended consequences of these late change are discovered at the worst possible times. And when features do not seem to cost anything to users, all bets are off - there is no way to consider the return on investment of the development effort. It's easy to blame feature creep entirely on the users. But developers can encourage creep if they do not have clearcut process in place for tracking and accepting user requests. And they're setting themselves up for last minute change requests if they don't check in frequently with users as they work to make sure they are on the same page. The moral: You need a well-defined process, and supporting tools, for tracking and managing your user's requests. image originally uploaded as: http://www.flickr.com/photos/nicohogg/344155950/

Getting your Message Across: : A Link Roundup

There's a lot of talk about accidental techies nowadays. But the non-profit world is also full of accidental marketeers: people who are experts in their subject but struggling beginners when it comes to selling their organization's programs to donors. This first half of June the blogosphere has been full of tips to help the accidental marketeer. 1. Underpromising A few days ago The Agitator talked about the current marketing maxim advising companies to "underpromise and overdeliver" and wondered how this applied to non-profits. How do you understate or modestly state your need, its urgency, the unique effectiveness of your approach, or the impact you expect to have, without getting drowned out by your more shrill or flamboyant competitors? An interesting question. It would seem to me that that underpromising does not mean to play down the need, or the quality of your approach. It means only to avoid making specific quantitative promises you might fall short on. There is no need to understate the devastating effects of Malaria. And by no means play down your great idea of placing health aides in popular cybercafes to provide information and sell treated nets to customers waiting for a p.c. But if your goal is to train and place 50 of these folks in the first year, promise 35 in your literature. Then do better. 2. Headlining A List Apart, a site devoted to website design and technique, focused recently on some very non-technical aspects of online marketing: the effective writing and and layout of web pages that sell your message. As they say, A lot of web copy is written by copywriters who aren’t trained in writing for the web—and much of the rest is written by people who aren’t trained writers at all. The article begins with simple advice on writing headlines and moves on to discuss an entire menu of techniques for writing online marketing messages. 3. Getting people talking The book is sandwiched between a forward by Seth Godin and an afterword by Guy Kawasaki... how can you not want to check out what these two communication gurus are endorsing? Word of Mouth Marketing: How Smart Companies Get People Talking, by Andy Sernovitz is a quick read that will get your head buzzing with ideas about how get your communities buzzing. For example, they remind you to reach out to all those bloggers you read, and tell them your news. They just might pass it on. Like this. But the book is full of far more surprising ideas that organizations have come up with to get their message out there. 4. And helping others talk less. While it's your goal to get your community talking more, some of us tend to talk on and on. Kivi Leroux Miller says she's found that about 60% of people complain that their writing is to verbose, and she provides six smart tips for pruning your prose. If you find yourelf doing more and more writing on behalf of your organization, you ought to pay attention to her blog, Non-Profit Communications. 5. Non-Profit Market Research. But whoa! Before you start writing, editing, and launching campaigns, do a little research first. Think market research is only for rich organizations? Check out Katya's Non-profit Marketing Blog. She can show you four things you can do for free without leaving your office that will leave you with a good bit more information than you started with about your organization and its brand. image originally uploaded as http://www.flickr.com/photos/dewayne_smith/433951055/

When is an email campaign SPAM?

I wrote about this a while back but I still frequently hear our clients worrying that every email they send out might be violating the CAN-SPAM act. Calm down. The law does not prohibit the sending of unsolicited commercial emails. It does not require people to opt-in to an email list in order for you to communicate with them. What it does do is set some very clear requirements that your unsolicited commercial email must meet. You must provide real, working FROM and REPLY-TO email addresses. You must provide an opt-out mechanism so users can request an email stop. You have ten days to act on such an opt-out request. You must provide your full postal address. Your must not use a deceptive subject line - it must make it clear the email is an advertisement or a solicitation. The law also prohibits the automated harvesting or generation of email addresses. But what the law terms "transactional" or "relational" emails are exempt from the CAN-SPAM law's requirements. That means a follow-up to a transaction (a confirmation, thank you, receipt, etc) does not require an opt-out or a working reply to. Nor does an email sent to someone you already have a commercial relationship with, if it is not a solicitation. In the last few months, one of our clients worried they were spamming if they emailed overdue notices to their members. Another was afraid that they could not send an email touting the launch of a new program to their existing donor list. Both of these are quite legal. The first is a transactional email not covered by the law. The second is an advertisement or solicitation and requires that you meet the opt out and other guidelines. But just because you meet the legal requirements doesn't mean everyone will be happy to be downstream of your communications. As a marketer, that should worry you even when there are no legal issues involved. As Wendy Roth says, Recipients hold email senders, whether political, non-profit or commercial, to a higher standard than what is required by the law. So use some common sense when launching an email campaign. Limit the frequency of your unsolicited messages. Target your communications so they will be genuinely useful and interesting to the recipients. And make sure you meet the CAN-SPAM guidelines when they apply. There is a nice synopsis of the CAN-SPAM act posted at the Federal Trade Commission website. Spam image originally uploaded as: http://www.flickr.com/photos/pe5pe/59398685/

Estimating Programmer Time

I've had a few questions in my mailbox recently about this subject -- and as leader of a company that provides software development services, it's one that is dear to my heart. Our usual way of working with our clients is to estimate the time required for any requested programming task, and to guarantee we will come in within 20% of that estimate. So arriving at an inaccurate projection can really hurt. The good news is we've gotten better at it over time; the bad news is that it is not easy, and there will inevitably be occasions when a task takes much longer than expected to complete. Here's what we've learned over the years. 1. The starting point - look at how often you underestimate and compare it to how often you overestimate. You aren't really surprised, are you? All developers have a tendency to underestimate how long a task will take. Programming provides one of the most clear-cut examples of that oft-stated law: "Everything takes longer than you think it will, even when you take this law into account." Understanding the factors that lead to this is the heart of becoming a better estimator. 2. The most important tool you can have handy when trying to estimate is a database of how long things have actually taken you in the past. If you do not track your time - your entire group's time - against specific development tasks, you should start doing that now. 3. Estimate in pairs. Your accuracy will go way up. 4. Here's the key: remember that the bulk of a programmer's time is not spent actually writing the new code, but in (1) figuring out how the existing program works, (2) determining where to make the change, (3) verifying that the change actually works, and (4) debugging any problems found. These are the times that are hardest to control, and are the most often overlooked: novice programmers habitually underestimate the likelihood that problems will emerge in testing. 5. To manage this, include estimates of "design and analysis" time, and "testing" time, and assume some time will be needed for debugging -- even in what seem to be the simplest modifications or enhancements. Remember to include time for defects found not just by the programming team, but by customers and end users after the item goes into production. 6. Be willing to revise the estimate after the initial few hours of the work. Perhaps the estimate was based on the idea that some new components could be dropped quickly onto a form. But it turns out the form is so crowded with widgets and gizmos that it needs to be completely re-structured. If good estimates are needed to track costs or delivery dates, programmers need to become alert to the fact that discoveries which will affect development timelines need to be reported immediately so other stakeholders can revise their expectations. image originally uploaded as http://www.flickr.com/photos/aarongeller/360135019/

Five tips for software systems training

My good friend Adriano Pianesi, the former trainer at Members Only Software, has taken the bull by the horns and announced the creation of his own training consultancy, Participaction. Take a look at this site - you'll see his approach goes way beyond drilling users on what button to click when. Adriano and I have had some long conversations over the years about how to best provide the training organizations need to make effective use of their information systems, and he led us in experimenting with a lot of different ways of doing training. We've led some awful sessions and some great ones. Eventually, we found that traditional classroom training was rarely the solution. Here are some of the things we learned: 1. Information Systems training needs to focus more on organizational policy and business practices than on technology. It's easy to teach someone how to issue an invoice. But who is the customer? When are invoices issued? What should you do if the system warns that an account code was not set up properly? Without this kind of knowledge, your users will have a long slow climb to productivity on the new system. But its not the software guys who know this. So the training needs to be a collaboration. 2. Information Systems rollout trainings need to include a change management component. Mission critical software rollouts have broad implications for the way people work. Otherwise, why bother? But to say "this will make our work easier" or "these tools will help our teams collaborate" just skims the surface. The users know the new system will alter their day-to-day lives. They may be eager for the change, afraid of it, or just plain resentful of the disruption. The training is a time to prepare for procedural upheavals. 3. Training needs to be active and interactive. Presentation and drill on the workings of the system are boring and ineffective. Training sessions need to actively engage the user from the first minute. We found, for example, that a treasure hunt -- plopping the users in teams in front of the new system and asking them to figure how to find things was far more effective than a presentation of where key information is to be found. 4. Your organization needs a plan for ongoing training. This is an area we see most organizations neglecting. Everyone knows they need new system training. But how will you deal with staff turnover? After a couple years, some of your key users will move on, and you will have new staff members who come in and find the system already in place. You need to create sustainable plan to train these new staff members without constantly paying someone from the outside to do it. You need ongoing training for other reasons, too. Staff forget things they learned but have not been using. And the software has seen a few updates by now - are you sure you are getting the full use out of your applications? 5. The answers to most of your ongoing training needs are already in your organization. The ongoing training is not as difficult to organize as you might imagine, because someone in your organization knows the answer to almost every question someone else has. The challenge is to make the knowledge accessible to your users. We did an advanced users training a few years back at one of our YMCAs. People were asked to submit questions in advance - and we got 56 of them. At the training, we broke the sixteen participants into tables of four and randomly distributed the questions to the tables. Each table was to present to the group the answers to the questions they'd been dealt. If no one at the table new the answer, they'd solicit help from other tables. On only 6 out of the 56 questions was our help needed at all. So the real issue had not been training in the traditional sense - but simply setting up a structure for sharing the information. image originally uploaded as http://www.flickr.com/photos/leighblackall/76202405/