When people redefine organisational structures, defining particular roles is often an area where people struggle. For those who don’t know, this is called “Job Analysis”, and there are a great number of systems available today. that help you perform this task. Whether they are of any use is a different question, though. This post is the first in a series on simple job analysis, where I hope to explain to you a simple method which helps to develop a clearer understanding of any given role.
When performing a job analysis, we often know what we want out of a position but not the specifics of how that will be achieved. That’s why it’s best to start at the end, and look at outcomes first. It may seem counter-intuitive, but it works. Now, there’s such a variety to jobs out there that I can’t begin to define outcomes for you, but I can provide some hints to help you do it.
Outputs are not outcomes. If there’s something that warrants its own article, that’s probably it. Outputs are generally the result of some type of process. A great example is a factory floor. A factory worker might work in an area and make widgets, which are an output of that process. They aren’t, however, an outcome. Outcomes sit higher, if you will. They encompass not just a process, but elements of the work before and after the process. They can even encompass other processes, including those processes done by other positions. For example, consider our factory worker. Although his output is a simple widget, one outcome of his position might be the timely production of a certain quantity of widgets that meet particular quality standards.
Think of defining your outcomes as the reason for this position existing. What contribution does it make to its organisational group, and the organisation in general? If this is management position, what are the outcomes of the positions area of responsibility? The better you prepare your list of outcomes, the better you’ll be able to work on the rest of the position.