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 out : Resource Management: Learning to Crawl + Resource Management: Foraging and Collecting Data.
Executive Summary
This 3rd resource management installment is about establishing a base structure and the requirements for your resource management process. You will learn the resources needed to provide visibility, capture employees’ unique skill sets, and document a current snapshot of your team’s demand and capacity.
- Resource Profile Database
- HR Data
- Work Characteristics
- Skills Inventory
- Role Dictionary
- Define the Skills
- Proficiency Scale
- Stand Up your Skills Model
- Current Capacity
- Demand Forecasting
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 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 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:
- Resource Profile
- Skills Inventory
- Current Capacity / Team Roster
- 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 Database
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.
-
Resource Profile Database
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 the 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.
Example:
- 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:
- 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.
- 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 JavaScript, Python, 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.
- 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 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 rank, and a 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 skill and 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 should be 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 for 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 the 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 the 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.
-
Skills Model
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 of each team member. This is the base of many reports you will use in your resource management process.
When first structuring your current capacity report it may be as simple as a team roster. At a minimum, this report should include a list of resources, assignment details, and base project information.
-
Current Capacity Report
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 assignments for each task on each day. Keep it high level – like at the overall project level – and think in terms of estimated 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.
-
Team Roster
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. This report does not include anything with a probability of less than 60%.
-
Project Resource Request Report
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 are ready, check-in for the next article in our Resource Management series to learn how to connect your data together and define your team’s resource management process.
Next Steps
Contact Us to learn 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.
Follow us on Twitter, LinkedIn, and YouTube, and use #KolmeGroup on shared posts!