This is why I love my job. I get to do all this experimental stuff and I get paid for it!
Okay, let me explain.
We are undergoing some reorganisation at work. In case you still don’t know, I work at a research lab of over 40 people where I try to apply software engineering to cultural heritage. Most of my workmates, however, are archaeologists, historians, anthropologists or soil scientists. Anyway. A few weeks ago we decided that we should define a few key roles that people should be playing at the lab. How do you define a role? Mmmmm… Well, ISO/IEC 24744 says that a role is a collection of responsibilities that a producer can take, where a producer is, usually, an individual in an organisation. I like ISO/IEC 24744 because I believe it can be applied to much more than software development methodologies, and the definitions are quite good. The fact that I was a key contributor to it has nothing to do, of course.
So, the problem was now: how do you define a collection of responsibilities? I recalled that Rebecca Wirfs-Brock (together with Alan McKean) published a good book in the early 1990s, titled “Object Design: Roles, Responsibilities and Collaborations” where she describes an approach to responsibility modelling based on three aspects:
- Knowing. What an object needs to know.
- Doing. What an object is supposed to do.
- Deciding. What an object will decide upon.
I thought it would be good to apply this pattern to our problem, so my colleagues and I started applying KDD (knowing, doing, deciding) analysis to organisational roles. That is, you think of:
- What the role must know. For each individual “know” item, we try to determine the source of the knowledge.
- What the role must do. For each individual “do” item, we try to determine other collaborator roles or entities in the organisation.
- What the role must decide upon. For each “decide” item, we also try to determine other collaborators in the organisation.
To round things up, I added what I called a “negative characterisation” of the role, i.e. a list of things that the role that you are trying to describe is not. This helps clarify the scope of the role. For each item in this list, we try to determine what other role or entity in the organisation has the property that the role being described has not.
So far, the technique is showing itself productive. I’ve seen the work done by some of my colleagues and it looks great. What used to be very vague descriptions of roles are now concise and clear statements about what must be known, done and decided. This helps naming the roles, developing job descriptions and, hopefully, selecting the best person to perform each role.
We are still working on this. I will keep you posted on the final outcomes.