Thoughts on building a structure and plan to manage organizational resources and work at the aggregate. |
There are five main parameters that I've identified that can help our thinking of PMOs:
Parameter #1 - Resources are of discrete types and have statuses
Although it all boils down to "they're humans" we can simplify the problem by thinking of the people as: utilized, available, expert, etc. to help us sort out how to fit people into slots. Availability is another property of the resource that can of course help us with planning. Of course the time dimension of WHEN people are of a specific type is critical to us as well. Time is a constant dimension in systems like this that must be considered throughout the planning process.
Parameter #2 - Resources are consumed or utilized in discrete ways, some more effective than others
Resources, like their name applies are value to us if utilized properly. There's good ways to use resources (putting them on the right tasks, treating them well) and there are poor ways to use resources (being abusive, overusing them, being mean, forceful, coercive, etc.) We want to respect our resources but they're here for some kind of compensation and we need to get value out of them in exchange. The matrix of resource type to preferred and dis-preferred utilization types is interesting for our planning purposes.
Parameter #3 - We can think of the work separately from the resources but need to put them together and manage the connections to add value to the system
It's nice to be able to separate the work and project plan from the actual resources. Some people in the roundtable were talking about finding your "critical resource" (a concept borrowed from Critical Chain and Theory of Constraints) and then planning the project around them. I feel like this method, however, is problematic and puts too much pressure on "hero individuals" rather than the team or collective. I prefer approaches that get the team, collectively, to estimate their work and have leaders such as that critical resource work on making the others faster or more confident and build skills.
Parameter #4 - Systems, portfolios, programs, projects, and resources have slack and utilization properties; unplanned or unused slack is waste and cost
Someone in the talk last night said that you WANT slack in your project. I couldn't understand this. I can see how it is nice to have people free to apply to the project and critical tasks but at the aggregate slack is waste if not applied to the project. Managing the slack is a key issue in planning one or more projects.
What do you think about these parameters? Do they make sense? Are there others? Please discuss below!