Hi Tammi.
We should chat on this one, but I'll ramble on here for posterity. I'll try my best to make this the thread I wish I would have found 2 years ago...
We're on our 4th skills schema/plan. We know 3 ways not to do it. Basically, my biggest challenge was getting people to understand what skills are used for in the Clarity tool and what they're not to be used for.
What they're used for:
1) Skills are used during scoping to better define a Resource Requirement (metadata).
Example:
Role: Developer
Staff OBS Unit: Web Team
Skill: ASP.NET <-- this Requirement says "I need an ASP developer from the web team for this work".
2) Once a good Resource Requirement is built, Skills on the Resource allows Resource Finder to find "matches" for the requirement with the proper skills and availability.
3) Yes, one can leverage this information to "mine" for resources with a skill, but this isn't primary tool functionality requirement.
Things not to do:
1) Based on the above, you need to get people focused on project staffing skills.
Example: Yes, I understand you're really good at fixing the copier. No, we will not have an Unfilled Requirement on our projects for copier fixer. "Copier Repair" is not a valid Clarity skill.
2) This is not the HR system. HR systems help HR people staff an organization ("Copy Repair" may be important to HR). Again, Clarity is Project staffing.
3) Get people to understand the difference between tool and skill. Visual Studio is a tool. ASP.NET is a skill.
4) Keep it manageable! Like Roles, they can creep on you. You'll need to establish a discipline to not let it creep.
Establishing the Skills Schema
1) Form a team that is responsible for the schema. Make sure they understand and adhere to the above (this was our first 3 failures).
- We went with a 2 level schema. Parent Skill is more like a category. Child skill is the real skill.
2) Once the schema is set, vet it and get the appropriate approval.
3) Establish a skills schema review process & cadence. During this review skills may be added, but also look at skills to sunset.
4) Establish a skills add/request process. No, emailing the administrator to add a skill because manager X wants it is not valid. I want us to establish a "Skills Czar" but so far no one is biting on this (I'd like us to staff a centralized resource planner - I'll nominate them the czar when and if we ever staff this).
Establish Operational Process:
1) Each new hire is given our Clarity Skills schema. They sit with their manager and do a self assessment. Again, this is work the resource and the manager wishes the resource to be "available to project work" for. Just because someone has a skill doesn't always mean they're the right resource for the job.
- The tendency (we've seen) is to "brag" in skills. Clarity Skills don't affect your pay. Stay focused on the skills that the resource is to be made available for project work, regardless if many other skills are applicable. Just because you can do a job, doesn't mean you should.
2) We require the skills to be defined on the resource within 60 days of hire (this is written into our Manager's performance expectations).
- I have a report that is automagically runs each month and is sent to our HR person to show violators. They follow up with the managers to ensure this gets done.
3) We require that a resource's skills be reviewed and re-assessed during their annual review.
- I've prototype some solutions to track whether this is done but all are kludgey. We're on the honor system for this one right now.
Tools we've built to support this:
1) "Skills List" (portlet) that shows the Parent/Child relationship and allows datamining.
2) "Skills Analyzer" (portlet) that allows datamining on all resource/skill combinations.
- This has a "Skills Defined" Yes/No drop box to allow us to see the "unskilled" ;P
3) "60 Day Exception" report (Webi) that simply looks for NULL skills 60 days > from Date of Hire.
4) "Skills Survey" form (Webi) - this simply pulls current skills out. This is the form filled out by the new hire.
What's next: We plan to "productize" a Resource Requirements schema in hopes of doing gap analysis reporting to help make future staffing decisions based off of upcoming demand. We also want to do a "next availability" burn down chart for the Resources that match the requirements. Big dreams, more work to do but it's working. We really need a Centralized Resource Planner to drive this to the next level IMHO.