Why user stories make sense?

User story is a popular mechanism used by most agile methodologies to communicate user requirements. Actually, this is only partially true. User stories are meant to be a placeholder to initiate an early conversation between the product owner and the team on key hypotheses so that a quick validation of them could be done to refine/confirm/reject our understanding of what the customer really wants. To that end, user stories are not anything like the requirements of yesterday – they are not even remotely meant to be complete/comprehensive and so on. 

The reason user stories (and not ‘well-formed’ requirements, if that is ever possible) makes sense is because we human beings are not experts in following the written word, and are likely to misinterpret requirements even when they are explicitly written down, especially when the communication is a one-time event and not an ongoing process. (if you don’t believe this, just visit this interesting site http://www.cakewrecks.com/ that celebrates real-life examples of how something as simple as icing on the cake can go horribly wrong despite really simple and absolutely clear instructions!). And we are talking about building complex mission-critical systems that must operate 24/7 with top speed and efficiency. If only the written word could be consistently understood by the receiver as intended by its author… 

On the other hand, if there is a continuous two-way dialog between the product owner and the agile team, such purposeful brevity leads to curiosity which then leads to a constantly improving and better shared understanding that refines as the product gets developed incrementally and gets periodic user feedback. 

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer's wants and needs.

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer’s wants and needs.

The key benefit of user stories is that instead of waiting for weeks (even months!) to get a fully-bloated and rather unprioritized PRD which is supposed to have fully-baked requirements while the development team sits idle all this time, is that identifying highest priority user stories and using them  to develop a prioritized product backlog allows the teams to get started much earlier and start developing features which could then be put out in front of customers to get real feedback (as opposed to individual ‘opinions’ that might/not best guide us in an uncertain environment). This is especially important because in the past, when the world was little less complex and much more underserved. I purposefully use this term ‘underserved’ because it is not that people have suddenly become much more demanding about what they like or not, but were just told there were exactly three carmakers to choose from, or just two operating systems to choose from, and so on. However, with rapid advancement of computing paradigms and constantly lowering cost of ubiquitous communication devices, they suddenly have the opportunity to demand what they want, and hence classical ‘forecast’ models of requirements elicitation, design or production (at least in the manufacturing sense) don’t work so effectively as much as the newer ‘feedback’ driven models that allow for developing key hypotheses (and not hard requirements carved in stone) which could then be quickly and cheaply delivered as ‘done’ features so that customers could tell us if they like them or not. Based on such valuable customer feedback, the team could iterate to either refine the feature, or to pivot, as the case might be. In the past, this might take the entire product gestation cycle, by which time, many, if not most, things might have undergone significant changes, and the entire development costs being sunk by that time, not to mention complete loss of any window of opportunity.

As Facebook says – Done is better than perfect. User stories allows developing a small slice of the product without really perfecting the entire product, but facilitates the process of validated learning that eventually helps develop a product with much higher chances of meeting customer needs.

In today’s world, you probably might not have the luxury of having investors wait multiple years for an exit, or customer waiting several quarters for a perfect product when the competition is willing to serve them faster (even letting them lay their hands on an earlier version and give feedback thus making customers a co-creator of the product), or employees working month after month without getting any meaningful feedback from customers. And we know that absence of any feedback eventually leads to erosion of trust. Incremental product development could help you bridge such trust deficit by delivering highest value to customers early and periodically, and user stories might help you get your project a quickstart.

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?

What Emerging Markets Customers Really Want from the Internet: An Indian Perspective

[This article was published in PDMA’s magazine Visions, issue Q1 2013, based on my paper presentation at PDMA Conference 2012]

Introduction

India is a new gold rush market. Home to some 1.2 Billion people, half of whom under the age 25, and buoyed by the recent economic growth, the country is poised to be a major economic powerhouse for the next few decades before becoming the second largest economy by 2050. In this short article, let’s review some of the data and trends that I discussed earlier in my presentation at the PDMA conference in Orlando, Florida.

Internet in India officially started on the 48th Independence day, 15 Aug 1995 when VSNL started offering services. However, adoption for the next ten years remained elusive largely due to poor bandwidth of the then dial-up connections and relatively high costs of computers. In 2004, government formulated broadband policy, and adoption picked up in 2005 but has always remained below worldwide averages.

[slideshare id=14856633&doc=tvpdmapim2012-121023162654-phpapp02&w=650&h=500]

Impediments and Growth

Some of the digital impediments that still hamper speedier adoption of Internet in India include poor and costly bandwidth, lack of content in Indian languages, payment and delivery issues in online retail sector and lack of one-stop e-governance solutions. Despite these formidable challenges, India today has 140m Internet users, which is roughly 10% of the population. It grew 25% from last year, and the projections are 300m Internet users by 2014.

Indian Internet CafeThis is in sharp contrast to 950m cellphone subscribers, out of which 350m have data plans, and only about 30m smartphones. The recent growth in smartphones can be attributed to the entry-level Android devices that have dramatically lowered the price-point for an Internet device, thus fuelling an entirely new category of ‘new to net’ users who will perhaps skip the desktop devices altogether.  However, this new class of users is responsible for a good 60% of the Internet access. As an example, 30% of new Facebook registrations are happening from mobile. Clearly, mobile as the default access device is a critical success factor.

Engagement

Top five activities on Internet by the amount of time spent include Social Networking, Entertainment, Portals, Emails and Search. In Social Networking, Facebook is the clear winner, and India is the second largest country with 65m users that has grown eightfold in last 2 years alone. Projections are that by 2015, India will be the largest country on Facebook. Similarly on LinkedIn, it is the second largest and also on Twitter in terms of active users. Clearly, that is a growth category. In terms of Entertainment, India thrives on Bollywood and Cricket, and hence it is not a surprise that this is a highly prized category. Bollywood produces over 1,000 movies a year and Indian Cricket is the largest market for entertainment cricket (i.e., five-year old Indian Premier League that is roughly a $5Billion industry now) as well as the professional variety. Another high-growth area of infotainment is news, which is evident from literally dozens of national, regional and local news channels in a country that is also the largest DTH market in the world.

Online Retail

One category that is not in top five is the online retail. It stood at $10B in 2011, and is projected to grow to $14B this year. It had a slow start, plagued essentially by problems in payment and delivery systems, but some new trends are very promising. 80% of this comes from travel, which has been a traditional pain point in India. Other categories like books, electronics and apparels are looking up. Flipkart, an online book seller, now ships over 30,000 orders a day and is poised to be the first Indian internet company with $1Billion valuation. IRCTC, which is essentially a government owned corporation and sells railway tickets, which has been another painpoint for ages. It does close to 200m payment transactions a year for a network that carries 10Billion passengers annually.

An interesting data-point here is that a good 150m Internet users are ‘internet-ready’ but only 10m are actually shopping online. So, there is a huge opportunity to bring them online by creating innovative solutions that take the pain away from online buying cycle.

Conclusion

Internet breaks down barriers of pricing and distribution that have traditionally kept big multinational players away from several emerging markets. In the context of India, it is fast emerging as a high-growth vehicle for markets that have been historically underserved, even by local players. The key to success is in being able to design products that eliminate bottlenecks in the complete online buying cycle at an affordable price-point. Indian markets allows Internet-scale problems to be tested for key hypotheses, which can then also be taken for global rollouts in comparable markets globally.

The Joys of Designing Agile Solutions for New-Age Problems

Pune is hosting India’s very first Scrum Gathering this year in July with the theme of “Scrum – Kal, Aaj aur Kal“, meaning the past, present and future of Scrum. I appreciate all efforts by Madhur Khaturia and his team in making it happen. I hope and believe it will be yet another milestone in India’s journey towards agility, and will stimulate a whole lot of new ideas and conversations thus ultimately leading to increased awareness, higher adoption and more breakthrough products from India.

Scrum Gathering India Regional 2013

Scrum Gathering India Regional 2013

I got confirmation mail yesterday that my workshop on “The Joys of Designing Agile Solutions for New-Age Problems” has been accepted for Scrum Star Trek, which is the track for discussing The future of Agile Philosophy and Scrum Framework. This would focus on new techniques, methods , innovations and concepts being used by practitioners. This would have workshops, concept presentations and round-tables on future of Scrum. The other two tracks are Scrum From the Trenches and Scrum Accomplished.

I am really looking forward to this workshop. Here are a few details about it. 

Agile methods, and scrum in particular, help organize the work by prioritizing items could be done and delivered in a small timebox. While its simplicity and effectiveness is based on timeless experiences that make it an effective approach for a certain class of problems where a product backlog exists in some shape or form, and there is some basis (scientific, data-driven or otherwise) for the product owner to prioritize features, it doesn’t really offer any clear guidance for a newer class of problems where, for example, the work is so radically new that there might not be a product backlog. For that matter, there might not even be a market, a customer or a product to begin with. Think of you specifying and designing ‘something’ when no such product ever existed – not just in the minds of customer but even in the dreams of its designers! How can one have a ‘product owner’ or a product backlog when there is even no source of such information? All we have is a loose set of ‘ideas’ which might or not work. Distilling such innovative ideas in a product or a sprint backlog might be too premature. We clearly need a different approach than a thoroughbred Scrum. 

In the last few years, the work on Customer Development and Lean Startup by Steve Blank and Eric Ries has led to putting a framework in place for solving such class of “VUCA = Volatile, Uncertain, Complex and Ambiguous” problems in a more systematic and result-oriented manner. These have greatly helped startups and entrepreneurs where failure rates tend to be extremely high traditionally. In this half-day workshop, we will experience to joys of creating a product starting with Design Thinking and apply principles of Customer Development and Lean Startup and explore the nuances of designing agile solutions for such new-age problems.

Do you have experiences to share in this class of new-age problems? How do you design effective solutions that allow you to thrive on ambiguity, deal with unknowns and keep moving at lightning speeds despite maintaining a holistic sense of agility? Share back your ideas and experiences…

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?

So, does agile really kill innovation?

In continuation of my earlier blog post on ‘Does Agile Kill Innovation?’, I had a great time moderating the panel discussion at Agile India 2013 with Henrik Kniberg, Owen Rogers, Sujatha Balakrishnan, Udayan Banerjee, Praful Pillay and Sudipta Lahiri. The panel discussion was literally the last program at the end of two long days of management conference – but despite that, we had 60-70 folks throughout the session.

Agile methods, with their rather short-term focus on achieving a ‘done’ feature seem to give away an impression that the eventual goal of a sprint is delivering such a full-baked feature. However, the new-age thought process seems to be more like ‘done is better than perfect‘. Question is, does agile implicitly become the rate-limiting step for your innovation process by self-imposing a stringent and non-negotiable completion criteria that possibly can’t be met by innovation-led ‘stories’ where the discovery and experimentation is generally a long-haul process and failure is such an acceptable outcome that we want to fail early and fail often!

We had some interesting perspectives ranging from ‘agile kills innovation’ to ‘agile accelerates innovation’ to ‘it depends’. Some of the ideas that emerged out of the panel discussion were:

  • agile, and scrum in particular, seems to be well-suited to the class of problems where a reasonably well-defined product backlog exists to begin with. To that end, there is some level of agreement on ‘what’ is to be done in the stacey’s matrix. For such problems, maybe ‘20% innovation’ user stories could be designed that allow implementing features with lesser uncertainty on ‘what’ and ‘how’ and leaving the uncertain aspects to the innovation user stories. This could ensure that the sprints are not losing steam just because of taking up innovation-led tasks, and neither are those tasks suffering in the anxiety of maintaining (and improving) team’s velocity.
  • for problems that are so radically new that don’t have any notion of a product backlog to begin with, perhaps ideas from lean startup (and design thinking) make more sense where the notion of ‘velocity’ is not so pronounced as compared to the ability quickly iterate through the build-measure-learn loop in shortest amount of time, and test various hypothesis around customer discovery or MVP, or any other moving part
Does your process let you think outside the box?

Does your process let you think outside the box?

  • one attendee from the session remarked that in their organization, they give a ‘break’ in-between the sprints to take up such innovation-led tasks, and it is working for them.
  • in organizations and teams that get too obsessed with meeting predictability goals and focus on velocity, there is a risk that teams don’t attempt big bets but just chipping away at the small bets. So, that version of agile is probably not going to lead to any radical or breakthrough or disruptive innovation, but more likely suitable for incremental innovation.
  • in services companies, the essence of business value is predictability of service, and hence there is some level of disconnect with the whole notion of experimenting and failing that might impede any innovation. To that end, achieving agility could be hurting innovation. However, there are always possibilities to innovate in such customer-facing processes, and one needs to deliver proof-points and earn the charter.

These perspectives made for some good conversation, questions and counterpoints. After all, what is a good panel discussion without some arguments and controversies!

So, does your agile really kill innovation? You tell…

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?

What’s the People factor in your Innovation equation?

Innovation is the hot new buzzword of our time. Everyone seems to be badly smitten by it. Going by the popular literature, those who don’t innovate are assured to perish sooner than later. Given that previous silver bullets Total Quality Management of 80s, Business Process Reengineering of 90s, and the most recent of them all – Outsourcing in early 21st century – have still left a LOT to be desired, there is clearly enough interest and expectation if Innovation can finally deliver! Coupled with a world still edgy after major Global Financial Crisis and an uncertain Euro zone, and we have perfect conditions to embrace Innovation in all shapes and forms – right from black magic to a holistic way of doing business – even if it still turns out to be a whimper.

Wait! Of course, it would be blasphemy to even as much as suggest that innovation could turn out to be a whimper! Like all of you good people, I too believe innovation is the key to sustainable competitive advantage in the increasingly uncertain and hyper-dynamic world. But, let’s just rollback to 80s for a moment – didn’t they say the same about TQM in those good old days? Or about BPR in 90s? Or about outsourcing until the last decade? Each generation came up with its own silver bullet fervently believing in its potent powers to slay the demons of poor corporate performance (in whatever metrics what you measure – be it topline revenue, or bottomline profits, or marketshare, or employee engagement and so on). And yet, history – the roughest of them all teachers – has reminded us time and again how naïve and wrong we were all along! All these management systems – well thought out and backed by years of irrefutable research and solid data – were heralded as the ultimate panacea in their heydays. However, they lasted only till the next crisis! The next sets of crises were much more powerful, much bigger and more ‘new’ than the previous ones, and like the stains of bacteria that grow resistant with each new antibiotics, they were invincible with the then start of art methods. Clearly something was amiss.

Here’s my take – all these systems were exactly that – just systems! They sought to fix the processes without really putting people in the middle of the equation – even though all the work was carried out by humans. I think we took Frederick Winslow Taylor a tad too seriously when he said, “in the past, the man has been first; in the future, the system must be first” in The Principles of Scientific Management back in 1911. Of course, we forgot to read the next two lines right after this sentence, “This in no sense, however, implies that great men are not needed. On the contrary, the first object of any good system must be that of developing first-class men; and under systemic management the best man rises to the top more certainly and more rapidly than ever before”. We simply delinked people from process and attacked the process performance problem without acknowledging that if people are not motivated enough, the performance improvement payoffs might either be short-lived and might not sustain at the same levels in the long run.

So, is Innovation is also going to meet similar fate and become another exhibit at the Museum of Management Systems? Maybe, or maybe not! Depends on how we change our strategy this time. If we continue to pay lip service to innovation as yet another management mantra, I am sure we will see another new management system in next few years. But if done right, we could certainly create better results that could last much longer than previous generations of management systems. Actually, there is just one thing that needs to be done right – get the people factor back into the equation.

Somewhere in mid-90s and beyond, we started throwing around the words ‘knowledge economy’ to represent the shift towards an economy that primarily dealt with ‘knowledge’ as opposed to, say, manufactured products. It signaled the Negraponte Switch from ‘atoms’ to ‘bits’. The term ‘knowledge’ worker’ came to be known as the move from blue-collar worker to white-collar worker  to pink-collar worker and finally to what I call as the ‘round-collar worker’ – someone who makes money from their ‘brain’ more than their predecessor cohorts of workers, and often have slightest regard for a formal workplace power structure and thrive in informal and empowered environment. They are on the top of their game, and don’t require any hierarchy to support them. Of course, the ’round-collar’ in their moniker comes from the quintessential round-collar tees that not just signify a more relaxed taste in dressing-down, but also brings a sense of confidence and swagger that typically comes from someone who knows their stuff.

Another less visible but far more important thing to note here is that in last couple of management systems, this is perhaps the first time that the worker has sprinted ahead of the system, and has become much more important – so much so that they has made the system redundant. And needless to say, the existing top crop has no clue how to deal with it!

Now let’s get back to the innovation story.

Imagine going back into a modern workplace, full of knowledge workers and telling that from tomorrow we have a new management system, and it is known as innovation. I will leave you to visualize rest of the conversation in your minds :).

So, how do we get it right? Unlike the previous generations of workers, where each of the management systems was imposed top-down, I don’t think this approach can work anymore in flat and egalitarian workplaces of today. Innovation process must be driven bottoms-up that unleashes individual human potential for creativity and challenging the status quo. So far, we hired and groomed professionals who ‘complied’ with our laid-down processes – we hired those who ‘fitted’ in our culture, we promoted those who furthered our existing thought process. Power hierarchy in those organizations was perfectly designed to promote compliance. There was hardly any place for non-believers, doubters, questioners, diagreers, dissenters or harbingers of change.

The current and upcoming generation is anything but that!

How are you going to channelize their talent and energy into something that works for you? How are going to enter the short-term vs. long-term battle? How are you going to embrace a higher risk/reward equation? How are you going to deal with the brash and young workforce that might give you maximum a few months as an employer before going out across the street and creating a new startup that might eventually buy you out a few years down the line?

By writing a new management system that once again puts checks and balances and builds a system of mistrust which saps their energies and stifles their creativity, or by trusting in their abilities and further liberating them? Depending on what approach you take, you will be deciding whether innovation is going to work for you, or will just end up becoming yet another exercise in futility. Eric Douglas has some thoughts on how leaders can make or break the people factor by how they comes across to people. Richard Branson places much higher premium on getting the right people for entrepreneurial success, which is perhaps strongest form of innovation, for nothing could be as audacious and risky as taking an idea and creating a business ground-up. I had blogged about some of the reasons why people don’t innovate in organisations (but rather end up leaving them and do it on their own!).

Goran Ekvall has identified ten innovation climate dimensions that could serve as a great starting point for organizations to self-assess how ready they are to embrace innovation:

  1. Challenge How challenged, emotionally involved,and committed are employees to the work?
  2. Freedom How free is the staff to decide how to do their job?
  3. Idea time Do employees have time to think things through before having to act?
  4. Dynamism the eventfulness of life in the organisation
  5. Idea support Are there resources to give new ideas a try?
  6. Trust and openness Do people feel safe speaking their minds and offering different points of view?
  7. Playfulness and humor How relaxed is the workplace-is it okay to have fun?
  8. Conflicts To what degree do people engage in interpersonal conflict or ‘warfare?”
  9. Debates To what degree do people engage in lively debates about the issues’
  10. Risk-taking Is it okay to fail?

There is enough literature, theory and evidence to suggest the people factor is core to the culture of innovation. Yet, I continue to be amazed that smart organizations tend to create an elaborate management system to ‘support’ and ‘control’ the innovation process. When I meet folks form industry and listen to presentations and papers, I am repeatedly shocked to discover how much focus is on process part of yet compared to how to really enable people and democratize the process of innovation! I hope that understand this can’t be yet another checklist item on their marketing brochure that can win them next contract – it is much deeper and bigger than that. It’s their future that they can’t afford to shortchange!

So, what’s the people factor in your innovation equation?

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.