Wage Cost and Project Labor Cost

I've been working with teams who want to move to agile. Some people on their teams are in another location, where the salaries are cheaper.

It's difficult to get agile started with a geographically distributed team. If everyone's distributed, it's easier than if just some people–especially if they are all one function, such as developers or testers–are. Or, if the people on the team know what it's like to work in a highly collaborative environment, it's ok, but not as good as when everyone is all together in one location.

The problem is that many managers have confused wage cost with project labor cost. Wage cost is a part of run rate, what it costs to keep the project alive for a week at at time. Yes, cheaper salaries will reduce the project run rate.

The problem is: what happens if the geographically distributed project takes longer to deliver the project? My experience says that all the geographically distributed projects I've met take longer to complete. The lack of being all in one place made a particular team take longer to deliver running, tested features. Here's an annotated value stream map that represents this organization's delays:


Wage cost is certainly lower in some parts of the world. But the only measure of productivity is running, tested features. If your project team takes longer to complete features, then you have a larger project cost.

Before everyone gets so excited about bits and pieces of remote team members, ask yourself, “Are we building in delays that will cause us to take longer to complete running, tested features? What will those delays cost us?” Now you can start to look at wage and project cost and make decisions that will make sense for your team–whether that means moving to agile or not.

11 thoughts on “Wage Cost and Project Labor Cost”

  1. I have managed teams that are geographically dispersed and I can attest to the overhead inherent in such organizations. It can be made to work but I agree that co-location is always preferred, furthermore, I have not really seen any organization do a great job of modeling the overhead though most try.

  2. This is much easier if, for example, you are on a government contract that is Cost Plus Incentive Fee. In such contracts, you receive an Incentive Fee, i.e. a bonus, if you deliver on a date, but nothing extra if you deliver after the date. In such cases, the value of delivering sooner is obvious.

    This is not so obvious if you are in a commercial market. In that case, it is practically impossible to calculate the value of having a product in the marketplace on a certain date.

    You can usually calculate this number after it is all over, i.e. after you got to market after your competitors.

    Perhaps you can use the $$ value from the last time you were beat to the marketplace as an estimate of what it is worth to reach the marketplace this time.

  3. I couldn’t agree more …. Run Rate costs more if collaboration tools and experience for team are not there.

    But big corps that span the USA or globe can’t avoid distributed teams. Especially IT projects.

    And many times the distributed members often feel “out of touch” with the rest of the team that are co-located. This slows down the team buiding process in getting to the productivity stage of teams. And I find the Storming phse tends to last much longer as well.

    Team leads need to be savvy at dealing with this. It can be done – and I’m seeing more and more of this.

    Donna Reed

  4. Stephan Schwab

    In my experience it all depends on skills. People working remotely need to be very skilled, disciplined and willing to communicate. Plus there needs to be a tool that allows everybody to see the backlog and current iteration transparently and with lots of opportunity to engage in conversation. With teams spread out over the world language is another isssue. If you have the right people a distributed team can beat easily a colocated team. In the end for the right people it doesn’t matter to be within eyesight of eachother or not. It’s a people issue.

  5. Doesn’t matter how skilled they are – if they are distributed, things will take about 15% longer than they would if you had all the team in one place. Delays in answers and decisions, bottlenecks, misunderstandings on scope, who does what etc. are more likely to happen.

    If you have to have a distributed team then try to
    * have everyone together at key phases, kickoff, major release points as far as
    * have small groups in each place,
    * get people who work on same parts to overlap geographically at least for key phases
    * create a war room feel using webcams, voice, etc. as much as possible

  6. “the only measure of productivity is running, tested features”

    You can take that one step further:
    “If you understand how software works, you know the futility of measuring productivity by lines of code. Measuring productivity by features or story points is not much better. In either case you’re measuring and optimizing for second order effect. Productivity tells you nothing interesting.

    Instead, pick the business metrics that matter most. Dave McClure dubbed them “metrics for pirates”: Acquisition, Activation, Retention, Referral and Revenue”

  7. Confusing labor rate with labor cost is pretty common. Rate is easy to count and true labor cost is not.

    The savings of distributed teams is likewise easy to count as are the costs of tools to support distributed teams. Cost of distributed teams and cost of *not* paying for travel, technology, and other supports for distribute teams are hard to count.

    Hard to count costs are seldom factored into the equation.


  8. Pingback: uberVU - social comments

  9. There was a study published in the federal software journal “Crosstalk” a few years ago that claimed distributed teams had a minimum overhead of 35%. For those of you who remember the SHAPE forum, we thought that amount was conservative.

    I don’t totally agree with Donna’s comment that big corporations cannot avoid distributed project teams. There is always a way if they wish to do so. Also, most teams, and particularly distributed teams (or teams that are multi-tasking – often a combination of both distribution and multiple project assignment – and what will that do to the run JR?) never get out of the “storming” phase (see the Tuchman model).

    Yes, good people with good tools make a difference, but not enough to make up for poor management.

  10. Pingback: younews.in

  11. Pingback: Economics, Models, and Money | Managing Product Development

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: