Archive for the ‘ Strategy ’ Category

Changing a Practice through Experience Capitalization

Change is everywhere and happens all the time…well except for corporations, where changing a practice, procedure, process is a rare phenomenon and there is no consensus on how to bring about it. Too many variables, too many factors since change always rattles the culture which is hard to define, let alone adapt.

Among many techniques for change, including management controls, dictatorship, incentivization, germination and gamification, one instrument is Experience Capitalization.

A technique from Knowledge Management which enables Knowledge Capture, Transfer and Utilization all in one with defined outcomes leading to Lessons Learned and ‘Good Practices’ with the stakeholders ready to buy-in and adapt for change.

Doesn’t that just sound great! Well, that’s the target anyways….

The essence to enable change, one has to institutionalize shared knowledge among the stakeholders based on their experiences and consensus.

We know that Knowledge Transfer is a core function of successful innovative companies. The “Flow” enables us to co-create, institutionalize knowledge and get a real feel of knowledge worthiness.

Knowledge Transfer takes place for a host of reasons like succession planning, product training, new employee ramp up, brewing up best practices, abandoning bad practices but when knowledge is systematically converted into capital to enable process improvement and structural change, it is often called ‘Experience Capitalization’.

Although ‘Experience’ is known to be the least effective knowledge acquisition tool since it carries a high risk of not learning anything further, or of carrying the ‘wrong’ experience, one which is made due to bad habits of short term quick and dirty fixes but here the term ‘Experience Capitalization’ refers to collective, institutional learning which overcomes such ‘Competency Traps’. In most if not all cases, Organizational Learning is a better critical success factor. Here Experience Capitalization focuses on Organizational Learning.

The philosophy is that by capitalizing on (latent) experiences, changes can be brought about since it is the (latent) experiences which are ignored and sidelined without this process, blocking the impetus to change.

Experience capitalization is a learning process but differs from personal learning in that the expereince is summarized and belongs to the whole group, reached through a concensus and thus reducing the resistence to change. Another fundamental difference from other forms of Organizational Learning is that experience capitalization usually focuses on the experiences of the stakeholders only without involving third parties. This ensures that the summation of the experiences are ‘local’ to the stakeholders who have to undergo change. Experience Capitalization cannot be delegated but third parties can be invoked only as facilitators.

The Swiss Agency for Development and Coperation defines it as:

Experience capitalization refers to the transformation of (individual and institutional) knowledge into capital by those directly involved in order to change a collective, institutional practice. It aims at changing one’s own practices or structures.

Read more about Experience Capitalization at their website.

A Presentation on HR Analytics

The Pre-Sales Diary:Great but Too Expensive Dear!

Thwack!

The apparent feeling of being dumped by a potential customer can be materialized by a host of many available options for such potential customers. Although there is no harm (apparently) for being rude to the sales team but just for the sake of better euphemism, these no longer ‘potential’ customers can simply blame their distaste of your products/services or whatever you do to being overpriced!

Although a fashion statement in some novelty industries and an admired trait, most enterprise business software taboo out the pricy tagging.

First of all, we all know it, IT notoriously sucks the money out of a business, especially when there is no enterprise strategy around, IT is definitely a pure cost center. That is why they invited you to sell them business performance management and intelligence software to get share of the corporate ‘strategy’ cake.

But you don’t like to understand any of this, you spent a lot of resources in time and people to execute a sales cycle, raised expectations, probably gave a proof of concept with purpose, all to listen to the once potential customer spit out the devilish decree. It all starts with ‘But…….‘ and follows a variation of ‘Your solution is too expensive‘ or ‘we can’t allocate the budget for it‘, ‘we don’t make the final purchasing decisions’, etc etc.

In reality, this is just a polite way of saying that you didn’t meet the expectations or weren’t able to create the right value of your products/services.

How do you cater to this catch-22 situation?

Many  survivors tell us some common strategies, including:

  1. Price Justifications (e.g. Our product works in zero gravity, our costs are only upfront heavy, incremental upgrades are very cheap)
  2. Price Distractions (e.g, we have overall very low TCO)
  3. Competitor Demeaning (e.g. The competitors have lousy products and are thus cheap) (Pun Intended)
  4. Bargaining (e.g. whats your budget, let us fit something for you, else we will definitely, ultimately come down to your level)
  5. Reinventing the Sales Wheel (e.g. Lets try again, lets talk again, let us repeat our efforts to emphasize why we are not so affordable)
  6. Reassess our own Assumptions about the Expectations and Value Offered (e.g. Does the customer really know what they can get as true ROI, is our product redundant, can they solve pain point using other lesser expensive solutions)

The reality is, most of these techniques are pretty frequently used, some of them are quite demeaning (e.g. 3), but in most cases, the bottom line is, you need to set the Expectations straight, and such an objection raised only indicates the lack of effectiveness to do the same.

Once the objection is raised, ask the prospect what should the product/service have more for him to rethink the budget?

He would either give you the points for mending the gaps or acknowledge your product fitness to be good.

For the former case, if the points mentioned are offered in your products/services with a workaround or a doable approach, go ahead, you have nearly resolved the objective.

If the prospect is unable to provide any missing points, then you need to re-emphasize on the need, figure out the real decision makers (if he/she sites others for budget approval), or figure out the true ‘champions’ and ‘villians’ in your deal. Most likely, you will find out that your current assessment is different from your initial assessment.

Apply the changes only, this will set new Expectations and hopefully hopefully you will have the objection resolved, your product/services will be valued the way you wanted or pretty close to that.

Happy Selling!

The Pre-Sales Diary: The emerging role of the presales and its infinite landscape.

I must admit, thinking of a professional which has anything to do with ‘Sales’ at first seemed quite demeaning, especially for an IT guy. No offense meant to my fellow Sales professionals whose career I respect a lot but one which is quite plagued by stereotypes.

Let me get this straight, Sales professionals are kool, dynamic and at times quite creative people. They are experts of deals, know how to conquer the social network within companies, markets, industries and regions. They represent a driving force in business development. Yet when it comes to technology and professional services, not many sales professionals get it!

That is why we have Presales. People who bridge the gap, the chasm so to speak between Sales and technology acquisition. Presales are subject matter experts who romantically guide the potential customer with the right solution and solve their business problems. They are not driven by Sales targets nor have quotas (usually). What they do have (again, very ideally speaking) is a knack to solve business problems using their technical skill set and prior vast experience in delivering solutions and consultancy.

Frankly speaking, the first time I heard the term ‘Pre-Sales’, I felt the connotations like a Preview of Sales, or what is to come. Something felt Premature.  I also got the feel that this bunch is not comfortable implementing solutions. All my misconceptions are getting cleared now as I see this as a role made for those who like to tread on unchartered territories all the time, who like to be paratroopers and land into new environments, understand the patterns, recommend the best solutions all in a competitive, game like environment where most of the time, you are dealing with a staunch nemesis.

Pre-Sales is an infinite landscape because you get (and represent) a breadth of knowledge both in business functions and technological environments. Most presales i’ve known are usually product specialists but the role demands a very good idea of enterprise software and how to really place your product with the right mix of configuration and services. AND YOU MUST WEAR THE BUSINESS HAT!

The role demands credibility, agility, and competency, more so than anyone else as this role is the brand ambassador for the company and product(s) he/she represents. Most of the times, the potential customer trusts the pre-sale to give the right advice which is devoid of commercial interests. This puts the pre-sales into a position which demands authority and responsibility.

It is by no means a job for everyone but for those who live it, enjoy it by the lead…

Article++: (Leadership by Strategy Execution – Palladium Group)

This is a brief synopsis of an excellent article by Palladium Group, arguably the home of Balanced Scorecarding. Here is my summary.

Its a statement of manifesto by Palladium about their belief in the single most important requirement for (a successful) strategy execution:

A Visionary and Effective Leadership

These leaders:

1. Consider Strategy Execution as their Job.

They are directly involved and actively participate in the activities required to execute the strategy, rather than just delegating them.

2. Have keen understanding of the process of change.

They have the ability to motivate and create a shared vision of the organization by winning hearts and minds of people. They create the impetus for change.

3. Take Decision Accelerating.

Change can be either incremental or transformational, they know when to take one of the approach.

4. Stay the Course

Focus is important, shows commitment and embrace resistance by engagement rather than compromising or confrontations.

5. Put a Premium on Communication

Transparency is key.Their shared vision is highly communicative (and collaborative) and it empowers people.

6. Delegate Roles with Responsibilities and Authorities

They create roles and ensure these roles have the right set of authorities for actions and decision making. Later on, they develop a proper system for accountability for each such role.

7. Avoid Shortcuts, Support Process Development

They know the power of creating robust processes for +ve change for strategy execution and do not rely on adhoc and quick fixes.

8. Plan and Budget for Strategy Execution:

They treat strategy execution as an investment of time and resources which will bear fruit. They appoint the right change agents and assign them roles to fulfill.

9. Analyze the right information

They make information driven decision making by employing good systems of governance, conduct frequent management reviews and create key strategic performance indicators.

10. Are open minded and flexible in behavior

They are continuous learners and encourage a direct feedback for their own performance improvement and insight.

 


Impact of Business Modeling on Data Warehouse Success

Business Modeling to Process Management professionals may mean something different, but in data management, business models are the logical data structures which capture the meaningful events in context. Here the context refers to dimensions, measures and their specific usage. Data Warehousing activities should be agile, thats the evolving zeitgeist which concepts like DW2.0 (Inmon), Agile BI and Self-Service demand. The fundamental problem with Data warehouse development is catering to change, agility and still serving a diverse user base.

BI processes and tools like Qlikview, Spotfire, Tableau with in-memory, associative models, alternative to OLAP provide the agility but the backbone of the organizational data warehouses are still locked into fixed, rigid and less scalable subject areas.

The impact of conducting Business Modeling sessions with the Business users prior to BI is effective on many fronts:

1. Business Exceptions are captured early.

One of the trick questions in requirements gathering for data warehouses is to extract the exceptions in business rules, processes, events from business users. This phase is an ‘art’ and only few can get a good knack of exposing as many business exceptions early in the design process. The problem with realizing business exceptions late result in architectures with patchy workarounds and fixes which reduce the overall muscle of the data warehouse building.

2. The Essence of Business Processes necessary for Data Warehousing is preserved.

At times, business modeling invoke the discussions among business users who rather than portraying the as-is states, often pertain to discussions and debates on what ought ‘to-be’ states and thus the BI consultant captures the overall strategy and goals of the business process under scrutiny. This info leads him/her to design solutions which adhere to the general gist and thus can manage both as-is and to-be with little modifications or further effort. Decent data warehouse scalability can be achieved.

3. A common language for communication is established between business and IT/BI.

Often times BI consultants & DW Architects force Business Users into understanding the business data model using the underlying database data models with naming conventions, physical layouts and dimensional modeling technicalities which overwhelm the business user. Business Users love when IT talks their language and IT appreciates removing ambiguity and vagueness by using a common lingua franca.

4. Greater sandboxing capabilities

Faster iteration cycles for prototype warehouse models can be reached which will allow for faster convergence to the desired data model(s). Easily an end to end prototype including subject area development, followed by BI can be experienced often revealing obstacles before going for the time consuming and complete implementation.

5. Setting expectations becomes more accurate.

Business Users through sandboxing and through modeling see the highlights of things to come and therefore right sizing is achieved.

6. An initial scope for BI is understood.

Business modeling will reveal to the BI Consultant(s) the major pain points of the business users and having seen the business models with its exceptions and all facets, a rough time estimate can be set and/or a rough activity and project (or phase) scope can be identified.

7. The A-Team is on-board.

By bringing a wide array of people from end users, power users, quality assurance officers, BI consultants and data architects, a company can easily identify the A-Team from the business modeling activity. This A-Team will carry the momentum to execute the project and in the longer run participate in the BICC.

8. Nip the Evil in the Bud, Data Quality and Governance issues start surfacing

Although they seem to be a distraction and are separate programs themselves, Data Governance (and Quality) has to be addressed as early in the Data warehouse design phase as possible since the design elements can be either considerate of cleansing or assume that to be cleansed when it comes to the warehouse. Secondly, Data Quality fixes later in the value chain, (worst case, front end reporting) will cause greater deviations from standards and design and a solution based more on patches and work around.

9. Greater Transparency in design and architectural choices is observed.

Due to Business Modeling, the organization can better track down on individual decisions which underwent while designing micro elements in the design process. Usually data warehouse implementations which don’t start this way, eventually end up with a long audit trail of documentations and ‘memos’ which are hard to capture and even harder to manage.

10. Overall project implementation times in principle, reduce.

Since the initial challenges are dealt upfront or are atleast discussed upfront, the overall project implementation times reduce. Lesser time is required to do exception management, lesser time is required in debating design choices and communication, and lesser number of surprises (in principle) have to be dealt with.

All in all, it is vital to involve the business users in the design process using business modeling approaches. There are several business modeling tools available in the market which assist in the process but at the end of the day, its the process of conducting such sessions that bear fruit.

Re-Structure, Re-engineer Not. Recycle!

I had been getting constant reminders this week to attend a very important meeting arranged by the shareholders of my company. The entire board and staff were invited to attend. Today, amongst all the hype of the meeting, I inquired about the agenda from the office administrator. He doesn’t converse much in english and said the company is going through recycling!

Yep, you’ve heard it, and are probably thinking it as well, he actually meant ‘restructuring’. However, coming to think of it, business should be actually recycling rather than restructuring or re-engineering.

Recycle in webster is defined as:

to pass again through a series of changes or treatments: as

  1. To process (as liquid body waste, glass, or cans) in order to regain material for human use
  2. Recover
  3. To reuse or make (a substance) available for reuse for biological activities through natural processes of biochemical degradation or modification
  4. To adapt to a new use : alter


On the other hand, Change Management is defined as:

“Change management is a structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state. It is an organizational process aimed at empowering employees to accept and embrace changes in their current business environment. ” – Wikipedia.

The overly painful and agonizing transition to this desired state with many a casualty, uncertain future, distration from focus, and a sense of panic which has haunted change management initiatives across the world simply misses the important mottos:

  • “To Regain”,
  • “To Adapt”,
  • “Recover”.

Thats the essence of Recycling! Well ofcourse to some degree, Adaptation is implied in Re-Engineering (Process Re-Engineering) activities, it is the explicit nature of subconcious ‘allegations’ that ‘as-is’ is below the required mantle while ‘to-be’ is in all its might, superior than the ‘as-is’, Thats why people in the middle of it despise change. Coming to think of it, the term recycling comes much closer to the point than restructuring for any possitive change management.

The goal for any organization to employ any change management initiative should to be

  1. To conserve its morale (or improve it), as it is the fundamental energy,
  2. To reuse this energy and materials, thats the lessons learned, the knowledge and the ‘what works’ in an organization using its existing people
  3. And finally it is to ‘Recover’ whats lost…, corporate focus! (The enthusiasim and drive which was once set long ago in entreprenueral utopia.)

Go Green, dont restructure or re-engineer but recycle your business!