Skip to main content

Projects Are Not The Problem

Mike Cottmeyer
Reading: Projects Are Not The Problem

A lot of folks in the agile community feel like projects and project managers are a big part of the problem we have delivering software. My view is that projects are not really the problem… it’s projectized organizations that are the problem.

Projectized organizations form when we have people organized into functional silos and assign them as necessary to project work. The underlying assumption is that people are fungible resources and can be split indefinitely across projects to get work done.

Agile methods take a different approach. People are organized into cross-functional teams and focused on a product… or a set of features… or a component… or a set of services… within the larger production ecosystem.

Projects as a funding vehicle in most organizations are just fine. The shift in thinking is that projects have to be broken up and funneled through teams. Each team is responsible for a subset of the project deliverables with integration happening on regular intervals

I’d much rather integrate the work of many teams producing working tested features than try to integrate the activities of many individuals working within their own particular speciality. Done is easier to see and bottlenecks are easier to identify and resolve.

This is the #1 biggest problem we see with organizations trying to adopt agile. They do not have a pattern for organizing teams and managing project deliverables across teams. Until this gets sorted out… you are not likely to have much success using agile at any scale.

Next Jesse Fewell at PMI Atlanta Technology Forum on April 23rd

LeadingAgile CEO and Founder, Mike Cottmeyer is passionate about solving the challenges associated with agile in larger, more complex enterprises. To that end, he and his team are dedicated to providing large-scale agile transformation services to help pragmatically, incrementally, and safely introduce Agile methods.

Comments (4)

  1. Glen B. Alleman
    Reply

    Organizations that consider their staff fungible get what they deserve. One of the critical success factors in full up ANSI-748-B Earned Value Management using DFARS 234, is the “staffing” plan, the Organizational Breakdown Structure (OBS), and the resource loaded Integrated Master Schedule, assess each month in the Contract Performance Report for its credibility.

    Treating staff as fungible is technically not allowed in FAR/DFARS procurement. Come on folks get a grip and “stop doing stupid things on purpose.”

    Reply
  2. Mike Cottmeyer
    Reply

    I think we’ve had this conversation quite a few times of the years ;-) Many, many software product companies are trying to do so much with so little, they trick themselves into believing that people are interchangeable and can be infinitely sliced across project work. We are trying (sometimes successfully) to help them see patterns of organization that minimize this behavior. Glen, I think you’d be shocked at the amount of goofy behavior going on in sone companies. It makes no sense.

    Reply
  3. Amith Pulla
    Reply

    Nice post! Thanks for sharing your thoughts on functional silos.

    Reply
  4. Yuri Sokolovski
    Reply

    Agree but what is also important is “cross-pollination” of acquired knowledge among members of a specific domain. This means regular get-togethers and communicating, exchanging ideas and best practices. Otherwise waste will occur from not knowing what other domain specialists have already been doing better and more efficiently.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *

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