PM communication model

Question

In our search for a zero-email SE/BIM solution, we’re struggling to strip communication ‘terms’ to their essence. In PM-jargon, we tend to use many terms, such as; Decision - Action - Task - Note - Question - Change request - Change order - Issue - Remark - Comment - Approval - Assumption - Item - …

What is the minimum set of 'terms' to manage all types of communication? It's about more than just semantics.

Imagine you want to set up a database application to totally replace the need for e-mail, for all communication needs in a project. It has to be role-based, traceable and water-tight.

So what do we use e-mail for in projects? To inform, to question, to give a task, to implement a decision, to flag an issue, to request or order a change, to give feedback, to .... etc. etc. How could we reduce this to a minimal set of 'types of communication' - for the lack of a better expression - so that we can build a database-based e-mail replacement? With the obvious benefit that all communication is always explicit, structured, related, logged, traceable, ... instead of my Inbox, which is a Black Hole?

For instance:

• a Note (or Remark or Comment) is a message (a piece of information), from a Sender (a person/role or a 'meeting') to a Receiver (one or more person(s)/role(s) or a meeting). It does not require a response. So the only data fields required are: Message (= the note) - Sender - Receiver.

• a Question (or Request for Information or Issue??) is a message from a Sender to a Receiver (same definitions as above). It DOES require a response, by a certain time. So the required data fields now are: Message (= the question) - Sender - Receiver - Due date. The Answer will be linked to this Question, so that it is traceable.

• a Decision is a message (a piece of information), from a Sender to a Receiver (same definitions as above). It does not require a response as such, but it should lead to the mutation of a Requirement (Delete, Change or Create). If not, it is just a Note. So the required data fields now are: Message (= the decision) - Sender - Receiver - Requirement(s) affected. The Decision will remain linked to the affected Decision, so that it is traceable.

• and so on ...

My question now is: how many 'terms' are required to cater for all types of 'information exchanges' in a role-based PM-system, if the objective is to make the use of e-mail obsolete? And what is the smallest set, to keep this as simple as possible?

Does some kind of 'information exchange model' (i.e communication model) exist?

Answer 1

I'll try to answer your question, but I'm not sure it's really possible to.

Let's say there are 5 discrete messages one can send to another.

• Feature - Something that is expected to be delivered.
• Decision - Something that needs to be (?) or has been (!) decided.
• Question - Generic, may also be used as a prefix, to specify a type of question. (e.g ?feature or ?Decision)
• Issue - Problem, risk or bug
• The other ones*

*Within 30 seconds of posting this, somebody will say "what about x?" and they'll be right. In order to make a small list, you need to make gross generalizations.

At this point a BA, or PM would ask, what really is the issue you are trying to solve? It sounds like email just isn't working for you and you want to create something better. Then we'd look and see how much it'd cost, and what the benefits would be to the organization.

One of the first things I'd ask my tech team is, "Are there any tools out there already that can be had for less than it'd take to build it?" Maybe, maybe not, but it's always worth looking. (Also, is this product going to be a part of your core business? See Joel's take)

In this particular case there are lots of different tools that can be used to solve this problem, although not quite the way you mention. Maybe slack would do the trick, or perhaps asana.

Answer 2

I understand your objectives as follows:

• Your organization (or some part of it) are trying to get rid of e-mail as primary means of communication.
• You are trying to replace it with some other tool. It sounds like you're aiming to develop a solution of your own.
• You are trying to go about this by building a theoretical model of project-related communication.

Assuming this is correct, here are my thoughts:

This has been attempted and partially solved by a whole bunch of people. How about having a look at various collaboration and workplace communication tools to see what they have decided to implement in terms of objects and workflows. This could be a place to start: http://alternativeto.net/software/jira/

I don't know your organization and what the stakes for this endeavor are, but your approach sounds a bit too theoretical. I doubt that it will be efficient and that you will arrive at a final understanding that everyone can subscribe to that is not very complex. I.e., you will have

• very high costs for developing a solution
• to make some compromises

Without knowledge about your organization, people will only be able to give you inspiring, but not necessarily to the point answers. If you are trying to develop a solution for your organization, it would be tailored to your needs, and should thus be derived from the processes that your organization currently employs (and ideally the ones you foresee being employed in the future). So either these requirements can only be understod by people in the organization. Or you will receive input on rather generic concepts, which then in all likelihood will already be available in some OTS solution (i.e., a common denominator of PM tooling, if you will).

Your best approach might be to use a solution that

• already exists and can be bought/subscribed to
• is rather flexible in its setup (you can model custom workflows in JIRA, for example)
• can be extended as needed by your organization with custom development

Answer 3

There are several communication models. However, the surest way to create a no-email environment and understand it's impact is to cut-off email for project communications.

Answer 4

For variety of reasons, including communication ... build your project workflow around Git or some DECENTRALIZED version control system.

You must anticipate that people will work in different locations, in airports, at their homes, in parks or coffee shops and occasionally at their desks. If you don't make version control repositories decentralized, the version control system will not get used and people will adapt a amazing variety of sneakernet and ad hoc file storage and backup alternatives.

I would strongly urge that anyone [who is serious about communication] take a hard look at Github-centric workflow ... because of the full Github codegraph and all of the ways of inherently communicating progress to all participants by visually tracking commits, pulls, issues, comments, etc ... AND, maybe even more importantly, so that you can dispense with meetings [where no real communication ever happens anyway] and use repository centric chat, eg Gitter.

An added bonus for everyone enduring the pain of learning Git and moving to a Git-based workflow model is that your skills working inside this mental framework will be transferable and will work across organizations.

Git is open source and and that is EXTREMELY important because it explains why Git and it variants have won the battle in the important realm of version control. Anyone who uses version control will be using a dialect of Git for the next 25 years or longer ... a Git-based PM [communication] workflow is going to trump all other proprietary approaches. If there is a better idea, it will come from an extension or fork of Git.