Nader K. Rad

Structuralism in Project Management

2023-09-23

Two big words

I was telling a friend about something interesting I had recently learned from a podcast. He asked me about the podcast, and I replied, "It's an interesting podcast about ethnography called Thinking Allowed".

He immediately asked, "What the hell is ethnography?!" So proud of explaining the meaning of an English word to a native English speaker, I explained the relationship between ethnography and anthropology. He waited a little and then said, "Are you going to explain what anthropology is, or do you want me to ask?"

He had an idea of anthropology, but not enough to help him make sense of my explanation of ethnography based on it.

I looked up both words to help me give a better explanation, and one interesting thing I saw online was this: "Anthropology is a holonym of ethnography". I asked my friend if he knew what the word "holonym" was, and he didn't. We looked it up, and it turned out to mean what someone like me would use the word "superset" for. Interesting word!

All the words

How do we understand the meaning of a word in a dictionary? The meaning is explained by a few other words. So, to understand the meaning of the first word, we need to understand the meaning of those other words. If we don't, there's no problem, we have the dictionary in hand, we can look them up, and it describes them with yet other words.

When you think about it, it's a circular relationship. Some may say that words have no meanings because their meanings have a circular relationship (i.e., what a word means depends on what it means), whereas some may have a different reaction to it, which can be seen as a form of structuralism: The meaning of a word is its relationship with other words. In the network of word relationships, the relationships give them meaning rather than the content of those nodes (words).

Back to projects

What is a "project charter"?

  1. A naive approach is to try to define it by its content.
  2. A better approach is to explain its purpose.
  3. The best approach, inspired by the structuralist idea above, is to describe its relationships with other elements in the same system. Different project management systems may use the same word, but they give it different meanings based on how they use it in the system.

What does it mean to be a project manager?

The relationships that a project manager role has in, for example, PRINCE2, is what really defines it in that system, regardless of what the provided project manager definition is in that system. If you compare this to the role with the same name in DSDM, P3.express, PMBOK Guide, etc., you will find similar but different concepts.

What's the problem?

I was talking to someone a while back who was a little too enthusiastic about Agile. He told me there should be no project managers in the future and went on to explain his point. I asked him about his experiences on projects and what the people who were typically called project managers were doing. The fact was that those roles were really horrible, and I, too, prefer to have a future without that type of role.

I asked him to imagine a project with hundreds of team members, and we discussed coordination in that project. We gradually agreed that it's a good idea to have people dedicated to coordinating and facilitating such projects and one person to lead them. I called that person the chief project facilitator, and we discussed how this person should interact with others.

In the end, I told him that the role we had called chief project facilitator is exactly what P3.express calls project manager and not so different from the project manager role in DSDM and PRINCE2. In other words, he loves the project manager role with one meaning and hates it with another. That's absolutely fine, as long as we remember to point out the meaning when we give our opinion and don't extend it to every system.

Coming with a package

Using fixed labels, such as project manager, helps make the conversations easier because we can use the common meaning of that label in different systems as a starting point. It's also a bad idea because each label comes with a package formed in various systems, and those meanings can't be detached from what the system is trying to build. For example, that's why P3.express didn't use the common term "work breakdown structure" and coined a new one (deliverables map) to describe a similar concept without dealing with its package.

In practice, it's a matter of preferring familiarity to accuracy or vice versa. My suggestion: use labels when creating awareness, but avoid them when solving complex problems.

Take the MoSCoW prioritization technique. The "must have", "should have", "could have", and "won't have" terms have typical meanings in people's minds that don't match their definitions in MoSCoW prioritization. I've tried explaining the correct meaning to many people, but it didn't work very well. I could finally solve it by calling them "class 1", "class 2", "class 3", and "class 4" instead.

Teaching project management

This is the ascending order of quality in explaining a concept:

  1. What it is built of
  2. What its purpose is
  3. How it's connected to everything else

Let's take the "business case" concept. Most training programs start the topic by explaining the content of a typical business case. This creates a dysfunctional approach where people think as long as they have a document called a business case, with content aligned with what they are told, they will be fine.

A better way of teaching is to start with the connections, move to the purpose, and only end with the content and name. As a trainer, you can explain how people run into problems by continuing an unjustified project and how they can have checkpoints for justification along their process to avoid it. Then, you can discuss the type of information required for proper checking of justification, and finally, package them in a document and close the topic by telling the learners that the information package they've created for checking the justification of the project in continual intervals is called a business case in the system they are learning.

Conclusion

Don't assume universal meanings for key project management term. Instead, understand them based on their relationships with other elements within the system.

— the end —