So right up front the take away point for this blog is that Project org charts are very important.
I’m sure everyone agrees with this, but experience seems to dictate that a project org chart is quickly sketched out with a minimal team and then forgotten. What inevitably happens is that more and more people become interested in your project, and you find yourself having to please all of these people who were never specified on the org chart.
But why does that matter isn’t this just stakeholder management?
In a way, yes. In another way no. Stakeholder management is not about ensuring that you personally make sure that anyone with a passing interest consumes your precious time to make them feel all warm and cuddly. It’s about ensuring that the correct process and responsibilities are in place to ensure everyone feels warm and cuddly. At the end of the day you only have a limited amount of time and if you find your self having to see to everyone personally this will run out and people will be forgotten and not be managed.
So how does an org chart help?
Glad you asked. The key is first of all to keep the org chart as a living document to describe everyone who your project interfaces with from the obvious people doing the work, to the somewhat more vague interested parties. Then you establish direct lines of management and reporting between the different areas of the project. As this is a living document you will naturally review this each time a new stakeholder et al comes along and put them into one of the appropriate camps in which they should be managed.
Depending on the camp in which they are placed will establish the relationship you will have with this new interested party. The list below gives some of the different holding buckets you could use and your relationship with these people.
- Project board: If someone’s in the project board then you need to look after them and report on a regular basis end of.
- User group: If you’re engaging someone from a user group then, you may be in luck here. If you have a senior user role then you may choose to let them handle the communication particularly if there’s a big group.
- Executive grouping: These are the guys who are paying for the project, however you usually wouldn’t have direct contact with these people, that’s why you have a project sponsor and it’s their job to manage these guys – make sure they’re aware of that.
- Suppliers: Generally you will manage most of the suppliers to the project, but if this is a large project and you’ve got a senior supplier / procurement or contracts role on board then add them into the correct bucket and let them deal with them.
Over the next couple of weeks I’m finalising some project tempates to be released under a creative commons license for comercial reuse and I’ll work up a usable org chart template to help you out with this and give a more visual representation of the org structure.
