Clarity

We have plans for using utilizing Resource Management in near future and trying to understand the role of creating Resource OBS and best practices in setting up Resource OBS. Any guidance on this would be helpful!

Draw your organisation's people-based-structure on a piece of paper (a hierarchical chart).

Build a Resource OBS that looks like that picture.

Resource Managers who look after people need to have access rights over the part of the structure containing the people that they "own".

How complicated this is (or isn't) will depend on how complex YOUR organisation is.

That is how it goes.
First you've got to ask yourself why to do want to do that and are you willing to put in the required effort to get the benefit.

Normally the need could be that you need to manage the resources more in detail than just a big pool.

Then you need to have the degree and division of granularity you need and want to plan and track and set the OBS levels and units according to that.

In addition to the structure of you organization you could look how you plan and track other costs than human resources. You might want to have similar structure in OBS.

In addition to planning and tracking OBS allows setting the access rights that when you have financial information you can restrict the access based on the OBS.

Consider the following:

•   Start as simple as you can – it’s easy to add complexity, very difficult to remove once users become comfortable with what you’ve built

•   Expect users will use Resource OBS for filtering portlets and reports

•   What do they need to filter successfully from Resource OBS?

•   What other fields are available to them that they can use with Resource OBS to be successful?

•   Don’t create branches in your Resource Pool that replicate content of other fields, if possible (security might be the exception)

•   For example, if using Location field, there are ways to get at this field for filtering purposes – one doesn’t need to replicate this in the Resource OBS

•   Putting location into both the Location field and resource OBS creates opportunity for error where Location<> Resource OBS\Location

•   Understand the new ‘Team’ feature in 15.4.1 – this may make the practice of putting teams into one’s OBS redundant

•   Will you use Resource OBS for security access?

•   We are walking back from using Resource OBS for security purposes, as ours was built years ago, with much detail that is now represented in Department OBS and other fields that weren’t available way back then; also, our organization structure is changing from regional to global.

•   Therefore, we started a new “Product Group OBS” where the top levels reflect global product groups and security can be granted at a high level (our Resource and Project OBS structure had product group in the middle, requiring multi-selection of many branches in order to grant adequate security access – difficult to maintain.

•   So now, we have

•   Project and Resource OBS unchanged – still, very complicated (we may yet simplify these!)

•   Product Group OBS

•   Company

•   Product Group A

•   Product Group B

•   Product Group C

•   AP

•   EU

•   NA

•   SA

•   Notice that for some product groups, regions appear for security access reasons (filtering portlets and reports doesn’t need this as one can filter on the parent region of a city in Location OBS via power filter or custom NSQL)

•   But that’s it – very simple – for security, today, we don’t need anything more deep than 2-3 levels

•   If Location is necessary for security purposes, see if you can use Location OBS before replicating as a branch in the Resource OBS

•   We were thinking about restructuring our Resource OBS around teams –

•   it’s 8 levels deep, and practically 100% redundant with Department and Location OBS (these weren’t around when we first started using this app …back in the Niku days of 2002….)

•   but we now need to understand what new Teams feature does – will it may make our Resource OBS entirely redundant?

Security, reporting, filtering, keep it simple, avoid redundancy, only add complexity later and only if necessary.  And if all this sounds complicated, by all means start simple!

Thanks for the detailed reply. I am kind of looking for simple way to categorise based on resource roles as pools.

For instance like below:

Just wondering again...

Did you notice Rego had a webinar on Effective resource management and best practices yesterdays (July 31). They will have a recording of it in a few days

Some of the points that echo in my mind are

Keep it simple (that is SIMPLE)

Do not create more information than you are ready to act upon

No more than 4 levels

No more than 25 role

and such like.

Looks good – nice and simple, a good place to start.

I am only adding to what David, Dale, and Urmas have noted.

Ensure you understand the clear purpose of what the Resource OBS will be used for, e.g;

- An additional Resource Pool structure. Remember there will already be at a minimum 4 resource pools that every resource will be a part of :- Resource Manager, Role, Department, and Location. If none of the 4 base resource pool structures listed accurately describe how you will manage your pool of resources, then introduce a new and complementary structure.

- Will it be used in team plans, particularly when requesting a role to be filled. I can use the Staff OBS to identify a role from the specific Resource OBS. 

- Will it be to reflect which parts of the business demand comes and therefore the resources are reserved for (though there may not be investments raised in the demand).

- Do I anticipate allocating a group of resources by OBS to a specific investment (Add/Update by OBS)

Then once that purpose is clear adopt some of the following principles:

- Your Resource OBS does not need to perfectly reflect an organisation reporting structure, it needs to reflect a hierarchical model.

- Ensure that the model is extensible for other units that may look to leverage this capability (this is talking to your Level 1 and 2 of your hierarchy and building this into your structure design up front).

- Make sure it makes sense when you roll up at all the levels. pdesur your structure has executive off to the right and super to everything, but is the executive not just another team alongside "Planning and Transformation", "Finance" etc. at that level. This is evident if you filter on the "Executive" level of the OBS and all nodes below would you get hundreds of resources or just your "Executive" team (the same could be said for the "Portfolio Management Office" in your example).

- Don't double up on information captured in other fields e.g. Project Manager should be a role, but you don't necessarily need to repeat this into the OBS. It is even more evident with the SMEs, which I am assuming come from your lines of business where they just need to be defined in their primary role as an SME and not necessarily a node on the OBS. Dale_Stockman noted this as well. A second example of this is 

- Design the structure in anticipation of restructures, because what you want to be able to do is move whole nodes under a new parent in the future to assist in bulk updates. e.g. "Risk" may be moved in the future under the "Planning and Transformation" node as a child. 

In a revised structure to your to what you mapped in the image I would initially be starting to look at the following:

Thanks for the response.

Idea is to use that in team plans by leveraging Staff OBS unit and derive in the OOTB resource planning portlets. I have aligned Executive as a team under Level 1(Org) as it makes more sense to what I had.

Hi @pdesur,

You have already received several detailed examples and guidelines for setting up a Resource OBS. I am also providing below the link to some PPM documentation that explains with examples how to set up an OBS. There are some useful videos in the topic:

Configure an Organizational Breakdown Structure [CA PPM SaaS 15.4.1]

Configure an Organizational Breakdown Structure [CA PPM !5.4.1]

Regards, Sarmistha