BUSINESS PROCESS AND IMPROVEMENT

Why Compliance to Laid Down Processes is So Very Important?

The ISO standards are supposedly famous for the following quote:

"Say/write precisely what you will do and do exactly as what you said/wrote you will"

Two words from the above are worth looking into at a more granular level.

Precise and Exact.

So what do they mean?

Precise (Reference: http://www.dictionary.com/browse/precise)

adjective
1. definitely or strictly stated, defined, or fixed: precise directions.
2. being exactly that and neither more nor less: a precise temperature; a precise amount.

3. being just that and no other: the precise dress she had wanted.
4. definite or exact in statement, as a person.
5. carefully distinct: precise articulation.
6. exact in measuring, recording, etc.: a precise instrument.
7. excessively or rigidly particular: precise observance of regulations; precise grooming.

Exact (Reference: http://www.dictionary.com/browse/exact)

adjective
1. strictly accurate or correct: an exact likeness; an exact description.
2. precise, as opposed to approximate: the exact sum; the exact date.
3. admitting of no deviation, as laws or discipline; strict or rigorous.
4. capable of the greatest precision: exact instruments.
5. characterized by or using strict accuracy: an exact thinker.

Going through the details of the dictionary meanings of the two key words makes it amply clear as to why the statement "Say/write precisely what you will do and do exactly as what you said/wrote you will" is so very logical and so very sensible.

Think about it this way.

If you want things to happen in a certain way, every time it is done, what is the best way to ensure it happens with the same consistency.

The best bet is - define precisely how things have to happen and ask for things to be done exactly as it has been defined.

That will certainly ensure the certainty of the outcome, come what may.

Remember the following quote:

"Insanity is doing the same thing over and over again, but expecting different results."

It can very well be rephrased as:

"It is perfectly sane and sensible to do the same thing over and over again, and not only expect but indeed obtain results that are no different"

The above also reflects the power of using a systems-driven and process-oriented approach.

At this point, based on the above, it should be obviously clear why compliance to laid down processes is so very important.

That would ensure the following:

There is certainty of outcome at the end of the whole thing.

Not only that, it is also clear as to what should come out at each intermediate step.
This will result in consistency and certainly of deliverable(s) produced by the process.

The steps including their sequence that needs to be followed while performing an activity are precisely known.

Not only that, they can be easily traced back to the defined process.
This will ensure high level of process compliance.

It is clear as to what steps should have been taken and what were, so the gaps, if any, that need to be taken care of, are obvious.

This will facilitate quick and objective process assessments or audits.

For the discussion so far in this post, it is assumed that there is no challenge in respect of the correctness/accuracy of the defined process.

That is really not true and will be dwelt upon in detail in another post.

At this point, however, it is not hard to see that as the process is precisely laid down and exactly adhered to, changes/improvements that need to happen to the process will be obviously easy to determine.

That will eventually aid in continual improvement to the process.

Note:

The quote "Insanity is doing the same thing over and over again, but expecting different results." is generally attributed to Albert Einstein but apparently he said none of it.

Rita Mae Brown, the mystery novelist in her 1983 book "Sudden Death", attributes the above quote to a fictional "Jane Fulton," writing, "Unfortunately, Susan didn't remember what Jane Fulton once said. 'Insanity is doing the same thing over and over again, but expecting different results.'"

(Reference: https://www.businessinsider.in/12-Famous-Quotes-That-Always-Get-Misattributed/articleshow/23671857.cms)

Selecting Internal Auditors for Internal Audits

Selecting internal auditors for performing internal audits needs to be done with a lot of due diligence and a lot of care.

It is a fact that many a times you have to make someone an internal auditor for reasons that have nothing to do with the person's competency.

When someone incompetent is imposed on a department from above because he is a pet stooge of the top dog, he or she needs to be made an internal auditor.

The stooge being a part of the auditors pool will ensure the top dog doesn't get the chance to say that "we don't have good auditors".

After all his pet stooge is a part of the auditors pool.

What kind of people should not be made auditors?

The above is a good question so that the "bad particles" are filtered out.

This filtering doesn't apply to the stooges though.

Avoiding following types of people when selecting internal auditors will go a long way in making the audit process professional and objective:

Avoid people who don't come on time but expect others to be there when they come in
Avoid people who create nuisance before and after the audit
Avoid people who come with preconceived biases
Avoid people who carry a condescending attitude towards other auditors and auditees
Avoid people who don't prepare and share auditor notes promptly
Avoid people who have serious behavioural issues
Avoid people who lack motivation and energy to act as auditors

In addition to that, it is a good idea to know which auditors should be allocated for auditing which areas and which not.

Like the pet stooges are unfit to be selected as an auditor for several areas.

It is better to assign them to audit areas that are manned by other pet stooges.

The audits done by the pet stooges will not be effective as the stooges are the insiders and will not want to bring up anything that the peer stooge doesn't want to be highlighted.

Internal audits can go a long way in helping a professional organization introspect and improve on its internal processes and practices.

In case an organization has too many people who are not fit to be auditors, especially at senior levels when they are expected to be mature and sound, it is clear warning sign.

There are undoubtedly deep-rooted cultural issues in such companies.

They are everything but professional.

They are actually "Lala" set-ups!

If the top man in such organization is not aware of this then he is totally incompetent and if he knows but doesn't care he is a partner in crime.

He is perhaps the biggest Lala of all. The king of Lalas.

His pet stooges being the other Lalas.

In fact, he would the prime suspect for things to have reached such a state.

After all, everything that has happened or is happening is under this man's watch.

If that be so, doing internal audits and findings internal auditors will remain a vexing challenge in such organizations.

In case you happen to be the unfortunate one who is supposed to take care of internal audits in such an organization be prepared to handle shit.

Get ready for a ride in the hell!

And yes, tighten your seat belt.

CMMI V2.0 - Some Major Changes and Improvements Over CMMI V1.3 - Part 2

An earlier post titled "CMMI V2.0 - Some Major Changes and Improvements Over CMMI V1.3" touched upon some of the major changes in CMMI V2.0.

Here are some more major changes that will come about in CMMI V2.0:

The focus in CMMI V2.0 will be on performance beyond compliance. What that means is that both aspects of an organization's performance are critically managed - whether goals are met or not and also how they are met.
The flow of performance management will include steps sequenced in a logical manner - set business objectives, understand performance needs, establish performance goals, measure & track performance and finally ensure that efforts are made to achieve those goals.
Appraisal method will be revised to enhance confidence on the appraisal outcome as well as reduce the cost of appraisal.
Threads related to safety and security will be added as optional practice areas.
The architecture of the model will be such that it can scale up to address newer threads as well as easily incorporate additional built-in guidance for specific methods such as agile/scrum

CMMI V2.0 - Some Major Changes and Improvements Over CMMI V1.3

The next version of CMMI will be CMMI V2.0 and it will replace the existing version, CMMI V1.3, that was released in the year 2010.

An earlier post titled CMMI Next Gen (https://business-process-improvement-blog.blogspot.in/2015/09/cmmi-next-gen.html) on CMMI V2.0, dwelt upon some thoughts on changes and improvements that should be brought into CMMI V2.0 as compared to CMMI V1.3.

Another post titled Next Generation of CMMI Version 1.3 - Will it be Version 2.0? Or Version 1.4? Or Simply CMMI Next Gen v1.0? (https://business-process-improvement-blog.blogspot.in/2017/08/next-generation-of-cmmi-version-13-will.html) dwelt upon some thoughts on the ecosystem around CMMI model and appraisal methodology that leads to certain challenges in deriving the true value from a wonderful model that CMMI is.

Following are some of the major changes and improvements in CMMI V2.0 over CMMI v1.3:

The term practice area will be used in place of process area.

The idea probably is that CMMI is a collection of practices and not processes.

Estimation will be added as an exclusive and separate practice area.

The idea probably is that estimation is the bedrock of successful project management and execution.

Generic goals and generic practices that are key to institutionalization will no longer be there in the current form and will get replaced by some new practice areas.

The idea probably is that it is better to drive institutionalization through a dedicated set of practices that are logically consolidated under few practice areas.

The three constellations of CMMI - Development (DEV), Services (SVC) and Acquisition (ACQ) will be integrated into a single model.

There will be a set of core practice areas and special/specific practice areas for the three threads.
The idea probably is not only to make CMMI adoption modular but also give a new leash of life to SVC (which is currently being used in a very less number of cases) and ACQ (which is currently being used in an even lesser number of cases),

PCMM, that poor cousin of CMMI, will get a new leash of life since it will also be integrated into CMMI V2.0 as part of workforce/people practices thread.

The idea probably is to create some market for PCMM. The current usage of PCMM is abysmally low.
Of course, there are reasons beyond the model itself.

The figure below provides a very quick and a very high-level summary of the key features of CMMI version 2.0.

Next Generation of CMMI Version 1.3 - Will it be Version 2.0? Or Version 1.4? Or Simply CMMI Next Gen v1.0?

An earlier post on CMMI Next Gen discussed about certain proposed improvements that will make the CMMI model richer and more attuned with the realities on-the-ground.

It is crucial to take care of the challenges that organizations continue to face in leveraging the CMMI model for higher business impact.

The CMMI model is as good as any model can possibly be. The foundations underlying it are based on rock-solid fundamental principles.

Working diligently on the opportunities for improvements to enable the CMMI model to better align with business needs and, more importantly, business realities is the right way to go as far as evolution of the next generation of CMMI version 1.3 is concerned.

Will the next generation be version 2.0? Or version 1.4? Or simply CMMI next gen version 1.0?

The fact is, whether it is called CMMI version 2.0 or anything else, that won't really matter.

Even what goes into the model structure, practises and their description won't really matter.

What would matter is, what actually goes into the working of the ecosystem around the next version.

If one looks at the CMMI for development, version 1.3 and using it tries to understand the fundamental concepts that can help a business run efficiently and keep on getting better, there seems to be no disconnect there.

Let us analyze this further. Let us see what are the key elements that are required to run a business organization.

Here is the list of some such key elements:

Define organization's vision, mission, goals and the strategy to attain them and track the strategy's progress regularly and rigorously (OPP)
Inject the above into the plan that guides the day-to-day functioning of the core operations, the supporting functions like facilities, HR, etc. and the business excellence function and keep the plan updated, track the progress against the plan and the risks that could lead to derailment from the planned path (PP, PMC, RSKM)
Ensure standardized practises are constantly scrutinized and improved/evolved (OPD, OPF, CAR)
Use data for analyzing how activities are performed and see what improvements/changes can make them better (MA, QPM, OPM)
Ensure work-items, documents and other parts are managed and maintained in a secure, systematic and structured manner (CM)
Ensure standard practises are used while allowing for flexibility in customizing them within certain defined boundaries and ensure deviations are controlled (PPQA, IPM)
Build competencies in people for performing the activities assigned to them (OT)
Ensure work-items, documents and other parts received from suppliers are managed and integrated in a well-defined and proper manner (SAM)
Understand what the customer wants and manage changes in customer requirements and expectations in a systematic manner (RD, REQM)
Determine the optimal solution for addressing the customer requirements and build, validate and deliver the solution to the customer (TS, DAR, PI, VER, VAL)

Just look at the process areas of CMMI version 1.3 referred to above. If you count them, you will get 22.

That's exactly equal to the number of process areas in CMMI version 1.3!

If all the process areas are relevant for any business organization, what is really going on?

Why do certain organizations tend to carry this impression that they have to do something extra for CMMI which is not needed for business.

It is obvious that is just not true!

Instead of an organization doing business and doing CMMI as two separate threads, it will be a much better situation for it to do business using CMMI.

Or for that matter any other excellence framework like NBQA, EFQM, ISO, etc.

So any excellence model or framework is not really the culprit. If that be so, who is to be blamed?

Now let us look at the ecosystem. Or better, let us look more closely at the actors in the ecosystem. The answer lies therein.

For the CEOs and the business heads, a certificate on the wall is something that they know the business needs as is its usefulness in pumping up their already-very-big egos! For such folks, the model behind the certification may also be important to get a sense of confidence in the business operations since there is a sort of benchmarking that happens when you adopt an excellence framework.
For the sales people who are really smart-asses, certificate is a reality as they may not be allowed to enter a customer's premises if their company is not certified! For such folks, the certification means nothing beyond their current quarter sales quotas and sales targets.
For those who create the models and frameworks, the model is like a family bread-winner and they got to sell it far and wide using any and every method in the book and even outside it! For such folks, the model should sell and become popular and doesn't mean much beyond that.
For those who act as consultants and auditors for the model, they need to pay royalties to model creators and are smart enough to know the compulsions of the CEOs and the business heads as well as the fact that their careers depend on the bloody model! For such folks, the model is simply a means to make money.
For those who act as implementers of the model, the situation is the most funny of all since they are caught in between the needs of the business, needs of the CEOs and the business heads and needs of the consultants and auditors! For such folks, the model is a reality that they did not choose (CEOs and the business heads get to choose) and have limited control over its implementation (consultants and auditors get to decide the model expectations) while they watch the mute model creator, stand far away.
For those who act as practitioners, the effect of a model is as varying as the kind of people on this planet since those who truly want to get value get that but those who just want to fool the implementers and auditors manage to do that (the only difference being, they actually fool themselves)! For such folks, using the model becomes kind of a necessary evil which is imposed on them from the top.

As was explained earlier whether the next generation of CMMI is called CMMI version 2.0 or anything else, that won't really matter.

Even what goes into the model structure, practises and their description won't really matter.

What would matter is, what actually goes into the working of the ecosystem around the next version.

Or to be more precise, what the actors in the ecosystem eventually do will only matter.

The big question that arises is this - is improvement in CMMI or any model good enough? Will that do the trick without the actors changing the way they act?

The answer to the above big question will mean what happens going ahead.

In conclusion, it is evident what would really matter.

One thing is certain though - whether the next generation of CMMI is called CMMI version 2.0 or anything else, that won't really matter!

Why Focus is So Crucial for Any Business Organization?

Focus means spending one's energy in a well-thought out manner.

If there is a lack of focus, one would fritter away one's energy in several pursuits, many irrelevant, without realising what one wants to achieve.

Focus is crucial for any business organization to do well.

Why is that so?

Here are some thoughts to consider:

Every organization has limited amount of energy and effort in terms of money it can spend, employees that work for it and the infrastructure it owns
No organization can work upon every idea that comes its way even if all of them are brilliant ideas (due to the constraint imposed by the above point)
If an organization tries to do several things beyond the amount of energy and effort it has at its disposal it will either fail to follow many of them through till the very end or do all of them but with effectiveness that will be much lesser than what would be the desired level

Given the above, it is not hard to conclude that a business organization has to be choosy and decide to do only certain things, maybe just a very few, but do them really very very well.

So well that the business organization creates a hard-to-beat competitive egde over its competition, both near and far.

Some organizations, especially those that are run by a pack of "yes sir", loyal-to-the-core clowns reporting into the top dog, turn themselves into a big mess due to lack of focus.

When the top dog says something, the clowns would always say - "yes sir".

Since no one has the courage to say "no", every idea is taken up.

In such organizations usually no discussion takes place on the amount of energy and effort available, other ideas that are work-in-progress, the relative importance of the ideas put up for consideration.

Chaos ensues in such organizations.

People are abruptly pulled from one area and put into another.

The clowns, who are absolutely unprofessional and unethcal to the core do all kinds of nonsense.

They pull a person out from a team without even informing the department head.

As the clown is a loyalist of the top dog, they together decide and do what they wish to.

And the department head is only informed about this when he meets the clown in a meeting that the department head himself had set-up.

A very painful question - would the clown inform the concerned department head otherwise?

The answer is obviously no. Loyal clowns own no one any explanation!

Professionalism and ethics can go to hell!

As an aside, this also means the organization is no more than a lala company!

Such an organization will do anything.

It will take up any project that comes its way.

It will indulge in and organize all kinds of events and meetings and initiatives.

Even when many of the events and meetings and initiatives are a sheer wastage of precious energy and effort.

Lack of focus in such organizations is a direct result of lack of leadership skills in the top dog and the clowns (otherwise, respectfully referred to as top management).

The lack of focus percolates down below to all levels of the organization.

The organization as a whole looks like lost in the woods. Trying this and then trying something else and then something else.

There is no strategy, no game plan.

There is no focus. And that could be very very dangerous!

Adding a New Office/Location to Your Scope of Certification - Important Things to Do to Get Started

For any organization, business growth may mean opening up of new offices at new locations.

Adding a new office/location presents its own unique set of logistics and people challenges.

Beyond that and generally very soon the organization will reach a situation where it will have to add the new office/location to its scope of certification - ISO, CMMI, et al.

So what are the important things to do to get started for an organization that wants to add a new office/location to its current scope of certification?

Here are some important things to do to get started:

Share the communication related to this with concerned stakeholders both at the corporate office as well as the new office/location
Discuss with the auditing partners and understand their expectations for successful audit at the new office/location
Assign someone as the overall SPOC for this initiative. The SPOC should have good knowledge of the certification standards and models and past experience with site coordination in external audits
Perform quick gap analysis to understand the major gaps and the key pre-requisites and pre-conditions for successful audit
Prepare a detailed road-map (who will do what by when) and share with the concerned stakeholders both at the corporate office as well as the new office/location
Perform detailed gap analysis and prepare a list of checkpoints that need to be taken care of. This should be done by the SPOC
Plan for pre-audit by external auditors at the new office/location before the final audit. It is an effective way to avoid any surprises cropping up in the final audit
Identify and communicate the risks and challenges to the concerned to ensure that the entire journey is smooth and happens as per the road-map
Adjust and modify the road-map to address issues and challenges that come up during the entire journey
Stick to the road-map but be flexible to change the course if the situation demands so. But never forget the milestones in the journey that have hard dates!

Why Are CMMI High Maturity Practices So Very Much Neglected Despite Being So Very Powerful?

Are CMMI high maturity practices easy to use? Or are they tough to use?

The answer surprisingly is, both!

Easy, if you are largely interested in getting through an external appraisal.

Tough, however, if you try to leverage them for management and improvement in the real sense.

Most of the appraisers have a procedural approach to the implementation of high maturity practices.

The focus is primarily on the steps to be followed. Do this, do that and then do that.

Nothing is really wrong with that approach. After all appraisers are supposed to be doing appraisal against a set of expectations.

And what better than converting the expectations into a sequence of clearly laid down steps.

Easy to follow for the organization and easy for the appraiser to do his job!

The underlying concepts behind high maturity practices are, truly speaking, as real and as powerful as any scientific process or phenomenon is.

If you a throw a ball in the air, it will fall down.

Similarly, if you want to succeed in doing a project, you have to define the objectives, put a plan in place, track it meticulously and take necessary actions on the way to ensure the objectives are met.

Implementers of high maturity practices know that very well but choose to toe the line of the appraiser.

After all they know very well that they do not have the final say in the matter!

And they are also supposed to see the organization successfully through the appraisal.

So where does the problem lie?

Why are CMMI high maturity practices so very much neglected despite being so very powerful?

Among various reasons, one quite clearly stands out.

It is the answer to a pretty simple question - who stands to benefit the most from the implementation of high maturity practices if done the right way?

It is undoubtedly the head of operations/delivery.

This gentlemen will be able to exercise superior degree of control on the predictability of project execution using high maturity practices.

So why does the head of operations/delivery fail to do justice to his role by neglecting something as powerful as high maturity practices?

Two of the key reasons for above are - lack of competency and lack of ownership. It is no coincidence that competency and ownership are closely intertwined.

The basic ingredient for a good implementation of high maturity practices is sincerity and ownership of practitioners in collecting and reporting accurate data.

GIGO is a well know principle, if projects report garbage-like data for high maturity analysis, they will get gabage in return.

The failure of head of operations/delivery in owning quality of data being reported is the main reason garbage gets collected, reported and analyzed.

CMMI high maturity practices are very powerful but get neglected because the head of operations/delivery doesn't want to or can't see the long term picture.

If an organization genuinely wants to derive the benefit from the power of high maturity practices then it is tough.

Neglecting high maturity practices is indeed an option available for any organization to follow but doing that means the benefits are foregone.

And if the core issues are not addressed especially those connected to lack of ownership at the end of the head of operations/delivery, the way it is going on now will go on and on.

Head of operations/delivery will be happy because he chose the easy path.

Appraiser will have no reason not to be happy and more so since the organization sticking to his formula makes his job easy.

Implementers will not be happy but have no choice.

They might still carry a happy smug on their face since those who are supposed to leverage the power of high maturity practices neglect it (the practitioners and head of operations/delivery).

And those who are supposed to appraise (the auditors and appraisers), are fine with the organization following what they have told them to.

Implementers are fine too with the above arrangement as in the end they are just facilitators!

For them, being able to see the organization successfully through the appraisal is a consolation enough not to get disheartened.

After all, getting through an external appraisal though simple is still not a small feat.

The effort required by the organization to implement high maturity practices is no different in either case - getting through an external appraisal or leveraging these practices for management and improvement in the real sense.

So what breaks? That's a question worth asking.

And if you are seriously looking for the answer to the above question, look no further than the cabin where the head of operations/delivery sits.

You will find the answer there. Or maybe not!

What has Happenled to the Good, Old Agile? Is it Dead Now?

Agile was supposedly a very good approach and a highly promising one when it came in several years back.

And it appeared as if the software world had finally found the "silver bullet".

But that was not to be.

What has happened to the good, old agile? Is it dead now?

The die-hard agile enthusiasts always used to write it as Agile (with capital A) but now they don't mind using agile (with small a).

This is a seemingly simple yet a very powerful change.

Agile originated with its own peculiar contradictions.

This is clearly reflected in agile manifesto which has undoubtedly been crafted very beautifully but has an adversarial tone.

For example, saying "people over processes" has a fundamental flaw. Both are important and the right approach would be "people using processes".

It is important to always remember that "processes" are created by people and have no intelligence of their own other than what the people defining the process put into them!

So if there is any issue with the process, it should be fixed by the people who are supposed to use it and by those who are responsible for maintaining it.

Also lack of commitment to the process and the needed competency to follow the process should not become excuses for giving a bad name to the process.

Never forget - process by itself is completely dumb!

People, however, should not be dumb. By not following a process they act like one.

A process is simply a path you take to go from one state/place to another state/place.

The key success criteria as you travel on the path as captured in the process are related to certainty and consistency of the outcome.

In the software world the biggest challenge has always been this - most of the practitioners undermine the value of a systematic and structured approach to writing software.

Writing software is seen as a creative activity like painting or sculpture. That is not totally right. Writing software should be seen as an engineering activity like building a bridge.

The initial part of the software writing which has to do with software architecture does involve some creative thinking but this needs to be necessarily within the boundaries set by technical feasibility of the proposed solution and the business context where the software will eventually fit into.

More than a software development approach, agile became a symbol of anti-establishment and its premise was primarily to correct what was wrong with the traditional approaches.

There were many traditional approaches when agile came in, but waterfall symbolized this so called "evil" affecting the software world and became a favorite punching bag of the agile enthusiasts.

The other issue with agile has been too much focus on rituals. Statements like "if you are not doing daily scrum you are not doing scrum" cause more harm than benefit.

Blind insistence on following rituals and minimal or no willingness to accommodate appropriate tailoring in accordance with varying situations in each project can result in process rigidity.

At the same, allowing too much of flexibility under the garb of "being agile" can lead to lack of a basic operating structure and eventually chaos.

The best approach is to mandate a certain core structure and set of practices that give a solid foundation.

Examples would include the following - having a plan/WBS, insisting on weekly status reviews (details of the how can be left to the judgment of the project team).

The remaining processes and practices should be evolutionary and should be adopted to ensure the objectives of the project are met.

There also there should be extensive guidelines and operating procedures that can be leveraged by customizing them appropriately in line with the project-specific needs.

The good, old agile may be dead.

Or may be not.

Because even before agile came into being there where many approaches with a similar philosophical outlook like incremental, iterative, spiral, etc.

The term agile was surely new but the underlying principles were not.

Since agile was never born, it will never die as well!

The core objectives of any engineering endeavor (quality, scope, time and cost) as well as the fundamental principles and foundational elements of how to do good engineering including writing software has been there since centuries.

And they would not undergo any change. Why should the basics change?

Why the Job of an Auditor is a Difficult One?

Auditors work in a very, very difficult job.

If they are tough on the organization and "go by the letter" of the standard or model they are auditing against, no organization would ever get certified.

So they "go by the spirit" of the standard or model they are auditing against, and every organization that applies for it gets certified!

That's a very difficult task to perform.

An auditor has to be both tough and flexible at the same time.

Very hard to do in a normal situation, for anyone.

The other aspect to consider is that the organization applying for the certification is supposed to pay for the expense involved.

The expenses incurred in the certification process forms the revenue for the auditing organization and which organization in its right mind will even think of cutting the revenue stream?

So the auditing organizations usually have an unwritten rule for their auditors - act smart!

And the auditors indeed do so.

Auditors are trained to come across as hard-nosed and raise hell while they are auditing an organization but write a soft report at the end of it.

Things cannot be any other way.

Auditors need to make their intellectual presence felt while doing audits and most of them, invariably, are highly intelligent and smart individuals and can easily do so.

However, auditors are bound by business logic too.

They have to look other way while writing the formal audit report and most of them, invariably, are highly intelligent and smart individuals and can easily do that as well.

But one thing is sure. Auditors are smart folks.

Whatever they may do, they very well understand what's really going on in the organization they audit.

They may choose not to say certain things but that is not because they are incompetent but they choose not to say that.

Also, they may choose not to write certain things but that doesn't mean they can't.

Collecting Accurate Software Development Process Data

Question - how do you improve a process?

Answer - collect data and analyze the collected data!

Unfortunately, the real answer is not as simple as above.

The real answer is - collect accurate data, rest is pretty easy to figure out!

In fact, the answer is far too complex than even the above, especially when it comes to software development processes.

Tooling and automation, artifical intelligence, machine learning, cognitive science, etc. can supposedly turn software development into a machine-driven process.

However, the current reality is that software developement remains a highly human-driven process.

For human-driven processes, availability of highly skilled and highly motivated people is a sine-qua-non.

And that makes collecting accurate software development process data and using it to improve software development processes extremely challenging.

It is useful to collect the following data in a software project to manage it effectively and to improve the processes employed.

Size - how big is the project? how much work needs to be done?
Effort - how many man-days are needed to develop the software?
Schedule - how much calendar time will it take to ship the software?
Cost - how many dollars will it cost to build the software?
Defect - what is quality level of the software?

The foresmost observation anyone with a keen eye will make - all the above depend on subjective judjment of the person performing the related activities.

The above statement is a stark reminder of the challenging fact that collecting software development process data is extremely difficult.

It violates the necesary conditions to get accurate data.

Condition 1 - Method and instrument to measure should be such that it can be benchmarked against a standard method and instrument.

Temperature is measured in a consistent manner in terms of degrees centigrade using a thermometer.
Of course, need for calibration cannot be overstated in this context.
However, software process data like effort is measured in man-days which is very vague thing.
There is no standard benchmark for how many actual working hours constitute 1 man-day of effort.

Condition 2 - Entity measuring the selected parameter of a process should not be the one performing it

Entity for measuring can be the instrument or device used for measuring the selected parameter.
Temperature is measured using a thermometer. In an ideal scenario, the temperature gauge should operate without manual intervention.
However, software process data like effort for an activity is reported by the very person performing that activity.
The person performing the activity is also the entity measuring the selected parameter of the process.
This is quite strange and can never be expected to provide accurate data.
Why would a person not want to cautiously hide bad things and clamoursly highlight good things?

Despite the above challenges, there is a strong business imperative for measuring software development processes in a commecial context.

Software developement should not be seen as an engineering activity performed by the developer but as a business activity performed for the customer.

The above also implies that, software development processes need to viewed like any other business process.

So until ntil ways to address the above two conditions are not devised, collecting accurate software development process data will remain an elusive goal.

Its a Myth that Business Survival is First and Foremost and Business Excellence Comes Much Later

Small-sized organizations are of two types - first, those that have a good chance of becoming big one day and second, those that are trying to just sruvive and remain small and would eventually die one fine day.

The core idea behind business excellence is closely tied to what finally happens to a small-sized organization.

If the organization is able to get good logos and nurture and grow them into big ticket accounts, the company has a fair chance of succeeding at becoming bigger.

In fact, one may think, that business survival is first and foremost and business excellence would come much later. This is not really true.

The concepts of business excellence can be leveraged to not only survive but to grow as well and that too at a fast clip.

Some of the following business excellence concepts are especially useful for small-sized organizations:

Do right the first time and do better the next time
Customer satisfaction is not enough to survive and grow
Customer delight is the best weapon for survival and growth
Winning a customer is tough but retaining is far tougher
Constant learning and improvement is the only way to go

Having Good Processes and Following them is a Necessary but not a Sufficient Condition for an Organization to Succeed

The key concern of every organization is the same - achieve sustained success, not only this year, next year and in the decades to come but (if possible) forever.

Sustained success essentially depends on two levers - formulation of a sound and well-rounded strategy and its flawless execution.

The above two levers rest on the troika of people, processes and tools.

Organizations need all the three:

Trained, experienced and motivated people
Adequate, appropriate and adaptive processes
Reliable, easy to use and well-integrated tools

However, the perception that is commonly prevalent is that process is everything. It is generally thought that if an organization has great processes, it will be a great organization.

This is nothing but a myth and far removed from reality. It ignores the fundamental aspects related to processes - they are dumb on their own.

A process takes life when "people" make use of it. This gets amplified if this usage is through "tools".

Consider the following example to understand what the above means. This example is related to the process of billing the items a customer has purchased at a grocery mart.

For the grocery mart employee at the billing counter the process can be captured in following key steps:

Let a customer place the items on the billing counter
Pick the items one by one
Scan the items
Tell the amount to the customer
Collect payment
Generate invoice
Hand invoice to the customer
Let the customer gather the items and clear the billing counter
Move to the next customer

Very simple process indeed. And interestingly, this process would be almost same from one grocery mart to another to yet another.

The big question now - is having a standard process like the above enough to ensure billing process gets executed smoothly, every time.

The answer is certainly not a "Yes". Why?

The people and tools aspect cannot be ignored and at the same time cannot be thought to work perfectly every time. And when these aspects do not work as expected, the conclusion is that the billing process is not smooth.

The above conclusion is not fundamentally a sound one.

The grocery mart employee at the billing counter needs to be trained, experienced and motivated to ensure she sticks to the defined process, every time.

In addition, the tools used while following the process need to be reliable, easy to use and well-integrated so that the grocery mart employee at the billing counter is able to stick to the defined process, every time.

It is important here to note that any "defined process" is dumb. What ultimately matters is the actual "deployed process" as against the "defined process".

It is essential that "defined process" should be adequate, appropriate and adaptive. However, that is not the end of the story.

Undoubtedly, having great processes is a necessary condition. This though is not a sufficient condition.

First, and foremost, "deployed process" should be exactly in line with the "defined process". Second, and more importantly, "people" and "tools" have a direct bearing on the "deployed process".

It is obvious, therefore, that having good processes and following them is a necessary but not a sufficient condition for an organization to succeed.