Kalexo - how project teams connect

The Nobel Prize winning economist Ronald Coase explained that firms exist to minimize the communications overhead within and between teams. This refers to the cognitive load of having to process information, like figuring who should do what, whom to trust, and so on. This is especially interesting in the context of project-based industries where large projects can only be completed by many firms closely collaborating with each other.

For example, most construction projects involve the owner (or the payer), the architect, an engineering firm, plus all the contractors and all sub-contractors. In manufacturing and design, we identify the company developing the project, design firms, consultants and manufacturing firms. Cross-organizational work is pretty much the way everything gets done today, and firms are expected to work closer together than ever before irrespective of organization, distance and time zone.

Even though everyone is “on the same team”, collaboration between firms on a project have a much higher cognitive load – some sensitive document are often not shared, and there are legal issues who should know what when. The cognitive load is especially high in the construction industry, where elaborate legal and paper barriers have been erected to protect individual firms from risk.

With ever increasing pressure to increase project velocity, firms are now looking to new techniques and tools to reduce the collaboration overhead between firms without exposing them to additional risk.  For example in construction, new contractual forms like integrated project delivery (IPD) are forcing the cross-organizational barriers to be lowered or removed completely. The benefit is huge; in the construction industry which is known for immense waste, project velocity has been improved by 30% by using legal incentives to collaborate better.

Unfortunately high-performance cross-organizational working is quite hard to implement on a practical level for a number of reasons.

Firms on a project are often rather loosely connected with each other, and its very hard to establish a project-wide view of what is happening in the individual firms.  It is common for the inter-firm connection to be heavily based on personal contact, meetings, phone calls, and emails, which is not amenable to sharing or analysis at a project level.  Also, even if a project-level view of all activity can be obtained, there are often issues related to confidentiality that works against the collaboration barrier being breached.

Its against this backdrop that Kalexo developed a number of new concepts that encourage very close cross-organizational working all the while establishing a project-wide view.

The first is to capture all information about a particular issue, and allow for it to flow where is needed. We call these information capsules “threads”, and the are both a way to organize work, and also create a permanent record of what has happened.  For example, a thread could contain all the information about a particular manufacturing defect over the lifetime of the issue – documents, comments, checklists, priorities, actions taken and the like.  Each thread has clearly identified participants, who are individuals that work on the issue. When someone new needs to be brought up to date on an issue, he/she can simple be added as a participant, and now has the complete record of what happened at his/her finger tips.

If this sounds like a rather common sense thing to do, you are completely right. Unfortunately many projects don’t event get this most basic thing right – the history of an issue is spread out over many brains, inboxes, and personal disk drives, and like Humpty Dumpty is pretty hard to put back together again.  If you ever got a request to re-send a particular file, you have experienced this problem.

In additional to making information available to everyone via threads, there are several other reasons why they are so important:

1. Threads can be work-flowed between individuals even if they work for different firms.  Kalexo uses a soccer ball metaphor to “kick the ball” to participant – the participant who has the ball on a thread is the one responsible for driving the issue to resolution. When finished, the ball can be kicked to another participant to “run with it”.  A nice side effect is that work flows to where it is completed, and everyone on the project has an always-up-to-date view of what  needs to be done.
2. Threads can be prioritized up or down at any time as an issue heats up or cools down.  When you have a few hundred things to do, you out of necessity need to put some things on the backburner, and jump in where the fire needs to be put out. We typically find that threads live a long time, even if they are just a reminder for something that eventually needs to get done.
3. Thread participation is a very convenient way to ensure access control.  If you are not a participant, you can’t see the thread.  Kalexo by default uses a looser interpretation of this idea: you can view a thread if someone from your organization is a participant.  We call this natural security, since there are typically lower collaboration barriers between colleagues.
4. Threads can be reported on and analyzed.  If your project manager keeps on asking you for status, or you are getting fed up with boring status meetings that you have a 5 minute speaking part in, you will be happy to know that your project manager can slice and dice and drill-down into threads to his/her heart’s content with our thread explorer – without needing to giving you a call.

Threads are a central aspect of working with Kalexo Teamwork – we basically started with a way to create accountability across firms and then built all sorts of bells and whistles around it (including real-time collaboration).  Please take a look at the demo on our web site, or best yet, download it for a test drive.