Mike Coyle’s Weblog

A couple of months back, I had the pleasure of being interviewed by Susan Ladika for PM Network magazine (a publication of the Project Management Institute). They were doing an article about managing small project teams for the March 2008 issue.

I put together a bunch of content in advance of the interview. Now that the magazine’s hit the streets, I figured that I’ll publish the stuff that I wrote that didn’t make it into the article.

I did my prep work by writing out a fake interview with myself. I’m certain that I’ll recycle some of this content in future writings and talks, but here it is in its original form for your reading enjoyment:

–[BEGIN FAKE INTERVIEW]—————————————–

1) Your company uses the slogan “We help small teams solve large problems.” Please explain.

The needs of small, disciplined project teams are largely unrecognized and under-served in the project management community. We started our company to bring the necessary people, process, and technology to small teams so that they can leverage their constraints and deliver value to their customers in a predictable and instrumented fashion.

Too many small project teams either wander their way through the project lifecycle alone, or end up suffocating under a heavy, inappropriate layer of bureaucratic oversight that makes project delivery slower and more painful, but doesn’t necessarily reduce any tangible delivery risks.

We know that there’s a better way, so we put our money where our mouth is. ProjectPipe.com is our project management software solution that embodies our approach to disciplined, high-performance small team project management. Our target customers in corporate settings are the small boats of ambition floating in the sea of big company mediocrity. While we’re not here today to discuss ProjectPipe, any interested readers can find out more at ProjectPipe.com.

We are convinced that the future of project delivery is small, distributed teams. We are fortunate to be in a position to expedite this trend through our software, consulting, and writing.

2) But isn’t bigger generally better?

No. Having more people on your team is not like having more money in the bank.

For example, jazz quartets don’t want to be orchestras when they grow up. The two are different beasts.

If you try to run a jazz quartet like a symphony, you get bad jazz. Run a 20-piece orchestra like a jam session, and you end up with chaos. The same goes for project teams. If you run a small project like a miniature large project, you end up with….pretty much what you see in corporate environments everyday. Namely, too many meetings, lots of low-value boilerplate documentation, and other adminstrative overhead that gets in the way of solving the real problems at hand.

Don’t get me wrong, a team of 4 people still needs to play by the book, but it’s a different book.

3) Why does the size of a team matter? Aren’t there universal best practices for project management?

At a high-level, there are a number of universal truths that the Project Management Institute, and other organizations have done a wonderful job categorizing and articulating. However, when it comes time to tactically implement these best practices, you see the entire spectrum of implementation choices, from hyper-bureaucratic process overkill to Wild West-style chaos.

In theory, practice and theory are the same. In practice, they are profoundly different.

This is why it is so important to have strict adherence to a lightweight process. As a project manager, you want to spend your overhead capital wisely, applying documentation and other process-related protocols to the specific areas of project risk that are relevant to your project.

4) What types of things are more difficult for small teams, aside from the shortage of manpower?

There are three general challenges for a small team. First of all, distractions and overhead can be a significant drain of time and attention. Second, context switching can be expensive, as members of small teams often wear multiple hats. Lastly, having fewer team members to draw insight from can result in less diverse domain expertise brought to the table.

5) Are there any advantages that come from having a small team?

Certainly. Small effective teams understand the nimble clarity that comes with having few moving parts. They have conversations rather than meetings.

Small teams separate the wheat from the chaff, since there’s nowhere for underperformers to hide. As a result, I’ve found that higher-skilled resources are more likely to prefer working in smaller teams, since there’s a bit of self-selection at play. For example, rock stars know that poor performers are more interested in being the 16th person on a 16-person team than the 3rd person on a 3-person team.

6) What kinds of special needs do small teams have?

Small teams need to behave like small teams, not miniature versions of large teams, because bureaucracy doesn’t scale down particularly well. Small teams need to be led by a project manager that understands the dynamics of small team delivery. Specifically, someone who picks their battles carefully and doesn’t mind getting their hands dirty from time-to-time. Additionally, small teams need to use the best tools available, as they cannot afford to arbitrarily throw labor at problems.

7) Are there particular issues that come when team members are dispersed around the globe?

Small teams should strive for “location transparency”, regardless of the team’s physical locale. Collaborative technology (and the day-to-day practices that support collaborative processes) should be employed whether team members are separated by a hallway or an ocean.

8) What ways can small teams work most effectively to accomplish big tasks?

There are four aspects that drive small-team effectiveness: Planning, Process, Automation, and Asset Management.

• Planning: Small teams need to focus their efforts on understanding how the key moving parts of their project fit together so that they can proactively categorize and manage delivery risk. This is far more important than trying to optimize the workload balancing in your project plan, since you’re not trying to distribute lots of work among interchangeable resources on a large team.
• Process: Small teams should maintain strict adherence to a lightweight process. Individual heroics are not scalable nor predictable over time. Even small teams need to play by the book, but they need to make sure that it’s the right book for them.
• Automation: Small teams need to maximize the amount of work that they don’t do, and focus their efforts on the important stuff. If work cannot be avoided, it should be automated. Computers are really good at doing predictable stuff really fast.
• Asset Management: Small teams should manage their important data using some sort of version control mechanism. A good version control system acts as a time machine in case users need to review and/or compare previous versions of a document or other artifact, and a bank vault to protect a single, current version of the truth for each project asset.

9) I also found the comment intriguing that large teams are usually bands of small teams in disguise, and I’d like your thoughts on that.

We coined that phrase to help decision makers understand the true nature and composition of their organizations, and soften any negative connotations that the “small teams” concept would have in larger organizations.

At the end of the day, projects get talked about by large teams and completed by small teams (or groups of small teams working together).

Any team can make a decision. Only small teams make great decisions.

Any team can do work. Only small teams do efficient work.

It’s true that there is strength in numbers, but sometimes that strength lies in small numbers.

–[END FAKE INTERVIEW]——————————————

IBM invests in PostgreSQL vendor EnterpriseDB.

This is good news for two reasons: First, it throws yet another (big) blue chip name behind the PostgreSQL brand and ecosystem. IBM was one of 4 firms participating in EnterpriseDB’s C round of venture financing, which raised $10 million for the firm.

Second, EnterpriseDB is also rebranding their value-add packagings of PostgreSQL as Postgres Plus and Postgres Plus Advanced Server. The products used to be branded as EnterpriseDB Server and EnterpriseDB Advanced Server respectively. This new naming scheme should bring more brand recognition to the underlying PostgreSQL project.

For those not familiar with EnterpriseDB, their main claim to fame is an Oracle compatibility layer that they’ve built atop PostgreSQL. This allows firms to save a few bucks by replacing Oracle databases with EnterpriseDB’s distribution of PostgreSQL. They also provide support and other value-added software and services for customers using PostgreSQL.

Speaking of databases, I highly recommend checking out FLOSS Weekly: Episode 26 where the guest is D. Richard Hipp, the creator of SQLite. SQLite is the most widely distributed relational database in the world. Aside from the interesting technical content, the interview can stand on the merits as a human interest story of how one man’s pet project can have a huge impact on the world.