PPM Tips
Resource Management Skills: Crawling to Walking
July 14, 2020
This is the third part in our series, “Getting started with Resource management.” If you haven’t caught the first two parts, be sure to check outResource Management: Learning to Crawl + Resource Management: Foraging and Collecting Data.

Congratulations! By this point in your resource management journey you have analyzed if an established resource management process can truly address your team’s pain points, identified the platform you will use to house all of your data sets, and foraged for and collected all of your raw data. You may find yourself asking… So, now what?  

Now, grasshopper, we move from crawling in your resource management journey to walking. And by walking, I mean establishing the data-based framework of the resource management analysis process. By the end of this session you will have the base structure required for your resource management process providing visibility into your resources, their unique skill sets, and a current snapshot of your team’s demand and capacity.  

So Much Data!  

The framework of any resource management process is organized, relatable data; Making your data make sense.

So far, you have a collection of resources (hopefully not the physical bodies piled up in the corner of your office, but rather a list of names), an idea of their soft and hard skills, current project assignments, a list of pipeline initiatives, activity estimated effort, and the typical ebb and flow pattern of each project.

That is a lot of information! Adding more to that heaping pile of data, you have also explored your project roles, technical skills, and your skill proficiency scale. Any more added and that pile will surely topple right over!  

Let’s get organized.  

There are four main components, or databases, to organizing your data:  

  1. Resource Profile 
  2. Skills Inventory 
  3. Current Capacity / Team Roster 
  4. Demand Forecast 

Below we will walk through each component to give you some organizational guidelines that will send you well on your way to having a functional resource management framework. 

Resource Profile 

Your resource profile database should be completely people centric. This should tell you all about your resources including HR related data as well as working characteristics.

This database should include direct employees, frequently borrowed interdepartmental employees, and contractors – particularly if these contractors are hired for long-term engagements or are frequently rotated into your resource pool. We will discuss the merits and strategy of how to use contractors as part of your sourcing options in a separate article. For now, we will focus on who is actively engaged with your team. 

HR Data 

HR related data is the base of your resource profile database and should contain static information about your resources that should not require frequent monitoring or updates. HR related data should, at minimum, include the following details:  

  • Name 
  • City, State and/or Region 
  • Employee or Contractor 
  • Job Title 
  • Manager 
  • Department 
  • Contract End Date 

This data set should be validated and updated at least once a year but should also be reviewed opportunistically such as with departmental restructuring or during annual reviews.

When constructing this part of your database, keep your information objective. You are not attempting to duplicate your company’s human resource dossier. In fact, doing so could result in you, inadvertently, violating an employee’s privacy. You only want to maintain pertinent information that will impact whom you may select for a resource assignment.  

Example: Having an employee’s full address, salary or hire date could result in a violation of privacy should your database be shared or viewed by an unauthorized employee. Protect your team’s privacy by maintaining only generic details. 

Work Characteristics 

Work characteristics is the second part of your resource profile database. This data set is a collection of attributes that provide key filters for your resource pool. As mentioned before, be careful what information you store. Remember, your job is to collect as much pertinent data as necessary to appropriately staff your projects. More, in this case, is often too much. 

Common work characteristics used for resource assignment include, but may not be limited to: 

  • Primary Role (Note: This is not their HR Job Title. Please see Role Dictionary below.) 
  • Travel Ability 
  • Willingness to Relocate 
  • Cost & Billing Rate 
  • Target Utilization 
  • Other: 
    • Certifications 
    • Compliance Requirements 
    • Government Clearances 
    • Foreign Languages Spoken 
    • Soft Skills 

Work characteristics are slightly more dynamic than HR data but can be updated with the same cadence of the HR data information.   

An example of a resource profile database is included below.  

Skills Inventory  

A skills inventory provides a common language when discussing skill sets that are desired for each role within a project. There are four steps to constructing a skills inventory: organize your role dictionary, define the skills, structure the proficiency scale, and stand up the skills module.  

Role Dictionary 

A role dictionary is a way to normalize project roles and define their responsibilities across all projects. Roles should not be identified as, or even aligned to, HR job titles. A team member may have a formal job title of Technical Consultant but fills the primary role of an Architect for most of his or her projects. This would be his or her primary role. 

The Role Dictionary should be structured as a narrative inventory or library. The definitions should be specific enough to identify the key responsibilities and actions a resource will be responsible for but not so specific to include individual skills or requirements. 


  • Project Manager: The Project Manager is responsible for planning, organizing, and orchestrating the activities of a project to deliver an initiative on schedule, within budget, and within scope. The primary responsibilities include definition and scope planning, work structure planning and sequencing, cost budget and actual management, meeting coordination and maintaining project documentation.  
  • Architect: The Architect defines a solution or product to meet a specific set of requirements. The Architect is responsible for considering all components of a proposed solution to ensure that they work together to develop a cohesive result.   

When considering roles, outline your roles with the concept that there should be only one primary role per resource. This is not to say that a single resource cannot fill various roles across multiple projects, but it is best practice to have one resource fill a single role within a single project.   

Define the Skills 

There are several key points to consider when defining skills:   

  1. A skills inventory should include all skills that are needed for each project role but should not be limited to resources that fill that role. Therefore, a full skills list will include skills for both project management and program development. However, resources should be able to select any skill that applies to them regardless of their primary role.  
  2. Only go to the lowest skill level required to appropriately define the need. If your company uses a single programming language within your environment, then “Software Programming” may be sufficient as a skill. However, if multiple languages are used, you may want to break this down further such as JavaScriptPython, or C++. Likewise, project management is technically a role (that of the Project Manager) and would be too broad of a skill set. This should be separated into management requirements such as Risk, Change, Project Plan, and Financial Management skills. 
  3. Do not add proficiency levels to the skills list.  

Example: When considering risk management, the skill should be Risk Management rather than Risk Management Level 1, Risk Management Level 2, and so on.   Separating the skill from the proficiency allows you to maximize your resources. You want to see ALL resources that have Risk Management experience. You can always narrow resources down with a proficiency level but if you only look for resources that have a level 4 proficiency in Risk Management, you may miss the better resource that has all other desired skills, availability, and a level 2 proficiency in Risk Management. 

Proficiency Scale 

Your proficiency scale should be inclusive for all levels of expertise, should include a numeric ranka definition for that rank, should be easy to decipher, and should be applicable to all skills. This is your ranking or scoring system that you will assign to all skills for a specific resource. There is always a 1:1 relationship between a skill and the proficiency level. Two proficiency levels should never be assigned to the same skill.   Below is an example of a standard proficiency scale:  

0 – No Experience 

1 – Has Been Trained. Has a working knowledge of the subject but has limited or no experience. 

2 – Capable. Can complete the work but will likely need to consult a more experienced resource for guidance. 

3 – Skilled. Can complete the work with little to no guidance. 

4 – Expert. Has deep knowledge and experience. 

Stand Up your Skills Model 

Now that you have your roles, skills, and proficiency scale captured, you can stand up your skills model. I recommend that this be a relational database that is linked directly to the resource profile. For each resource, the primary role is identified, a list of skills should be assigned, and the proficiency levels identified. A few best practices for maintaining your skills model include:  

  • The skills model should be updated annually or semi-annually depending on how fast your environment changes. Your Resource Manager(s) or Resource Management Office (RMO) owns this database and the responsibility of its maintenance.  
  • Resources should self-assign their skills and proficiency levels. Resources know their own capabilities. Allow them to provide you with the base skills assessment. Skills should be assigned at time of hire (for new resources) and regularly updated, such as with their annual performance reviews. You may also identify other, opportunistic times that skills may need to be updated such as department or organizational changes or after completing a project where the resource learned a new skill or advanced in proficiency of an existing skill 
  • All assigned skills should be reviewed and updated/approved by managers for accuracy.  

An example of a skills model is shown below.

Notice that Sandra Dee, whose primary role is that of a Developer, has several project management skills in her skills inventory along with architectural and software engineering skills.  

Current Capacity 

Now that we know who our resources are and their unique capabilities, let’s take a look at their current capacity. Your current capacity view should answer the who, what, when, and where for each team member. This is the base of many reports that you will use within your resource management process.  

When first structuring your current capacity report it may be as simple as a team roster. At minimum, this report should include a list of resources, their assignment details, and base project information. 

Resource Management: Data Based

Keep in mind that the % of Allocation is the FTE (Full-Time Equivalent) required to fill the project role. Additionally, notice that the start and due dates of the assignment may not align with the start and due dates of the project. Roles should only be held in a project for as long as they have an active work assignment. As projects move through stages, roles will naturally roll off and change.  

At this stage in our discovery, be careful not to get too detailed. We aren’t looking for resource assignment for each task on each day. Keep it high level – like at the overall project level – and think in terms of estimate percentage FTE.  

As you gather a bit more experience, your team roster will evolve to show allocation and availability for each assignment as shown in the example below.  

Demand Forecasting 

Resource management demand forecasting brings together several exercises and best practices that we can explore, in depth, in a separate article. For now, for this exercise, let’s focus on what is within your immediate pipeline and no further out than a start date within the next 30 days. This report should be similar to your team roster. However, this report will show requested roles for projects along with specific resources, should call out the assignment status (assigned, soft book, open), should show the requested FTE per assignment, and should include the % of probability for each project. Anything with a probability less than 60%, do not include in this report.  

Resource Management: Data Based

You’ve Come So Far! Do Not Cheat This Step. 

Once again, this is a big assignment for you. I understand the work that must go into this but I’m here to tell you, it is all worth it! Take as much time as you need to organize your data. If you find you are lacking in certain sections, go back and do some additional research. Once you ready, check in for our next article in our Resource Management series to learn how to connect your data together, defining your team’s resource management process. 

Also, check out our webinar – How do resource management practices affect project and PMO performance? Watch on-demand.

Next Steps

Contact Kolme Group to find out more about our Resource Management Services and we’ll be happy to support you with a free 15 minute Q&A with a resource management expert, please email us at PPManswers@KolmeGroup.com.

Be sure to follow us on TwitterLinkedIn and YouTube  and use #KolmeGroup on shared posts!



More from this topic

Together we fight for project success,
Live for happy teams,
Geek out on PM software, and
Love what we do!