For a long time here at Imulus we had trouble keeping track of internal company information. Client datasheets, software licenses, Imulus specific programming tips, bug tracking, email setup documentation, employee calendar links, etc. This problem was not something isolated to just us, every work environment I’ve been a part of has struggled with documenting and finding information. Generally the solution ends up being a massive repository of excel documents or a shared hard drive full of text files and snippets. Neither of these solutions are practical or scalable.

Our answer to this problem was an internal company wiki. Our goal was to have a central resource that was easy to update and easy to get information out of. It needed to be searchable, easy to edit, and secure. Being a .NET shop we decided to go with ScrewTurn a free open source wiki for .NET environments. A few other alternatives are: Wordpress plugins and hosted solutions such as pbwiki.

We’ve been using this solution since last August and it has been a huge time saver. Our project manager no longer gets flooded with requests for, “that spec requirement the client sent over,” and our programmer’s no longer have to use local text files to keep track of bugs in their code.

For years we have always done milestone approvals either by verbal approval or simple email confirmations. When I used to work at Refinery (now G2) we tried doing the legal / contract version of project approvals. I found that method to be cumbersome and difficult to quickly deploy. We’ve decided to try something new and I think it’s worth sharing. We’ve decided to use Wufoo. Using this service we can share pre-developed approval forms which log client acceptance along the development process.

I’ve blogged about Wufoo in the past. I think these guys are one of the most underated Web 2.0 companies out there. Their interfaces a rocking and their shit just works real well. We’ve setup about 14 pre-defined forms, which can be shared with our clients for approvals which take less then 30 seconds to read and submit.

Here is an example.

Here is what we are hoping to achieve with this shift in our process:

Deliberate Action. It’s too easy for a client to just give verbal approval, or reply to an email. Filling out a short form is a deliberate step which requires the user to read before taking action. It falls outside the normal workflow enough to be memorable.

What am I Signing? A short explanation helps the client understand the impact of what they are signing without all the legal mumbo-jumbo of a contract. It’s enough to explain the point and nothing more.

What’s Next? Once signed, what does that actually mean to the client. This is a friendly reminder of the next steps which will be taken on the project along with a statement about what it means to give approval to this task.

Get to Know Us. A quick “Thank you” followed by a “Did you know?” We see this as another opportunity to interact with our clients in a way which helps us better know each other.

I sincerely hope you try using Wufoo to replace the old sign & fax forms of the 80’s. I’d like to hear the results if you do make the switch.

Tonight Jason Fried from 37signals spoke at the Oriental Theater in east Denver. He discussed everything from client deliverables to the 37signals four-day workweek. In essence, Jason’s talk boiled down to three key points:

1. Don’t work on hard problems. Break them down and keep things simple.
2. Avoid distractions (open office environments, meetings, e-mail, etc.) get a site or product out of your head and into production ASAP.
3. Deliverables are bullshit, clients don’t care, the end product is what matters.

First off, I want to say I have great respect for 37signals and their impact on the industry. Having the chance to talk with Jason about issues such as: stopping IE6 support, disregarding Photoshop in the design process, and scaling with growth, was an absolute treat. Clearly the team at 37signals is one of the most innovative and talented in the industry.

However, I think 37signals dominance in the web products field has distorted their ability to critique the client-based approach. And while I don’t have knowledge to speculate specifically on day to day client interaction, I do have a few things to offer from a developer perspective.

Team chemistry is important.

First, people working from home all the time can be harmful to the group chemistry. Jason and team do a huge amount of work via telecommuting. Relying on campfire, screen sharing, and video chat interactions for the bulk of their communication. They feel this helps minimize distractions and keep people productive.

I’m not sold this is the way to go. I think it’s hard to truly feel connected and dedicated to your team if you don’t spend real time with them. When’s the last time you became really good friends with someone without spending some serious face-to-face time with them? For me it’s never happened, not once. And as great as chatting online is, it’s not the same as being in the same room and hashing things out. You miss the subtle face gestures, the inside jokes, the bantering, and the all around comradery that happens in the workplace. Part of the reason Imulus does great work is because we have dedication to one another. Even on days when I’m completely out of wack mentally I still find myself focused on helping the team. Why? Because I’m relied on to help create the great stuff we build. And I trust those I work with to do the same. As ridiculous as our office gets sometimes in the end we get shit done and we do it for each other and ourselves.

Deliverables have a purpose, it just needs to be refined sometimes.

Second, I don’t buy that all deliverables are bullshit. Just as some companies like to skip Photoshop (37signals) and go straight to coding, and others (Apple) like to make mockups pixel perfect it’s impossible to say that one solution is better than the other. Yet, we can agree that certain processes work better for certain people as well as certain projects.

Let’s talk about the way we work. Imulus’ basic approach is to offer the client a timeline, design brief, wire frame, and mockup of the final interface. Now, it’s important to realize that we haven’t always done it this way. In fact, for some time before I came to Imulus the wireframe process was basically nixed. What was the result? Instead of 5 hours spent reworking things in the wire frame process, 25 hours was spent reworking things in the development process. Look, we aren’t naïve, we recognize that clients change their mind and get new ideas all the time. However, we’ve found that most of this re-thinking takes place in the wire frame stage. And therefore we save hours of coding changes by altering the approach up front. In essence, if you’re building a car and the frame is faulty, why wait until the upholstery’s getting put on the seats to fix it?

Still, we know it’s a strong possibility that some of our deliverables are blown out of proportion. And as most firms do we will continue to collaborate and narrow down our inefficiencies. However, we have found that some deliverables are an extremely important step, and just because some projects or companies don’t require them doesn’t mean they aren’t important.

In conclusion

Clearly 37signals has clout and track record to support the way they work. And regardless of how that alters the Imulus process we love hearing about it. It’s phenomenal that they have so much passion behind what they do. I hope over time we can refine our own process to the point they have. Until then it’s great hearing a second opinion about things.

So, I would assume most Account Managers, Project Managers, and anyone else in client services all know about (and occasionally create) call reports. However, I’d be willing to bet that eventually almost all of you have given up on them. I know, from personal experience, that the call/meeting report is thought about and started with good intentions. Inevitably, however, it ends up being one of the first items to slowly fade away. While it appears to be a good idea, it always seems like a waste of time, and the easiest task to drop. You get busy, and bogged down with tasks, and figure “who really reads these things anyway?” Well, as much as it may seem like extra, unnecessary work, I can say it is one of the best tools anyone in client services can use.

For those of you who have never heard of these, it’s basically a summary of a meeting, phone call, or even quick discussion you’ve had with a client. (It doesn’t hurt to do this with internal meetings too.) After every meeting, send a summary and list of action items to your team and your client. Trust me. It’s worth it.

The call report does NOT need to be an extensive document. It just needs to cover the basics. If you have a client who tends to “forget” what you talked about, you may need to be a bit more specific. No matter the level of detail, just do one. Every time.

I can’t tell you how many times there has been a conflict about what we decided, a task unassigned, or a lack of follow up on an urgent request. With the call report, this is practically impossible. I have had times where the client was quite upset with a situation and couldn’t believe we chose to go down a certain path for his design. Based on a meeting we had over two months ago, I vaguely remembered him requesting something along those lines, but I honestly had no idea what we decided. I feared we were in for a huge change (and a significant loss of money). Low and behold…the magical call report. I pulled up the old document that was sent to my client the day after the meeting, and copied the exact statement saying he agreed to the change. Not only did he insist on this change, but he also agreed that it was out of scope. The call report saved us hours of headaches and a bundle of money. This is not just a random example. These types of things happen at least once a week, and the meeting report has saved my team, my company, and myself a lot of problems. So, I beg of you. Take the time. It’s worth it. And who knows? It may even save a life or two.

Why is it that we all seem to allow for things to go undone for long periods of time? Personally, I’ve been guilty of leaving small tasks, which might take 2 hours to complete, go undone for over a year. Am I a lazy person? I don’t think so but then again I have been known to push a few things off which could get done here and now.

I’ve had to question what makes some tasks rise to priority while others just hang in the background for what seems to be eternity. In reflection, I’ve arrived at these insights. (more…)