Current Articles | RSS Feed RSS Feed

Code Management versus Project Management

Posted by Andy Singleton on Tue, Apr 05, 2011 @ 09:41 AM
 

What if we could get rid of software project management? On a big project we would save millions of dollars and a lot of boring meetings. As noted in Statistical Proof that Project Managers are Useless, project management is a difficult and thankless job. It's a task ripe for automation

PROJECT MANAGEMENT: We need project managers because we have project plans. The plan describes how multiple people contribute work to a coherent whole. Project managers coordinate this work by reminding contributors about the plan.

VERSUS CODE MANAGEMENT: On a software project, there also a coordination process running around code. As people write code, they have a process to contribute into a shared release. I reviewed some of the ways that we do that in the previous article on Four ways to manage code, simplify projects. The workflow for contributing, reviewing, and accepting code is a different way to assemble the work into a coherent whole.

In the project management case, you assemble the work of multiple people IN ADVANCE. You plan a set of tasks that fit together. In the code acceptance case, you do the work AT THE END, when you decide what code to accept. So, you do the work at different times, but you can get a similar result. The processes can be substitutes for each other.

I can't say which is more effective in general. Most projects do both. Both processes can deliver equivalent results. They both require work. However, I can think of some reasons that you might prefer to work with code.

1) It's sometimes easier to control code than people. Managers have a tough time herding smart programmers. Code, on the other hand, doesn't go anywhere when you run out of Jolt Cola.

2) Project management doesn't scale. The success of project plans declines dramatically with the size of the project. The problem is that big projects have a hierarchical structure with some sort of a boss who makes the plan, and that boss doesn't know everything, and the plan is always wrong in some way. On the other hand, code management can scale. You can imagine a project, maybe with Gerrit, which has hundreds of contributors throwing in code. You could in principle do this without hierarchy, scrums, and scrum of scrums. They might not all be going in the right direction, but at least they are figuring out the right thing to do at an individual level. So, you can see how this thought fits into the broader discussion of project scaling.

Tags: , ,

COMMENTS

I have similarly begun to ask myself the question after many years of Project and Engineering Department management: what is the role for a project manager in an agile company in a competitive market (agile development methodology scaled across all company functions)? I have seen in action project management as an emergent property of agile development with teams self-organizing to get the job done. I agree with your recommendations drawn from Casper Jones' work. But I do not agree that "code acceptance" and project management are equivalent or even comparable or that by somehow exchanging one for the other you can produce overall value . The key problem that we must find a way to resolve is what I will call the planning problem: the company needs to have an idea in advance about what the project will cost, in order to sort through all of the options about what to do, about what to do first, and to allocate people and resources for (even coarsely) predictable periods of time. You just simply can not avoid the need to compare predicted costs with predicted returns. Companies that do not have good ROI processes in place rarely succeed over the longer term, which is what we all want. Right? This is especially true in competitive spaces where you need to adapt, and possibly change directions quickly. When you adjust your perspective to broader company need, the role of the project manager as coordinator of these predictions becomes less useless. The value of project managers during project execution is a different topic for discussion.

posted @ Wednesday, April 06, 2011 7:52 AM by Michael Motta


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: