Core Incompetency

Core competencies have been a corporate buzzword ever since Hamel and Prahalad popularised it in "Competing for the Future".  The idea was for organisations to understand themselves, know their strengths, their core competencies, so they can leverage it to advantage (or 'Stick to the knitting' as Peters and Waterman wrote in 'In Search of Excellence')

Perhaps companies can also benefit from understanding their core incompetencies.  Where do they compare badly to their peers?  

The Problem and the Non-Solution

What’s wrong with presentations like the table below?  You’ll find tables like that in many enterprise communications.

Problem	Solution
Customers moving to a competitor’s product.	Increase product information campaign to let customers know the benefits of our product
Employees unhappy about the new salary arrangements.	Provide a channel for employees to voice their concerns.

Let’s ignore the actual problems and solutions as shown – they are just vehicles for this discussion.  The problem with solutions like this is that there is no description of the desired effect that will dissolve (or reduce) the problem.  For problem number 1, what is the intended effect of the solution? Is it to stop the customers from moving to the competitor?

Before a solution to a problem is proposed, we need to first identity the effect we want.  What will the world be like once the (still unknown) solution has been put into effect? For the first problem, perhaps what we want to achieve is a stanching of the flow of customers to the other side.  Next, we ask what is the measure?  How do we measure the effect?  One measure might be the number of customers per month moving to the competitor.  The higher the better. 

By this method, we make it clearer what we want the solution to do.  We make it clear what the mission of the solution is: to stanch the flow of customers to the competitor. 

We can come up with several solutions to this.  For example, we might decide we want to offer additional perks to our products.  Or we might decide to lower our prices.  The next question is: which of these solutions might be the most effective?  That is, which one will more considerably deliver the effect we want?  We can measure solutions by several attributes.  These would include the number of losses it stops, the cost to implement the solution, the length of time required for the solution to be implemented, and so forth.  We decide which solution offers the best bang for buck based on these attributes (using systems analysis).

Only in this way can we show the solid relationship between the problem, the effect desired that dissolves the problem, and the solution that will bring the intended effect.

First Level Requirements

We devise systems to bring about a new, better situation, a better tomorrow. This better tomorrow can be an alleviated problem, a realised vision, or a captured opportunity.

Unfortunately, many systems are built with only a passing familiarity with what the mission is.  Without a rigorous understanding and clarity of what is being sought, the result will be unsatisfactory.  Systems are expensive to build.  They cost money, use up time, extract effort.  We can do things more effectively. How?

First, one must have a clear understanding of the current situation.  What is it that’s causing pain, causing dissatisfaction?  The examples are myriad: foreign aircraft are able to cross our boundaries at will; our payroll system is too slow and making the staff spend too much time using it; our operating costs are too expensive compared to the industry for the same services, and so on.

Then we analyse the situation, and identify what changes need to occur in the problem domain for the problem to be alleviated.  For example, a change might be to have the ability to detect, intercept, and if necessary shoot down unwelcome aircraft; vastly reduced payroll processing time; reduced operating costs by at least 15%.

These changes are what the solution systems needs to ‘effect.’  A solution system that provides the ability to sink ships; run a payroll program on Unix; improve morale do not address the changes required.  They would not exhibit the necessary effects on the problem domain.

Some solutions will be more effective than others. A solution may be able to track 10 planes at a time while another can track 100;  A solution may reduce payroll processing time by 5 hours while another by 1 hour.  A solution may reduce operating costs by 20% and another by 25%.

The difference in their level of effect is the measure of effectiveness. All things equal, we want more effective solutions than less effective solutions.

The changes required on the problem domain map to the effects required from the solution system.