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…)

I’ve now been using SantexQ beta for 24 hours and thus far, pretty darn good for beta and all-in-all a useful tool. I was introduced to SantexQ by one of the comments posted by a reader of our BaseCamp article. The comment couldn’t of come at a better time. We are currently working on our own task management program developed around the way we work. We are developing it out of a need to replace BaseCamp (we’ve outgrown it’s use) and to offer yet another program for task management.

Pros:

I like the overall organization of the system and how it places tasks at the center of the project management process. It is easy to setup and start using. In under 15 minutes I added our team, a few clients and a handful of tasks. Best of all the system is free. I hope it stays that way.

Cons:

The date selector on tasks didn’t allow me to directly enter the date, I was forced to use the calendar tool instead. I feel like the task add page could have been shortened up if organized more efficently and I also wasn’t a fan of the fact it required me to add various fields, like a description. In some instances, a subject is sufficent enough.

I didn’t look at the tool’s billing / time-tracking features because we use ClickTime, and that product is hands down the best tool for time-tracking.

I certainly encourage our readers to give it a try, especially since it’s free.

Since leaving Refinery in 2002 to help start Imulus, I’ve been on a quest to find decent project management software for OSX. At Refinery all project management was handled in Microsoft Project; however when we started Imulus, I chose to go with OSX as my primary operating system which then severely limited my project management software options.

I first started with FastTrack Scheduler only to be very disappointed in it’s usability. We then decided to use 37Signal’s BaseCamp, which we still use today. There is however limitations with BaseCamp. It works very well as a client facing tool to manage deliverables and thread conversations yet it fails at managing large projects with various task / activities and resources.

I now believe I’ve found the perfect answer to my project management woes, Merlin2. I started using this software 2 weeks ago and it is immediately intuitive, easy to use and it produces excellent reports which clients and project teams clearly understand.

Merlin2 has all the primary features that Microsoft Project and then some. Other then the reports, two of my favorite features are the utilization view and the document versioning. Under utilization view I have a quick visual as to the resource allocation across projects. The document versioning let’s me save edits on my documents as various versions so I can have a documented history on the project.

I highly encourage any project manager or development lead to give Merlin2 a try. I’ve been extremely pleased by this well built, intuitive software.