Coupling and cohesion apply to the real world too..

[swatts]

Wotcha LV Peeps,

Hope you are doing good, doing work (if you want) and healthy.

If you are familiar with my witterings you will be aware of the terms coupling and cohesion. Because my brain is attuned to thinking in this fashion I've noticed that they apply to other things too....

One skill you get by default if you do what I do is that it makes you a pretty efficient project manager. (I get paid when I finish a project, it focusses your mind!)

I noticed something the other day when presented with a Gantt Chart .... I always work hard to remove things from the critical path. So rather than the chart below.

I much prefer this next chart, where possible.

Because I've decoupled the tasks from each other they are no longer on the critical path. If needed I could start task 4 before task 1 or even better get someone else to do it. The links are therefore coupling between tasks. How would we break those links? We could design the task to be easy to define and has limited and clear inputs and outputs.

This brings us to the point of coupling and cohesion, it was so that software could be broken into modules that could have multiple people working on them.

Another example is when organising events, one task is to organise the catering. It might be nice to provide the staff with GDevCon badged attire. This simple requirement has a lot of implications. We are coupling the organisation of the catering to the individuals in the catering staff. In essence we have become too involved in the internal workings of the catering company. It's much better to either not be involved in what the catering staff wear or to clarify in the contract that we want GDevCon badged uniform and provide clear requirements and leave it up to the catering company to organise.

So we are using cohesion to decouple ourselves from the internals of the catering company, this could be considered using a contract to hide the internal workings of the catering company.... Information Hiding!

All the best 

[thoult]

Hi Steve,

A common challenge that project managers have to also consider is that whilst tasks can often be logically decoupled in the technical domain, their complexity will often mean that they're not resource independent and so must remain on the critical path.

The approach of "...better get someone else to do it" is a key one in bigger projects to parallelise progress, but one of the challenges is identifying early on those tasks where you do not have enough "someone elses" of the right calibre to complete tasks. I've yet to find a PM who has figured out how to differentiate between time-coupled and complexity-coupled task sequences like this in a way that helps me justify asking for more advanced level resource.

It's easy for them to say "hey look, if we had another X hours of engineering resource, we'd complete all these tasks!", but it feels like it's some form of three dimensional chess for them to show how the critical path would be reduced if only I could bring in a few more kung fu masters rather than novice students. After all, sometimes the Big Bad in the project can only be defeated with the Five Point Palm Exploding Heart technique, and only a few have mastered it 😄

Have a good Christmas!

[swatts]

I love it!

And as with software design, everything is a compromise.

Your comment makes me want to think about project management a bit more!