Project Organization Structure
Darwin's natural selection is a great thing. The shape of every species is crafted over thousands of years, to get the functions it needs to survive in the environment it operates. If it does not have the necessary skills, it just dies and is doomed with extinction. All the beautiful, blonde, long legged creatures survive.
The Homo Projectus is an ugly thing. It survives in extreme situations, where dirt has to be shoved. In this case it has the aspects of a hog. But to get the right features to have a party of hogs operating in such a way the pack will survive, is something completely different. We cannot wait until nature has killed all unsuccessful project organizations (the hog party), so the software project manager has to help nature a little bit, tinkering with the organization, so it might have a chance to survive in the corporate jungle.
Links of Interest
A project organization is a temporary thing. It will only exist from the projects start until its end. All the project team members are coming from different organizations of part of the organization. They will all have a temporary assignment to the project. So, they have not only a project boss (the project manager, that might be you), but also their 'normal' boss, who orders him around when the employee is not in the project. These 'normal bosses' are an important group of stakeholders.
The project organization should be a result from the project strategy, it should be constructed in such a way that the strategy can be implemented within the environment of the project ("look what the dog brought in, a presumptuous sentence"). A very obvious example: if the strategy contains an aspect of having independent reviews, the organization should support its independence, by creating a separate working group with no ties to the other team members, e.g. But, I'm a little too far now mentioning working groups and the like.
The project team that does the work should be as small as possible. Small is beautiful, and effective. Don't start inviting everyone to the organization. Only people who have an added value and will spend a significant amount of time to the project can be in the core organization. Try to avoid going overboard on working groups. Working groups can drown a project in communication overhead. If there should be that much discussion anyway, postpone the project and first make up the minds.
Next to the people who do the work, are the people that have some influence on it, but do nothing; a large part of the stakeholders. The project organization can be used to satisfy some wishes of stakeholders to create the much needed win-win situations. In its most simple form, you can create a project trashcan ("The Project Tactical Non-Binding Advisory Committee") where you put in the people who just want to be involved in the project (to save their territory), but which you have no use for.
Be creative while constructing the project organisation. Take the Bob Ross way to paint your organization: "This is a sweet little project staff. I put it here next to the tracking and control group, so it has a friend."
No comments yet. Be the first.
Leave a reply

Subscribe to my blog by email and you will receive bi-weekly a summary of my postings. As sign of my gratitude you receive the first part of my book "
Bas de Baar, blogging as "The Project Shrink", is taking his message to the International Project Management community with a vengeance: "Projects Are About Humans. Now Deal With That!" ...