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]——————————————
