Category Archives: Project Management

How do design and build an organization for success?

In-flight magazines and management bestsellers are all full of ideas and opinions on how to build an organization for long-lasting success. Best-selling authors and management gurus have made a handsome career talking and coaching about things that seem like universal panacea for just about any kind of organization. Unfortunately, in modern times, it is dangerous, even suicidal, to put your professional reputation at stake by calling out such fantastic organizations that achieve (or are preordained to achieve) such long-lasting success – whatever that means! What was once a hopeless laggard might unexpectedly hit a jackpot and become a smashing success tomorrow, and what is flying high today might suddenly get birdstruck and be biting the dust tomorrow. There are no one-size-fit-all prescription that fit all kinds of organizations, what we have don’t come with a good user manual, and most certainly none of them come with a thirty-day no-questions-asked full-refund policy! So, how does one go about doing exactly that – design and build and organization for long-lasting success?

In my experience, there are three critical elements that need to be present in ‘interlocking proportions’ for any organization to truly achieve a sustainable long-term success. When I say ‘interlocking proportions’ I am implying two key things – one that there must be a natural and mutually complementary fit among all the components, and secondly these components are in such measure that they complement, ideally amplify, each other, rather than canceling out one component at the cost of other component.

For example, we might have a developed a great car that delivers 100 MPG fuel efficiency, but then it compromises on the road safety aspects, or if the safety standards are left uncompromised, than the passenger comfort leaves much to be desired. iPhone5 might be a great mobile device (a highly subjective statement, based on what camp you come from!) but its battery life sucks. In a way, this is similar to “integrative thinking” – Roger Martin’s term for human brain’s ability “to hold two conflicting ideas in constructive tension“. However, it might be (reasonably) easy to visualize integrative thinking in the context of steady-state, but how does one keep constantly rebalancing them as the system goes from one change to another, never perhaps settling on a transient steady-state long enough?

 

Success doesn't follow a straight line

Success doesn’t follow a straight line

In the context of organizations, what is means is that as the team grows from a startup into its next phase of growth and eventually into a larger organization, these components also need to commensurately grow in tandem. I have seen this being the biggest bane of many growth-phase companies – they forget what once made them successful might be impeding their further growth because those policies, procedures or practices might not make the same sense anymore. Today’s solutions are indeed tomorrow’s problems.  Unfortunately, success is blinding and the one that comes along with light flashes and glossy pictures is even more so! So, the approach and methods that led to the initial success become so sacrosanct that under no circumstances are we willing to question them, let alone adapt them. They become holy cows, and often after  few repetitions, get set in stone. As a result, while the body has grown up, the mind is still taking the low aim. The result is friction in the system, leading to turf wars among otherwise well-meaning peers, eventually leading to poor performance in the system. This might manifest in lack of rapid innovation, or bloated organizations, delays in decision making, poor customer service – just about anything.

What is the solution? Assuming that if someone has come this far, then they probably have the fundamentals in place – stuff like right talent, leadership, and strategy. However over and above these hygiene factors, I believe these three core factors that must be present in interlocking proportions at any stage of the organization:

Efficiency

An organization thrives on its ability to make optimum usage of its shared, and usually scarce, resources. In a typical startup, the demand far outstrips supply of any kind of resources – be it real estate, computing resources, marketing dollars or even the people, and hence preserving the burn rate is a critical measure of efficiency, at least till the revenues have started kicking in. But the startup team often has a vision far more compelling than those ‘large-company perks’ that are nowhere to be seen and can only be read about in those glossy magazines – business class travel, corner offices, club memberships, reserved parking lots and exec admins for senior folks, and cool stuff like free gourmet food, free office transport, generous health benefits, corporate iPhone, office gym and TGIF parties for the lesser mortals. 

So, these startups figure out a hungry, lean and mean organization structure where pretty much everyone operates as a multi-skilled expert, and wisdom of crowds is often the best way to find smart solutions to nasty problems quickly. Founders are often the decision-makers, partly because they are the subject matter experts and partly because that’s the way they want it to be. The process works very well for the initial ten- or even twenty-people startup.

Over time, unfortunately(!), success happens and it brings growth as a bye-product. Anyone who had driven a car knows that you need to keep changing gears as you get on a gradient and as you pick up speed. However, our startup team often doesn’t want to give up control, and hence continues to stay involved in all those day-to-day discussions and decisions. Over time, it creates self-inflicted inefficiencies of scale – new players don’t know their  property rights, and whether they are empowered to make those decisions, and hence they push it up for decisions, but since the guys at top are getting totally backlogged with so many things that they should have ideally delegated, they create avoidable delays, not to mention an organization that feels disempowered to act without adult supervision.

Clearly, as the company grows to a growth stage, there is need to redraw the boxes and arrows and constantly keep looking for opportunities to delegate and create leadership and accountability at each of these levels rather than keeping them all centralized. By decentralizing, I don’t mean abdicating the responsibilities but making sure everyone on the team has a fair opportunity to be a ‘part of it’ rather than simply being a bystander.

One more important but invisible and hence ill-understood connotation of efficiency is culture. If people are doing the right thing as per the organizational policies and procedures, then it is a good culture of ownership and compliance (some might agree if ‘compliance’ is still a good idea, but let’s suspend that judgment for now). However, if people are not doing the right thing because their organizational policies and procedures don’t explicitly let them take such initiatives even if they are on a burning platform, then such culture is fundamentally inefficient, even dysfunctional. So, the notion of efficiency shouldn’t be seen only in the context of how well a process uses time and resources to product its intended output, but should holistically factor-in people aspects as well.

Innovation

The lure of the geese that lays golden eggs is so tempting, it clouds our ability to think next and take any amount of risks to find if the geese could do any better? No one wants to mess with products that are performing well in the field – sales doesn’t want disruptive changes that customers might not like, and in the age of quarterly guidance and micro-scrutiny, no one wants to stick their neck out and signup for a mission impossible project. As a result, new initiatives are never bold big bets, but end up being mostly cosmetic and ‘wall-street-safe’ initiatives that won’t kill the company (and the execs behind it!) if something were to backfire. Business books are littered with real-life case studies of such thinking that killed long-term disruptive innovation in favor of preserving short-term revenue thinking. Sony was so successful with its Trinitron technology that it never felt a threat from the newer flat TV technology, and as a result, lost out to newer and more nimble players (even though it managed to catch up with its Bravia series later). Similarly, Nokia’s success in a largely monopolistic and virtually unchallenged market led to it saying no to micro-trends in some of its ‘non-sexy’ markets, like China and India.

Many people confuse efficiency with speed or a maniacal focus on cost-optimization. Speed at any cost is an indicator of extremely myopic thinking that might lead to some nice results in the short-term, but is almost always guaranteed to misfire in the long run. Similarly, cost optimization (more crudely, cost cutting) is often used by organizations to hide or cover up years of neglect and mismanagement and please investors by firing innocent people who are more often than not, hapless victims of the very same policies themselves. I was recently reading that Infosys’ new (old?) chairman says it will take 36 months to stabilize or rejuvenate Infosys. How did a company built on such strong ethos and management, and which had strong of co-funders providing stable leadership suddenly find itself needing such a long lifeline? The rot that needs 36 months to clean-up couldn’t have happened overnight, could it? Perhaps playing it too safe turned out to be risky after all! Had Gerstner believed in playing safe, he perhaps would have never got the elephant to dance.

Key is to believe that innovation is not just a great thing to do in these modern times – it is already downgraded to being a bare necessity. What was great yesterday is not great enough today and most certainly won’t even be good by tomorrow. Your competition is outsprinting you, your investors are expecting that you can deliver better returns on their investments than the competition, and your employees expect to have a rewarding career with you and not do some derivative work.

Did you say innovation was all gas?

Scale

In today’s world, scaling up is not an available option. If you are successful by any means, your investors, employees and customers (and you too!) will want to scale up – be it the little florist round the corner serving its neighborhood and known for excellent customer service,  or the software company that is able to offer innovative solutions to its customers twelve time zones away. In fact, refusal to scale up might eventually bring about your downfall.

However, the same agility and frugality that led to the initial success now stands firmly in the way to scaling up. If you are the supertechie founder-CEO who designed and developed the award-winning product, you probably were there at each step of the product development and your diligent involvement and ownership ensured such phenomenal success. Now imagine you have a team in another part of the world who owns another part of the complex software. How do you expect them to make technical decisions – should they keep calling you all the time (in the middle of your night?) or wait for you to get to office and reply to each of your mails? If you are the customer-facing founder-CEO who insists on being involved in all deals, how will your sales team make any serious progress if your presence starts becoming the rate-limiting step to their process?

I think scaling up is perhaps the most complex of these three pillars because it requires the founders and early-stage managers to accept an inevitable fact of life – that they alone can’t take the company to the next logical stage of its growth, and now must hire and depend on professional managers to help them achieve that. It also forces some of the tech-happy founders to become managers, thus making it extremely difficult, if not totally impossible, to write code or do some other technical stuff they enjoy doing (and was perhaps the reason in the first place they left their cushy corporate job to start a tech company). One of the reasons companies like Coca Cola, Pepsi, McDonalds and Pizza Hut have been so successful is because they figured out a model to scale up globally – despite having a heavy dependence on virtually all perishable raw materials to be sourced locally (and hence creating a wide variance in assuring quality). When Toyota developed Lean Production System, it was widely felt that Lean could not be replicated outside Japan. However, the success at NUMMI changed it all – and established beyond doubt that Lean was, after all, scaleable outside Japan.

A few years back, an independent portrait photographer from Pune came to Bangalore to set up his studio. He was a reasonably big name in Pune but struggled to establish himself in Bangalore. He wasn’t able to establish connections with the market of Bangalore, and as a result, packed up and headed back home after suffering losses after three months. I know this because we got a lovely family portrait done from him, before he moved back. Clearly, he did not have a process to scale up his operations to another city. So, what applied to large companies also applied very well to solopreuners too.

Conclusion

So, where does it all lead to? While there are probably hundreds of variable that need to be tuned properly for an organization to smoothly and successfully grow on a sustainable basis, obviously not all are critically important and  hence one needs to focus on only a few key ones. In my experience, Execution, Innovation and Scaling up top the list. And more important than which factors does one consider, it is more important to recognize that these factors are needed in ‘interlocking proportions’ and lest we create a lop-sided organization that falls apart sooner than later because even though its engines made it run at 2x, its wheels were not strong enough to support traveling at such high speeds, or its braking system was not advanced enough to control such high power. In the end, people don’t buy cars because one of the experiences is better than others – they buy it for holistic experience. Such holistic experience is not an accidental outcome – it happens when the company’s foundations are created holistically.

How do design and build an organization for success?

Does your process help you preserve status quo, or deliver some kick-ass skunk works?

Problem-solving in the past has been dominated by methods involving rigorous and meticulous planning and flawless execution – something that has been questioned, largely by results (or rather the absence of it) in the recent years, if that is (still) the best approach when there are so many moving parts and the external world changes in a blink. We frequently ‘blame’ old practices of assembly plant-style waterfall days where it took years to get a project team to jump multiple hoops and just get a project done – in most cases, hopelessly delayed, unacceptable quality and overbudget. Building process frameworks was once thought to be the panacea for all these maladies, especially in mid- to late-nineties, as we say with a series of processes – CMM, ISO, BPR, and so on… And thus, birth of agile movement came as a big relief and promise to speed and improve things up a bit. The idea of starting out with just enough requirements and iterating along with way had an intuitive appeal in this VUCA world, where no one had complete information nor all the time to wait for that perfect moment of epiphany – because that epiphany was a moving target in reality. With more efforts to design a solution, we learnt a bit more about the problem and this became an unending spiral – which was not necessarily a bad thing, but the gated processes didn’t provide much guidance on how to address it effectively. Clearly, we needed nimble processes that allowed for more iterative development without making too much commitment upfront, especially that couldn’t be easily changed downstream, and a matching sociological process that allowed teams to build unconditional levels of trust among themselves that stimulated collaboration and made them operate at the speed of light. Many of these ideas have emerged from multiple disciplines such as software development, behavioral psychology, team dynamics, systems thinking and leadership, just to name a few, in the last ten to fifteen years, and have led to statistically significant successes in several domains. However, as we are learning, some of these practices have been around for decades – just that we haven’t ‘discovered’ them just yet. I just found out one such great example this weekend – the Skunk Works. Wikipedia defines it as blow:

skunkworks project is one typically developed by a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation.[1] Everett Rogers defines skunkworks as follows: “[It] is an especially enriched environment that is intended to help a small group of individuals design a new idea by escaping routine organizational procedures. The R&D workers in a skunkworks are usually highly selected, given special resources, and work on a crash basis to create an innovation.” [2]

Clearly, developing skunk works is not a business as usual approach. It is a special quarantined environment created for the sole purpose to incubate a radically new idea under special conditions that catalyze teamwork and collaboration and accelerate innovation. Another definition describes it as:

A skunkworks (also known as Skunk Works) is a small group of people who work on a project in an unconventional way. The group’s purpose is to develop something quickly with minimal management constraints. Skunkworks are often used to initially roll out a product or service that thereafter will be developed according to usual business processes.

However, there is more to Skunk Works than this. Starting out in 1943, Skunk Works at Lockheed owes its foundation to a mantra of “quick, quiet and quality” that still continues after seventy years. The first project, XP-80 Shooting Star jet fighter was designed and built in only 143 days – seven days less than required and without any contract or an official submittal process! The formal contract for XP-80 did not arrive at Lockheed until Oct 16, 1943; four months after the work had already b

What is your skunk works process?

What is your skunk works process?

egun! However, when we look at its operational record, it was delayed – it was pressed into service only towards the end of WWII – something that clearly didn’t meet its original objective. There were many accidents, and several ace test pilots were killed on the test flights. Given that there were several innovation on this ‘product’ there seems to be a strong flavor of fail fast, fail cheap and keep iterating – even though the loss of human lives seems to be tragic and perhaps avoidable in some cases. However, this blog post is more about the underlying process and associated principles that led to such innovation in the first place. Upon reading further, I was impressed by its founder, Clarence “Kelly” L Johnson, who started it all. He broke the rules, challenging the then bureaucratic system that stifled innovation and hindered progress. I think these rules have never been so important ever before… Kelly’s 14 Rules and Practices Kelly wrote down these 14 rules that led to the successful culture of innovation at Skunk Works at Lockheed. Let’s study them and understand their context in today’s workplace, and if our practices address them effectively:

1. The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.

There must be a clear-cut responsibility, ownership and accountability lest there be diffusion of responsibility leading to confusion, chaos and associated symptoms of delays and poor quality. As much as we need self-organizing teams with democratic decision-making process, we still need to have a clearly defined ownership – someone who is tasked with breaking all rules to get the job done! Agile teams make the team responsible for delivering to its commitments, and agile thought process doesn’t generally support the notion of a ‘manager’ but a product owner is still responsible for eventual success of the product. Yes, the notion of what constitues work for a manager will keep changing with the times, but in some shape or form, I believe there has to be a sense of final responsibility for the outcome.

2. Strong but small project offices must be provided both by the military and industry.

There is no denying the importance of reducing management and administrative overheads but making them more effective. Bloated models that create large hierarchies are on a wane, and new-age program management is all about leadership by influence rather than using positional power to get the job done. Scrum takes a leaf from servent leadership to describe the role of scrummaster,  which is a significant departure from having a manager with positional power to get the job done.

3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).

More than the ability to actually work with small teams is the recognition that having a small team is much more productive and effective compared to the “so-called normal systems”. Of course, not all problems can be solved by having small teams, especially if one is looking to complete them faster than the competition, but one needs to weigh-in all the factors, but definitely in favor of small teams. Agile makes a strong case for small teams.

4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.

This sees like making big commitments upfront is being deemphasized. This principle sounds very simple to what Lean Construction Institute, several decades later enunciated when it said, “…design decisions will be deferred until the last responsible moment if doing so offers an opportunity to increase customer value.” Agile thinking is very much aligned to avoid making heavyweight commitments upstream, especially when there is a heavy cost of change them later, and given the rapid pace of changes around us, it is certainly not a hypothetical and extremely rare situation for which we are delaying making the decision.

5. There must be a minimum number of reports required, but important work must be recorded thoroughly.

It’s so funny to imagine that in the era of typewriters too, they were sick of reports! I think there is nothing that can justify having a disproportionate number of reports under any circumstances. The old thinking was to increase the micromanagement when in crisis, or even otherwise (I fondly remember a General Manager in at an old job who would come to our cubicle every hour and check the status update on ‘design document’!). I think asking for a number of reports smacks of Theory X, where the underlying assumption is that unless you make people work, they won’t take initiative and most certainly won’t assume responsibility. So, the hierarchy gets created simply for asking for more frequent status updates, and since the higher levels wield considerable power in deciding renumeration and career progression for the ‘lowly underlings’, who do you think wins in the end? Certainly not the project, I guess!

6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.

I see no reason this doesn’t apply in any possible context. Any sponsor needs to know how is the team doing. The team owes it back to their stakeholders, management and customers to keep them posted of what is keeping them busy, and when are they likely to be finally done. When I look at agile thought movement, there was an almost anti-establishment feeling that was so palpable in numerous views on dozens of discussion forums, that it is not a surprise that agile didn’t find too many favors with ‘management’. I don’t think it is called prudent wisdom to take money from a project sponsor and tell them they are ‘chickens’ :). Thankfully, I see more maturity among agile thought leaders today, and any level of project team owes it to keep their first-level of ‘customers’ engaged through the development phase.

7. The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.

There was a time when people outsourced to save a few dollars. Not anymore. With such tight integration of your suppliers in your value chain, it is not about cost anymore – they need to have much more than their skin in the game. A strategic project can’t afford to have relationships that seldom go beyond conventional commercial considerations. Perhaps the best-known example is how Toyota treats its suppliers – “…we believe in developing mutually beneficial, long-term relationships based on mutual trust. To foster that trust, we pursue close and wide-ranging communication with suppliers.” and “…We at Toyota rely on outside suppliers for most of the parts and materials in the vehicles we make. Every step in making Toyotas, from development to production, consists of joint work with suppliers. The suppliers we seek are companies that have the will and the ability to become active partners with us. We are looking for suppliers who possess world-class competitiveness in terms of qualitycostdelivery, and technological capabilities.“. I don’t believe without such strong win-win mindset, a company can succeed in achieving the agility required to compete at big game.

8. The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don’t duplicate so much inspection.

Inspection is essentially a waste. Deming was vociferous in his views on this “Principle#3Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.”.  Clearly, there is no way we are ever going to completely do away with any form of inspections – there are far too many normal and special variations in any process to be able to run subsequent part of the process in autopilot. However, a more conscious effect to eliminate duplicacy in inspections not only improve the value stream but also fosters the culture of trust and interdependence among all players which can eventually help everyone run faster rather.

9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles.

If you can test components of an aircraft in initial stages, what stops you from doing the same for, say, software? Some of the biggest opposition to early testing comes from enterprise software and from software platforms – that they can’t possibly test half-baked functionality? However, nothing could be further from truth. If we are not testing product and its components early enough, we are accumulating significant risks downstream that can force untold miseries during the big-bang integration. I don’t think anyone disputes it seriously today.

10. The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.

I think there is nothing wrong with this idea. However, there is a presumption of technological stability that doesn’t hold so well anymore. The pace at which newer technology gets productized is unprecedented, and one can’t sit comfortably having zeroed-into the hardware platform at the start of the project. However, there are surely classes of problems where for regulatory reasons, the technology cycles are much longer, and hence it makes sense to be cognizant of them. However, the advise is generic enough to be universally applicable for all class of problems.

11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.

Simply put, if you don’t pay your suppliers on-time, they will have less motivation to work on innovating the next big thing and more to worry about how to pay salaries to their staff! Perhaps this was a big deal in early 40s that Kelly has to write it down! However, lack of funds can surely cripple or kill a project and hence enough care must be exercised, commensurate to the project size and impact, that ensures this is not on critical path. 

12. There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

Again, Deming has some useful advise here too “Principle #4End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.“.  While one can debate if having one single supplier is a wise thing to do, there is no doubt that one needs to build a long-term relationship on a foundation of loyalty and trust. A relationship on short-term commercial interests might hold critical projects to ransom in times of crisis, and control or coercion might  backfire. However, trust will almost always be reciprocated with accountability.

13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.

This might be more relevant in military, but in true innovation projects where a mere whiff of what are the designers thinking is likely to be significant competitive intelligence in the hands of competitors, a sense of maintaining right amount of secrecy is not unusual. Apple is well-known to maintain absolute secrecy about its new products, and goes to any lengths to protect its competitive advantage. I also think it is not just about the secrecy due to competitive reasons, a little bit of ‘confidentiality’ might actually increase the amount of buy-in from team members and make them more ‘possessive’ about their work, making them all come together. However, it’s clearly a double-edged sword, and one must choose what works for them.

14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.

I think Kelly was either a battle-scarred veteran of performance appraisal systems (back then!) or a visionary to be able to call a spade a spade! Perhaps the conventional systems at that time rewarded people for the number of personnel supervised, which might have no bearing on ability to innovate or deliver performance. This might even be his pet peeve, because in an earlier principle, Kelly has called for smaller teams, and here he is asking for rewards to be performance-based and not based on the team size. As we have seen in last few decades, power-hungry managers have only worked towards building large self-serving empires with no relation to the nature of work. In the end, such pyramid structures has become just that pyramid-shaped ponzi schemes. However, today’s social norms and professional values don’t support such stone-age thinking, and hence, this is only a gentle reminder to today’s managers. However, it must have been very profound at the time Kelly jotted this down. While reading these 14 principles, I couldn’t help but admire the genius of the man behind it – Kelly was not only on the top of his game, he was willing to literally fight the establishment to get his job done. If he perceived his process as stifling innovation, he was willing to talk about it, and make necessary changes commensurate to what was expected of him. A lot of people take refuge under and behind the process frameworks without thinking if it meets their needs. The thought process is that you buy a certain level of performance with established processes, and hence if you fail, it must be due to the process and not entirely because of you. This gets aggravated in organizations that apportion praise on the process and management, and failure on the managers and the individuals. As a result, people stop sticking their necks out, and instead choose the trudge along the status quo. But think about it – are you paid to preserve status quo, or to push the thinking, bring about changes, break some china…in short, deliver some skunk works… So, does your process help you preserve status quo, or deliver some kick-ass skunk works?

How do you manage intercultural issues in your teams?

I recently had the good fortune to fly in from Doha to Dubai in a Dreamliner, and later again from Bangalore to Delhi – before they got grounded following a safety advisory. No doubt, it is a marvel of engineering excellence, and I am sure they will figure out battery problems sooner than later.

However, while reading this article “From the Start, Dreamliner jet program was doomed”, I could not help express surprise over some of the issues discussed. While some of the issues reflect a very high-end of engineering being tried out for the first time, and hence some teething troubles could be expected that could be solved by engineering, some other relate to the human aspects, surely not happening for the first time, which perhaps trumped several other issues:

It seemed like the Italians only worked three days a week. They were always on vacation. And the Japanese, they worked six days a week,” said Jack Al-Kahwati, a former Boeing structural weight engineer.

Even simple conversations between Boeing employees and those from the suppliers working in-house in Everett weren’t so simple. Because of government regulations controlling the export of defense-related technology, any talks with international suppliers had to take place in designated conference rooms. Each country had its own, separate space for conversations.

There were also deep fears, especially among veteran Boeing workers, that “we were giving up all of our trade secrets to the Japanese and that they would be our competition in 10 years,” Al-Kahwati said.

None of these are new issues to any student of inter-cultural issues, especially in project management, but what is surprising is that for a program of that strategic importance and such magnitude, these issues were ignored and they eventually came back to bite.

Distributed and virtual teams are a reality of today’s world. It is not just limited to well-heeled MNCs – we see countless everyday examples of such teams with NGOs, startups, voluntary efforts, college project and so on. There is more to working with people from different time zones and cultural contexts than we realize. Problem is, most of us haven’t been exposed to, or adequately trained to handle such diverse teams – not just as a manager but even as a team member. As a result, when there is a need to work with distributed teams, we tend to curl up in our cocoons and shun working with them. It could be due to excessive paranoia due to job insecurity, or it could be due to prejudiced mindset about folks who are ‘out of sight’, especially at a low-cost destination. Sometimes, it might simply be due to sheer laziness. I have once been in a situation where a VP based out of company headquarters wanted to only work with people within his ‘line of sight’ – he hated getting on emails, hardly ever responded to them, and his preferred style was chatting in hallways or at cubicles. Sounds familiar? However effective this strategy might be for his immediate team within a shouting distance, this would lead to his remote teams feeling disenchanted. You might be a great leader, but remember – managing remote teams is also part of your success!

Panel discussion on "Intercultural Issues in Project Management" at Grace Hopper Conference, India, 2012In Dec, I had the opportunity to participate in an interesting discussion at the Grace Hopper Conference, India on “Cultural Intelligence in Project Management”. We discussed some of the personal experiences of a very diverse and highly experienced panel. Some of these experiences ranged from Bangladesh to China, Japan to Israel, and US to Europe and so on.

One of the points I shared was about how to manage inter-cultural teams. This is a big topic and we can spend a day on it and still don’t get it right! In my experience, there is a process that I have developed and refined that works well. Here is how it goes:

  1. Be aware of the intercultural differences – don’t paint everyone with the same broad brush. This is especially important for ‘foreigners’ in your team lest they start considering them as ‘aliens’ in the team! To me, recognition of such differences means respect and that itself is such a motivation for everyone to feel welcomed in a diverse group. In a Chinese company I once worked for, it was common for everyone to be in office till 9pm everyday, 6 days a week, even if there was no work that demanded people to stay back. Meetings would be setup at 5pm and go on until 9pm and beyond. While this was ok for many of the Chinese folks as they were ‘foreigners’ to Bangalore and had nothing better to do in evenings than work at office, this was not so ok for many Indian engineers who had a family. While no one minds occasionally staying staying for work exigencies but everyday was a drain. In that high-performing culture, leaving early for home would be seen as a sign of lesser commitment and effort. While things did eventually get better (at least in my team because I summarily rejected such outrageous ways of ‘measuring’ performance of an individual), it took some time and great efforts to make people realise their intercultural differences that we have grown so subconsciously used to.
  2. Creating common norms – Instead of forcing one set of people to change to another set of people’s preferred way of working, it is much better to arrive at a common way of working, even if that is not the most efficient way of working. Ideally, let the team evolve such norms so that there is a higher buy-in for those common standards of mutual behavior. This will demonstrate tremendous respect for individuals and encourage them to participate in team proceedings that will go a long way in building their individual buy-in and a team camarederie that will set the team on a high-performance trajectory. More than once in my career, I have been involved with diverse teams where simple things like how fast an email should be responded to has been subject of intense debate. We all have different ways to answer them. Some would take the old analogy of a telephone call – just like someone who is physically present is more important than the one calling on phone at their leisure, why should someone sending an email become a priority for me? On the other hand, there are folks who would want to respond to emails within a hour if not minutes! So, what is the best way? Clearly not making everyone answer the mails in one hour, I hope! Let the team discuss this issue and let them come out with common norms such as 24hrs or 48hrs based on what is important for the business. As manager, step in only when you think teams are setting the bar too low, and then also, step in not to dictate your preferred ‘norm’ but to clarify the objectives and provide supporting data and steer the conversation towards why it is important to meet those objectives – teams are smart, they will figure out the rest. For example, if time tracking is a project requirement (either for tracking project effort or for billing the client, or for any other reason), and given people’s propensity to either avoid it completely or do very meticulous time tracking, then it might be a good idea to also identify a common tool, such as a time and attendance software, that makes sure everyone is on the same page. 
  3. Exploit intercultural strengths based on individual strengths – the idea is not to make a rabbit fly or to make a bird swim, but find out who is naturally adept at certain strengths and match their tasks to their strengths. As managers, we don’t want to be parents to the team members, and there is no point ‘forcing’ them to change them to do thing that they don’t relate to (unless of course, that is jeopardizing project objectives). Instead of doing a command and control style management of allocating tasks, managers should walk a few extra steps and undertand what motivates their team members, and if possible, assign them that work. In most cases, that might be a strength they already posses, and in some cases, it might a skill they aspire to possess and might not be the best candidate for it. However, if they can demonstrate that they have taken steps to match their desire to improve their capability in that subject, then as managers, we owe it to them to give them a fair chance. Assigning a mentor as they take up a new task might also be helpful. I once had a great team member who was majorly motivated by helping everyone on the team. Almost each evening as people were winding up their work, he would go to them and chat up with them on their problems and offer voluntary help to stay late and fix it. He would do it in such unintimidating and affable manner that other team members loved it (and I can’t recollect anyone misusing that gesture of benevolence, in case you are wondering). As his manager, the only thing I was supposed to do was just to stay out of the way and cheer him up! He was clearly driven by his own deep passion for the product that we were working on.
  4. Broadbase core strengths – finally, once the team has come to the point where people don’t feel intimated or vulnerable due to their shortcomings but rather feel appreciated for their strengths, it will be much easier to cross-pollinate those strengths among the team members. Since everyone is a mentor and everyone is a ‘mentee’ to someone else at this point, chances are that this won’t create adversarial relations among the team members, but actually stimulate a culture of mutual respect and learning. For example, someone might be an expert with a technology and another team member is great at planning. Once there is a feeling of mutual respect, it will be much easier to make them seek each other’s expertize in furthering their own knowledge.

This four-step process has served me well in multiple scenarios. There is nothing rocket science about it, rather it is based on simple laws of respect to everyone, and that’s why it works. And to me, intercultural is just that – a matter of respecting people for what they are rather than ignoring or ridiculing them for what they are not. After all, we are all perfectly imperfect and similarly different!

How do you manage intercultural issues in your teams?

Does Agile Kill Innovation?

I will be moderating a panel discussion on this topic at the Agile India 2013. Given the incessant pace of technology evolution, ever-growing competition where product functionality is hardly the differentiator anymore (if it ever was!), shrinking time-to-market expectations where ‘continuous deployment‘ seems to have been relegated to a hygiene factor already, there are clearly two major trends in product development. While development teams are focusing on using principles from agile, lean, kanban and lean startup to tackle risks and uncertainties earlier in the lifecycle and deliver working software to improve customer collaboration from the word go, the business are looking at complex world, more popularly known as the ‘VUCA’ world – Volatile, Complex, Uncertain and Ambiguous, where making big bets seems fraught with risks of untold magnitude (not to mention, the additional pressures of quarterly earnings calls, at least for public companies), and ironically, the other option of incremental innovation seems to be simply not a fit candidate for the ‘next big thing’.


Agile India 2013So, is agile just that much – a set of powerful methods to simply improve the development efficiency without being able to answer the fundamental questions from the business that funds it and expects to get a topline ROI? Or, should the businesses start looking out at next big thing on their own? Are ‘agile’ and ‘innovation’ the long-lost cousins who are destined to meet somewhere sometime, or are they at a fundamental conflict with each other, and we have simply created a new two-axis ‘project triangle‘ – where you could choose just one of these two?

Agile practices are sometimes considered an ‘overhead’ by product teams that are used to a more free-wheeling culture of innovation, and sometimes considered too ‘lightweight’ for developing large enterprise-class products that require high availability or reliability requirements to be rigorously baked into the product. Similarly, for companies that manage outsourced application development and product maintenance work, the notion of delivery reliability and predictability is paramount from their customer’s perspective, and hence leaves little scope for innovating service delivery processes. On the other hand, we do have examples of application of agile, lean and lean startup practices leading to highly successful innovation, especially in web-based startups.

So, is it a right hypothesis that agile kills innovation, or are there critical success factors that we could learn from? Is it possible to tailor agile methods to accelerate innovation in different domains? Can services companies innovate their service offerings using agile practices and create win-win proposition for their customers and themselves?

Can agile and innovation co-exist and co-deliver?

I think the time is ripe for such a conversation.

In this session, we will explore this question with experts, practitioners and business leaders, and try to understand what, why and how it has worked for them?

Do you have ideas, anecdotes or success stories to share on this subject? Share them here, and I will be happy to refer to them at the panel discussion.

How are you managing your talent?

In recent times, performance appraisal has been a subject of intense ideological debates. Performance appraisals have traditionally served as a mechanism to basically assess an individual’s performance in the previous year to reward employees in terms of compensation and career progression in the coming year. On one hand, organizations, at least the reasonably larger ones, need some systematic and transparent way to deal with employee’s performance evaluation. On the other hand, with more part-time and virtual employees entering the workforce on a very mission-based engagement as opposed to building a long-term career, the whole idea of formal performance management systems seems to be rather backdated. So, what’s the real deal?

The discipline of performance management has been relatively recent, and rather controversial. Taylor pioneered the subject with his famous Time and Motion studies that highlighted the notion of individual worker productivity, and demonstrated, rather successfully, how application of scientific management could be used to tremendously improve such productivity without exhausting or shortchanging the worker. His thoughts on The Principles of Scientific Management are a great peek into the social system and division of responsibilities between management and workers at American workplace at that time, and should be considered as just that – a journey in time where human society was coming together for the very first time to engage in large-scale machine-based manufacturing, and the theories and practices were still very raw and constantly evolving. 

talentHe criticized that the ‘best system’ at that time, the so-called ‘initiative and incentive’ management was really not the best because it relied completely on the workman, and, in turn, made management unconditionally responsible for this. His fourth principle states – “There is an almost equal division of the work and the responsibility between the management and the workmen. The management take over all work for which they are better fitted than the workmen, while in the past almost all of the work and the greater part of the responsibility were thrown upon the men”.  He further writes – “It is this combination of the initiative of the workmen, coupled with the new types of work done by the management, that makes scientific management so much more efficient than the old plan”.  While I believe Taylor’s intent must have been to apportion the accountability to the one best-suited to influence and ultimately achieve the results, thereby protecting the innocent workers for collective outputs beyond their scope of control or influence, I think this has also led to some serious long-term challenges. However, in an unfortunate way, in one sweeping shot, Taylor condemned an entire generation of workers to subservience by keeping them outside the decision-making process, which subsequently rose on to become an elite preserve of the new management class. This further championed the era of Fordism where ‘division of labor’ and moving assembly line lead to unprecedented growth in productivity, faster production times and worker wages, but also led to lower skill requirement from the workers. Here’s an interesting piece on this counterintuitive thinking from Henry Ford and Innovation, which was a marvel at that time, and literally led to creation of an America middle class and a culture of mass consumption:

“Ford’s $5 day is often cited as a key factor in expanding the middle class. But less often understood is just how that happened. The $5 day did more than simply increase wages. It reversed the historical relationship between wages and skill.

Throughout history, the way for workers to increase the price they demanded for their services was to increase their skill level. The master craftsman always made more money than the journeyman. Conversely, the way for an employer to lower labor costs was to lower the skill required to do the work. For example, mechanization in the textile industry and the shoe industry lowered the skill level required to spin yarn and make shoes, and lowered the value of the labor of the workers in question. But the $5 day turned that relationship on its head by creating something the world had never seen before: the low-skill/high-wage job. Suddenly high-wage jobs were available to large numbers of people who could never have had them before, especially people from rural areas and from foreign countries. The Georgia sharecropper and the Polish peasant both found in Detroit or other industrial cities the opportunity to make a good living despite their lack of industrial skills. Unfortunately, this process led to a devaluing of education on the part of many workers and their children. Why do I need an education, they asked, to work on the line? A willingness to work, not a high school diploma, is all that is required.”

Taylor’s work in 1911 also had significant impact on industrial management theories and practices at that time, and was subsequently built-upon by the pioneering industrial psychologist Walter Dill Scott in his ‘man to man scale’ in 1923. Scott’s work, especially for the army had major influence on how performance is evaluated, and even compared among workers.

In subsequent years, the great management guru Drucker felt there was a need to have a system to assign goals lest managers lost sight due to the so-called ‘activity trap’ of being immersed in fighting daily battles. Drucker introduced the idea of Management by Objectives, or MBO in 1955, which “… is participative goal setting, choosing course of actions and decision making. An important part of the MBO is the measurement and the comparison of the employee’s actual performance with the standards set. Ideally, when employees themselves have been involved with the goal setting and choosing the course of action to be followed by them, they are more likely to fulfill their responsibilities.” However, apparently, Drucker himself got disillusioned with MBOs as he felt “…MBO is just another tool. It is not the great cure for management inefficiency … Management by objectives works if you know the objectives: 90% of the time you don’t.” There has been criticism from other thinkers and practitioners that MBO tends to overemphasize control as opposed to fostering creativity to meet their goals.

Meanwhile, another great guru, the quality guru Deming was also one of the critics of Drucker’s approach. Deming identified evaluation of performance, merit rating or annual performance review as one of the Seven Deadly Diseases.  He wrote in The Deming System of Profound Knowledge (SoPK) – “A manager of people needs to understand that all people are different. This is not ranking people. He needs to understand that the performance of anyone is governed largely by the system that he works in, the responsibility of management.” Clearly, there were growing concerns among leading thinkers if conventional system of rating and ranking people were effective in the long-run.

However, notwithstanding such criticism, another bold experiment was in the offing. The great manager of all times, Jack Welch introduced the tough system or ‘rank and yank’ at GE that earned him the moniker of Neutron Jack but led to unprecedented gains in productivity and performance. However, similar experiments at knowledge companies such as Microsoft seem to now have been recently criticized as a failure that led the lost decade.  

However, the advent of 21st century changed everything. The notion of tech-savvy, highly confident and fiercely independent Gen X and Gen Y knowledge workers working on small and highly collaborative teams in a highly empowering culture of self-organization became the new normal. Simultaneously, the concept of leadership underwent major transformation where the Command and Control leader had to finally cede its position in favor of a more democratic and collaborative leader who provided servant leadership which was led by influence (rather than authority) and knowledge was bigger source of power than titles (or corner office). In such an environment, managing talent the old way was bound to be detrimental to employee motivation, team productivity and company performance in the long run. During this last decade, the hitherto employer-centric jobmarket became a predominantly employee-centric. Internet and globalization created opportunities for the best talent to chart their own course rather than work for big brands. In software development, the advent of agile manifesto signaled an era of managerless teams. How do you manage talent in such teams? And who manages it – remember, there is no manager here!

We all might not be in utopia yet. The reality is that not every organisation or team will be able to achieve such self-organization, at least in the forseeable future, and perhaps it might not be the most effective management system for every kind of industry. So, there will always be a need to have traditional system of performance management, but adapted to the newer environment. Instead of making performance appraisal as an annual event, we all know that we need to make it more like an ongoing process round the year. We know that it’s not just the employees, but even the managers that are uncomfortable with the idea of performance appraisals. We need better mechanisms to collect 360 degrees of feedback from top, down and sideways. We need stronger linkages to company goals and a more meticulous follow-ups, and clear demonstration of the accomplishments. We need more objective ways to apply standards of performance consistently across the organization. And, we need to do all this without making the process complex, bureaucratic, or time-consuming. We need to recognize that support systems should keep pace with the pace at which business is being asked to deliver results. And finally, clearly staying focused that this is simply one of the means to eventually deliver the ends.

For startups and new businesses, this is less of a challenge, for they are invariably formed with different objectives and are low on traditional symbols of performance or career progression. It is normal for most team members of a startup to take lower salaries and equal (and multiple) roles in a team. There is no notion of career progression – rather, the opportunity to work on bleeding edge problems is the biggest reward these individuals crave for, and the IPO dreams keep them going beyond the thresholds of sanity and hard work.

However, I think any non-trivial organization needs some systemic solution to ensure that standard processes are applied consistently and are executed free of individual manager biases and prejudices. In such organizations, apart from having a centralized performance management system, there might even be a requirement to connect-up information with/from/to other adjacent HR functions – compensation, recruitment, learning and development, compensation management, and finally succession planning. In such situations, solutions such as Halogen eAppraisal might make sense, because they can ensure compliance with organization-wide standards and timelines, while ensuring that information from associated HR functions doesn’t get lost out while conducting performance appraisals.

So, whether you are a large multinational or a startup, the basics of talent management are critical – in fact, they haven’t been more important ever. We are in the era of talent scarcity and with everything else being equal and openly available to anyone across the globe, the success depends on having the best talent which is then let loose on solving the most complex problems.

So, how are you managing your talent?

Calm down Sandy! Calm down!!

Sandy continues to unleash its raw fury tonight.

Over 14,000 flights had been cancelled ahead of the landfall. Once it crashed ashore, it brought calamity of unknown proportions. 10,000 calls were being received every half hour in NYC to 911. The subway seems to be submerged 4 feet under water, and there are conflicting reports of 3 feet of water on the floor of NYSE. Millions of homes are without electricity. Cars are floating on streets and the high tide only made the situation worse (water since then seems to be receding in NYC). There is a snapped crane dangerously hanging and swinging at 90-storey skyscraper and no one can do anything about it. JFK Airport is closed due to flooding. Seawater has entered close to a mile in Atlantic City.

Ten more states are bracing for the worst natural disaster of our times.

20% of US population will be affected by Sandy.

No one really knows how long the ordeal will continue before it eventually abates. We can only hope and pray for safety of millions of affected people.

For a Category 1 storm on the Saffir-Simpson Hurricane Scale, the impact is simply too humongous to imagine.

This is unprecedented, unthinkable and perhaps un-plannable from a disaster recovery, let alone disaster avoidance, mitigation or planning.

Watching it all unfold live on news channels, I only wish it were a scene from a Hollywood movie. Sadly, this is all happening for real.

However, the real challenge will begin when it is all over and the sun is out.

Millions and millions of gallons of water will have to be pumped out of the subways – only after when the power has been restored. Until then traffic can’t start and people can’t get to work. NYSE is the virtual center of global financial markets and if the reports of water flooding in NYSE are true, it could take days or weeks before it is business as usual. Global businesses could take significant hit in the aftermath of this superstorm.

It will perhaps cost over $10Billion in insurance losses – and perhaps much more for losses that might not have been insured, not to mention the time it will take to clean-up all the mess and restore normal life.

As a project management professional, following days and weeks will be a great learning in how do civic authorities and people deal with reconstruction efforts. Surely, new ideas will emerge in BCP (Business Continuity Planning) and DR (Disaster Recovery) of critical business functions. There will be better insights into how to improve preparedness, both of systems and also for people, to deal with such unavoidable disasters. I hope to share some more of my own learnings in a subsequent post.

But for now, calm down Sandy! Calm down!!

Are you thinking about solving the problem, or simply fixing it?

What is the first thing that comes to mind when we see the problem? Most of us immediately jump in to start solving it. While this might appear to be a natural instinct and a logical choice for some simple problems, reality could often be otherwise, especially for complex problems. If we don’t know enough about genesis of that problem, we might spend countless hours ‘fixing’ it, and yet hardly make any meaningful headway. Or, we might fix it in the short-term, but might not solve it in the long-run, i.e. address the root-cause behind it. For all we know, the first thing we do might actually be the worst!

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about the solutions” – Einstein

There is an interesting story about the famous Jefferson Memorial. A few years back, for no apparent reason, the monument was found decaying significantly more than other monuments. At the initial inspection, it seemed like it was acid rain or some such thing, but on detailed inspection, and after asking a series of ‘why’ questions, the root-cause was found to be completely unrelated to the original problem. Here’s roughly how the chain of thoughts proceeded:

Problem: Jefferson Memorial was found crumbling more rapidly then other similar monuments.

Question:Why was Jefferson Memorial crumbling faster than other monuments? Was it due to acid rain?

Answer: It was not acid rain. The monument was being cleaned both inside and outside twice a week with strong cleaning soaps. Upon further investigation, it was revealed that erosion was being caused by soap solution reacting with exhaust from jet fuel from the airport across the river.

Question: Why was the monument being cleaned twice with such strong cleaning agents?

Answer: Because there were lots of bird droppings, which were spoiling the monument, and to keep the monument clean, they had to wash it frequently.

Question: Why there were such high numbers of birds at this memorial compared to other memorials?

Answer: Because there were very high numbers of spiders at the memorial which birds like to eat!

Question: Why there were such high numbers of spiders at this monument?

Answer: Because there were a large number of midges (tiny aquatic inspects) that these spiders love to feast on.

Question: Why were there so many midges at this memorial?

Answer: Because midges were coming out for sex (yes, literally!) at dusk and were being attracted by light which was caused by the floodlights that were being put on just before the dusk – to make the memorial beautiful for the tourists! They would promptly die thus triggering the whole food chain.

So, that was the key. This was a long-lead food chain that had eventually turned into a problem. While the initial possible solutions included building a huge glass cover around the memorial, or even moving the airport far away (both of which seemed like very costly and complex solutions), eventually National Park Service delayed putting on the floodlights by one hour which led to midges population going down by 90% and the food chain was broken, and the problem was solved.

You can watch a nice short video on this from Juran Institute here: 

 

 

This is of course a great application of the Five Whys that was originally developed as a problem-solving tool by Sakichi Toyoda, the father of Japanese industrial revolution, at Toyota and became part of the Toyota Product System. Over the last several decades, several of the principles, tools and practices of TPS have found its way beyond automobile manufacturing, and are now generally considered as a vital problem-solving process for pretty much anything.

So, why this blog post?

Because the subsequent process of initiating required change is not as easy or straight-line as it appears to be.

Surprisingly, we still continue to see knee-jerk response to ill-understood problems that end up paying just a lip service to the real issues. Invariably, the 4th or the 5th why lands us into an unfamiliar territory – another function in an organization that we don’t have control over. In case of Jefferson Memorial problem, the solution involved getting in pigeon expert and then spider expert, and so on. Solving the problem effectively requires people to muster up all their courage and go over the fence and work with stakeholders to change something in their way of working – something easier said than done! There is a nice story of how a mousetrap, meant to be problem just for the mouse ends up being being a problem for everyone else but the mouse himself! It is a nice and simple illustration of how smaller causes cascade into bigger effects, and how trivializing them in the initial stages only ends up growing them into a monster problem that one is simply not able to handle. However, hindsight is always 20/20, and if only we could rewind the problem and get another chance to start it all over.

In my experience, apart from the ignorance about the power of a simple problem-solving tool such as five whys, when it still fails to find an effective solution, it is generally because it requires two different set of skills –

  1. the first is about doing a series of deductive reasoning steps to keep double-clicking on what is being presented as a cause till everyone agrees on the root-cause behind the problem. This needs smart thinking, ability to go beyond the obvious and build and test hypothesis that uncover more deeper issues.
  2. the second part is all about actually influencing people in another part of the organization to go and fix it. Invariably, the reaction is – “that’s not my problem”. In a way, this is like the Butterfly Effect – the flap of a butterfly wing sets off changes in a system causing a chain of events that eventually manifest in something very big in a completely different time and place. Solving this problem, then, is significantly difficult because it requires establishing the entire chain of events that led to the current problem. Given that these events are likely to be spread out in time (e.g., decisions made over time) and space (e.g., different functions in a organization), no one is likely to own them individually.

So, how do you go across organizational silos and ask people to take some preventive action that really solves the problem they have probably not even heard of! In general, making someone agree that they need to change something is hard enough.

I have found the following approach that works in many situations –

  1. First, get all the data. In the absence of data, we are all only conjecturing, and as creative that might be, we need to back it up with objective data to eventually make meaningful and better decisions.
  2. Whenever possible, involve other affected groups or individuals in the process at the earliest. No point second-guessing on their behalf.
  3. If they haven’t been part of the original root-cause analysis, instead of shooting off an email to them asking them ‘what’ is to be done, walk them through the entire process and ask them for validation. At this point, get an agreement on the problem without telling them your view of the solution.
  4. Once there is an agreement on the problem, half the battle is already won. Now start asking them how would they solve it.
  5. An ideal situation is when their solution is same as yours. But that might not always happen. If their solution is different than yours, first understand what is it that they are telling you, and why do they think that will solve the problem.
  6. At this stage, if you are not convinced of their approach, let them know so, and share what your original root-cause analysis exercise has come up with. The idea is not to confront them, but rather present another perspective and to compare and contrast what is better way to address the issue.
  7. If there is a toss-up between these two approaches, it might make sense to go with their solution rather than yours for two primary reasons – they are the primary function owners and hence expected to have better subject-matter expertise and professional judgment than you, and secondly if you go with their perspective, you are likely to get a better buy-in in the long run.
  8. However, if there is a deadlock, and quite often that is the case, one has to be accommodating. A very natural response is to go up the reporting chain and push for our solution, but I haven’t seen that is very productive in the long run. I would give benefit of doubt to the concerned group or the function and ask them to try for a reasonable and mutually agreed upon period of time till we see if the problem is resolved effectively. If it is not getting resolved, it’s time to once again get back to the drawing board.
  9. Hopefully you have an agreement by now on a solution that actually addresses the core issue and solves it. God bless you.
  10. Always remember – today’s solutions are tomorrow’s problems. While you might have solved the problem, in the bargain you might have inadvertently triggered-off another problem that is waiting to be manifest somewhere else in the organization in due course of time. So, keep your eyes and ears open if any new issues are reported – it is quite likely that they are regression effect of the current solution!

In today’s world, solving a problem effectively is as much a hard process as it is an individual and sociological change – affected people need to understand not only the required changes, but also the reasons behind it and adapt accordingly, which is more often than not, very discomforting. In a way, one can even argue that this is not even ‘change management’ – it is ‘change initiation’ which requires chartering unknown waters. Initiating the change requires even higher level of individual courage, leadership and persuasion skills to bring all affected parties on the same page. In a large and complex organization, it means hopping over silos and other political boundaries and tribal cultures and getting them agree to something else. Apart from a very strong understanding of systems thinking, it also needs very high amount of political capital and people suaveness to get it done. It also takes a lot of time to get this done, and most of us are simply not prepared to initiate such transformational change for a variety of additional reasons (e.g., if my performance system rewards result-orientation at the cost of long-haul systemic improvement, how can I demonstrate results by the time next review is due, and so on). So, we settle down for what appears to be second-best – just fix it. In reality, that is just postponing what eventually needs to be done anyhow – and perhaps at an even greater cost!

So, think again – are you thinking about solving the problem, or simply fixing it?

What’s in a Name?

[Note: This article was published in PM Network Sep 2012 “Peer to Peer” column as a dialogue between me and Cindy Lee Weber, PMP, a practice manager at Trissential in Minneapolis, Minnesota, USA. Registered PMI Members can access the magazine and the article here. My article is reprinted here, and my views are in green color.]

Tathagat Varma, PMP: Fewer people confuse projects and programs than they did 10 years ago, but there still is some confusion because it can be objective. By definition, a project is an endeavor funded by finite resources with a finite duration and specific outcome. A program is a group of projects aligned by a single objective or outcome that can be better managed collectively than individually.

Cindy Lee Weber, PMP: There also can be confusion in projects versus work effort. For example, a request for a report that will take less than 200 hours and US$ 1,000 might be deemed an operational work effort rather than a project. You might not use the same project management framework, or you might use the same framework but with less rigor.

Mr. Varma: Sometimes you have to put it in different terms for executives. I explain to executives that we should use projects to address specific, one-off problems like delivering a product ahead of the market to gain market share. 

But we should look to programs to address organizational problems: How do we look at so many moving parts? How do we train all the people together? How can we create consistency in our process framework across the organization? 

I explain to executives that we need to look at it as a strategy program with a much wider charter, not just look at the immediate benefits for one project.

For example, we might decide to create a new engine that will improve search results. This cannot be a one-time activity. We need to look at all moving parts. After we’re done, how do we improve it? How do we improve the operational part of it?


Ms. Weber:
You have to ensure alignment with executives in language and concepts. I worked on a US$15 million to $20 million human resources consolidation project that really was a program. Because it had so many legs, as the project manager, I had no real responsibility—I didn’t have budget or quality control. 
In the beginning, I worked with all stakeholders to agree on the language used for this “project.” 

I assigned project leads to the individual work silos rather than “project managers,” but their roles and responsibilities were project management-like. I used a program management approach but didn’t call it that. It worked well. Whether we called it a project or program was irrelevant as long as we aligned with goals and objectives.

Mr. Varma: For a large, complex software delivery that was incorrectly labeled a “project,” I incorporated many program management processes. I created a program structure and program government framework, and appointed 14 competent project leads responsible for each of the subsystems, giving them a fair amount of autonomy. 

I served as the program manager and did not micromanage the decisions or progress tracking. My role was to put it all together, look at the data and interdependencies, and make sure all 14 subsystems ran on the same timeline so we did not end up with a bottleneck.

Ms. Weber: By treating a true program as a large project, you risk under-resourcing and underestimating the time needed for program management. You also lose sight of some of the urgent parts because there isn’t ownership at the project level. 

If it’s cross-functional or multi-site, there’s a tendency to not involve all stakeholders, so you may not understand all the requirements or organizational change that will happen.

Mr. Varma: In addition, the project manager might overstep boundaries and micromanage, which leads to frustration amongst the team. 

If it’s a true program, you need a program manager to behave like one—zooming in when there is a problem, then zooming out to manage at a high level. If the project manager makes all decisions and attends all meetings, he or she will burn out at some point. Plus, there can be delayed decision-making because he or she can’t make all decisions on time.

On the opposite end, if you treat a large project as a program, you over-provision resources and management, which increases costs. Secondly, you elongate decision cycles—decisions that could have been made at the team level are made one or two levels above. And at some point, team members feel there is too much upper-management involvement.

Ms. Weber: You also risk losing budget and schedule elements—when you roll up a project to a program, the responsibility of a particular piece gets segmented and you don’t see the overall costs, for example. 

And if you put a program manager in a project manager role, he or she may not get into the day-to-day task management of project management. The two roles require different skill sets and interest levels, and there is a big risk in failing to identify those competencies.

Mr. Varma: Moving from project to program manager after a couple of years shouldn’t be automatic because the roles require different mindsets, maturity and problem-solving capabilities. 

Because projects are more compact units and project managers generally have authority over team members, team members likely will align with whatever the project manager says. But because program management is all about collaboration and team members don’t formally report to program managers, they have to lead by influence. They have to bring people on the same page, create collaboration and negotiate between different stakeholders.

Ms. Weber: If organizations don’t recognize the right roles of project and program managers, chances are they also don’t understand the role of a business analyst, architect, systems analyst or a quality-assurance person. There’s probably a bigger, overarching problem there.

Can Program Managers Make it to the Executive Suite?

Note: I recently shared some view on this subject for PMI’s Career Central article by the same name. You can access the original article here. In this post, I have shared the original article, with my comments highlighted in green color.

 

Not many of today’s senior executives come from a project management background. But that’s not to say that program managers aren’t capable of getting there.

“The skills required in most executive positions compared with those required to succeed as a program manager are similar,” says Oluwatosin Agbetusin, PMP, PgMP, program manager, Ericsson, Lagos, Nigeria.

Outlining the similarities, Mr. Agbetusin said both program managers and executives:

  • Decide and guide the actions of their teams
  • Manage human, financial and physical resources
  • Oversee stakeholder management
  • Ensure the organization’s strategic goals are achieved
  • Help establish oversight and proper governance

According to a 2011 PMI-sponsored study, Project Managers as Senior Executives, about 74 percent of respondents said the experience and skills required for project and program management is good preparation for an executive position. Survey respondents included senior executives and project and program professionals from six countries.

And program managers are particularly well positioned to make the jump.

“Program managers usually report to higher levels, which gives them a broader view and more personal exposure to the executive levels,” says Russell Archibald, PMP, the San Miguel de Allende, Mexico-based co-author of the study.

Before moving into his role as senior director of business operations for Yahoo! in Bangalore, India, Tathagat Varma, PMP, worked as a project, program and general manager. He says the skills he honed as a program manager gave him an advantage over line managers.

For example, as a program manager for Huawei Technologies, a telecom company in China, Mr. Varma managed 190-plus people on a program with 14 parallel projects. His experience also taught him how to overcome challenges like cultural barriers and stakeholder alignment.

“It’s about leading with influence versus leading with authority, which I learned as a program manager,” he says. “My approach was to focus on results and let component project teams figure out the means to achieve those results.”

Similarities between executives and program managers center on such abilities as strong decision-making, communication and negotiation, according to the PMI-sponsored study. But one skill that truly transcends positions is leadership.

“As a program manager, if your leadership skills go beyond just managing programs and into areas like contributing valuable insights into strategy, or operational and personnel skills, you will start getting regarded as a leader,” says Naveen Venugopal, PMP, project and program management consultant, International Finance Corporation, Washington, D.C., USA. “This can pave the way for an executive spot in the long run.”

To set themselves apart, program managers must take a holistic view and get creative, says Asad Ullah Chaudhry, PMI-ACP, PMP, PgMP, CEO, AUC Technologies, a training and development firm in Karachi, Pakistan.

“Most program managers think rationally and focus on deadlines and scope. They lose the creativity. To be an executive, they need to use an innovative approach for managing their programs,” he says. “Review the whole process, and try to remove the bottlenecks or shorten the process.”

Program managers should also seek projects aligned with the organization’s overall business goals, says Mr. Varma. When program managers can show they can both deliver and develop or influence strategy, they’re more likely to rise up the ranks, he says.

For added credibility, program managers should consider earning a Program Management Professional(PgMP)® credential.

“The topics, core skills, requirements and knowledge identified as part of the PgMP® credential process are very important for any program manager to either land an executive job or succeed in one because they are closely tied to those required for executive-level job functions,” says Mr. Agbetusin.

Whether program managers realize it or not, the very nature of their role is preparing them for the executive suite. If they continue to hone those abilities, they’ll be on their way. 

If you are a program manager, or know someone who is one, ask them to share their viewpoint on this topic. Program Management is in nascent stages, and it serves the larger community to collate all lessons from its practitioners. 

Can Program Managers make it to the Executive Suite?

Effective Escalation Practices

This article was provided by Erin Palmer from the University Alliance. Erin writes about project management topics such as PMP certification.

Great leaders know how to focus on project management competencies. Perhaps nowhere in project management do effective soft skills shine through more than in the process of escalation and escalation mitigation. Knowing when and how to escalate requires more than just an intimate knowledge of the emerging issue, but a deeper understanding of the entire business landscape surrounding the events that have led you to this moment. Handling conflict in an action-oriented manner that effectively brings about resolution and promotes team cohesion may at first seem like contradictory goals. On the contrary, effective project managers know that teams work best when trust in leadership is palpable and when team members feel confident that if a problem arises, the leader will expediently and effectively resolve the issue. Strong leaders have strong teams and that is why it is imperative to spend time considering the finer points of an escalation strategy as part of your overall professional development process.

The Art of Knowing When to Escalate 

Establishing long-term communication protocol for all team members is vital to maintaining a feel for the pulse of the project and anticipating challenges before they become full blownissues. Some challenges cannot be avoided, such as a major upheaval in supply chain management when sudden events like natural disasters or international social unrest grind project progress to a halt. It is the more mundane situations encountered over the course of a career that will test your effectiveness more intensely than the occasional huge event. Here are a few questions to ask yourself before escalating.

1. Do I have all of the facts?

Escalation in its purest form is a strategic move. Make sure you have all your facts together and have taken the time to consider alternatives before escalating. If the issue personally involves team members, strategize how this escalation will be a learning tool if at all possible.

2. Will this issue come to a complete surprise to superiors?

If communication is open and effective throughout a project, then your superiors should have some indication that a challenge is present before the escalation occurs. The soft skills involved in finessing communication techniques over the course of a career become more complex and more important as the stakes grow. Be sure that your communication skills grow with increasing responsibility. Seek professional mentoring or other professional development to keep skills current.

3. What do I want from this process?

Escalation as a management strategy involves a comprehensive understanding of outcome goals and long-term project planning. Escalate too many issues and you may be perceived as the “Boy Who Cried Wolf” which may result in the lack of engagement of superiors when you truly need them. Holding back and waiting too long to escalate an issue can result in the project falling apart. Effective escalation takes skill, knowledge, and experience.

4. Am I prepared?

While seasoned professionals will disagree about when or how to escalate an issue, most will
agree that if you are going to escalate an issue you need to be completely prepared. Accumulate your documentation about what you have done so far to mitigate the situation; prepare a concise report detailing any related financials; have clear ideas about your outcomes. You want to be a partner in the process, so involve your team as necessary and engage your superiors as colleagues. An escalation can be an effective learning tool for teams if strategized properly.

Additional Factors to Consider

Effective escalation requires a certain level of professional maturity that emanates from top project managers. When you are in the presence of great leaders, how they handle conflicts and unexpected issues becomes the glue that builds team cohesion and is noticeable from a distance. Every company has divisions and teams that work smoothly despite issues that arise as projects evolve. Project management is a dynamic field with a strong history of building innovative solutions to business’ toughest challenges. It promotes a collegial environment where collaboration is a key element. Developing effective escalation strategies can help you keep your skills relevant and leverage career growth throughout the longevity of your career.

Bridging the Cultural Divide in Global Projects

This is a guest post by Michelle Symonds. Michelle has many years’ experience in IT and IT Project Management in the oil industry and investment banking working on complex global projects involving the management of overseas project teams. She is now a freelance consultant specialising in article writing for businesses such as www.parallelprojecttraining.com and is also editor of the Project Management News website www.projectaccelerator.co.uk.

With most major corporations doing business on a global scale, projects are naturally part of that global business and, as such, project management is increasingly about leading projects and teams from different countries and cultures. This introduces potential risks related to language, time-zone and cultural differences, above and beyond the usual project risks.

The project management of geographically diverse projects requires a different approach to leading and communicating with teams if it is to address the cultural divides that often exist so that effective multi-cultural teams may be developed to deliver successful projects. It is important to recognise that cultural barriers are not simply between “East” and “West” but that they can potentially exist between any two different countries from any part of the globe. A cultural divide can exist between closely located countries and even between countries with the same language so recognising this at the outset of a global project, and introducing strategies to deal with it, is essential for a successful project outcome.

But, whilst location, language and time-zone differences will have an effect on a project, these aspects are relatively straightforward to manage for an experienced global project manager. Less easy to manage effectively are the cultural differences, which, by their very nature, are not often explicitly stated or well-understood. Indeed, because of reticence to mention a problem in some cultures, a project manager may not even be aware that a problem exists until it is too late to rectify. Cultural differences may necessitate adapting standard project processes and procedures to take account of certain factors. No culture can claim to know the “right” way to run a project, and every culture has been successful in its own right, but maybe by addressing cultural issues we can all learn something from other cultures that will add value to global projects.

So just what are the most typical culture-dependant areas that might require a “non-standard” project approach?

 

  • Communication – Understanding and Interpreting 

Face-to-face communication will always minimise misunderstandings, but it will not eliminate them altogether when cultural differences are significant. Wherever possible, all stakeholders should meet in person prior to the start of the project. Indeed when dealing with some countries, such as China, face-to-face meetings are an essential part of building an all-important trusting working relationship. Understanding other cultures helps a project manager anticipate and respond appropriately to issues during the project and ensures that the project manager’s behavior does not offend or insult the other parties involved.  

Face-to-face meetings help both sides of the cultural divide to gain an understanding of each other’s expectations and aid the interpretation of unspoken signals. In many Asian cultures modesty, patience and politeness are expected behaviors that are not necessarily expected in Western countries (although they would be nice).

Once a project is underway, much of the communication is likely to be by email, which in a western culture is used by the sender of the email to clarify all issues beyond any doubt for the recipient of the email. However, in many Asian cultures detailed clarification of every point can be seen as an insult to the intelligence of the recipient so the onus is on the recipient to infer what is meant by the sender. This factor alone can unintentionally cause problems so, for example, an English PM should emphasise that detailed clarification is simply a part of how projects are done in the U.K. when dealing with Indian or Chinese stakeholders or project teams to avoid causing personal offence.

  • Cultural Viewpoints – Seeing Things from the Other Side: 

Understanding the viewpoint of others involved in a project is a two-way process (or more) to ensure all stakeholders and teams understand the expectations and attitudes of each other. This is not just the case with eastern and western cultures, there can, for example be issues between Indian and Chinese teams involved on the same project where the hierarchical culture of India and the Chinese culture based on personal relationships can cause conflicts in determining the best approach to deal with risks and problems encountered throughout a project.

The success of a project will require an understanding of the underlying values of a different culture and how they affect the working practices of those involved in the project so a professional project manager should take the time to research these different cultures. There are a number of organisations, such as the China-Britain Business Council and the UK-India Business Council that offer useful advice in this area.

But be aware that China and India, in particular, are vast and diverse nations with different underlying sub-cultures and languages so there are no quick and simple tips to understanding all aspects of their cultures. Different attitudes to areas such as project quality, cost and time can exist within different individuals in the same culture. So be cautious about making general assumptions and try to get to know and understand each stakeholder and local project manager as an individual and develop good working relationships that go beyond standard project procedures.

  • Reporting – Obtaining Accurate Progress Information 

Western cultures tend to value openness and frankness when it comes to project progress and reporting. They believe that project issues can be prevented from becoming serious problems if they are raised as soon as they are detected and that serious problems can be better solved by discussing possible solutions with the group. But how issues and problems are handled is a culturally sensitive issue. Admitting to a problem can be seen, in some Eastern cultures, as an admission of failure so a project team leader would not openly report schedule overruns or the inability to complete a task in the same way as his Western counterpart. Instead the information might be gradually brought to the global project manager’s attention bit-by-bit.

Similarly, the way in which changes to the schedule are requested may not always be in the most obvious way. Even on projects where there are defined and documented procedures for updates these procedures may simply not fit with the working mentality of all those involved in the project. For a PM to assume the procedures will be followed by multi-cultural teams simply because they have been defined is a naïve view. Some teams may approve procedures only because it is culturally unacceptable for them to openly disagree with the global PM.

  • The People – The individuals behind the Names 

It is a vital skill for a global project manager to understand what motivates the diverse teams and individuals working on a project and to take the time to provide constructive feedback on completed tasks in order to clearly define ongoing expectations. But, clearly, on a large, complex project being run in various locations around the world it would be impossible for a global PM to know all team members well, let alone understand their personalities and motivations.

This is where building common understanding and trust between the global and local project managers will be of benefit. Working with the local project manager, who can better understand individual motivating factors and who can present feedback in a culturally-sensitive way, can aid the development of multi-cultural project teams which can work efficiently and co-operatively together.

Rivalries and different agendas may exist between culturally different project teams (just as they may between co-located teams) so the network of relationships must be managed sensitively to minimise their impact on the overall success of the global project. It is essential for a successful project outcome that the global PM facilitates co-operation and support between all teams and attempts to minimise conflict.

Whilst it might be possible, in an ideal world, that we all follow some “international” standard of project management, in practise, adapting standard procedures depending on the different cultures involved in a project is likely to lead to more successful project outcomes. Managing global projects presents a particular set of challenges that require specific experience and PM training to overcome the inherent difficulties of cultural divides but the advantages of doing so can lead to a project that achieves cost-effective technical excellence.

A checklist is more powerful than an org chart?

Most of us so-called ‘knowledge workers’ don’t particularly fancy the term ‘checklist’. It smacks of an antiquated top-down command-and-control Dilbert-style bureaucracy where someone sitting on 42nd floor of corporate headquarters hands down a piece of paper for you to blindly follow and to make you feel dumb and outright humble – for it dilutes your role and underplays your intelligence as if anyone else in your position could have done it! In short, it seems to trivialize the knowledge, skills and expertize required for the job into a mechanical routine requiring no human intelligence, and places the decision-making into hands of people irrespective of their competence levels. And we hate it!

Wikipedia defines a checklist as:

“A checklist is a type of informational job aid used to reduce failure by compensating for potential limits of human memory and attention. It helps to ensure consistency and completeness in carrying out a task. A basic example is the “to do list.” A more advanced checklist would be a schedule, which lays out tasks to be done according to time of day or other factors.”

From the definition above, it seems like an innocuous tool that just helps you keep focus on the most critical things – things that you might skip rather unintentionally or lose track of during one of the numerous hand-offs, or mix-up their sequence when there is time pressure. Obviously, there is no way a checklist could enlighten a dummy into being an expert overnight!

Atul Gawande has done a wonderful job of elevating the good old checklist in his pathbreaking “The Checklist Manifesto” to a modern management tool that can be used to prevent unintentional human mistakes and improve collaboration and decision-making in emergency situations – even in the areas that require utmost brainpower. He cites real-life examples from some of the most complex endeavors – complex human surgeries, constructing tall building and flying jet planes, among others, that no doubt require very high

A short pencil is better than a long memory…

amount of individual cognitive skill in respective functional areas, but also require a high precision in the steps to be followed – both during meticulous planning and preparation, and in making split-second decisions during an emergency, be it flying at ten miles above ground or a complex brain surgery on operation table. One after other, he repeatedly presents compelling data from such hi-intelligence professions that reinforce his assertion that something as rudimentary as a checklist could have such dramatic impact in complex human endeavors.

In this article, I have taken some teasers from this book that I liked and made a lot of sense to me. I have also included my own commentary and perspective for each of these.

Knowledge continues to grow at an astounding pace. No one person can hope to ever keep pace with all latest advances in any one single field, let alone build a body of knowledge around core specialization area and adjacent knowledge areas. And yet, in many cases, we have no option but to rely on the individual judgment by a supposed ‘expert’. What if that ‘expert’ was not good enough, or as good as we make out of them? What if that one single source of true knowledge, the true ‘Master Builder’ was more like someone who was a mediocre talent as best, and could not live up to the high expectations of infallibility, and yet we place almost entire decision-making into their independent charge? That would be a true disaster. Gawande calls out such challenge:

“…in the absence of a true Master Builder – a supreme, all-knowing expert with command of all existing knowledge – autonomy is a disaster. It produced only a cacophony of incompatible decisions and overlooked errors.”

So, while autonomy is the desired end-state, we need to be cognizant that perhaps there is no such single person in real life who deserves to be the undisputed knight of all things worldly! At best it is an urban myth and at worst, it is a nightmare played out multiple times in each field! A cacophony of incompatible decisions and overlooked errors! Sounds outrageous, but apparently not so rare.

Let’s walk a bit with the fact (?) that there is no one single person supremely capable of mastering all the knowledge so as to be the single source of truth. What would then be the second-best way to manage complex human endeavors? Perhaps assign it to teams who are then chartered to figure out the solution? A group of perhaps regular people who individually posses a bit of knowledge each, and collectively represent whatever it takes to address the problem at hand? That does seem like a logical way, because we believe more heads are better than one. However, it is difficult enough to get a collocated team perform in top gear, imagine distributed teams in multiple time zones, contractors from different companies with different and often incompatible cultures and processes working together, employees coming from various departments for whom local departmental gains are more important than the global organizational goals. Can checklists provide some guidance?

Here again, Gawande has some interesting viewpoint:

“in the face of the unknown – the always nagging uncertainty about whether, under complex circumstances, thing will really be okay – the builders trusted in the power of communication. They didn’t believe in the wisdom of the single individual, of even an experienced engineer. They believed in the wisdom of the group, the wisdom of making sure that multiple pairs of eyes were on a problem and then letting the watchers decide what to do.

Man is fallible, but maybe men are less so.”

However, we often believe that by simply crowdsourcing, we can fix the problem. We expect a reasonably sized group to eventually gravitate towards one common solution. While this might be true for simple party games like ‘guess the weight of the cake’, how do we extend and apply this to more real-life problems that entail tangible risks, such as do we need an additional overhead beam to distribute the load on the 37th floor of a highrise building, or whether we need to give more anesthesia to a 63-year old patient of severe diabetes and hypertension on the table for his bypass? In traditional management, a manager would be supremely empowered to make such decisions – his knowledge and experience was ‘supposed’ to mitigate any risks associated with such centralized decision-making, because, well, the ‘workers’ in that quintessential industrial age were after all dumb. In such one-sided match, the worker participation was almost always zero, and the decision-making was the elite preserve of the management class. We can’t say if that was effective or not (though we do know that was not the most motivational way), but apparently that’s the only thing that was! However, the advent of knowledge-economy brought with it three important changes : rapid pace of creation of new knowledge, new means and mechanisms to rapidly mass proliferate the newfound knowledge and a faster obsolescence rate of old knowledge have all collectively led to a more balanced play at work. No longer is ‘manager’ the Mr. Know-all, but is increasingly dependent on the critical inputs from her team member – most of whom have much more current knowledge and also hate a centralized hoarding of decision-making.

In such workplaces, it’s time the decision-making was made more democratic. What would be the risk of democratizing decision-making? Would it be akin to the inmates running the asylum? How can we ensure that best decisions will be made, and who will be accountable for those decisions? Can checklists help in this regard?

“In response to risk, most authorities tend to centralize power and decision making. That’s usually what checklists are about – dictating instructions to the workers below to ensure they do things the way we want. ….it spelled out to the tiniest details every critical step the tradesmen were expected to follow and when – which is logical if you’re confronted with simple and routine problems; you want the forcing function.”

So, apparently, the checklists ‘decentralized’ the decision-making but more as a forcing function. In a way, we can say that since Managers couldn’t be everywhere, Management created Checklists! Clearly, that’s not the best reason to justify or support checklists, even though we might have succeeded in our nefarious designs.

However, history has repeated shown us that every new invention has two sides – the good and the bad. While a checklist might have succeeded in its ‘forcing function’, it also has a positive side. This is the aspect that helps pilots and brain surgeons achieve better planning and performance. This allows for teams to create better bonding as much as making life-or-death calls in a split second. You have the read Gawande’s book to believe that.

So, why is that people hate checklist? Do they fear loss of individuality, respect, authority? Gawande offers some perspective and the counterintuitive wisdom:

“The fear people have about the idea of adherence to protocol is rigidity. They imagine automatons, leads down in a checklist, incapable of looking out their windshield and coping with the real world in front of them. But what you find, when a checklist is well made, is exactly the opposite. The checklist gets the dumb stuff out of the way, the routines your brain shouldn’t have to occupy itself with.”

As an example, he cites an interesting anecdote about what makes a team high performing by a simple act of just making sure that people follow the simple checklist of introducing themselves to the team by just telling their names:

“People who don’t know one another’s names don’t work together nearly as well as those who do.

The investigators at John Hopkins and elsewhere had also observed that when nurses were given a chance to say their names and mention concerns at the beginning of a case, they were more likely to note problems and offer solutions. The researchers called it an “activation phenomenon”. Giving people a chance to say something at the start seemed to activate their sense of participation and responsibility and their willingness to speak up.”

Imagine if the simple act of sharing names could accomplish so much, what else lies unexplored? However, in the absence of a checklist that ‘mandated’ such ‘routine’ we were potentially wasting this opportunity. Surely we could do away (and perhaps should do away) with checklists if only we could do such ‘common sensical’ stuff without them!

So, if checklists are an important management tool, how best to operationalize them? Should the manager ‘own’ the checklisting process? Here is an interesting take from the field of aviation, where, as we all know, once you take-off, you are literally hanging in the mid-air, and hence must do everything right to land safely:

“In aviation, there is a reason the “pilot not flying” starts the checklist. The “pilot flying” can be distracted by flight tasks and liable to skip a checklist. Moreover, dispersing the responsibility send the message that everyone – not just the captain – is responsible for the overall well-being of the flight and should have the power to question the process.”

So, there we are. It seems that there is a significant body of work to support the conjecture that checklists can be beneficial in more ways than one. They are not simply a forcing function, nor do they impede empowerment not stifle creativity. On the contrary, they help facilitate conversations during unexpected non-trivial situations. They also make the decision-making more decentralized and often democratic. To that end, a checklist is more powerful than an org chart. Too bad if that scares you!

Use checklist for all reasons and all seasons. As they say, a short pencil is better than a long memory…

How to establish credibility in a democratic workplace?

Flattening of organizations is an oft-repeated phrase that means different things to different people. My favorite connotation is what I call as ‘democratization of management’, which essentially means a more symmetric power distribution between erstwhile ‘management’ and the erstwhile ‘worker’- if at all such words make sense anymore. While there are serious advantages of such an organization structure, it obviously doesn’t come free of cost. For example, a key byproduct of such change is moving away from ‘leading with authority’ to ‘leading with influence’ where leaders can’t rely on their positional power or the organizational title to basically get things done. Instead, they need to establish their ‘credibility’ to be accepted as a ‘leader’ and the harbinger of change, and get things done. Sounds simple? Well, it may not be so easy…

In the old world where management unilaterally made rules, managers were empowered with making all key decisions and the workers were simply expected to follow them. Henry Ford created the moving assembly line where basically the supervisors made all decisions and the shop-floor workers were fungible to work on any of the low-level tasks. Naturally, it didn’t require much for a supervisor to demonstrate his ‘power’ – all he literally had to do was show up and shout orders. People knew who was the boss, and given the roles they were hired into, either they were not of adequate intellectual level to be able to see the big picture, or were not allowed to think of the big picture. And even though last few decades were prime examples of worsening industrial relations, the workplace conflict between management and workers essentially got managed because of ‘clear’ division of labor – management made the rules to govern the work and output of workers, and the workers made the goods by obeying orders from management.

Enter the new world, the flat hierarchy, the knowledge economy, the informal Gen X and the indomitable Gen Y, and the old system comes down crumbling fast. Gone is the bad old world that essentially ‘exploited’ the workers. The good new world is all about collaboration, shared leadership, joint decision-making and other similar 21st century values and norms. There is simply no place for three-piece suits and bombastic titles in such a workplace. There is no corner office – at best, there is a corner cubicle! Everyone gets their own coffee, and everyone picks up their own printouts (from a common printer, did I say?). The notion of ‘experience’ gets blurred in such a context. I blogged about it earlier on inexperience is the new competency.

Such workplace sounds so romantic! Gone are the high walls that separated managers from real people. There is much freer flow of ideas and feedback, and makes the perfect setting for some real work. Right? Well…maybe…

But it also comes with one BIG caveat – how does someone, anyone, establish their ‘position’ in such a flat world? There is no title anymore to rely upon or hide back behind. Decision-making is often a teamwork and though it might have some real dangers of groupthink, it still has more advantages to be taken up seriously. If you are new to the team, or have the onerous task to bring in new ideas, how do you do that? What are the chances that the team will give you any hearing, let alone adopt your ideas? In short, what is your credibility to bring in new ideas? In the absence of any demonstrated credibility, why should anyone listen to you and waste their time?

Sounds very humbling and outrightly brutal, isn’t it? But, I believe that is the idea workplace of today – and one has to be lucky to be in such a workplace (and I will come to that later). Such workplaces don’t accept the ideas just because they come from someone sitting on a better chair, or drawing more salary, or wearing expensive designer suits, or is seen hobnobbing with the power that be. Such workplaces are ‘democratized’ and believe in bringing out and bringing up the best ideas just on its sheer merit. Let the game begin and let the best idea win.

While this could be real fun to participate in a workplace with such unbelievable energy, it could be equally frustrating for someone trying to bring a new idea, e.g. trying to convince for a new product, or rallying for entering new markets, or pitching for some process change, etc. Actually, if you think of it, most of us would be doing one such activity at any time (and those who are not doing are anyway getting closer to extinction, but that’s for another blog post). So, how do convince your peers, your team members (yes – even they need to be convinced, you can’t simply shove a decision down their throats anymore!), your boss and other key stakeholders? Why should they believe in your story? Do you have some proofpoints? What if they listened to you and the whole thing bombed? After all, you don’t come with the credibility that IT managers in 60s and 70s often believed in – “No one ever got fired for buying an IBM”. This simple ‘feeling of safety’ made them buy IBM with literally their eyes closed. Do your ideas come with such ironclad 30-day money-back guarantee?

A lot of these questions are because you haven’t yet paid your dues yet. You are too new to the system, or your ideas haven’t been fructified yet. Or maybe they have in the past, but this is a new manager. Or the rules of the marketplace have changed and you have a much shorter runway than in the past. The hard truth is that you don’t have credibility, and the absence of credibility means you don’t have enough ‘political capital’ for others to support your ideas. It’s not that they don’t like you or your ideas – just that you haven’t been able to register yourself in their minds as someone who is innovative, trustworthy and reliable enough to not only bring up sexy ideas that matter to them, but also willing to endure a long and hard fight to set those ideas to fruition. Question is, how do you earn such impeccable credibility?

I have been lucky to learn some valuable lessons in building credibility. Here are seven of them:

Learn from history…but don’t be enslaved to it

When you are new to a democratic workplace, you often find a combination of multiple factors – you are chartered to initiate and execute a change but the organizational history is against that change (and hence you) because of bitter experiences in the past. While it is very important to study the history and learn from it, it is even more important to not let history dictate the future! Quite often, false starts and fire drills desensitize people from jumping headlong into future change initiatives…they become sceptic of motives and impact of such failed change attempts on their own careers, and hence prefer to stay away till there is more clarity. You, as the change agent need to learn all you can learn from all those failed endeavors – without falling in the trap of sympathizing with the status quo. If despite all failed attempts in the past, you have still been given another chance, it is only because someone up there still believes that this change is needed. Don’t shortchange them – and yourself!

Identify passionate practitioners…and let their voice matter

While new ideas often have the power and potential to create disruption and hence create resistance among rank and file, there are always some people who are extremely loyal to some of those ideas – how so much minority they might be, and some of them are often quite good at it. Instead of appointing experts from outside, the better way is to identify those internal subject matter experts, and elevate them to play more important role in change management. Instead of ignoring them, turn them into your biggest allies. They carry invaluable institutional knowledge with them, and understand how and why some of the previous attempts failed. Since their heart bleeds for the given change, they will be willing to risk their own personal credibility to support you in your endeavor. They should be your A team.

Learn the “real world” first…don’t simply forcefit process to it

My favorite pet peeve against the snake-oil salesman (a.k.a. “process gurus”) is how cleverly they use the principles of FUD to scare the hell out of you, and forcefit their version of process to your version of problem. They almost make you believe that your problem is wrong because it doesn’t confirm with their solution. Stay away from those ‘experts’. Rather, look at the real world and understand the issues – whether or not the solution addresses it or not. My favorite is from the Swiss Army manual – if there is a difference between map and the terrain, trust the terrain! If people see you as an internal spokesman for an external paid consultant, then you can safely kiss your chance of being accepted as the neutral and well-balanced voice. Till you have properly understood the problem, don’t rush into a solution. It not only insults people’s intelligence (which is bad for you, and hence the organization too), it also significantly reduces chances of finding a better solution (which is bad for the organization, and hence you too).

Don’t preach from the top…demonstrate proofpoints

It is a human tendency to rush into ‘showing’ expertise by taking a position and adopt a condescending stance in an anxiety to establish oneself in a new team or a new organization. Sometimes, being negative or just showing a casual aloofness is considered as a proven way to create an aura of expert. I think all this is nonsense. People are smart, and they can spot fake from miles. Preaching without any proofpoints is meaningless. Preaching creates the impression that all people are naives or idiots, and hence need such prescriptions. However, I think people are basically smart. Anyone in any position of responsibility and accountability must be trusted to have some common sense – they need you to solve some specific problem, but they haven’t allowed you to change their lives. Instead of selling panacea, you would be much better off taking up specific problems that create objective and repeatable experiences, and allow people to form their own views about it. Don’t put words in their mouth that they might not like, instead leave them with experiences that they can relate to and form their own opinion, even if that goes against you – as long as that is good for the business and people.

Validate ideas externally…but don’t hardsell them internally

What do you when people won’t listen to your ideas internally? You have tried all tricks of trade – got external experts to come and talk about it, or shared world wisdom internally, but people are still sceptic. Sometimes, such sustained rejection of your ideas could set you back in your endeavor, and in extreme cases, kill your spirit enough to drop the change agenda. What do you do next? Perhaps the best move it not to pursue it aggressively but first go out and validate your ideas from external world – the professional network, the practitioner community and so on. Listen to their challenges and adventures and share your own with them. Learn from each other and improve upon your ideas. A few things will happen when you do it: your ideas will improve when you listen to feedback, and your own ability to articulate your ideas and your conviction in them will shoot up tremendously when you talk about your ideas a few times. Finally, when the world starts talking about your ideas, even your peers will sit up and take notice of them. That’ just the way we humans behave – we just need someone to initially endorse the ideas for us to support them.

Don’t try to boil the ocean…rather, establish beachheads

Very often, when we are chartered with a change agenda, we immediately start daydreaming of world domination. We start fantasizing how we will change the world with our romantic ideas, how we will become the next big thing that mankind has never known! Armed with such ‘dangerous’ ideas, we run like possessed spirits looking to infect everyone with our newfound ideas, energy and enthusiasm. However, depending on how the world sees us, they either ignore us, or shun or simply reject our ideas! Even if our ideas somehow get decreed by law, people in democratic workplace simply choose to ignore them and keep doing things their own way. So, what do you do? If you force yourself further upon people, their resistance only hardens. You need to back off. In short – don’t try to boil the ocean. That is simply not the 21st century way of doing things. Ideas, take a subset of the problem that is more tangible, and has higher chances of accepting your ideas. Take that up and establish the beachhead, and create a rocksolid success story around it. That will earn you much better support than aiming for land grab.

Socialize with key stakeholders…multiple times

No idea can survive in isolation. Being a lone ranger is of no help in pushing any significant idea in any meaningful manner. It takes a village to raise a child. If your idea is what I like to call ‘laminated’, meaning it can’t be modified or soiled, then it is meaningless. First of all, to make people take any level of meaningful interest in it, the idea can’t be positioned as being immune to modifications or enhancements. If it appears so much change-resistant, people might reject it because they might think of it as a mandate much against their own views about it. Secondly, if they have not had chance to put their fingerprints on it, even the idea might remain immature and not grow up to become strong enough to deal with all complexities. So, the key is to socialize the idea with key stakeholders as many times are it makes sense. Each interaction might make the idea one baby step better and the eventual result might exceed all your initial expectations.

So, there you go. These are my seven learnings on how one can establish credibility in a democratic workplace. What are your learnings?

Role of Integrative Thinking in Project Management

I just finished reading the brilliant “The Opposable Mind” by Roger Martin. He introduces the notion that we all possess the so-called  “opposable mind” which has this amazing capability to simultaneously hold two contradictory views about a problem.

The conventional wisdom is to try to find a via media but that is perhaps meekly surrendering to complexity by taking a short-cut to a suboptimal solution. He argues that the some of the most exceptional leaders do not succumb to the obvious “either/or” thinking but rather work patiently towards synthesizing the best from both of these opposing views to create a best-of-breed solution that is far superior to either of these. He calls it “integrative thinking”.

Martin writes, and I quote:

“…the leaders I have studies share at least one trait, aside from their talent for innovation and long-term business strategy. They have the predisposition and the capacity to hold two diametrically opposing ideas in their heads. And then, without panicking or simply settling for one alternative or the other, they’re able to produce a synthesis that is superior to either opposing idea. Integrative thinking is my term for this process – or more precisely this discipline of consideration and synthesis – that is the hallmark of exceptional business and the people who run them.…Human beings, it’s well known, are distinguishes from nearly every other creature by a physical feature known as the opposable thumb. Thanks to the tension we can create by opposing the thumb and fingers, we can do marvelous things that no other creature can do – write, thread a needle, carve a diamond, paint a picture, guide a catheter up through an artery to unblock it. All those actions would be impossible without the crucial tension between the thumb and fingers.…Similarly, we were born with an opposable mind that we can use to hold two conflicting ideas in constructive tension.”

The book is a treasure trove of how go develop integrative thinking, but I was struck by how much it is relevant to each one of us at all levels, not just for the leaders at the top. The field of project management is all about making sensible but often hard trade-offs. Effective management of Project Management Triangle is literally the holy grail of project management – one that not only is the nemesis of every project manager but is also, in fact, the genesis of modern project management. In layman terms, what we mean is that out of Scope, Cost and Time, you may pick up any two, but can never meet all the three of them at the same time. So, if the requirement is to build replica of Eiffel Tower in just three months and ten thousand dollars, then yes, it can be built but it might look more like a school project. If it is a fixed-scope project like migrating all tax payers to a new software by close of the current financial year, then one might need to look at costs involved without which either one of the scope of the time might not be possible to meet.

However, what ends up happening in reality in many situations is that a project still ends up taking the amount of money that is takes, and yet the scope delivered is too little, too late!

If one were to look at modern project management (though most of us in software industry would probably call it as ‘traditional project management’), I think we just don’t have any similar notion of integrative thinking. The only treatment I have seen is perhaps in the Theory of Constraints where the approach is more holistic.

In software development, the conventional project management is modeled around industrial model of a production process – the so-called waterfall. In a linear, sequential flow done by silos that specialize in a single functional area, there is natural tendency and inclination to optimize the area of responsibility. For example, a design team might be most concerned with how elegant their design is, whether is meets the future issues of maintainability or portability or not. Similarly, the high wall between developers and testers is industry-famous – which is a major reason why developers don’t trust testers (“they will come up with only Sev 3 bugs and kill us with volumes towards the release, and expect us to fix them all before GA”) and in turn, testers don’t trust developers (“they can’t write clean code”, “if only they did better code reviews and unit testing and found all code-level defects, we could do such a better job of finding all Sev 1 bugs and focus on performance and reliability aspects”). Clearly, such a process breeds a mutual trust deficit, and the narrowly focused project roles simply perpetuate it further. What happens is the tragic story of optimization of parts at the cost of sub-optimizing the whole – completely anti-lean approach!

Agile software development (the concept, not a particular methodology) helps by offering to eliminate such artificial boundaries that force “either/or” thinking. Instead of taking a monolithic approach of meeting 100% of the project triangle, it offers to simultaneously meet part of the scope at part of the cost in fraction of time that what would normally be needed in a waterfall model. However being recently introduced to this concept of integrative thiking, I am still thinking if agile philosophy fully addresses it, and on the surface, it doesn’t look like. However, I have been proven wrong in the past, so we will see…

Inexperience is the new Competency?

Past experience is often considered to be a proxy for future performance. After all, when there is no single perfect way to forecast someone’s future performance, the best you can do is to look at the past track record and extrapolate it! However, experience will only tell that if the given person were to undergo similar experience once again, would they achieve similar results? But, how do you know that experience is not really getting in the way of future success?

Last week, I was chatting with an old friend over lunch where our conversation, incidentally, drifted to what really makes someone take on unknown challenges, like startups. He was part of a startup for last few years that made, through a lot of hard work and a bit of luck, a decent exit and he had recently taken up a ‘regular’ job. So, adequately credentialed to comment on risk-taking. His view was that while logic and analysis was required to solve hard problems, to solve problems unseen and unknown, one needs to have an emotional perspective and finally the guts to take the call. A rational thinker might overthink several steps ahead and conclude it is not worth taking the risk, or perhaps the outcome might not be as rosy as envisaged. However, someone who is viewing it from an emotional angle will see it differently and eventually the toss-up is between someone who shows exemplary guts rather than chickens out! Maybe that is the reason why young people make better entrepreneurs? The experience perhaps makes us cautious enough not to drop safety guards and recklessly venture into the unknown, while an inexperienced youth, driven solely by the youthful exuberance and unconditional confidence, not only takes unknown challenges head-on – they even go out and hold the muleta to invite the bull!

Paul Arden’s book “Whatever You Think, Think the Opposite” is a favorite of mine because it leaves you with more questions than it even strives to answer. Here is a nice passage from the book –

“Old golfers don’t win (it’s not an absolute, it’s a general rule).

Why?

The older golfer can hit the ball as far as the young one.

He chips and putts equally well.

And will probably have a better knowledge of the course.

So why does he take the extra stroke that denies him victory?

Experience.

He knows the downside, what happens if it goes wrong, which makes him more cautious.

The young player is either ignorant or reckless to caution.

That is his edge.

It is the same with all of us.

Knowledge makes us play safe.

The secret is to stay childish.

So, there you go again – experience seems to be standing in way of performance, and inexperience is perhaps the new capability! However, the world works exactly opposite – we reward experience and shun inexperience. The result is that we end up creating a strong use case for folks who will go any length to ‘demonstrate’ experience. And when there is a demand-supply imbalance, the supply will need to become extremely innovative to create differentiation to carve out a niche for themselves.

Look at this picture I took from a car windscreen – surely this IT professional knows his business and doesn’t need a his resume – he pretty much wears it on his windscreen, and just a glance at his windscreen is enough to send shivers down other job applicant’s spines! What does it tell about the ‘experience’ of the individual? Well, I don’t know about you, but one thing it does tell extremely well is that our friend is very well-experienced in changing jobs. However, not sure if you want to hire someone with those skills and give him yet another chance to demonstrate or possibly hone his skill further!

Of course, we all change jobs – in fact, we all need to change jobs! After all, of what possible use is the freedom and flexibility of being able to decide one’s own destiny if one doesn’t exercise it? I am not against it as long as one is able to convince others that they are not just being honey-bees sucking the nectar off flowers, but are actually going to be around a little longer and hopefully, make some small contributions while they are there. However, how does such job-hopping make someone stand out as ‘experienced’ and hence better-qualified for a new job? The problem again is that we have over-rewarded such promiscuous behavior because that, to us, means rich experience which loosely translates to future performance. If only that was half true!

 

And if you look at this old soldier, don’t you get this feeling – my goodness, someone get a drink for the old chap! Now, I have the highest regard for soldiers – they protect us from bad guys when you and I get to stay in warm comforts of our homes. They lay down their lives when you and I won’t be willing to even step up the courage and face up street rowdies. However, my point here is on how many medals does one need to command respect about one’s experience?

He must be carrying a lot of metal on his chest, and what social approval or recognition is he seeking anymore at this age? Does he still need to prove a point? I am sure those you know him don’t care anymore how many kilos of metal he is lugging around, and for those who don’t know him – well, does it even matter?

Once I was leading a complex hi-tech product. We were building a core router. Not a run of the mill product, but a really complex pieve of hardware and software that powers your network. I had to build a team of 100 development engineers – and staff it in 3 months! To build a team of that many development engineers in such a complex technical domain is a challenge to say the least – not just in Bangalore but anywhere in the world. I took the challenge and hired a set of technical leads – none of whom had any idea about core routing. Not because I got a kick out of it, but simply because there was no one with required skills and instead of waiting forever, I did what I had to do – hire the best talent from other technical domains, like switching, network management, embedded software, etc. and took them through grueling self-learning in a 5x compressed schedule. In just a matter of few weeks, we started seeing results that were encouraging for us to move to the next stage of our seriously uphill battle. One thing I have learnt in staffing large teams is that you can’t have all Einsteins in a large team. You will have to consciously make hard decisions and take calculated risks if you ever want to make progress. I was going on with my hiring for the development team but still woefully short of the ‘target’ to get the project going. Suddenly skies opened up and I was made the ‘generous’ offer of taking in new college grads, so affectionatele known as ‘freshers’ in our part of the world. They were M Tech graduates but without any work experience. I was ‘required’ to take ~20 of them because as a company, we had the campus hiring program and we all needed to absorb them in our teams. I like having ‘freshers’ in my team because they bring the endless energy, daring and teamwork that simply injects new life in any team. Knowing that I was in a precarious situation, I decided to ask for double that number of grads because they were simply available to me! They were there literally the next day! My challenge was to now ‘train’ them – and who were the trainers – the folks who had learnt the subject just a few weeks before them! Well, to cut to the chase, we soon lined-up all the ducks and after six months, we were finally system testing the product – just as per the schedule. There were other challenges in final integration, but not because of taking ‘inexperienced’ folks. In fact, it anything, we had cruised to that stage only because 40% of the contributions had come from inexperienced brainpower in my team. Today after a decade, most of them have moved on to become young budding successes with a lot of potential for kicking even bigger successes! Moral of the story – bet on inexperience, they bring a lot of experience!

So, there you have it. The future is unknown. We have no reasonable clue how tomorrow’s problems will be. If all we do is take up yesterday’s experience and hire based on an assumption that tomorrow’s problems will be a linear extrapolation of them, we are blissfully ignorant of what lies ahead and perilously close to extinction. The other day I was chatting with my teenage son who wants to be an architect. His question was – why should he study biology? My response was – if you want to be an architect, you will be making houses with materials that are yet to be created and technologies yet to be invented. I made a bold assertion. I said – in my view in next 15-20 years, the houses will be made of natural plants and trees that will allow a ‘grow as you go’. For example, you will make a two bedroom house when you are a young family. Now you know that you will need two more bedrooms in next ten and fifteen years respectively. So, you will actually start ‘growing’ them for the next couple of years and just when you need them, those ‘rooms’ will be ready! How about that for a futuristic fantasy? But, seriously, think about it a few times and suddenly it doesn’t sound so unrealistic anymore. Does it? I could conjure it up only because I am unexperienced in both these disciplines – architecture and biology :).

Are you carefully grooming your inexperience as the new capability?