Best Project Organization

What is the best way to organize a stream of releases on multiple related projects where the software is quite complex?

Project Based

Our VP is changing the organization to a project organization where each project is basically a separate group. The problem is this group cannot possibly underdstand the design of the system well enough to make the changes because they are pretty much just tossed onto the project and told to do X. At the same time other groups may be working on the same code for a future release or for a trailing release that hasn't released yet. You can these groups should communicate etc but the problem is there is no real accountability or continuity. There is nobody who can say, no, really don't do it this way because the people who are really in the know are in another group and have no control.

In addition the project managers become littl demi-gods that compete against each other for resources at the expense of the over all product.

This organization gives managers the warm fuzzies because they think parallel effort is happening where what is really happening is mass confusion.

Functional Based

In a functional based organization a particular group is responsible for working on a feature accross different releases. This group has a shared culture and history and can plan how the feature releases would work together. If more releases need support then more resources can be assigned to the group.

This has the problem that the group gets bogged down with supporting the older versions, interfering with development of the new versions

Half Ass Functional

This is what gave functional a bad name. Supposedly a function was given to one group but in reality responsibilities were given to groups of people in different geographical locations under different managers. The people who knew about the code and the feature could not enforce how new code was developed because of this disconnect. And of course releases got delayed and were buggy because the people on the various releases didn't not know what they were doing. The functional organization got blamed and thus the move the project based.

Any opinions?

Any Opinions?

YES. Organise on project lines. These are your deliverables. Hold back a small number of talented engineers who thrive on challenge and variety as 'bees' that cross polinate the projects. They emphatically do not drive the other projects. Other projects welcome them not as busy bodies but because when visiting a project they act like an extra resource. They have their own 'project' team too. Bees mission is to save people work by leverage.

We're not just talking code reuse, we're also talking 'tools'.

You also need a damned good people person in there who can help defuse turf wars. Where I work for example there is consderable overlap in functionality between the test database frameworks and the configuration database frameworks, but it's too much of a political hot potato to force the issue and decree that they should build from the same source.

How big is this system? How many people are working on it? How many lines of code are in it?

2 millions lines of code. 60 people. 3 geographical locations.

A large project at Bell Labs (7-8 years ago, I don't know if they still do this) had product people and project people. A project was a set of features. Each feature was the responsibility of a feature engineer. Each module was the responsibility of one of the product people. A feature engineer would figure out how to implement the feature and then would implement it and test it. There were design reviews where the product people would look at his design and critique it. Once it was implemented, the product people would look over the changes and rewrite them if necessary before making them part of the standard release. It was fairly inefficient, but they made steady progress and their system was quite reliable.

One problem with the system you describe is that if nobody is in charge of a module, each group will hack it up for their own needs, and not pay any attention to the needs of other users. If a module has many users then you have to treat it as a product with the systems that use it being customers. The people working on the module will try to satisfy all their customers, but they will always be balancing the needs of one against the needs of the others.

Another problem with what you describe is lack of communication. How can you be building version N+1 if you don't talk enough with the people working on version N to know what they are putting in it?

There are probably other problems. Those are just the ones I see.

This is a lousy page name, by the way. It has nothing to do with a best project organization. You just need to find one that is not fatally broken. The one you describe is broken, perhaps fatally. -RalphJohnson

CategoryProject CategoryProjectManagement