Minimizing Communication Requirements
iMarc has a unique approach to managing projects and internal resources. For iMarc, a project is typically a new website and internal resources are the people, our employees, who design and program websites.
As more people are involved in a project, more time is required for internal communication. A solo project with one person doing everything requires zero internal communication. In fact, in iMarc's early days, there was only one person assigned to each project. One person doing the design, programming, and project management is ideal for keeping communications costs down, but obviously limits the quality of work.
As iMarc grew, we hired more specialized talent. Eventually we had one project manager, two designers, and four programmers. This worked well, but again, we encountered a limiting factor. We could only work on about six projects at once. When the sales team got on a roll, we found ourselves turning down good projects. Each programmer could juggle one or two large-scale projects. Designers could spread their time across two or three projects. But asking a single project manager to lead ten projects would, again, limit the quality of work.
Our solution was to hire another project manager. A second project manager allowed us to take on more projects, hire more programmers and designers, and avoid bottlenecks.
However, the way that multiple project managers are implemented at iMarc is slightly different from other service-oriented companies.
A traditional implementation of multiple project managers would create two levels of production. One, where projects are assigned to project managers; the second where project managers assemble a project team from the company-wide pool of designers and programmers.
Benefits of this traditional approach include:
- The project manager can be selected and brought in to the sales and planning phase early on.
- Teams are optimized for each project.
- Teams are constantly changing, breathing new energy into each project.
- Easier to grow the company — just add more people to the production pool or the project manager level.
The approach iMarc chose creates one level of production. A production team consists of one project manager, one designer, and two or three programmers. Technically the project manager is more of a team manager. Teams are like mini-companies within iMarc. Team members work together on every project assigned to their team.
There are plenty of drawbacks to the iMarc approach. It's difficult to bring the project manager in on the sales and planning phase of a project. This is because we often don't know which team a project is headed to when the sales cycle begins. Assigning a project to a team depends more on which team has resources available when the 6–12 week sales and planning cycle ends.
The iMarc approach also puts more responsibility on the designers and programmers. Since we don't have the luxury of optimizing teams for specific projects, it's up to each designer and programmer to fit the role requirements of the project — not the other way around.
From the business side, growing the company requires adding or rearranging whole new teams, not just throwing more people into the pool. On one hand this is more difficult. On the other hand, it encourages the steady, well-planned growth that has benefited iMarc.
There are, of course, a few benefits to the iMarc approach:
- Less communication and coordination. Project managers don't coordinate with one another, asking, "When will Craig be done with Project X? I could really use him on Project Y next month."
- Teams members become familiar with one another's style, again cutting down on communication requirements. They work more fluidly and efficiently.
It's these two benefits that we feel far outweigh the alternative. To quote Fredrick Brooks in Mythical Man Month:
The purpose of organization is to reduce the amount of communication and coordination necessary.
The tree-like structure of organization reflects the diminishing need for detailed communication[...] The principle that no man can serve two masters dictates that authority structure be tree-like.
We've divided our production resources into autonomous teams and made the project manager's role more of a team manager. By doing this, we minimize communication and coordination — especially among project managers. This also eliminates the possibility that any designer or programmer is serving two masters project managers.
Minimizing communication requirements is not an excuse for minimizing communication. Removing extraneous dialog centered on coordinating people allows everyone to focus on important communication. Like building better websites.
Comments
Interesting approach to project management. So one thing I'm curious about is how strictly enforced the production team structure is. Does every project get assigned to a full production team? Or are there smaller projects that may be assigned to one or two members from a given team, and if so, how does that impact any full-team projects they're working on? Do people ever shift between teams? How do you maintain a sense of the larger company community when the company is internally divided into separate teams?
@Peter - great questions...
Quick recap - There are 3 production teams at iMarc; Most teams consists of 1 project manager (or team manger), 2 developers, 1 designer.
Your questions: Does every project get assigned to a full production team? No. Typically the designer works on each project with the PM and one developer. The team might be working on 4 projects. The designer and PM have their hands in each project while each developer is juggling 2.
are there smaller projects that may be assigned to one or two members from a given team? Yes. Almost all our work can be completed with one designer and one developer, with the PM managing the process. This allows the team to work at a fairly consistent pace - while one developer is finishing a project, he's also starting work on a new project.
Do people ever shift between teams No. But within a team, we might flip people around, or pull in the other developer to get something done.
How do you maintain a sense of the larger company community when the company is internally divided into separate teams? Physically, we're not segregated by teams. The four designers are in one room and the six developers share two other rooms. This encourages people to peek in on, help out, answer questions, and give opinions to their co-workers on other teams.
Open, non-separated, physical space PLUS open, engaged, opinionated employees keep it very un-cliquey
Read something more recent.
Statements and opinions expressed in this blog and any comments made are the private opinions of the respective poster, and, as such, iMarc LLC is neither responsible nor liable for such content.
Visitors
The "pick your team" approach would also inevitably lead to my favorite school-yard scenario where I'm standing around after everyone has been selected.