cognoise

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…

Advertisements
Standard
metaidea

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

Standard
f.art

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.

Standard
metaidea

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.
Standard
cognoise

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 …

Standard
metaidea

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.

Standard
cognoise

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?

Standard