Project Management Professionals (PMP)®s are aware that Project Resource Management is just one of the areas they need to work in. If you have recently sat your PMP® exam (or are in PMP® exam preparation mode as we speak), you will remember that one of the processes in this knowledge area is Acquire Resources. While this process is concerned with getting hold of all sorts of resources – people, equipment and materials – here we are interested in acquiring the project team.

On this page:

• Creating Effective Job Descriptions: Focusing on Artefacts
• The Artefact Life Cycle: Skills and Requirements
• Using Business Process Maps in the Hiring Process

Creating Effective Job Descriptions: Focusing on Artefacts

In the real word, this is often decided at a higher level. The organization only has so many people available, so project managers are often given a charter and a group of people to implement its goals and objectives. Depending on the calibre of this group, the project manager will act as a rudder – steering the project to a successful conclusion – or s/he will have to be a propeller, driving the work every step of the way.
But what about those cases where the organization is in hiring mode and project managers have the luxury of going out there and recruiting new staff? Even in places where there is a Human Resource department that handles all recruiting, the project manager will be expected to produce a job description at least. It is a pity that you are not hiring solely for project managers. At least then, all you would need to look for is a project management certification, ideally the Project Management Professional (PMP)®.
The Guide to the Project Management Body of Knowledge (PMBOK® Guide) does not offer much advice for this task, so how do you create an effective job description? Looking at adverts for vacancies suggests that every role in every organization is being filled with “exceptional people”, all “enthusiastic self-starters” with “outstanding communications skills”. Technical positions often feature long lists of technologies that no single person could be expected to master. Indeed, the job advert is often used to advertise the organization more than the role itself.

The Artefact Life Cycle: Skills and Requirements

Because many roles require unattractive characteristics, framing your job description in terms of personal qualities may not attract the right candidates. For instance, someone who works in a maintenance role does not necessarily have to be a team player, but most certainly must be persistent. Similarly, a tester is someone who delights in finding fault with other people’s work and, of course, how much of today’s software has been written by shy, introverted people, whose communications skills would never be described as “outstanding”?
In 2006, an Irish academic, Jack Downey, came up with a novel approach to the problem. He was studying the different roles in software development teams and realised that all the roles shared a remarkable number of skills. He concluded that these had nothing to do with the role itself, but were required in order to work in teams. Rather than focus on the skills needed, he suggested focusing in on the artefacts used in the project.
This is very revealing, because the creation of an artefact involves going through a life cycle. Suppose a project manager wants someone to evaluate a potential, technical solution. We basically want that person to produce a technical, feasibility report (the artefact). So the first step in the process involves the project manager sitting down with the technical expert and explaining what is required. This operation requires that the project manager can explain the requirements properly, but the technical person needs to be able to gather sufficient information during this exchange to embark on the study. Once s/he is clear on what to do, the expert now researches the proposed solution, ideally reading up on previous attempts to do something similar. The expert may conduct some trials or experiments to evaluate the solution. The results of this research needs to be articulated in the form of a report. On receipt of the report, the project manager now has to decide if this solution is the way we should go.
If we want to hire a technical expert, who has to do this sort of evaluation, then we can see from the artefact life cycle that a lot of skill is required. We need someone who can:

1. Elicit a description of a technical solution from someone who is NOT a technical expert.
2. Conduct a research study into technical solutions. Be familiar with the literature in the area and be capable of creating actual prototypes and proofs of concepts.
3. Understand what should go into a report. Some people can write very detailed reports, which are absolutely no help to the person making the decision at the end of the day. The expert needs to have learned in the first step what the key performance indicators of the solution are. S/he will need to produce quantitative values for likely performance figures, maintenance costs, technical risk and so on.

Most organizations have clear business process maps that show how projects are worked through to completion. These can be very useful in guiding the hiring process. If you know the artefacts the new recruit will have to work with and also at what level the person will be expected to engage, then you have a clear understanding of what you will be looking for.
Just compare these two job description fragments:

Candidate requires strong communications skills and technical expertise to conduct technical feasibility studies.

and:

Candidate will evaluate the technical feasibility of alternative solutions. Those commissioning the studies will have little technical knowledge and will require objective feasibility measures (such as performance, complexity, maintainability, etc.) in order to make decisions.

By concentrating the job description on WHAT the person will be expected to do, potential candidates will have a better understanding of the recruiter’s expectations. In this case, candidates can decide whether dealing with non-technical people is something they are capable of (or would like to do). They can also see that their key deliverables are reports, not technical artefacts. They will see that their work will support the decision-making process and not contribute directly to finished products. For the project manager sitting on the interview panel, s/he has a clear picture of the role as well and can tailor the interview to explore the artefacts and the types of interactions involved.

Using Business Process Maps in the Hiring Process

This approach can fit nicely into the PMBOK® Guide’s Responsibility Assignment Matrix. If the project manager uses artefacts instead of activities, those “Responsible” actually create the artefact; those “Accountable” commission and evaluate the artefact; those we “Consult” help with researching the artefact and those “Informed” will review the finished artefact and may also influence the decision to be made at the end. So your PMP® certification does help after all.