Project Management: Simple = SuccessBy David F. Carr | Posted 2006-05-23 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
The founder of a software development startup doles out unconventional advice to large companies: Limit work on custom projects to three weeks.
Jason Fried's company, 37signals, builds niche business applications and sells them by subscription on the Web. But this small fry's philosophy could be a good model for developers of internal Web applications at large corporations.
"My advice to corporate Web developers is that the most effective thing is to have something you can use right now," Fried says. "Build something in three weeks, because people love results. And the way you do that is you cut your vision in half."
In other words, don't get bogged down in writing the spec for the perfect system and spending weeks locked in meetings ironing out the project plan. Developers trying to "prove their worth" often wind up "biting off more than they can chew," Fried says in an interview.
This is consistent with studies showing that the risk of project failure goes up as the project schedule stretches out. For that reason, research firm Gartner recommends that anything taking longer than a month or so requires additional planning to mitigate that risk (read: more meetings). Of course, there are inherently complex projects for which a three-week schedule just won't work. Still, Fried suggests taking a hard look at whether there's a simpler solution, something that meets the 80% or more of project goals that really matter and can be done quicker.
If you're building rather than buying software within an enterprise these days, you're probably filling a niche need--some set of requirements within your company that differ from everybody else's, or solve a problem in a slightly different way. And that's not so different from what 37signals does.
The company outlines its simpler-is-better software design philosophy in Getting Real, a self-published book released on its Web site earlier this year, and serially in its blog, Signal vs. Noise.
The Getting Real approach is about starting simple, then trying hard to keep your system simple so that it's easier to use and maintain.
Among the recommendations:
That's how the 37signals developers approached project management a few years ago, when they looked at the tools on the market and decided products like Microsoft Project were too complicated. They wanted something simpler and more flexible, so they started work on what became Basecamp, a free-form project coordination tool. At the time, the company was a Web development consultancy rather than a software-as-a-service vendor, but it was managing some big projects that it needed to coordinate with its customers. Once 37signals began offering Basecamp to the public, it became popular with small businesses and startups, particularly for coordinating projects with subcontractors and outsourcers.
37signals subsequently turned itself into a Web software products firm, introducing Backpack, an information manager for contacts and other personal and business information; Writeboard, a collaborative writing tool; and most recently Campfire, a business-oriented group chat tool.
Although 37signals is private and doesn't release revenue figures, Fried says the firm is self-funded, debt-free and profitable, and has more than 500,000 users of its products.
And the reviews have been positive. "37signals' products are beautifully simple, elegant and intuitive tools that make an Outlook screen look like the software equivalent of a torture chamber," opined Wall Street Journal columnist Jeremy Wagstaff.
"Getting Real is at once an operating manual on building great software, and a comprehensive condemnation of the startlingly dumb preconceptions that animate most software development," commented Stowe Boyd, managing director at consultancy A Working Model and member of the Web 2.0 Workgroup, in his blog at www.stoweboyd.com.
Although he has never been a cubicle slave himself, and runs a company that consists of just seven people, Fried thinks he has some idea of what corporate work is like from past consulting on intranets and other big company projects. When corporate projects fail, it's usually because some manager has made a political ruling about how the system will work, rather than looking at the evidence of what really works. Or the project gets bogged down in specifications and meetings, rather than working code.
"The thing that gets me is, everyone talks about how the enterprise is so complex, and has such special requirements," Fried says. "But people are people. Most people have the same problems. Simple solutions are the ones people are going to use."