We came, we saw, we concurred
Loosely Typed in Ohio

Culture, Marketing Easy way to improve customer service

Do Not ReplyImproving customer service can be hard and expensive, because most companies start with things like six-sigma, re-training call-center employees, or improving CRM software.

But nearly everyone has plenty of opportunities right under their nose. Take for example, the classic email address: DoNotReply@CompanyName.com. Organizations that use this address for billing, ticketing, and notifications could just as easily use the same address they use for support email. They'd be rewarded with fewer phone calls and happier customers.

I can just imagine how this started: back in 1995 someone in IT at Time Warner discovered a huge pile of email sent to a billing REPLY-TO that everyone forgot about and decided to end the problem once an for-all. Now, some of the best companies do this without even thinking about it.

The point isn't that this email address is hostile to customers. The point is that getting back to basics by imagining things from your customer's standpoint is a cheap, quick, and powerful way to improve your company.

For fun (or depression), search your inbox for 'DoNotReply@*'.  

 

Culture Linux User Group (COLUG) meeting tomorrow at Innova

COLUG at InnovaWe're looking forward to the Central Ohio Linux User Group meeting at Innova HQ tomorrow. Hoping someone brings a new iPhone.

As usual, Katzingers, beer (Belgium Wit for this week), and free downtown parking.

Software Unimpeachable software development

As a lazy community-minded developer, I generally prefer open source solutions to bespoke applications. So when we found ourselves needing a content management system, you'd think I'd choose a nice open source solution such as Drupal or Joomla and adapt it to the project requirements.

It turns out that that would have involved a lot of adapting. There were also elements of other open source packages - MediaWiki for example - that we wanted to see in the CMS. In short we wanted the moon on a stick.

Continue Reading…

Design, Software Writing meta-use cases

codereview Update: some folks on our team let me know that the tone of this post seems very negative. That's not my intention, and this project is still going great :) Heavy handedness aside, what I'm trying to communicate is that it is important to think about everyone that needs to live with a technology solution , not just the actual users. And Agile needs to accommodate this truth. That is all.

Sometimes a project at Innova reminds me that we don't do everything particularly well.  I'm always glad when we can get back to building sensible technology solutions, but it would be a mistake not to learn something from these tough experiences.

We began a new project for a major long-term client with our typical high-level system specification.  Standard practice for us, this artifact of our design process describes the use cases which led to the system spec, and sketches out a preliminary interface through a rough prototype implemented as html.  In our normal Agile practice, this document helps get everyone on the same page at the start of a project, and it is gradually "taken over" by a working system.  

This process works, and our customer had experienced it repeatedly.  The thing was, on this project, we were working with the IT group-in the past, we've always worked with business units at this client.

IT departments have different priorities than business groups.  Whereas business folks care about development time (minimizing it, that is), usability, and strategic advantage, an IT group may be more focused on fitting a solution into their support organization.  This means they don't want heterogeneity in technologies, and they don't want approaches that make auditors and future bosses raise their eyebrows.  In short, they want to buy IBM.

Which is fine.  We use stable, mature technologies and think our software is among the best designed in the industry, using high levels of code separation, DRY, and a predictable MVC design pattern.  But that's not what this post is about.

This post is about the difficulty we've had communicating that our solution meets the needs of the IT group too. So, where did we go wrong?  I think the answer is simple–we didn't consider the IT folks in our user-centered design documents.  We forgot that they're users too.  Not in the traditional sense, but in a kind of meta-sense–just like others, they have unique goals, and a design that doesn't accommodate their needs will fail.  Similarly, a design that doesn't communicate its efficacy for these meta-users won't get purchased.

Here are some things we'll think about next time when considering meta-user needs:

  • Is the customer comfortable with the technology approach?  To be clear:  Can the customer defend the technology approach to people who might criticize it?
  • Does the project allow everyone to feel like a respected, useful contributor?
  • Is the customer comfortable with their role in training and support?
  • Does the customer feel that their resources are used as fully as possible to drive down cost and aid in knowledge transfer?
  • Will the project result in the required artifacts needed for things like Sarbanes Oxley, regulatory compliance, and professional standards?  Have we made life easy by packaging these up for the client properly?
  • Does the project align with mission statements, charters, and organizational budgets?
  • Are the stake-holders comfortable that they'll know where the project stands at all times?
  • And most importantly:  Did we listen carefully to everyone?  Are we confident we know what each stakeholder needs to make this project a success?
After writing  for these use cases, we'll be careful to communicate the plan clearly and slowly, making sure everyone understands.

Part of being a professional is aligning your actions with the customer's needs.  Adopting an Agile development approach without consideration for meta-user needs is the kind of Agile development that gives the whole process a bad name.  And the kind of business practice that is sure to lose contracts.




Software Sometimes, I Hate Microsoft

SQL Server Enterprise Manager Error

I tried to startup Enterprise Manager this morning (in my virtualized copy of XP through Parallels) and was greeted with this error message, followed by another stream of messages, followed by the program crashing. As a programmer, I know what this means, but your average user (even one using SQL Developer Tools) may have no idea what the hell’s going on here. But I’m digressing; this isn’t a rant about Microsoft’s shoddy user experience.

The problem is that I didn’t do anything to these DLLs. The only things I did system-wide since the last time I successfully ran Enterprise Manager was upgrade to Parallels 3.0 and install Dawn of War: Dark Crusade to test out the new DirectX features in Parallels. Neither of these should have screwed around with these libraries!

So, annoyed, I had to reinstall Enterprise Manager to fix it. …except it didn’t fix it. I’m still getting the error message, and it still won’t start, and at that point I was actually starting to become behind on work because of it!

That’s what gets me — on Mac OS X (or, technically, a NeXTSTEP machine or any similar system) any custom libraries would be included in the .app bundle, so I wouldn’t have to worry about randomly corrupting some libraries and a re-install would fix it if it did happen.

So, lazyweb, is there any way to fix this?

Close
E-mail It
Socialized through Gregarious 42