My PM Network Interview, or Tales from the Cutting Room Floor
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]——————————————
March 29th, 2008 at 6:10 pm
Hi Mike,
This is an excellent and unique article! I’m very interested in reproducing the article on PM Hut. In case you are OK with it, then please use the “Contact Us” form on the PM Hut site and we’ll take it from there.
April 2nd, 2008 at 1:25 pm
Mike,
This is a good article with some excellent insights. It’s good to see such strong recognition of the disproportionately large contribution that small project teams play. Just as small businesses disproportionately contribute to the nation’s economy (in terms of employment, if nothing else) so do small projects contribute every day in excess of what their sizes would predict. They are the pilot projects that point the way and guide the planning of large projects. They are the initiatives that organizations undertake to explore possible new products, technologies, processes, or management initiatives, thereby shaping those organizations for some time to come. And they include the initial projects of each new generation of project managers, building the foundation of their practical project management skills and setting the stage for their later professional and career management.
Despite such important roles, I don’t think there has been enough attention to the art and science of directing small project teams. As you point out, small project team management is not just a miniaturization of large project management. The small project team manager must serve the same principles, but will need to do so with a very different approach than someone running a large project due to the qualitative differences in their challenges and dynamics. For example, small project team managers are usually managing without a safety net since their smaller schedule and budget don’t allow much room to recover from errors or unanticipated circumstances.
From my personal experience running projects large and small though, it seems that the most striking difference between large and small project teams has not been in management as much as in leadership. In small project teams, the manager interacts with everyone on the team and becomes very familiar with each of their challenges, abilities, orientation towards their tasks, and the issues they confront in their day-to-day project assignments. It’s therefore easy if not inevitable to maintain a relationship with each team member that helps to promote their and the team’s success. A project manger cannot use team-wide personal leadership in large projects, however. Instead, he or she must exercise leadership through the task and activity team managers using the dynamics of organizational leadership. Those are very different models involving very different approaches that can cause some problems if confused. You can often see this happen when a manger used to running small project teams takes over his or her first large project team. And vice-versa.
Thanks of the great article and I look forward to your future articles on this topic.
Frank O’Mara
April 5th, 2008 at 12:06 am
[…] Note: The above article was slightly modified from its original source. You can find the original article here: My PM Network Interview, or Tales from the Cutting Room Floor […]