Quality Hold or Non-Quality Hold?

At times, a manufacturer is forced to put a product on quality hold owing to some issues getting identified or getting reported on the product from the field.

When the above happens in just a few weeks of the product getting launched, it speaks volumes about the lack of necessary product quality measures before the product is allowed to ship.

This has direct and immediate business impact on the sales figures for the period the product stays on "quality hold".

The term "quality hold" is an interesting one.

It means a product is put on hold due to quality.

Whereas, the product is actually put on hold due to lack of quality or due to non-quality.

It would be better to use the term "non-quality hold" rather than "quality hold".

From a business point of view, quality holds come at a cost.

In addition, there is an impact on the market reputation of the manufacturer.

This has a lot to do with the pressure on manufacturers to design, build and ship new products as well as frequent and continuous product improvements and innovations.

The business pressure leads to short-cuts being taken or crucial aspects getting ignored.

That may result in faster delivery, but at times, not a good one.

Organizations need to carefully assess and balance out the time to market pressure against the need to have good quality of the product that eventually gets shipped.

Quality holds are never a desirable situation for any manufacturer.

In several instances, it is possible that the issues getting identified or getting reported on the product from the field may not lead to any visible product failure in the short run.

However, in case any issue comes to the notice of the manufacturer it has an obligation to act upon it with high degree of urgency.

Hence quality holds.

It would be preferable to never have a quality hold or rather non-quality hold happen.

Business should, at no time, be forced to hold itself from continuing to ship and sell products due to quality hold.

The reason is very simple.

Every quality hold is nothing but essentially a business hold!

Process, Process Everyhwere But Not A Practice To Be Seen

The above reflects the true state in many organizations.

They have many processes, at times more than what is perhaps needed.

However, the compliance to these processes may not be adequate.

Which means they have process, process everywhere but not a practice to be seen.

In such organizations, whenever somethings falls through the cracks, the first and natural tendency is to put a process around it.

So over time, the volume of processes adds up and builds up to a very high degree.

There are processes that get defined and documented for anything and everything.

The above is a good approach to apply the systems approach in an organization.

There are two key rules that should be followed in such situations:

• Standard process is put down for those activities that are done again and again and generally very frequently

• Standard process is put down for those activities that involve multiple hands and multiple stakeholders.

The problem arises when these processes are not followed religiously.

The compliance to the defined processes is for namesake only and hence these processes do not deliver value in an effective manner.

Lack of compliance to processes in many organizations is a result of cultural issues as well as operational pressures.

Compliance issues may not have immediate impact but do have an impact in the long run for sure.

Such organizations have process, process everywhere but not a practice to be seen!

Lala Culture in Pseudo-Professional Companies

There are professional companies.

And then there are the pseudo-professional ones.

The pseudos do all possible things to create the facade of professionalism.

However, peel the first layer off and you get to see the dirty reality immediately.

The top dog in such companies has a fetish for external recognition.

And that is really sick.

Even if you are the biggest rat in a small rat-hole, you are still a rat.

This is exactly the case with the Lala-type man who is the top dog or the top rat in a small shop-type pseudo-professional Lala company!

This man is invited to an important meeting where he is also the chair.

On the day of the meeting, an hour or two before the scheduled start time, this man calls you and tells you that he some other supposedly important engagement.

Which also means this particular meeting is not important!

And asks you to go ahead without him.

He says this meeting will mostly be about the routine stuff.

So its okay to go ahead.

It is actually not okay and only a Lala-type man can make such a statement.

For any company, focusing on the routine stuff is absolutely important to ensure the operations go on smoothly.

Of course, focus needs to be on strategic stuff too.

However in small shops where the Lala is the boss of the house, there is nothing really that can be called as strategic stuff.

The Lala-type man creates a false impression about himself and the small shop he is taking care of more like a watch-man than the top leader.

When told that the so-called routine meeting is an important one and he should attend, this man reluctantly agrees and provides a date and time slot when the meeting can be re-scheduled to.

When the day of the re-scheduled meeting arrives he does something completely non-sense, something only a Lala-type man can do in a pseudo-professional company.

This man is, interestingly, the one who is the chair of the so-called routine meeting.

You are the organizer  of the so-called routine meeting and you have asked someone in your team to send out the meeting request to those who should attend the meeting including the chair (that same Lala-type man).

This Lala-type man does something amusing.

He wants to re-schedule the meeting again by pushing it further by half-an-hour.

That's really crap.

The bigger crap is that he doesn't call and inform you directly.

He calls one of his stooges from the old boys club he has created in the company.

This stooge becomes a messenger  of the top dog.

The stooge tells you that the Lala man wants to move the meeting ahead by half an hour.

You are supposed to comply.

This was told to you for your information only.

You are nothing, just a complete zilch.

Do you feel humiliated?

Not at all.

Why?

Just one reason.

You have seen the same kind of non-sense happen umpteen times already.

There is no surprise.

There is no shock.

After all, this same man has parachuted an incompetent nincompoop over your head with a funny, dysfunctional title.

So what else can you expect other than sheer non-sense?

That nincompoop has only only competency -  he is a "yes sir" stooge.

This Lala-type man is used to such an abnormal style of functioning so you cannot and should not expect anything fair and transparent in such an organization.

The meeting gets shifted and eventually happens also.

What also happens at the same time is, that whatever little respect you had left for this man simply vanishes into nothingness.

You have no choice but to comply with the Lala's wishes, whims and fancies.

You do have a choice regarding how much respect you really have for the Lala in private.

In such companies it will be a zero-respect in private situation, but you would create the facade of just the opposite.

The reason is that you need to play smart with the respect factor for the Lala in public.

And then, the big question.

Lala culture in pseudo-professional companies is a bitter truth.

The faster you adjust to that truth, the better for you.

Don't carry any ego as you will be humiliated again and again.

Be ready for any and all kinds of non-sense.

There should not be any surprise.

There should be any shock.

If you do the above, you will be at peace with yourself.

Do, however, enjoy the experience as you pass through the amusing times you are surely going to have when you work with a pseudo-professional Lala company.

ITIL 4 - The 4 Four Dimensions Model and Service Value System

The ITIL 4 framework, the latest version of the ITIL framework, was released in Feb 2019.

The key concept in this model is the concept of services that are delivered by a service system.

So what does a service system contain?

A service system essentially contains the following elements:

• Service relationships (the supply chain through which service is delivered)
• Service offerings which constitutes of:
• Goods
• Access to resources
• Service actions that provide the core, enabling and/or enhancing services,
• Products (refers to the hardware and software used to deliver the service)
• Resources (refers to other elements like people, knowledge repository, etc.

The ITIL 4 framework, broadly speaking, consists of the following key components:

• The Four Dimensions Model
•  Service Value System (SVS)

Here is a schematic representation of the ITIL 4 framework in a nutshell:

The ITIL 4 framework consists of the following key components:

• The Four Dimensions Model
•  Service Value System (SVS)

THE FOUR DIMENSIONS MODEL

The four dimensions include:

• Organizations and people
• Information and Technology
• Partners and suppliers
• Value streams and processes

The above four dimensions represent perspectives which are relevant to the whole SVS, including the Service Value Chain (SVC) and the ITIL Practices.

However, the PESTLE factors, as mentioned below, that are beyond the control of the SVS constrain and influence the four dimensions:

• Political factors
• Economical factors
• Social factors
• Technological factors
• Legal factors
• Environmental factors

The interplay of the four dimensions impacts the creation of products and services for the provisioning of the service offerings for creating value for the service consumers.

ITIL SERVICE VALUE SYSTEM (SVS)

The ITIL Service Value System (SVS) coverts the inputs in the form of Opportunity/demand into outputs in the form of Value.

The core components of the ITIL SVS include:

• ITIL Guiding Principles
• ITIL Service Value Chain (SVC)
• Governance
• Continual Improvement
• ITIL Practices

The Seven ITIL Guiding Principles

• Focus on value
• Start where you are
• Collaborate and promote visibility
• Think and work holistically
• Keep it simple and practical
• Optimize and automate

ITIL Service Value Chain (SVC)

The service value system (SVC) is the central element of the SVS and is essentially the operating model which outlines the key Activities required to facilitate value creation through service provisioning.

The six SVC Activities are:

• Engage
• Plan
• Obtain and Build
• Design and Transition
• Deliver and Support
• Improve

For converting inputs to outputs the SVC Activities use different combinations of ITIL practices.

Governance

This provides the system for directing and controlling the organization and is realized through the following activities:

• Evaluate - Assess the business needs, strategic priorities and current portfolio
• Direct - Decide the strategic direction, future investments, organizational polices
• Monitor - Appraise the performance of organizational outcomes and business benefits

Continual Improvement

Opportunities for continual improvement needs to be explored at all levels of the organization in all functional areas.

The continual improvements can range from strategic to tactical to operational  to the ones which are transaction-based in nature.

The continual improvement model involves use of the following steps:

• What is the Vision? - Align with company mission, business goals and objectives
• Where are we now? - Determine current performance baseline (KPIs and metrics)
• Where do we want to be? - Define measurable targets that need to be achieved
• How do we get there? - Define the improvement plan
• Take action - Execute the improvement plan
• Did we get there? - Evaluate improved performance baseline (KPIs and metrics)
• How do we keep the momentum going? - Put in place measures for ongoing sustenance

The improvement ideas should be logged and tracked to closure using a structured system like a continual improvement register or log.

ITIL Practices

The practices essentially constitute a set of resources designed for performing work.

There are 34 ITIL Practices which are arranged in three broad categories:

•  General Management Practices (14)
• Architecture management
• Continual improvement
• Information security management
• Knowledge management
• Measurement and reporting
• Portfolio management
• Organizational change management
• Project management
• Relationship management
• Risk management
• Financial management
• Strategy management
• Supplier management
• Workforce and talent management

• Service Management Practices (17)
• Availability management
• Business analysis
• Capacity and performance management
• Change control
• Incident management
• IT asset management
• Monitoring and event management
• Problem management
• Release management
• Service catalogue management
• Service configuration management
• Service continuity management
• Service design
• Service desk
• Service level management
• Service request management
• Service validation and testing

• Technical Management Practices (3)
• Deployment management
• Infrastructure and platform management
• Software development and management

When the Head of Operations in an Imbecile as well as a Dim-witted Nincompoop

The head of operations is a crucial role in any organization.

The person in this role needs to be not only smart and intelligent but also fair and highly professional.

However, in several organizations, the head of operations is effectively a joker.

He is there for one reason.

His loyalty to the top man.

When this person is an imbecile as well as dim-witted nincompoop it is very damaging to the professional fabric of the organization.

Several unfortunate things happen in such a company.

This person creates his favorites in the system.

• The set of favorites are beyond the usual rules of business operations. 
• The favorites are into R&D for the future, technology innovation, IP development, competency building, brand building and every such thing where they are not exposed to the pulls and pressures of corporate life. 
• These special folks are basically living a retired life just like the head of operations himself. 

This person acts with a pronounced bias.

• He needs to keep his favorites in good humor.
• He also needs to keep those who he is loyal to happy and needs to prove his loyalty again and again.
• He doesn't own up to the mess he ends up creating every time he does something due to lack of clarity and poor communication.

This person needs to be a "yes sir" barking dog

• He needs to bark when told to bark and shut up when told to do so.
• He has no mind of his own and needs to take orders.
• He needs to oblige the different sirs in the organization who are letting him carry on with the nonsense and mess that he has created.
  

This person projects an image of exclusivity and seniority

• He gets a bigger room similar to other imbeciles in the organization.
• He goes for lunch with other jerks like him.
• He is there for long time so has become a senior due to loyalty more than merit and leaves no opportunity to show a sick sense of exclusivity and seniority.

Such imbeciles and dim-witted nincompoops are usually hard to tackle.

They, however, do provide a comical, but not at all necessary, relief from the professional hassles.

In the long run, they end up making the organization sick.

Very sick.

Very very sick.

Process Definition Continuum

An earlier post on this blog titled Process Tailoring, Process Deviation, Process Exception, Approval and Waiver dwelt upon concepts such as tailoring, deviation, exception, approval and waiver in relation to the defined process that gets used for performing any work.

In light of that, it can very well be said that process definition in the real sense happens over a wide continuum starting from standard process getting used to a situation of "no process".

As an aside, an important one though, it needs to be clearly understood that "no process" does not mean no process is being used but that their is no agreed/common/consistent process in place that is getting used.

• Everyone is on their own and supposed to deliver their piece
• Work would seemingly happen but their is no assurance about what exactly will be coming out of that work at the end of it, if the work even reaches its end ever!
• There will be a lot of friction between the manager and the team, between the team members and between various sub-teams engaged in that work
• There will rise out of the ashes some "heroes" who may happen to save the day, but only in certain instances and that too after they and the others would have undergone severe burn-out

Clear understanding of the continuum concept is necessary to ensure a systematic and structured approach is firmly put in place while following the standard processes or the variations thereof.

The continuum view of process definition also implies that the process definition that is finally put into use is the one that happens at the granular level.

The granular level process would get captured as part of the project management plan, service delivery plan, product management plan, etc.

And even if localized processes are used or the "no process" type of process is used, there is still an overall governance layer to take care of deviations as also the exceptions.

The big thought here is that there is a well-defined process in place for handling any situation, including that of the situation of "no process" too!

The following figure presents the process definition continuum illustrating the different levels at which process definition at the project plan level would typically play out.

 

Here are the four levels in which the process definition continuum can be categorized into.

ORGANIZATION’S STANDARD PROCESS

• Ideally speaking, standard process should be followed by every project.
• This will enable meaningful comparison of performance across different projects in the organization.

PROCESS TAILORING

• There are situations, where a project would require that it be allowed specified variation over the standard process without the need for any approval.
• Such variations should get included in the tailoring guidelines and govern any process tailoring.

PROCESS DEVIATION

• Then there are situations, which should be infrequent, where a project would follow an applicable process but in a manner that is different than the standard process as well as the tailoring guidelines.
• Such case-specific process deviation should get approved and waived-off by the topmost authorities accountable for process and delivery outcomes of the organization.

PROCESS EXCEPTION

• And lastly, there are situations, which should ideally be rare, where a project would work with no basis in standard process, process tailoring or process deviation. 
• Such process exception (either to few or all applicable processes) should get approved and waived-off by the topmost authority accountable for business outcomes of the organization. 

CMMI V2.0 - Services View

CMMI 2.0 or version 2.0 came into being with the release of the Development view in March 2018.

This was closely followed by the subsequent release of the Services and Supplier Management views in December 2018.

This post is exclusively focused upon the Services view of CMMI V2.0 model.

It provides high level description of the four practice areas that come under the "Services" category.

• Strategic Service Management (STSM) - what services to provide?
• Service Delivery Management (SDM) - how to ensure delivery of selected services?
• Incident Resolution and Prevention (IRP) - how to ensure smooth service delivery?
• Continuity (CONT) - how to ensure disruption-free service delivery?

 
The above four practice areas are described in a more detailed manner in the following sections of this post.

Strategic Service Management (STSM)

STSM relates to designing, developing and deploying new or upgraded services. It also conceptually relates to decisions regarding downsizing or discontinuing of services that are in operation.

The key point here is ensuring there is deep and strategic connect of the service offerings with the business objectives, needs and directions.

Key elements that need consideration in this practice area include:

• Creating and maintaining a service catalogue that lists down all types of service offerings with different levels of support (like standard, premium)
• An example of this could be a bank offering different facilities/services like ATM, lockers, teller, FD opening/closure, etc.
• Again, there could be different SLAs/levels of the above services based upon customer types like regular. privilege, etc.
• Creating and maintaining the SOP for providing the services with detailed description of the work flow
• Creating and maintaining the SOP for introducing a new or upgraded service and also for downsizing or discontinuing an existing service
• Analyzing the services portfolio to keep it aligned with the business objectives, needs and directions of the organization.
• An example of this could be a bank offering new facilities/services in the branch operating in a specific locality based upon that locality's unique characteristics.
• Again, the bank can discontinue certain services in the branch operating in a specific locality including even shutting down the branch (which essentially means all services get discontinued!)

Service Delivery Management (SDM)

STSM takes care of which services should be offered. SDM takes care of service delivery system to ensure services are delivered as planned.

SDM relates to the provisioning and delivery of the selected services. It also conceptually relates to decisions regarding enhancements, changes and improvements to the services that are in operation.

The key point here is ensuring there is clear operational connect of services with the service catalog and the SOPs for the services that are on offer.

Key elements that need consideration in this practice area include:

• Provide services (which essentially means handle incoming traffic of service requests/tickets) in line with SLAs or service performance contracts and includes services scope, service window (time/availability), SLA commitments, etc.
• Operate and maintain the end-to-end system for service delivery including introducing changes to enhance or improve the parameters related to effectiveness and efficiency.
• Analyze service performance to identify improvements in service delivery like cycle time reduction, response within SLA, resolution with SLA, SLA tightening, etc.
• Evaluate the suitability of service delivery system in terms of its capacity and its actual performance in catering to the incoming traffic of service requests (this would also feed into SSM for the top-level intervention at the service catalog level)

The workflow for handling service requests can follow a workflow similar to what gets used for handling an incident or issue as mentioned in the section below.

Incident Resolution and Prevention (IRP)

SDM takes care of the actual delivery of services on the ground. IRP ensures incidents and issues that  disrupt service delivery are addressed promptly to ensure high availability to the end-user of the services.

IRP relates to identification and resolution of incidents and issues that disrupt or degrade the delivered services and in selected cases investigate the underlying causes to prevent recurrence of certain incidents and issues.

The key point here is ensuring that any disruption of degradation in services is restored and the service operations brought back to normal state at the earliest so that services continue to be delivered in line with the SLA commitments.

Key elements that need consideration in this practice area include:

• Identification of incidents and issues (both in a reactive mode as well as anticipatory/proactive mode) that disrupt or degrade service delivery or may do so
• The definition of incident can be extended beyond issues or problems faced by an end-user to include requests regarding some help or query related to something where the user may have got stuck.
• The incidents, issues and user requests can be logged as service request or problem ticket or service issue or service ticket, etc.
• Logging and tracking the incidents and issues to their resolution and eventual closure
• Resolving incidents and issues in a systematic manner in accordance with the SOP for the same - this SOP should have steps like:
• analyzing the incident or issue
• classifying the incident or issue correctly
• assigning to the right team/personnel
• identifying the fix or workaround needed
• verifying that the proposed fix or workaround will actually resolve the incident or issue
• implementing the proposed fix and pushing that into production
• verifying the fix or workaround is actually working as was thought
• informing the concerned stakeholders and/or the requester that the incident or issue has been resolved
• obtaining concurrence of the requester that the incident or issue has indeed been resolved
• closing the service request or ticket
• Investigating the underlying causes of selected set of incidents or issues and take measures to prevent their recurrence either by eliminating them altogether or minimizing their frequency of occurrence - this is recommended in following situations:
• an incident is occurring very frequently or becomes a pain point for the end-users
• an incident is not occurring very frequently but has significant disruptive or degrading impact on the service delivery system
• an incident is not occurring very frequently but has end-users like the CEO, senior management whose down-time is pretty expensive

Continuity (CONT)

IRP takes care of resolving incidents and issues that disrupt or degrade the services being delivered by a service system.

CONT ensures mitigating measures or controls are put in place to reduce the likelihood of serious disruptions or catastrophic events that have severe impact on the availability or performance of the service system and also the overall business operations.

An example of this could be the outage of the web portal of an e-retailer!

CONT relates to identification and implementation of mitigation measures to avoid the occurrence of serious disruptions or catastrophic events during the operation of the service delivery system.

It also conceptually relates to the complete business operations which essentially means all services being delivered by the business.

This view has direct linkage with the business continuity and disaster recovery plan concept in the ISO 27001 standard as also ISO 22301 (ISO standard exclusively focused on business continuity management).

The key point here is ensuring some kind of FMEA (Failure Modes and Effects Analysis) or FTA (Fault Tree Analysis) is done on the service delivery system (or even the overall business operations) so as to identify and address, in a proactive manner, things that could go wrong.

Key elements that need consideration in this practice area include:

• Identification of the triggers that can lead to serious disruptions or catastrophic events
• Identification of the approaches to mitigate those triggers
• Implementation of the measures and controls in line with the selected approaches for mitigating the likelihood of the triggers
• At times, it may not be possible to influence the likelihood of a serious disruption or catastrophic event so in that case it is advisable to focus on reducing their impact should they happen (an example could be floods in an area where nothing can be done on the likelihood part but a better building design would lessen the impact)
• In addition to mitigation plan, there should be a contingency plan which would state what will be done should any serious disruptions or catastrophic event were to occur
• Preparation of a continuity plan for service operations which should include
• List of functions and services that are essential to ensure continuity of operations
• The sequence of restoration, RPO (recovery point objective) and RTO (recovery time objective)
• Period verification and validation of the continuity plan which should include
• Training of the staff involved in ensuring continuity as well as recovery and restoration after the occurrence of any serious disruption or catastrophic event
• The trained staff should be fully aware of the contingency measures as documented in the continuity plan
• There should be periodic testing of the continuity plan to ensure the plan would "go right" when it needs to be invoked and this is important because it will be a situation of real crisis when it would need to be invoked, if ever

Why Software Size and Effort Estimation Continues to Haunt Software Projects?

The profit margin one is expected to make in a software project is a function of the productivity one expects to operate at and the cost that would be incurred at that level of productivity.

Accurate and precise estimation of software size and effort estimation has remained a key barrier in estimating the productivity of software projects.

In some sense, software size and effort estimation continues to haunt software projects.

Finding the "silver bullet" method for estimating size and effort is akin to finding a drop of water one can drink while one is stranded in the middle of an ocean.

Almost impossible.

Looks like that.

However, that's not true.

Size and effort are simple but powerful concepts.

Size indicates the amount of work or the volume of work that needs to be performed.

Effort indicates the amount of work hours spent to generate a certain size.

And by definition productivity is the size generated for a unit of effort spent.

Very simple.

The key consideration however is that effort should use the size information.

That makes the whole game of estimation interesting and hard.

So how to estimate size?

There are many ways like function points (FP), kilo source lines of code (KSLOC), situation-specific complexity points (CP), number of requirements, number of pages, number of test cases, etc.

It is better to use FP since there is lot of literature available on it in addition to the support system available.

Once size information is available how to estimate effort?

Effort is based upon size as well as additional factors like complexity of work, competency of the person performing the work, effectiveness of project management processes and controls.

All the above factors do somehow get captured in the concept of productivity.

So effort can be estimated from size simply using productivity figures.

Many organizations never get started with the above methods due to several reasons like poor understanding and incorrect notions regarding the industry methods, lack of will, lack of ownership.

In fact, in some of the organizations, there are some "dummy experts" on estimation who think they know more than those who are recognized in the industry as experts on estimation.

The dummy experts end up creating an estimation framework that is neither usable (the method is over-engineered and with too many layers of details after details) nor useful (the estimates that get computed by using the framework are not realistic and hence of no use in real).

On top of it, the experts do not own the future maintenance and enhancement of this framework.

Lack of any effort on sustaining the framework is like slow poison that kills that framework eventually.

The whole thing may happen with lot of fanfare but meets its natural death at some point in time.

So what to do if nothing works out?

If nothing works out, the best bet is to create a very very granular WBS (work breakdown structure) or PBS (product breakdown structure) or a combination of WBS and PBS.

Effort for the WBS elements can then be estimated based on the volume of work at the WBS element level.

That brings the flavor of size being estimated followed by size information being used for deriving effort estimates.

All said and done, estimation is a hard nut to crack.

And while you are at it, trying to crack it, it may make you go nuts!

Cyber Security Key Terms - Event, Risk, Incident and Breach

The terms - event, risk, incident and breach - are generally not clearly understood and at times used in a manner which is not appropriate.

So what do these terms mean?

Here is an attempt to define these terms in a very simple language.

Event is any observable occurrence in a system or network. Some events can be conveniently ignored, whereas some would need to be investigated and there are some that would even need some kind of an action. An example of an event would be someone attempting to hack a company's network

Risk refers to the likelihood of a certain event that has the potential to cause some kind of loss or damage. An example of a risk would be data being stolen from a company's network.

Incident is a risk that gets materialized. An example of an incident would be an actual instance of data being stolen from a company's network.

Breach is an incident that violates specific legal requirements. An example of a breach would be an actual instance of data being stolen from a company's network where the breach involves personal information which violates privacy regulations.

Data Privacy and Information Security - How are they different and how are they same?

Data privacy has become a commonly used term in the industry now.

Though this term has been around for several decades, the introduction of the GDPR law in the EU on 25th of May 2018 has brought this into the mainstream.

In any case, data breaches are dreaded by the information security folks.

These folks are essentially cyber warriors who take care of two crucial things for any organization:

• protect the organization's information from getting into wrong hands.
• secure the organization's IT assets from getting hijacked or compromised by other cyber warriors.

Data privacy adds a new twist to the already existing tale.

It actually makes it much more serious by bringing legal angle into the already complicated cyber security equation.

Data breach is a serious thing.

And if the data breach involves personal data of living individuals the seriousness gets compounded by a significant degree.

Data breach involving data privacy doesn't remain just a security breach but becomes a legal violation.

That's the reason for the increased focus on data privacy in the organizations in the business world as well as in other organizations that handle personal data.

It is important to note that the administrative fines and compensation for damages may have significant material impact both in financial terms as well on the organization's brand equity.

How are privacy and security different?

Here are some of the aspects where they are different like chalk and cheese:

• Privacy is important when the data is personal in nature, whereas security is important with any data.
• Privacy breaches would directly amount to legal violations, whereas security breaches may or may not amount to legal violations.
• Privacy is concerned not just with securing the personal data but also adherence to the generally accepted privacy principles (GAPP) whereas security is concerned just with securing the data.

How are privacy and security same?

Well, they are not exactly same, speaking in a strict technical sense. They are however strongly linked.

Here are some of the aspects where they are linked with each other:

• Privacy breaches in many instances would generally get reported as a security breach first where subsequent investigation may turn it into a privacy breach also should any personal data found to have been involved.
• Privacy cannot be ensured and assured unless security is taken care of as the basic building block over which privacy would get built (security for privacy).
• Privacy would mostly rely upon the technical controls implemented as part of information security to take care of adequate technical measures required for ensuring privacy.

Data privacy and information security are actually comrade in arms.

Improving one would make the other better.

However, security has to be seen as a more fundamental thing as compared to privacy.

For any organization, the first step in strengthening its cyber defense systems should start with information security measures.

The next step would be to go with data privacy measures.

Regular reviews, audits and technical assessments of information security and data privacy in an organization has become a sine-qua-non in the present context.

In summary, it can very well be said that security first, privacy next and after that both together forever and ever.

Data Privacy Regulations - Some Key Practices

Given that there is no escaping from data privacy regulations it is important to understand some of the key practices that an organization should implement.

Following list provides some of the key data privacy practices that an organization needs to put in place and in practice to ensure compliance with data privacy regulations:

Identification of operational/functional business units in the organization that need to be made owners of data privacy compliance

• Since activities of each and every employee should be covered under data privacy regulation, at times, logical entities may have to be identified and treated as operational/functional business units so that all employees are brought under the purview of data privacy regulation.

Identification of business processes in different business units that handle personal data

• This is a crucial step in ensuring no business process gets missed out, even by chance.
• The owner of the respective business units need to be made accountable to ensure that all relevant business processes in that area get identified

Identification of personal data in the applicable business processes

• Even if there is one element of personal data involved, data privacy regulations apply and need to be taken care of adequately and appropriately.
• Identification of personal data being handled across the multitude of processes and transactions across the various business units in an organization is the most important and crucial step in ensuring 100% compliance to data privacy laws.
• The key outcome in this case is the setting up of a personally identifiable information inventory (PII inventory).

Handing of personal data across the entire life-cycle of a data element

• Data collection
• Data storage
• Data access or view
• Data processing which involves active use of data for agreed, declared and specific purposes
• Data transfer including cross-border
• Data deletion, archival, de-identification

Retention strategy for personal data

• How long to retain the data for active use? The duration of retention should be in consonance with both the purpose for which that data was collected and the fact that minimum necessary data should only get collected.
• What to do at the end of retention period? This includes clarity whether data would need to be deleted or whether data would be de-identified or masked and kept for a longer duration.
• How to ensure data is not stored in any media beyond the specified retention period? Clarity with respect to where all a certain personal data would get stored in the PII inventory would greatly facilitate this.

Determination and declaration of basis of processing data that makes it lawful

• The best thing is to obtain data subject consent or have a contract that would govern the processing of personal data.
• If not, legitimate interest analysis needs to be performed. This is a risky option to choose and needs to be well supported by a strong and logically formulated business rationale.
• For any business organization, typically the public interest and vital interest would not be a valid basis in most situations.

Risk assessment around data privacy

• The first step here is to do screening
• And as as needed perform detailed data privacy impact analysis (DPIA) and identify risks and mitigating controls and actions that would be required.

Personal Data Privacy Regulations - Some Interesting Corollaries

Since May 2018 when EU GDPR came into force, privacy and protection of personal data and information has become a critical compliance requirement for organizations.

It is important to note here that privacy laws are applicable to all organizations, whether private, public or government and whether business or others.

Any organization that handles personal data needs to ensure their data privacy practices are in consonance with and in full compliance to the data privacy regulations.

The above statement leads to some direct and interesting corollaries.

Corollary 1 - Data privacy must be a matter of grave concern for every living person in the world.

• Data privacy laws consider natural living persons as data subjects.
• Speaking differently, you are a data subject and so is every one else.
• You are a data subject much before you are the owner or employee of an organization and in that capacity expected to protect the organization's interest..
• Violation of data privacy laws by organizations impinge directly upon your civil rights as a data subject.
• You are the rightful owner of your personal data and should have complete say on anything related to it except for matters pertaining to national security, public safety and law enforcement.
• The "Digital Parasites" in the digital economy like Facebook, et al if not tethered would continue to devour your personal data to mint money.
• The digital economy will continue to grow and become bigger with newer "Digital Parasites" coming into existence as time unfolds.
• Hence data privacy must be a matter of grave concern for every living person in the world.

Corollary 2 - Data privacy regulations are applicable to each and every organization.

• Any organization will have employees at the very least.
• By definition, every employee is a data subject (in GDPR) or a data principal (in the proposed Indian Data Protection Act). 
• Hence data privacy regulations are applicable to each and every organization.

Corollary 3 - Every employee must ensure individual-level compliance with data privacy regulations.

• Any employee will come across personal information of some of the other employees or other persons outside that organization in some or the other manner in the course of fulfilling work responsibilities.
• By definition, when an employee is handling personal information as part of work responsibilities, the organization, effectively speaking, acts either in the capacity of a data controller (or data fiduciary) or a data processor.
• Hence every employee must ensure individual-level compliance with data privacy regulations.

Corollary 4 - Even one bit of personal data must be viewed as one too many. 

• Every bit of personal data that is handled by an organization needs to adhere to the data privacy principles:

• Lawfulness, Fairness and Transparency
• Purpose Limitation
• Data Minimization
• Storage Limitation
• Accuracy
• Confidentiality and Integrity
• The above data privacy principles have to be individually and independently applied to each and every bit of personal data handled by an organization.
• Hence even one bit of personal data must be viewed as one too many.

Corollary 5 - Every organization must appoint a DPO (data protection officer) with direct reporting into the Board of Directors to drive enterprise-level compliance.

• Since even one bit of personal data is one too many, every organization must ensure enterprise-level compliance.
• Any organization that wants to live to see tomorrow must secure and protect every bit of personal data it comes across.
• Violations by an organization can lead to abrupt cessation of its operations or even a quick end to it's very existence like what happened in the Cambridge Analytica case.
• For ensuring business continuity on data privacy front and  to avoid going the Cambridge Analytica way, organizations must appoint an executive-level officer to drive enterprise-level compliance and advise the Board of Directors on data privacy matters.
• The executive-level officer can report into the Chairman/CEO also but should certainly have direct reporting into the Board of Directors too.
• Hence every organization must appoint a DPO (data protection officer) with direct reporting into the Board of Directors to drive enterprise-level compliance.

In the end, and just to summarize, organizations must carefully watch out for the following business-critical aspects:

• Given that data privacy is a given now, organizations must take care of the above corollaries that provide the broad guiding principles to appreciate the usefulness of data privacy regulations as well as key enablers to ensure compliance.
• The executive-level management must be genuinely committed to ensuring the  privacy and protection of personal data and information handled by the organization.
• The tendency to find short-cuts in implementing data privacy practices in the name of cost to compliance should be strictly avoided.
• Comprehensive records of PII (personally identifiable information) processing activities must be maintained diligently to avoid any possibility of litigation risks to the organization.

If only someone had advised on the above business-critical aspects to the Board of Directors and Chairman/CEO of Cambridge Analytica in good time!

How Organization Structure Impacts Process Culture?

The primary manner in which organization structure impacts process culture is that it makes it harder for efforts around compliance and improvement in the organization to translate into real gains for the organization's benefit.

When the Business Excellence Head in a company reports into a incompetent operations/delivery guy from it (small IT) then what you would expect is an example of how not to structure an organization.

There are funny situations related to organization structure in some of the small companies managed by hare-brained management where the top man has those under him under his direct obligation.

In above type of organizations the so called management team under the top dog has only option - go with the boss or the sir.

In such companies, some of the delivery is owned by someone outside the delivery group.

Funny groups are set-up without any thought towards why those groups were set-up in the first place.

You have a center champion role headed by a man who goes to the center very very rarely and that too not very willingly.

The man who is the center head at one of the centers is lesser in heft as compared to another center head.

Then you have new group carved where the guy who is made in-charge has a special arrangement to bail him out from certain tasks that continue to be handled by those earlier at the helm.

In such companies designation is a chimera.

Someone may be a VP in this kind of a company but is no better than the program manager in a good company.

The coterie of the top dog and his puppies keep on getting promoted and in turn keep promoting each other.

However, what they do at this point is exactly the same thing they were doing 15-20 years back.

Its a company which has a sick mutual admiration club kind of system in place.

In such companies the Business Excellence Head looks after everything on compliance and improvement but is deliberately kept on the structure at a lower position than the incompetent operations/delivery guy from delivery group.

Given the non-sense that keeps on happening, it is not hard to imagine what will happen in such companies.

The little delivery (small Delivery) guy with big title would violate processes and ignore compliance requirements right, left and center.

The little delivery (small Delivery), it (small IT), hr (small HR) and finance (small Finance) guys with big titles in such companies are the real reason for such companies not to grow in the real sense.

The big folks with small titles don't matter in such companies.

Also those who do what matters do not matter in such companies.

If one were to look at the genesis of why such things happen in such companies one ought not to look very far and beyond.

The reason is the toxicity created by the top man and his coterie of the little guys with big titles.

When a Company is Few Projects, or Worst One Project, Away from Disaster

Some companies have limited number of projects. And even in those projects there are several challenges as explained below.

A certain group of projects are from the parent which are there because of family relations between the management of the company and the parent. This situation carries following risks:

• What happens when someone in the family on either side either dies or is shunted out?
• What happens when there is a takeover of the parent?
• What happens when the parent starts going down the drain?

The biggest project is the only one of its type with the largest team size with people whose skills cannot be utilized outside this project. This situation carries following risks:

• What happens when the customer of this project terminates the contract suddenly?
• What happens when there is massive attrition in this project?
• What happens when there is high level of disengagement in that project due to repetitive but high pressure nature of work?

The projects are mostly small in size and short in duration and their ratio in the overall project portfolio is extremely high. This situation carries following risks:

• What happens to the core skill-set of the company since work comes based on whatever is the flavor of the season?
• What happens to people who are brought with specific skill-sets for executing a project and have no real work after the project gets over?

There are too many internal projects with no clear defined deliverable as well as no real estimate of their return on investment. This situation carries following risks:

• What happens when these projects are staffed with heavy weights (not heavy in terms of competency but in terms of compensation)
• What happens when these projects stay in R&D mode forever with no real, concrete outcome getting generated.

There are many reasons for this to happen the primary being lack of professionalism and real leadership in such companies.

Decisions in such companies are taken in meetings where the funny four musketeers meet their master.

The master is like the ring master in the circus and the funny four are like donkeys without any brains or ethics.

Such companies are run on the whims and fancies of the master.

The master also has his master controlling him remotely from a far away site.

The company is more of a circus then a company.

And such companies are just a few projects, or worst one project, away from disaster.

Risk-Based Thinking

Risk-based thinking is a management approach that relies upon anticipating the future and adjusting the plans accordingly so as to be better prepared for things to come.

The whole idea behind calling a future anticipated event or happening as a risk is based upon following criteria:

Likelihood

• The occurrence of that event has an associated likelihood. 
• The likelihood could be at different levels such as low, medium, high. 
• So something with high likelihood means that it is very likely to happen.

Impact

• The impact should that event happen has an associated severity. 
• The severity of impact could be at different levels such as low, medium, high. 
• So something with high severity means that it will lead to major consequences.

Risk-based thinking has been made a key and essential element of ISO standards such as 9001:2015 and 27001:2013.

So in the above ISO standards, the purpose of the management system revolves around ensuring risks to the organization's objective are identified and managed.