Data privacy is a growing challenge for #IoT and #M2M applications with concerns for abuse of personal data by companies in the #DataValueChain. Whilst the privacy around data acquired through the consumption of individual services may be covered by user agreements for each service, how will private information created from aggregated non-personal data be protected? In many instances, non-personal data can be triangulated to derive highly personal information. Should 'non-personal' data be treated as personal data? 


Non-personal data can become highly personal if augmented by contextual data. For example, your presence on the high street is probably not very personal on its own. Now augment this data with a purchase in a wine bar, followed by a taxi ride to someone's house before you arrive home. Suddenly, the combined data could become highly personal.

The data for this hypothetical scenario is already being harvested by service providers and smartphone apps such as travel maps, card and mobile payments, internet search, social apps, etc. 

How will we balance the need to provide personal data for specific service provision and prevent this data from being combined with other personal data shared for a different purpose? How can the service providers assure users of the use of personal data AND other data about the user?
According to #GigaOm, the data privacy ship left a long time ago. Is it really too late to do something constructive to safeguard personal  data?

Project management best practice recommends that lessons be learnt and applied to future projects or later stages of the same project. Do you follow best practice with regards to lessons learnt? Here is what typically happens:

1. A lessons learnt workshop is conducted at the end of the project (if time allows before the project team is re-assigned to another project). This means that many lessons are forgotten and those that were captured are not leveraged into the current project. 

2. A lessons learnt log is completed to tick the box on the project closure form and once filed the lessons are never looked at again. The effort of capturing the lessons are wasted and the value of the lessons lost.

3. New projects are initiated without any consideration of lessons learnt from previous projects. Lessons are NOT learnt, but mistakes are allowed to be repeated and flaws perpetuated. 

Why are we not learning our lessons? At the start of a project, everyone is focused on getting on with the project and supercharged with optimisms. Once a project is underway, the focus is on meeting milestones, managing scope and dealing with in-flight challenges that reflective lessons learnt workshops are postponed to the end of the project. When the end of the project is finally reached, the incentive to do a lessons learnt workshop is low as any lessons will only benefit future projects. This is a vicious cycle.

In summary, few lessons are captured, even fewer lessons are benefiting the current project, and hardly any lessons are considered by future projects. The consequences are that many organizations stagger from one project failure straight into another failure. This reminds me of Albert Einstein's definition of insanity: "doing the same thing over and over again and expecting different results".

With the benefit of a lot of cumulative hindsight, we would recommend that the Project Management Office (PMO) takes the lead in conducting lessons learnt workshops during and at the end of each project and applying these to future projects. Alternatively, an independent expert such as Caleidoscope Associates can help companies to benefit from lessons learnt by capturing, analyze and leveraging these.