Project Mismanagement: Lessons From a Near Disaster

Last Updated Jul 29, 2010 1:21 PM EDT


By Martin Davis, President of Ratchet, Minneapolis
When my partners and I founded our company in 2004, we were three guys who did everything from writing code to interacting with clients. As we grew, obviously we needed to become more efficient. But in the quest for efficiency, we focused too much on the process and not nearly enough on what our clients needed.

How it happened
We build marketing applications for mobile phone and web-based platforms. Our software development model dictated that one group of employees works with the customer to design and spec a project, only to hand it off to another team that actually builds it. There isn't a lot of sharing in this model, nor an opportunity for feedback between the different groups. And that frustrated a lot of our employees.

We got to a point late last year when we realized that our development model was actually causing more problems than it solved. The process was inflexible -- the teams weren't set up to share any new ideas, so altering a design midstream was a challenge. Our employees lacked a sense of ownership because they could only see the parts of a project they were working on.

What's more, our developers were seriously out of the loop. By the time they got to work on a project, most of the design decisions were already written in stone. That's a big problem: Many of our clients don't really know what they want, much less what's possible. If we're doing our jobs successfully, we help identify a client's end goal and help them figure out the best way to reach it -- whether that's building a new application for them, or just modifying an application that they already have. But with our developers out of the loop, we couldn't provide that expertise anymore.

So we asked ourselves, if this approach isn't working for anyone, why are we doing it? We decided we needed to get back to our roots -- but we had to make it work for all 40 of our employees.

When we look at it now it seems so obvious: Instead of siloing different roles, we mash the teams together. Put business analysts with developers and see what great ideas they come up with.

It felt as if the clouds had parted and we finally saw the sun. We could get back to giving employees ownership of a project from start to finish. And we could give clients exactly what they needed.

The best of both worlds
Our old project management strategy was called Waterfall. It imposes a linear workflow onto a non-linear process. It works well from an assembly-line point of view, but not from a creative point of view. The most common alternative is called Agile, which lets you complete projects in a piecemeal fashion. The work plan covers one or two weeks at a time and the client never really gets an idea of how much it's going to cost or how long it's going to take until it's actually done. Despite the creative freedom, the second option has some obvious drawbacks.

So we developed a path down the middle -- we're in the process of coming up with a cool name for it. It took a little over half a year to flesh out the concept to where we were ready to implement it. But it's been a huge success.

The strategy involves laying out a rough road map with a ballpark budget for the client, but each stage of a project is a one- or two-month sprint. Each of the stages has a smaller scope than you'd find in Waterfall, and as a result we can adapt to new ideas and changing needs, while still sticking to a predictable timeline. Business analysts are happier because it helps them give the clients what they need and the developers are excited because they get to help define the project as it moves along.

The team as a whole understands the client's ultimate goal. This is essential given that many of the major project advances in this industry are made by developers at 2 a.m. If a developer is on the same page as the client, then the chances are much greater that the 2 a.m. decision will be the right one.

Give them what they need
The success we've had has been easy to see from a management standpoint. It's contributed to improved morale, which means it's easier to recruit and keep the best people. That translates into better work for our clients, which will eventually contribute to the revenue side of the equation. In 2008 we posted revenue of $5.1 million, but we were down to just $4.6 million in 2009, largely due to the economic downturn. This year we're on track to hit $6 million, and I think the success has a lot to do with our new project management strategy.

One way we know we're on to something: Recently a client that was having trouble developing products in-house came to us to discuss outsourcing the work to our firm. But we realized right away that they didn't need a technical fix, they needed a strategic fix. They saw how we revamped our project management process -- and boosted employee morale in the process -- and now we're working on helping them do the same.

Martin Davis was born and raised in Anoka, Minn. His love of outdoor sports is taking him to Whistler Canada this winter, for snowboarding and heli-skiing.
-- As told to Peter McDougall

Resources: