Why the PMO is dead, done and dusted?

Lets look at some core functions of the PMO and how it is dead, and why they will continue to be irrelevant.

1. Major responsibility that I did when in an IBM PMO was review of a bunch of projects. Review of progress is not so useful in the world of constant communication, low planning and high coordination. Primarily because there will always be a delay to this reporting and whatever form of output, will not be fresh or add to current decisions and progress. Only being engaged constantly, in-situ works esp in the complex/emergent and chaotic/novel domains.

2. Second job within the PMO was demand and intake management. As I see today, the central IT departments are so warped in their own cocoon of legacy processes and structures, their client business departments are fortunately free with their own IT budgets and prefer to go independent.

Thus leaving the IT department only with some of the following that are stuck in a different age tenet.

  • GRC, ERP, finance, other corporate systems, stuck in the records era
  • providing infrastructure that is already commodity, stuck in the pre-cloud era
  • or licensing of standard software, stuck in the PC/pre-mobile era

For example take document storage, editing and collaboration, in the age of dropbox and google docs, when all we get within the company is a PC age MS Word to be sent over email or uploaded in a sharepoint, all these were the IT department’s independent decisions. Take connectivity or storage, with  at least 2 mobile devices per head that have better connectivity and also employee’s overall personal storage leads the standard enterprise storage with poor connectivity. OK those for another post.

Point I am trying to make is the legacy standard processes have lived their life (and dead now) to be managed from the PMO. Recently I was filling a paper form for deploying a mobile application internally, and I realized this in a worst possible way waiting for some PMO to review this and get back on the request. Surely their demand management processes are outdated and responsibilities have shifted elsewhere which is business itself.

3. When business departments have gone independent, it makes it clear for them to track accountability for their investment not some un-translatable set of IT metrics that the PMO tracks. At least through my career, I have seen so many promotions inside the IT department, because of this lack of clear metrics, that even a failed business outcome project could be a grand success IT project.

If the PMO was to be even marginally useful, only way is actually play/perform, not review/report…


Innovation risks

Drucker‘s Landmarks of Tomorrow lists clearly 3 risks that arise out of innovation is comprehensive and can orient towards tasks and outcomes around innovation quickly. Even if outcomes are a function of many variables and ambiguous,(an excuse that innovation managers typically ride on to retain jobs/titles while not really “tasking”) you still have to act. That said  “tasking” / task orientation is necessary and not arbitrary or ambiguous in any enterprise. That’s a post for another day. So these tasks arise after the enterprise decides to reduce its first risk in innovation.

1. Risk of Exposure. Exposure risk is an inaction risk, while remaining very successful in the chosen market, this risk makes the whole business irrelevant as newer models and innovations take over existing customers and create new ones. I visualize this risk on a slider bar, where there is a NO on the left end and an YES commitment on the right. Depending on the level of YES, time and resource availability is determined for innovation.

Risk of Exposure Slider bar

This YES commitment (on the risk of exposure) does not mitigate but lead to the next, new set of risks below. In any case this risk cannot be avoided. You can see examples today in education like the massive open online courses offered by Coursera and the likes while the incumbent i.e. every higher education player could have very well acted earlier or the popular digital photography disruption misses by Kodak.

Risk of failure in developing the innovation When I heard Ravi Venkatesan at the recent Zinnov Confluence, he mentioned “skunkworks are interesting to see in labs, but unless the whole organization aligns to an innovation, there is really no chance”. I believe that, by organization he would mean the “tasks” on business processes starting from budgeting, development, sales/marketing, service, legal etc. that are specialized and entrenched across departments, but need to come together. Successful businesses ideally should not delay capex investments into innovation, and commit to experimenting the next set of revenue drivers. Experiments could be for example

  • small like skunkworks or community driven developments internally
  • taking ownership in companies that are doing the development

Still the structure has to commit itself to this developmental action and evaluate all along even if it means changing directions many times mid way to make sure the next risk of failure is covered. With the crowd sourcing possibility on almost anything this risk has greatly reduced, this as a model has been operational across many platforms like kickstarter (for investments), or ninesigma (for effort).

Risk of failure of the innovation itself

This is the biggest of all risks and can be really dramatic, and we know many stories like these in recent times. What Drucker calls here as ‘responsibility for the consequences’ of the failure itself, while constantly acting for the opportunity. It is no more a chance but choice and choosing to resolve contradictions between the global versus local, profit versus free, etc and thus becoming a value decision in itself. Most of us are aware of the commercial failure of much touted innovations like Segway and others.

Risks in Innovation


5 essential meeting room filters

I feel meeting rooms have to be equipped with special filters to shorten meetings, make them meaningful and useful. I will start with the simple one and gradually build complex filters.

1. Clichés Filter: This filter will simply cut out all the clichés uttered in the room from the grand global database of clichés

2. If Only Filter: “If only, …simple past blah blah blah” is almost like visioning in hindsight with no possibility ever to change anything in the present, but can go on through the meeting and its next 4 occurences.

3. Me more me some more me Filter: Although can be avoided with a good time-keeper, there is an interesting instance of this filter under the name of “hide updates from this user without unfriending” feature on Facebook.

As we move from words to word collections to me me me, filters get complex as below

4. Plati Atti Servi tudes Filter: This is a seeded learning filter, inputs vary across organizations due to varying limits of acceptable platitudes and attitudes, and the number of people adopting servitude in a specific meeting. It operates on many principles like deepening organization hierarchy,  modes of operation range from total internal reflection of words (when speaker starts to meditate in the meeting room or usually sleeps off before completing the sentence), substitution of words with antonyms, thus disrupting any units of conveyable meaning.

5. Blame the Culture Filter: BTC filter operates on instances of not taking personal responsibility for failure and vaguely attributing to a figureless culture. Like “tudes” filter this is also a seeded learning filter. Performance of this filter varies based on initial org conditions, retirement age, hiring and firing volumes, country of origin among other variables.


Stage setting for Conflicts in Innovation Programs

Conflicts are natural and they become nasty only when they are not anticipated. Running innovation programs is no different in setting stage for all forms of conflict among agents. My idea to list some of the stage settings and prepare as a facilitator and go with a plan to move action forward, rather than kill an idea with a potential but in conflict. The categorization is naive but I hope you get a drift of how the stage gets set in different forms.

Selection Conflicts

  1. In larger enterprises key problem is detecting and selecting an innovator and a family of high impact ideas. The selection process if badly designed lead to sponsoring ideas that are not going increase firm’s competitiveness.  This can set stage for considerable conflict and disengagement between selected and the left outs and may result in exits with key information or high potential ideas.
  2. While detection is not an issue in smaller enterprises, a high potential idea can be in direct conflict with ownership status and the desired direction of the sole owner or promoter. If the high potential idea is not sponsored directly or given independence internally, it leads to creation of a competitor in close vicinity with the ideas.
  3. Hiding white elephant projects (i.e. projects that hog both limelight and investments for a long time with some key sponsors but produces nothing more than slide decks and platitudes for the business) within large innovation programs are a common stage for conflict, and it drives away original innovators from signing up into the programs.

Management Conflicts

  1. Innovators are at odds with their immediate supervisors usually, leading to conflict within teams and disengagement from ideas. When innovation programs are envisioned/developed at top management level , it is not fair to  expect the same level of understanding with managers running the program as concerns are at different levels. For the innovator working with such a manager there is conflict with what the top management spoke in a town hall meeting versus what happens on the ground. This conflict generally goes unresolved even when brought up in top management forums, usually results in less than anticipated participation for the entire innovation program.

Strategy  / Process Conflicts

  1. A set strategy in place, inhibits experimentation that are directionally outside of it. This is against innovators who just like to play or experiment. If the experiment succeeds innovators typically want to build further. Specifically tackling organizational administrative systems to get approvals for strategically unaligned ideas is usually tougher. This will create a stage for conflict among weak or dated ideas that are sponsored versus newer or unproven ideas that are left out.  Seeking investment versus running stealth is a choice, until capital needs remain small and avoiding conflicts with processes. Beyond a threshold the need to go through the cumbersome budget and approval process or finding a sponsor, leads to other conflicts.

Head, Hand and Heart for Change

I am not a philosophy major, but I understand the differences between reason, will and desire. In a corporate setting, most published “content type” from top is just plain reasons viz. whys to do something, to approve a budget, to take up a new initiative, an ROI and more such. But the will and desire are left out mostly. When you hear “to lead by example or walk the talk”, it is an indication of will, and when you hear “did not feel like doing it” “ Yes, but…” it is an indication of desire (or the lack of). At this point, we depart from the simple system definition to one in the complex domain as the agents and actions are intertwined. Will and desire (or the lack of) spreads faster and influence actions more than the published reasons. To work only with reason and undermine will and desire is a forceful push from the complex domain to simple domain.

A simple framework for action/change thus in any reasonable sized system should handle all 3 (reason, will and desire). One may be more magnified than the other, and in fact, they should be. When this happens, a series of actions unfolds with no clear attribution possible. These are system responses and agents are playing part. Here is where stories that people tell each other and social objects come in, bringing players from all over the system for action willingly.

A simple metaphor for this framework is the simple head-hand-heart to reason-will-desire respectively. In action/change scenarios, all 3 operate simultaneously, but you can never determine outcomes. If boundary conditions are favorable, outcomes are impactful and always contextual.

Now to orient a bunch of leaders on this head-hand-heart framework is easy, make a list of past failed initiatives like below

  Head/Reason Hand/Will Heart/Desire
Initiative 1 <<Enter biz case/ROI/5W etc>>    
Initiative 2   <<Enter policy change, mobilized support, experiments done etc>>  
Initiative 3     <<Enter social objects, desires tapped, etc>>
Initiative n      

When you fill this up, you will notice that the last column will be the most sparsely filled or even empty.

Coming from an industry that runs on perennial initiative fatigue, I was not surprised when I filled one for myself.

Try it …


5 easy ways to kill an idea

Organizations claim they are open, innovative, smart etc, but unquestionably every organization’s ability to kill an idea easily overtakes the ability to build an idea and deliver value to customers…from what I have seen below are the 5 easy ways to kill ideas with very less action.

1. Delay till all parties forget: Really 2 kinds here, first one is, accept ideas only during a small annual window (typically called jams or camps) or second kind to have the idea submitted in a system and just let it rust or decay there. In case of smaller companies that have not invested in systems this death may very well happen in someone’s Inbox.

2. Ask for details that are already known in a different format and then ask for more: This is common in the so called knowledge intensive industries, where there is a template to submit the idea, with so much detail that by the time you actually finish filling it, someone else has implemented the idea. It manifests as mandatory fields in web forms and also in workflows of the idea itself within the system, if it goes through.

3. Dissent the person, language, package, identity and talk nothing of the idea: Here the idea submitter is typically outside of the knowledge domain, but nevertheless has the urge to give an idea to people in the domain. Submitter gets beaten by jargon, rules, constraints, and other special linguistic tools that each domain has. Usually the submitter never returns after the first conversation. Manifests as status changes in the system with complex comments or as an email response with sentences averaging ~21 words each.

4. Hide the Station Master and his Suggestion Book: Manifestations will be announcements typically sent to media or emailed across a thousand people stating, there has been 100% conversion on ideas/suggestions that came to the station master, while no one has actually see the station master. For those of you familiar with the sub-continent might have seen the notice in all railway stations.

5. Install a large Suggestion box beside the front door and throw away the key: This is the second most common; no one really bothers to open the suggestion box. Manifestations will be usually some static content marketing page stating the organization is open to ideas and may also have some primitive classification of innovations.

There are other ways like making it really hard to form groups in the organization, equate busy to value, equate IP to value, measure performance from yesterday’s hindsight etc among others,

but these are either results of processes in action for a long time or current action.

So still the above 5 are the easiest ways to kill an idea.


Org Vocabulary

All jobs include a vocabulary exercise, be it responding to a prospect need, or writing your appraisal or coming up with a methodology/strategy or just speaking publicly for a change especially KM jobs. What differentiates departments/companies is not their vocabularies but their stories and it takes long time to catch stories from different contexts.

Anyways problems of attrition in my industry gave rise to other problems as people migrated from company to company with their vocabulary.
To such an extent that even slidewares and pitches (to specific egos) across vendors started to sound same. I have heard vendor selectors claiming “that just changing the master layout of your presentation will make it exactly same as what I saw with the last vendor prospect”. I also know of some real stories when people moved from one large vendor to other with their slideware, actually confused these selectors because it was exactly the same “methodology”.

Second of the problem that arises from vocabulary is, for those that stuck around and got older in parent companies without switching. These seniors were stuck with limited stories in a restricted vocabulary/language of the company they are loyal to. That in itself is not the problem, it becomes one if all they have is old stories to make new changes in the enterprise, because nobody feels that story (distant in space, time and intent) and language itself has shifted to something else that these seniors cannot speak.

So sparking action internally or selling to your boss or prospect almost becomes impossible just by changing vocabulary or being stuck with one for too long.

What do you think KM Managers should do? What story should be listened? retold?

books, cognoise

Why is family a bad metaphor for organization?

I have always felt strongly against the use of the family metaphor on organizations for various reasons

  1. Family is not run for profit
  2. Family cares for the weakest most and organizations care least for the weakest
    1. In times of crisis in a family there is lot of sacrifice at the top
  3. In family there are no multiple stake holders with conflicting demands like employee demanding more salary versus investor demanding cost controls, which forces organizations to resort to point 2
  4. Family does not evaluate for performance (can you imagine rating your dad against a benchmark dad or he evaluating you)

You can find apt metaphors/Images of organization elsewhere including  machines, organisms, cultures, brain, psychic prisons, and domination instruments.

Thanks to Venkat from ribbonfarm for the pointer. btw have you read the latest post by Venkat?…


Safe Fail and Fail Safe Roll outs

Safe Fail and Fail Safe concept of the 2 types of experiments or trial runs is not new. I had to make a case to a strong process oriented crowd on adopting a new process and tool for allowing harvested knowledge at an organization level.

 Major portion of the debate that ensued clearly gave a chance to contrast between the 2 types of experiments. I am only taking the roll out part of the whole change (a better word in safe fail types would be adoption).

 For Fail Safe roll outs

  1. A business case that proves or claims that a change would happen on a stated benefit which is along either commercial or satisfaction value
  2. Once the business case is all clear there would be a pilot on a smaller (claimed representative) chunk of selected projects and disproportionate effort goes into making the business case a reality
  3. Now proving the benefit means you have a fixed boundary on the initial state and a new end state that has happened due to the change/experiment. Of course this will include non accounting for reasons that possibly worked in favor (that statement reflects the fact that I just finished reading “Fooled by Randomness”)
  4. Provided the sample set results are satisfactory the change is rolled out to larger set of people whose contexts are generally not clearly understood, and the effort that was put into the pilot is surely not replicated at this new large scale
  5. Post this usually benefit measuring exercise is conducted and published as is or there may be a change in parameters of what is measured as scale has changed

 On the other hand Safe Fails

  1. Do not have a “business case” as the outcome is usually not clear when begun
  2. The pilots are usually not chosen or selected but are rather like drug trials are volunteers
  3. Boundary states are not necessarily fixed and coupled with outcome not being clear
  4. Larger scales is possibly an indication of the success of the change/experiment itself, but really speaking the success comes from the number of such experiments that Safe Fail type allows that will work in context.
  5. This point is not applicable as usually there is ignorance of how the change will adapt and work.

KM and Job Titles

The problem with KM is it is too intangible to define and fit in an org structure.
For example you can say
1. KM’s job is to make people smarter
2. KM’s job is to enable more meaningful conversations across a company
3. KM’s job is to generate good connections from which good conversations/knowledge flow

Each of these can never be put into a job description nor can competency frameworks be designed for above. What in turn happens is we start to fit in with generic descriptions for K Managers, Consultants, Facilitators, Directors etc.

Question is even if you do away with the central structure the few thinkers left in the system would enable all above and more without ever knowing or calling it KM.
If you as a KM Practitioner disagree with the responsibility tell me why it cannot be KM responsibility and what other thing would be a responsibility under KM.

Thanks to enlightened tradition for sparking the thought