Simulation FAQ

a. Figure out how much of the project time is spent in meetings and how much in individual work.
b. Create a random number of meetings with random participants at random locations to fill the meeting hours.
c. Create a timeline for each employee with hours for this and other projects randomly distributed.
d. Compute the wait time for each meeting for the participants to be available.

a. Click simulate several times for each set of data, to get a sense of the averages and variance.
b. Increase the multitasking level slowly to see that project completion time takes a really long time. Notice that if this is the only project everyone works on, completion time is low
c. Increase collaboration level and notice that the more meetings they have, the longer it takes. Also notice that at 0 meetings, you get the fastest project completion time.

One key assumption is that the need for the meeting is not known in advance. The wait time is computed at the time that the meeting is supposed to take place. For a construction project for example, this resembles the architecture and permit phase more than the concrete pouring phase. The modeling leans towards fluid collaboration more than assembly line style collaboration. The plan essentially is a dependeny graph with meetings serving as synchronization points.

The more busy people you try to bring together for a meeting, the longer it takes. Here is an example. If 3 people that are working on 4 projects each, need an hour for a meeting, it could likely take 64 hours to find a common time. Since each person is working on 4 projects, the chance that they have the next hour free is 1/4. The chance that second person is also available is (1/4) * (1/4). The chance that the third person is also available is (1/4)*(1/4)*(1/4) = 1/64. So, in total, it can take 64 hours to find a common free hour.

If other projects have similiar level of collaboration, they would involve wait times too, which could delay this project even longer. Optimizing for low wait times across all projects is a hard task, like scheduling flights to maximize airplane utilization for an airline company. For real world projects though, often there are plenty of unknowns and plenty of things that change after the plan is made that it is very hard to eliminate wait times across the board.

a. If you are collaborating with a busy person, it is going to take a really long time to complete the task. They can hold back everyone up for long times.
b. The more meetings (or interdependencies) you have, the longer it takes to complete the project.
c. Multitasking is far worse than the number of meetings on completion time.

Even if Kamune helps decrease the need for one meeting, you get savings. Here are many ways that could lead to that or more. People can get good context and updates from the logbooks that they otherwise get from meetings. People that attend a meeting just to see what was going on, can skip the meeting and read the transcripts at their convenience. Someone on the road can read the transcripts on Kamune from their mobile phone. People can hold meetings on Kamune (no audio/video yet), through text chat, sharing and custom slide presentations. These are surprisingly effective when participants are in different cities or countries. Questions that don't need a full meeting can be answered through other means on Kamune, from chat to bubbles to whispers, if not logbooks. Some of the routine meetings, like status meetings, can be eliminated altogether and that purpose met through logbooks on Kamune.

Sure, as mentioned in the easy fixes section, one could catch up on the status if their inbox was neatly organized, if they had access to their colleague's inboxes as well (for emails they weren't copied on), and if information in other sources (file servers and intranet web sites) was equally accessible and organized. They could use instant messaging to get quick answers if they all had each other on their buddy lists.Also, one of them could take the transcripts after each session and upload them to an organized location. They could send their daily or weekly status by email to avoid the status meetings. In addition to the problems it leads to with email, a lot of these activities are not natural in the normal course of using these tools. As described in easy fixes section, they require a self discipline that is rare, which leads to inefficiencies in meetings.

a. Planning recurring meetings in advance, can significantly cut down the wait times. However, they are ripe for abuse with increasing number of unnecessary attendees, unimportant agenda focusing on routine items that could be handled outside of a meeting.
b. Keep the number of participants in the project to a minimum.
c. Especially keep the number of projects someone is simultaneously involved in, to a minimum.