November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
It still sounds like there would be some hierarchy, even if it is role-based. A simple tree chart/org chart would likely suffice and you could combine that with a RACI (or RACI-S) chart if you wanted to have more details of the responsibilities & accountabilities of each role.
I like Kiron's idea of using a RACI/RACI-S structure because of the focus on the roles within the context of the project.
This site has several alternatives to the traditional org chart. Perhaps one of these will work for your need.
As I see from your comment that hierarchy is not a solution. Also it is only for one program, in this case I would recommend to go for holacracy; as this will give you solution for the current problem of politics as people will be divided in to cluster of expertise and will not interfere too much in each other’s topics. Flatarchy may not be suitable considering your comment, as it still has some level of hierarchy into it though it is more flattened
I do not a have a template though to share with.
I also would take help of a RASIC chart with defining roles, responsibilities and authorities. This will also help me in avoiding conflicts.
Please share more details incase my understanding is not inline to your query.
Flat org charts have their own inherent problems as well. Unless everyone has a completely unique role, the number of communication channels increases dramatically, which can also greatly complicate decision making processes. Everything can quickly become the dreaded "Design by Committee", which many case studies show can be a road to disaster. Politics becomes the enemy of practicality.
Hierarchical org charts are most often organized by function (role) rather than title. The titles simply differentiate the tier of the hierarchy.
You may have many people with the same job function (e.g. programmer) but are then aligned to a higher tier product function such as User Interface. When managing larger projects, the PM does not have the bandwidth to communicate directly with every individual on the program, so it becomes necessary to deal with focals from individual teams (roles) who can then translate that into practical direction to all of their other team members.
The key question here is: why do you need one? You do not need ones at all, except for leaving quit to somebody who still think that seeing a structure it will show a reality which does mean certain level of authority or influence. If you still need one take the picture inside the PMBOK that you think best fit.
Sergio made some good points.
Please login or join to reply