Software development has this concept of “loosely coupled” components, which are components that reduce to the absolute minimum their dependence on other components. Actually, the definition is even stricter, saying that components should reduce to the minimum their knowledge of other components:

In computing and systems design a loosely coupled system is one where each of its components has, or makes use of, little or no knowledge of the definitions of other separate components.

The main advantage of these systems is that they are much easier to manage. For example:

• you can change the behavior of one component without breaking the whole system;
• you can replace a component without breaking the whole system;
• you can easily test a component because it’s isolated from the others

Recently, there has been a growing interest in asynchronous communication, like Message Queue or Publish/Subscribe systems, where the component that sends the request doesn’t block waiting for a response. Again, this is the “loose coupling” principle put in practice. There are some producers who produce messages and there are some consumers who consume messages. What makes it loosely coupled is that fact that producers don’t have a clue on who are the consumers and vice-versa. This makes it possible to build applications in completely parallel branches. You can have two independent teams who are completely oblivious of the existence of the other, one developing a producer and another developing a consumer. The application is worthless without these two pieces, but each one can function by itself.

The advantages of these systems are well understood and recognized by experienced software developers, but I wonder if the same principles wouldn’t apply to project management in general. One of the most difficult things to manage in a project is task dependencies. That’s where you’ll find the bottlenecks: some people have to stop their work because their tasks depend upon completion of another task. In other words, the tasks are as tightly coupled as they can get: they not only depend on other tasks, they have to know about the other tasks (at least, they have to know which tasks they depend upon and when those tasks finish).

What if you could manage the project in a completely loosely-coupled fashion? You would setup a simple rule: everyone in the team must be able to finish their tasks without depending on someone else. This means that when two tasks have a dependency between themselves, you have to mercilessly remove that dependency at all costs by:

• Trying to redesign the system so that it can work asynchronously or
• Simulating the output of the task you depend upon (in software development, this means using mocks or stubs)

If you fail to remove that dependency, then those two tasks must be done by the same person.

Now, I won’t lie to you: this comes at a price. Removing the dependencies will probably make the tasks longer, because you have to develop additional mechanisms, like simulating the output of other tasks. Assigning a sequence of tasks to the same person is also a risky move – that person may be doing a series of mistakes but since she doesn’t depend on anyone, you’ll only notice it later than in a typical project.

However, if you have a talented small team, it will work really well. It will be like watching several high-speed trains running in parallel, leaving a complete finished component from time to time. Maybe one of the trains is going faster than the others. It doesn’t matter. The project manager just keeps picking the finished components, until they can connect to each other (for example, until you have a producer and a consumer). It’s a great feeling. Try it.