Actually no matter whether a client pays for a PM in the team or not there are some project management tasks which have to done. Sometimes you don't even need dedicated PM (as it in my team now) because a project isn't complex enough to require full-time project management job. But we still need project plans, schedules, a little bit of formal communication with customers, some coordination with other teams in our company etc. It is project management and it is being done.

The other thing is whether and how client pays for the job. Majority of projects I worked on were fixed-price not time-and-material and, as such, we rarely needed to ascribe each hour of our project managers to project costs.

However if you set up an agreement where you list each resource working for a client and they reject to accept a PM there, well, you can always treat it as a supportive role for developer (which it really is) and include it somehow in your margin. After all you don't add a secretary to the list of resources and she helps your team, isn't she?

I agree, it would be a combination of factors such as effort, duration, team size, complexity, process confirmance etc. that would help determine if a project is "small" or not.

I used to work at an Offshore Provider that had startups as clients and they would typically have projects similar to the 2 man-month project that you have described. It was an uphill task to try and convince the client to pay for a vendor-side PM. Their thinking was this is a "small" project so why should I pay for the "overhead" of a PM. Big mistake! Ultimately, we used to "invest" in a part-time PM to ensure that the project was managed successfully till the end and it paid off.

What has been your experience with such clients?

Actually I used an ambiguous term "small" on purpose. You can have 10-man-month project which will be small as it's relatively easy, tasks are well-defined and there isn't much of bureaucracy around and at the same time you can have a two-man-month project which is a hell of a PM since you have 4 subcontractors, tons of different documentations to to process and strict process constraints which makes it rather a complex project.

Judging by the length of a schedule only it's hard to say whether project is "small" or not. On this point – fully agree.

Of course big projects are a valuable lesson too but a different one. As you say you can have a project where the most important task is dealing with office politics (which sucks if you ask me).

And of course experienced PM should be able to deal with all sorts of environments.

I just had this thought before writing the article that we tend to focus on this big complex projects as these are ones which look difficult. Then we expect to learn. At the same time we tend to leave small projects with a "simple task" label which is wrong. Or so I believe.

Actually every project can be, and should be, a lesson. Especially these which doesn't go according to plans.

Simplicity plays its role on every front. And yes, I definitely forgot about infrastructure.

What I'm trying to get at is the simpler is the project the more merits can be touched by a PM. And that's great since we're often put somewhere high where we no longer do "the real work" but coordinating group of people.

The dynamics are completely different, and very important in both cases.

On the last project I worked on, politics was more important. Communication, dealing with multiple stakeholders and multiple project managers that worked for me, these all made things much more complex.

I had a scheduler, risk manager, project controller, etc. At times, I longed for my smaller projects where I could do these things myself.

Every project can be a great lesson, if you let it be.

Josh Nankivel
pmStudent.com

isn't there also the question of how much infrastructure is necessary? With a small project, minimal infrastructure (project schedules, meetings, communication plans etc.) The larger the project, the more infrastructure is needed. At some point the law of declining returns sets in, the infrastructure needed for the project exceeds the project.

I believe Einstein said something like "Everything needs to be reduced to its simplest form, but no simpler." Likewise, a project needs to be as small as it can possibly be, but no smaller.

Is that what you're trying to get at?

Andy