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.

Here’s a really interesting web application made for the graphic designer’s workspace. ConceptShare created a web application playground to present visual design among interactive users in order to communicate design and gather feedback.

ConceptShare seems like a great communicator tool between designers and their clients. Most designers prefer to meet with their clients in physical space when presenting visual designs, but there are times when that communication needs to happen over the phone or e-mail. This could lead to potential confusion and time loss. ConceptShare solves this problem by allowing designers to import multiple desings and chat with multiple clients at the same time. Each design sample can have multiple comments and drawings on top of visuals that are well organized.

ConceptShare works well not only for designers in their professional field, but also for students taking e-learning classes. Although you have to send your e-mail and wait for a registration request, it’s still worth the wait-time to try out this web application.

Sitemaps are a fairly typical method interactive agencies employ to communicate website structure and content flow. Sitemaps do a fairly good job at communicating the site architecture on small to mid sized websites; yet they are somewhat unwieldy for larger sites, so try this approach.

At Imulus we use OmniGraffle to quickly develop sitemaps for our clients. For large sites we approach a sitemap in various phases.

Phase 1: The General Overview
Work with the client to define the top level and sub level content structure. Focus on the priority and the organization of which items will appear in the top 2 levels. Often you will find this is the most time consuming area to find agreement on.

Phase 2: Breakdown Each Section
Take each section and develop a separate sitemap dedicated to that section. This will allow you to focus on the specific content under level 3 and 4.

Phase 3: Change Management
Get client sign-off on phase 1 before moving into phase 2. This *should* help in controlling changes which move content from section to section. Get approval on phase 2 by section. For instance, work on the product section first before moving forward into the solution section or the support section.

Hopefully this process will help you better define site architecture while minimizing changes.

After the architecture and logic of an application, comments are the most important factor for scalable, efficient, and reusable code.

Any developer who has worked on large, long-term, or evolving projects understand the value of commented code. Any developer who hasn’t should too: just about every coding book, in every programming language, advises it.

I’ve recently (re)developed a few legacy projects with less-than-perfect code. By itself, this is fine – I work through the logic the code and figure out the code’s intended goals and refine and improve it as I go. But if the previous programmer would have commented his or her intentions – no matter how erroneous or inefficient the code is – the process of improvement and refinement would have taken less time and been more efficient.

Commenting – although it can add negligible time to production – can save countless hours of future maintenance down the line. Comments also help scalability by promoting efficient, well-written code.

So please, write pretty code – very pretty code, if possible – like Martha Stewart would. You’ll save your organization, company, and yourself time, effort, confusion, and money down the road.

So many times I’ve been in sales meetings fielding questions about the size of our company (5 people). Often the client has the perception that the larger the agency the better. Here is my contribution to put this myth to rest.

First let’s set a few assumptions. We are talking about designing and developing a corporate level website or web application, I’m not talking about enterprise applications which several teams are working on various facets of the project, i.e redeveloping NASDAQ.com or Amazon.com.

Size will always be an issue to the customer. I don’t care if your company has 5 or 80 people. There will always be a competitor larger then you. Truth be told, many larger agencies will use teams of 3-7 people to design and develop the project.

I have yet to find an interactive agency using a team of 10+ people at least 50% of the time on a single corporate website redevelopment project. Small teams are nimble, responsive and they communicate easily without meeting 24-7.

Prior to Imulus, a few of us worked for the interactive agency, Refinery, outside of Philadelphia. While at Refinery we successfully tackled projects which spanned from movie websites to Fortune 500 clientele with teams of no more then 6 people. Teams of 3-7 people are small and nimble, that is why they work so well.

The other myth I often run into is that a small company cannot develop as quickly as a larger firm. Again, simply untrue. Given the fact that most teams are 3-7 people, development usually takes the same amount of time regardless of how big the agency is.

Lastly, the myth about number of projects active at any one time. The perception is that a small company is easily overwhelmed by just a few clients; whereas the larger agency can handle a greater demand. Again, untrue.

Regardless of size, any company is going to need to find continuous revenue. There crux in the difference between any agency is how well they balance the workload between current work and new work. This however is not easily evaluated by the prospective client. It comes down to a personal level and the trust the prospective client feels with the selected agency.