FIND InnoNuggets

 

My Book on Strategic Decision Making

My Book on Strategic Decision Making
Applying the Analytic Hierarchy Process

Sunday, September 30, 2007

The Dying Business Model - MVNO is withering away

The MVNO business model is going downhill.

The Mobile Virtual Network Operator business model is going very deeply into gutter - it seems.

What is an MVNO?

I think the major reason for this goeing down is extreme complexity that emerges due to multiple dependencies on the partners - the MVNO on its own does not own the Network, the infrastructure, the spectrum etc. This is the GIX Bang world where Innovation is behind the Complexity. The pace of complexity is much faster than the pace of innovation - hence the model is dying. If there can be an increase in pace of Innovation - to leapfrog the complexity - or those MVNOs who are able to reach the simplicity on the other side of complexity faster will be making MVNO a successful model.

Outsourcing Patents

In 2002, I told my then employer, that it is a matter of time when Outsourcing patents will be started - obviously by the Big Boys of IT. That was considered - So what? We will not be impacted. This Patent thing is for product companies. The Sevices Industry doesnt have this threat and anyway we are growing 40% YoY.

Well here is the new battlefront started because of business method patents being allowed in US. Look at the following patent applications by IBM

1. Outsourcing of Services
Abstract (US Patent application: 20070162321)
A method for identifying human-resource work content to outsource offshore of an organization. The method is provided on a computer readable medium and includes the steps of identifying at least one task being performed by an organization; associating each identified task with a functional group within a plurality of functional groups related to the organization; determining information about individual human resources spent on each task; determining task information about human resources spent on the plurality of tasks, the task information based on the determined information about individual human resources spent on each task; using the determined task information to determine a value of each task; and outsourcing tasks having a value lower than a predefined limit to at least one of offshore and to a low cost supplier.

2. Electronic marketplace for identifying, assessing, reserving and engaging knowledge-workers for an assignment using trade-off analysis
Abstract (US patent application: 20070043603)
A method and system for matching a knowledge worker to a selecting entity's needs according to a system of codes corresponding to pre-defined rules of engagement. The rules of engagement include, but are not limited to, experience levels, salary, geographic location, job starting date and duration, and industry sector. If a search of knowledge workers fails to match an available worker with a job need of the selecting entity, the selecting entity posts a job posting on a website maintained by a third party administrator who maintains webpages that are accessible only to screened job applicants.

3. Efficient Frontier and Attainment Rate for Business Transformation Outsourcing
Abstract
A method and system for establishing an Efficient Frontier (EF) and Attainment Rate (AR) for Business Transformation Outsourcing (BTO) is presented. EF is the maximum service level achievable at a point in time for a specific business process or business process area. AR is the pace at which the EF can be reached from an initial value. Clients, outsourcers, and third-parties determine whether proposals are infeasible (above EF) or inefficient (below AR). Fact-based discussions of the merits and limitations of various implementation initiatives are supported. A determination is made as to whether there are any business segments to which different EF and AR apply. Any underlying factors for the EF and AR of each business segment are determined, and any change (rise or fall) of EF over time is predicted to maintain an optimally accurate EF and/or AR for each business segment.

Now Look at Microsoft

1. Outsourcing of instant messaging hosting services
Abstract (US patent Application: 20070067396)
A system, a method and computer-readable media for initiating the hosting of instant messaging services for an Internet domain name. A request is received from an entity requesting initiation of instant message hosting services for a domain name, and a secure communication channel is established with this entity. After verifying that the requesting entity is authorized to control the domain name, information describing user accounts having the domain name is received, and instant messaging services are provided for the user accounts.

2. Outsourcing of email hosting services
Abstract
A system, a method and computer-readable media for initiating the hosting of email for an Internet domain name. A secure communication channel is established with an entity requesting email hosting services. After verifying that the requesting entity is authorized to control the domain name, information describing email accounts with the domain name is received, and email services are provided for the email accounts.

Following is the search result links at USPTO with offshoring OR outsourcing in title. Hope this is a wake up call for companies in India and other geographies to understand and invest effort, money and thought in the Patent Game!! It is going to be a big one from this year onwards!!! Look at the increasing trend: 2001: 1 application; 2002: 2 applications; 2003: 6 applications; 2004: 7 applications; 2005: 9 applications; 2006: 12 applications; 2007: 4 applications so far.

20070162321 Outsourcing of services
20070067396 Outsourcing of instant messaging hosting services
20070067395 Outsourcing of email hosting services
20070038502 Efficient Frontier and Attainment Rate for Business Transformation Outsourcing
20060227810 Method, system and program product for outsourcing resources in a grid computing environment
20060200537 System and method for online human resource outsourcing and portal access
20060184412 Resource optimization system, method and computer program for business transformation outsourcing with reoptimization on demand
20060167706 Design for outsourcing contracts
20060161441 Application outsourcing
20060130065 Centralized identity management system and method for delegating resource management in a technology outsourcing environment
20060107070 Method and system for secure computational outsourcing and disguise
20060089943 Computer system and process for aiding in an outsourcing environment
20060080156 Outsourcing command center
20060080119 Method, system and program product for funding an outsourcing project
20060069607 Transformation of organizational structures and operations through outsourcing integration of mergers and acquisitions
20060064336 Method an system for facilitating electronic outsourcing value assessment
20060004596 Business process outsourcing
20050288984 Outsourcing simulation system and method
20050240916 SYSTEM AND METHOD FOR DISTRIBUTED PROJECT OUTSOURCING
20050159992 Process for identifying potential customers for business outsourcing
20050144895 Systems and methods for outsourcing service orders
20050144894 Concrete outsourcing methods
20050131754 System and method for estimating the feasibility of outsourcing information technology services
20050086120 Method of managing subcontracting for backend outsourcing business
20050065831 Simulation of business transformation outsourcing of sourcing, procurement and payables
20050060224 Simulation of business transformation outsourcing
20040220910 System and method of dynamic service composition for business process outsourcing
20040215496 Outsourcing method and system for sheet metal processing industry
20040181465 Method for on-line outsourcing of customized merchandise containing personalized logo
20040181444 SYSTEM AND METHOD FOR MANIPULATING MOTION PICTURE DATA USING LABOR OUTSOURCING
20040128303 Outsourcing management system and method
20040128209 Outsourcing management system and method
20040093298 Method for providing energy commodities trade outsourcing services within the energy markets
20030225638 Method for outsourcing accounting functions over the internet; using an integrated system between the bank account information and the accounting records
20030177039 Method of outsourcing IMRT services
20030177024 Outsourcing service apparatus concerning electronic drawing data
20030069777 Integrated system for providing remote outsourcing of services
20030046656 Information technology outsourcing hubs
20030018608 Method and system for secure computational outsourcing and disguise
20020049778 System and method of information outsourcing
20010051913 Method and system for outsourcing information technology projects and services





Keeping it Simple in GIX

How do you keep the things simple in the world of Globalizing Innovation Complexity (GIX) Bang (a 'la BigBang) World.

1. For starters make the business model straightforward.

What are you selling? To whom? For what specific needs? How you are selling? Also why you are selling?

2. Keep the communication Simple. How to keep the message complete, comprehensive and unambiguous? This is better said then done.

3. Keep the business processes simple. Just because you have a technology available to you, doesnt give you a license to incorporate it into your processes. Un-necessary process complexity is sure-shot recipe for failure.

4. Keep the business metrics simple and straight forward. Let us see an example. In software development organizations measure Schedule deviation and effort deviation and then they punish projects that are having the devitation. What is this deviation? The deviation is from the estimate given by initial project analysts. As we know, software development is not straightforward implementation or production of parts such as an industrial production. It is extremely difficult to have an estimate upfront in software development scenarios. When you measure deviations, you are not measuring the delivarables at all, you are measuring the efficacy of estimation, which anyway is a nebulous.

5. Above all keep the organization structure simple. This can be the root cause of all the issues and problems that your business may be facing. When I say simple, it means non-rigid, malleable organization structures. You need to balance the Service Level Agreement (SLA) driven rigidily and ad-hoc of free structure of a start-up, where everyone does everything. Or may be find out a completely new structure. However, organization design is the biggest challenge that top management has, unfortunately, they do not realize it.

Keeping it Simple is not Stupidity in the world of GIXBang world! May be that is the recipe for success when complexity threatens to destroy everything.

Tuesday, September 25, 2007

Learning from 20-20 Cricket

NOTE: For Those who do not know CRICKET Please read the post in Business standard.

India wins the 20-20 world cup, after winning the 60 overs one day world cup in 1983.

20-20 has very interesting observations - for the new world that demands new ways of doing things!

With the new format of 20-20 Cricket comes a very interesting observation on the tempo of the game. Over the years we have seen how one-day (60 overs) and later 50 overs cricket started as a more commercially viable option of speeding-up the 5 days test-match cricket.

With the new format and speed-up the tactics and strategies changed. The tempo of a cricket-match changed to much faster. The level of quick-thought needed, physical fitness needed and planning required in double-quick time increased manifold. This was a sea-change for purists who still said the ultimate test of skill, technique and temperament remains the Test match cricket.

Now comes the 20-20 format, where the exciting parts of the 50-50 game which are typically the slog-overs and may be the initial 15 overs have been carved out to make it the bang-bang cricket. Imran Khan, the legendary Pakistani all rounder made a comment saying that 20-20 is all about Talent. If you have talent you can do well in 20-20. The other two facets, as he mentioned, technique and temperament are sort of neglected or do not surface to the extent they are needed in test-match cricket. MS Dhoni, the Indian world cup winning captain, said the other day, that 20-20 is more physically taxing. Obviously when the tempo has increased so much that even a single over can change the whole match, it is the complete focus and intensity during the 40 overs that will succeed. And as Imran mentioned, the talent will win - Pakistan and India have much more natural talent than other teams, hence the results. Other teams strengths in technique and temperament do not play such a major role in 20-20, as per him.

Now, let us look at what is happening, the business world has been shaken by the Internet and mobile technologies in the last decade or so, ushering all of us into connected globalization. This is akin to the shift to a one day cricket match compared to the test-matches that the manufacturing world was so intent on playing - focusing on talent, technique and temperament. In the business test-matches of the old, one had multiple innings, strategies, and endurance needed to play out the game and succeed. The predictability that you will get two innings to play was enough to strategize and build capabilities in the organizations that can help you to learn from your mistakes. The Internet revolution created the One-day cricket where the time to strategize was less but variation of strategies and innovation needed to play was more. The team work needed to win a 50 overs contest is much more although the focus is only for a day. Secondly, one can not get a second chance. It is the innings that you play that matters. You can not have off-days. Aussies have perfected the consistency needed coupled with talent, technique and temperament as they won most of the cricket matches. Similar has been the successes of Cisco, Microsofts, Google and WalMart in the new game.

The business world from 2005-onwards demands continuous 20-20 games. The focus is on continuous talent in Innovation. The techniques and temperament that has won you the test matches of the last millennium need to be relooked for the new 20-20 Cricket matches that we all will be forced to play - now onwards. We will need either fresh, young, fearless, and innovative minds or reformat the minds that we have been carrying from the legacy of 50 overs or even test-match cricket.

The future is Innovation on your feet based on continuous re-creation of the ways in which we play. The rules will be new, and it is the people who define the new rules who will rule the game. In fact, more surprises you hurl more likely that you will win in the 20-20!

Are you ready to create a new surprise every day? - if yes - 20-20 world is calling you!

Friday, September 21, 2007

Letting Your Customers Innovate on You?

What is the next stage of co-creationization. If you let customers innovate on you, may be the customer satisfaction and delight will be extreme even if there are continuous, major failures.

How?

You provide your tools, products, minds and capabilities and say to customer to use these in the way that they want to fullfil any need that they have. Is it possible? Making it possible is the "Innovation". The co-creationization has to reach its pinnacle when your customers become the designers of your next product.

Is it too much to even comprehend? Search for customers who are partners in Innovation. How? By giving what you have to them to build, use and twist the way they want.

Business ByDesign - The SAP Internet Software Model

ERP Major SAP unviels the New Business Model

However look at the key Innovation has come from Salesforce and NetSuite - Using Internet for Packaged ERP Deployment. It is a service model rather than the product Ownership model.

The ERP Majors - thought how can Internet impacts their business as they have so much value in their products and only way for companies is the product buy!

Well, the changes are impacting everyone - Big/Small/Medium... In fact, it is very interesting to connect to Seth Godin's book titled "Small is the new Big"...

I would like to modify it the "Connected Smalls is the New BIG" .... Wealth at the bottom of the pyramid... It is the scale that gives you wealth.

Are Monolithic Product Designers listening!

Thursday, September 20, 2007

Creating Brilliant Enterprises

Recently read an old paper of mine titled Creating Next Generation Enterprises which was published in the erstwhile eAI Journal (In 2002). Well 5 years back! Isnt it too old.

I have described the journey of entrprises from Data Driven -> Information Driven -> Knowledge Driven -> Intelligent Decision Making (I called the UDEK - Ubiquitous Decision Enabling Knowlegde) -> Smart Enterprises and Finally the brilliant enterprises which will be not only smart but self-learning and environment aware - where Innovation is the norm.

Looking at my own journey - I think I have been exploring various techniques from modeling simulation, multi-criteria decision making, TRIZ, Lean, and now the complex systems studies as reflected in the so called New Science - I believe the subconscious mind works on its own - as these are not explored in any systematic manner - I have been moving into these fields inadvertently - Amazing.

The concept of Brilliant Enterprises came to me from defence terminology - having read about dumb bombs to smart munitions and then the so called brilliant bombs that were coined to differentiate the inherent intelligence of the new bombs compared to the dumb bombs of the old technology.

So the Brilliance really lies in continuous knowledge, learning, adpating and exploring change. In effect - it is about enterprise wide Innovation.

Process Productivity - Software Equation

The software equation proposed by Putnam, relates the size of software, effort and time taken in a non-trivial way. The result is defined as the Process Productivity. It is mentioned that a true measure of productivity should be Process Productivity and not the conventional measure of productivity defined as KLOC/(Person-week). This conventional measure has been criticized because its value varies widely at any size the estimator is considering and even more widely from one size to another.

The Putnam equation [Putnam L.H., and Myers W., Five Core Metrics – The Intelligence Behind Successful Project Management, Dorset House Publishing, New York, 2003.] as it is known, explains a relationship between software size, effort spent and time taken to deliver the software. It relates these quantities with what is termed process productivity. The equation in words is

Size (at Defect Rate) = Effort x Time x Process Productivity (1)

The equation in its generic form is

Size (at Defect Rate) = Efforta x Timeb x Process Productivity (2)

After studying various projects, Putnam found the relationship as

Size (at Defect Rate) = (Effort/β)1/3 x (Time)4/3 x Process Productivity (3)

This is called the software equation. Beta (β) is a size dependent parameter that has the effect of giving greater weight to the effort factor in very small systems).

It is a real surprise that Software development organizations havent used this as widely as they could. In fact the evidence of experimenting with this coupled metric is also not there. May be we need to explore this more!

Software Reliability and Complexity

Software Reliability Growth Models

Software reliability models are developed with a premise that with more testing and bug-fixing, reliability will increase as number of bugs remaining in the system will go down. This is based on the assumption, that total number of bugs in a developed software system are fixed. These models are called software reliability growth models (SRGM). This is however the perfect debugging scenario, where the process of fixing bugs doesn’t introduce more bugs. In the SRGMs where imperfect debugging is assumed, the modeling is based on the assumption that by fixing bugs, one may introduce more bugs, but always the number of bugs after the fix will be less than the number of fix before the fix.

Since the process of bug occurrence and bug fixing is non-deterministic, most of these models are stochastic in nature. This implies that there is a probability function associated with both the error content in the system and the error detection rate at a particular instance of time in the life cycle of the system. Typical probability distribution assumed is the Poisson distribution. When the averages of the probability distribution vary with time, it is called the Non-Homogeneous Poisson Process (NHPP). One of the earliest models in this class is the Musa Model, which has been developed from the basic Goel-Okumoto model.

Musa model belongs to NHPP exponential model class and was first proposed in mid 1980’s. Since then the field of software reliability modeling has progressed further and many new models closer to reality have been developed and used. In the NHPP models class, NHPP S-shaped, NHPP imperfect debugging and NHPP S-shaped imperfect debugging models are new advancements.

All these models require an accurate and robust parameter estimation mechanism. A major parameter of interest in these models is the estimate of total number of bugs in the system. By having an estimate of total number of bugs, a decision on when to release the product can be taken by estimating the remaining bugs at a particular instance of time. Ideally one would like to have zero bugs when product is released. However the amount of testing needed to find and eliminate all the bugs is time and cost prohibitive. The SRGMs can help the designers/developers to estimate the remaining bugs which can be used to take a call on fit to release.

System Complexity Estimator

System understanding requires a detailed analysis of system complexity and the factors that contributes to the complexity. Complexity emerges due to greater demands of providing more functionality within multiple constraints. The System Complexity Estimator (SCE) developed by me takes into account the functionality being provided by each module and the dependency of each module on the system to compute the relative contribution of each module on the overall complexity. The analysis is based on two fundamental concepts of Cohesion and Coupling in the software design. Best design is one with minimum coupling between modules and maximum cohesion of each module. The complexity is measured relative to an ideal system with minimum complexity. An ideal system with minimum complexity is defined as the system where no module depends on any other modules for its functioning and each module performs only one function. The output of this analysis can help in prioritization of development effort, resource planning, integration scheduling, etc.

McCabe Complexity/Code Complexity

Cyclomatic complexity is the most widely used member of a class of static software metrics. Cyclomatic complexity may be considered a broad measure of soundness and confidence for a program. Introduced by Thomas McCabe in 1976, it measures the number of linearly-independent paths through a program module. This measure provides a single ordinal number that can be compared to the complexity of other programs. Cyclomatic complexity is often referred to simply as program complexity, or as McCabe's complexity. It is often used in concert with other software metrics. As one of the more widely-accepted software metrics, it is intended to be independent of language and language format

Maintainability Index
A program's maintainability is calculated using a combination of widely-used and commonly-available measures to form a Maintainability Index (MI). The basic MI of a set of programs is a polynomial of the following form (all are based on average-per-code-module measurement):
171 - 5.2 * ln(aveV) - 0.23 * aveV(g') - 16.2 * ln (aveLOC) + 50 * sin (sqrt(2.4 * perCM))
The coefficients are derived from actual usage. The terms are defined as follows:
aveV = average Halstead Volume V per module
aveV(g') = average extended cyclomatic complexity per module
aveLOC = the average count of lines of code (LOC) per module; and, optionally
perCM = average percent of lines of comments per module
---------------------------------------------

So What to do - how to use these and when?

In the software development life cycle - these models and metrics need to be placed appropriately so that complexity increase from one phase of the life cycle to next phase should be under control of maintaining reliability of the system being developed. This is easier said then done. As of now, I dont know about any end-to-end model for managing complexity simultaneously increasing reliability of the software being developed and at the end making the system maintainable. May be food for thought!

Wednesday, September 19, 2007

The T-shaped people

A friend of mine became the CEO of a company. He is very good - in solving technical problems - in the past he designed single-handedly new IT systems and solutions to complex problems.

Now since he became the so called highest level executive manager of the organization, he was forced to get away from technical problem solving - he was suppose to lead the company, take it the next level as per the market needs, think customers, think relationships, think conflict resolution, think creating future capabilities. Well so much and so many thinking needs - where is the execution part. However, whenever he get the nitty-gritty technical problems he will contribute much more. In fact, he designed technical systems (based on his past memory) in the board room - everything for him can be automated. His only direction to solve any problem is how to automate and everytime he gets a kick out of automation solution to any problem.

Secondly, since the CEO himself by his action setting up this direction, everyone of his reportees also got into technical problem solving - in fact designing technical solutions for the day-to-day problems - trying to automate everything and getting their Techie Kicks out of it.

However, Employees, Clients, Suppliers and partners who were suppose to work through the highly automated systems that the CEO was interested in designing became extremely frustrated with no focus in the big picture communication and design.

His company suffered. He got out of the job, with enough money - and he got into technical problem solving as R&D Scientist in one of the companies.

Well the lessons are -

Higher you go in the organization - bigger the picture should be - even if the depth in one or two areas may not be there. However, there is a concept of "T" Employees which IDEO talks about (http://www.ideo.com). The design employees needed should have broad exposure, interests, aptitute and attitude while having deep competencies in one or two key areas.

Can the CEO's get away with only Breadth or only depth? Come to think about - can anyone of us get along with only depth or only breadth? The new world - where emphasis is on change, learning, knowledge, networking and Innovation - it is the T shaped people who will succeed. Is that so?

The way we solve problems

How do we solve problems?

First we acknowledge something to be a problem only when it becomes a pain in the, well, neck. Unless it becomes a monster hitting us where it really hurts - we dont look at it at all. May be - since we have been told to Stop Worrying Be Happy, we forget about any active problem hunting. Here in lies the first danger - Stop Worrying doesnt imply Stop Thinking. How can we be proactive in hunting problems - (1) Be there to observe how and what our customers need - dont ask - all Feedback systems fail to get to the essence of what is needed (2) Spend time in observing, getting inputs, looking at how our customers do their work and then think some more - well our Top Managers must be saying - you cant keep on thinking DO - Act - Execute - Well execution without thinking or what the Japanese call Hansei, is a recipe for disaster.

Second, we invariably or 99% of time design the solutions for wrong problems. This is for the simple reason we have not spent time in developing the problem - describing it from multiple perspectives - looking at it from inside and outside.

After we have developed a solution for the wrong problem - which also by the way will be a sub-optimal solution - we find the actual problem to be different because in our cause-effect mind, the solution that we proposed havent triggered the desired results. Then we say Oh - the real problem is not what we solved but THIS. Now comes the fantastic ingenuity of human mind and lethargy in letting go of partial success - we say any way we have a solution that we designed for what we thought is the problem - now how can we use the solution to solve the newly identified problem. We work on tweaking the solution, refining it adding more components to achieve new functionality needed. This leads to the solution becoming more complex than the orginal problem. In fact, the Monsters that we create need to be managed now - we will create infrastructure to manage it - we will not let it go at all. After all that has given us past success. Any body knows how many Enterprise IT systems have become these monsters?

This is a problem fission reaction - that keeps on building bigger and bigger complexity rather than Value needed by the end customers. Had we spent more time in thinking about existing and future needs of the user - may be we would solve problems that really need to be solved?

Think - Think deeply - however Observe and Learn are two very strong - unfortunately highly neglected ACTION verbs in solving problems.

This is not about too much analysis leading to paralysis (thats where may be the Post Facto Data Analyts get into - Six Sigma Experts (The pseudo ones) are listening!) - it is about active processing of experiences.

It has to be beyond Politics, beyond specific persons, beyond specific relationships, beyond petty personal gains - it has to be at a higher selfish goal - as My selfish goal is that I win if my customers create more- everyday!

Monday, September 17, 2007

Change is the Only Job You have

From the 2000 AD article in Fastcompany Your Job is Change comes the concept and job title of Change Insurgent - phew... Well - how many of us are change insurgents? What are the key Change Insurgencies Skills we need to have in a world thriving and growing on continuous change? I just reiterate the Key skills mentioned

1. Continually invent better oprganizations
2. Aim for Dexterity - Growth AND Sustainability
3. Explode the Organization - Open (business, innovation, sourcing)
4. No Hierarchy - Work from current position only

The 10 rules are very relevant even now - 7 years is too much for same rules to be relevant - looks like these will survive next 7 years as well -
1. Manage the Blood Supply - just like a 30 minutes Jog per day will manage your heart for sustianing your body
2. Find and promote people who make you uncomfortable - This is very difficult in manager based organizations - however in a leadership driven organization this is the norm
3. Undermin or Subvert the Relationship people - This is most difficult as the political cliques formed in the organization over a period of time are difficult to undo - however thats exactly what is needed!
4. Generating Heat - I am not very sure about it - however it has to be learned -
5. Change Allies - the technology guys/solution designers and sales guys - let all other facilitate this dialogue as this is the only way to Cut-the in between management crap - well it is better said than done- position play is so rampant in most organizations
6. Hold change resister's hands - Destroy change inertia through making resistors fit in the changing way of work
7. Use tough love - Striking high in the organization - well CI's need to craft strategies
8. New Measures - I sincerely believe the metrics need to keep pace with the change - even the Balanced Score Cards - are really not so balanced.
9. Just Do It - The Nike Mantra is a recipe for execution - nothing succeeds like execution!
10. Leave it at the time you should - There comes a time for CIs to loose their value - right timing is important - rather than banging your head on closed doors !

Tuesday, September 11, 2007

What is Innovation Tsunami?

The announcement of the new processor - called Barcelona (while it was being developed) - the ultra new Quad-Core AMD Opteron processor - and its comparison with the Intel processors - have led the AMD CEO to coin the word - Innovation Tsunami. I am not so much fascinated with the latest processor as by the latest articulation of Innovation pace as the unleashing of Innovation tsunami - well - if we look at the globalisation and increasing complexity has churned out innovation at a pace that has been unprecedented - in fact the futurists are all gung-ho about what we will become to what way we will generate wealth - with all the new ways that we are creating there also are emerging new ways in which we are destroying - well - we dont know which tsunami will be winner - the innovation tsunami which creates more value in the Globalizing Innovation Complexity (GIX) Bang world - or the Innovation Tsunami that destroys value - Hope it is the value creators who will win!

Embrace Failure - the Path to Innovation

Embracing Failure a theme closer to my thinking as of now - I have been calling it intensity to fail comes to the forefront of the Innovation debate - if there is something like that by the way!

The interview above highlights the need to empower employees to drive change in the organization. Change, Learning and Innovation are linked to each other to a great extent - and I believe the intensity to fail - which means how quick and big is the failuire - will determine the success of the organization. So if you want to innovate or drive change or create a learning organization - be ready to fail with maximum intensity - meaning fastest and biggest failures will lead to biggest success! This is too contrarian a view to our minds programmed to incremental success - well get reprogrammed quickly!!

Sunday, September 02, 2007

Primary Colours of Customer Value

Customer value is back as the basis for success!

Customer value is based on Needs. Needs are complex - phew! so what is this complexity, the above article tells us - four regions from where this complexity is emerging (a) Functional Needs (b) Emotional Value (c) Symbolic value (d) Cost value.

Prof. Mohanbir Sawhney's paper - Fundamentals of customer value I keep on revisiting.

It defines three dimensions of customer value - Functional, Emotional and Cost. In a way these are the three key dimensions as emotion and symbolic are sort of linked.

The problem is much more complex as for a particular class of customers it is extremely difficult how the three key dimensions play out. It is because of one dimension that people get a service or product - I think it is really a combination of all three - in a way that Red Blue and Yellow form the three primary colours - these three dimensions of customer value need to be combined in such a way that the colour needed by a particular customer is delivered to her as per her needs! Thats a great challenge!

Lean Inventive System Thinking - A Framework for Software Development in GIXBang

The rapid explosion of Global complexity calls for new ways of solving problems and making decisions. Continuously increasing complexity in the modern day systems call for radically different measures to ensure high levels of productivity. Couple this with increasing distance between user requirements of what they really need versus what they want, the challenges are increased manifolds. Since Information Technology is central to the modern world, it is but obvious that approaches to create, design and develop IT systems need to respond to the complexity explosion. The current approaches to software construction and delivery are finding exceedingly difficult to meet these challenges. Further the problems of software design are compounded due to non-physical nature of software systems, where intuition, experience and judgment of experts plays more important role than quantitative and measurable metrics of the traditional engineering world.

The existing methods based on the normative or descriptive approaches for making decisions leaves lot of decision makers and problem solvers on their own despite making claims to the contrary. The problem solver finds him alone in a complex web of decision dependencies and fuzzy end of decision complexity. I have been experimenting with some of the techniques and methods for solving real life problems in Information Technology (IT) service delivery. These techniques are organized as a framework for collective problem solving using three key thinking dimensions – these are Lean Thinking, Inventive or Design thinking and Systems thinking. The framework called LIST framework has already proved its worth in many real life case studies in improving overall productivity, reducing cycle time, designing relevant solutions needed by customers and minimizing stress on the employees. The framework has some of the known LIST techniques such as Design Structure Matrix (DSM), Analytic Hierarchy Process (AHP), TRIZ, Set-based concurrent engineering (SBCE) and Value Stream Mapping (VSM). There are some of the new techniques developed by me, such as System Complexity Estimator (SCE), System Change Impact Model (SCIM) and Project Cacophony are also included as part of the framework. LIST for Software Development is the need of the hour!

Enterprises in the GIX Bang World - Key Questions?

Questions: In the GIXBang world how do we perform following tasks…


•Business Strategy Formulation & Tracking
•Product Strategy Formulation and Tracking
•IT Strategy
•New Product Development
•Opportunity Finding - for an Idea/Product
•Patent Portfolio Management
•Technological Alternatives to a Patent
•Decision Making
•Outsourcing/Off shoring
•Project Management
•Innovation Management
•Problem Solving
•Process Improvement/Re-Engineering
•Performance and Reliability Improvements

How and What …

•Make work visual
•Let learning lead
•Employees empowered
•Ideas and work to flow
•Multiple Kaizens
•Focused R&D
•Customer Value Imbibed

Create Frameworks for ...

•DECISION ENGINEERING
•IDEA CRAFTING
•CUSTOMER VALUE
•BRAINSTORMING
•PRODUCTIVITY IMPROVEMENT
•PATENT PORTFOLIO MANAGEMENT
•SET-BASED CONCURRENT ENGINEERING
•LEAN OFFSHORE-OUTSOURCING MODEL (LOOM)
•PERFORMANCE ROBUSTNESS INNOVATION DEPENDABILITY ENGG
•IT VALUE

Saturday, September 01, 2007

GIX is changing the rules of the Game!

Sarkozy sees French way to globalize: Collectively
Can General Motors Change How Companies Think About IT Outsourcing?
Globalization: The good, the bad, the ugly

Just a sample is the above three links on how Globalizing Innovation Complexity (GIX) is changing the rules and actors.

first one says the French President wants France to embrace Globalization with new rules of Governement joining with the industry to create a new type of organization, besides relaxing the 35 hours week industry policy. Second says how GM which has been outsourcing IT services for more than a decade is defining the new way of IT outsourcing - where the new CMMI ACQ Model will be used for outsoucring assessments. This is a classic case of trying to control - an area which is traditionally been self-organization based (see the open source success). Third link talks about a small story about Journalistic work being outsource as well, considered as a new arena of outsourcing.

I think - GIX will change the actors and the rules will be defined and created as the GIX Bang move faster and faster. So all those actors who want to follow command and control and want to control GIX Perestroika and GIX Glasnost (remember Gorbachev in late 1980s) - should really understand the GIXBang - it is all about co-creation. If you are not co-creating, you are out!

General Motors, CMMI, IT Outsourcing - Can Toyota help?

When next time when you face the IT outsourcing decision - from which ever side (whether the supplier or consumer of IT services) - beware of the new kid in town - the CMMI-ACQ - the highly detailed Capability Maturity Model -(CMM) has a new arena - it is the outsourcing landscape.

General Motors with billions of dollars in IT outsourcing has come up with the new model.

Having seen the CMM first hand in some of high CMMI companies - it promises to be a all encompassing framework with focus on lot of documentation and lot of metrics measurement etc. Well, the framework is fine. However, it should not be carried out at the expense of actual work. With an inherent tendency of inefficiencies creeping in any standardized processes for software development, it is imperative that the framework should focus on continuous learning and problem solving at the lowest level - and here Lean thinking from Toyota production system comes in handy. May be the IT outsourcing needs to get Lean not CMMIzed!

My Book @Goodread