Today evening, we lost at least 9 innocent lives in the fire at Carlton Towers, Bangalore, and many more are still battling for life. All these were office-goers who worked an honest living and were part of the burgeoning IT industry. While details will be out in next few days, preliminary reports, live tweets from some of the people stuck in the building, and eye witnesse accounts all suggest that these most of these lives could have been saved. I write this blog post to offer my tribute to those lives that we lost, and want to share my anguish by means of lessons that we project management can (and must) learn and hopefully avoid such tragidies in everyday project, and in homes and workplaces where we work and our families live.

Emergencies can strike anytime

This was otherwise a perfectly normal day – as normal as it gets. No rain, no thunderstorm, not really hot day, no major loadshedding. We don’t know whether it was a short-circuit (reports at this hour do suggest that short-circuit was the most probably culprit), or some other cause, but the circumstantial evidence suggests that there was nothing that could perhaps be blamed on an ‘external’ factor. I am reminded of the famous lines from Fred Brooks timeless classic, The Mythical Man-month, that it is ‘termites’ more often than the ‘tornadoes’ that hit the project. Most often, our carelessness and neglect sustained over time leads to breeding grounds for such termites and results into such grave catastrophes. It is important to ensure that regular health checks are part of any infrastructure, project or a system, for nothing is big enough to escape an emergency, even if its probability of happening might be miniscule.

Continue reading ‘What can fire tragedies teach project managers?’ »

Share This Post
  • Share/Bookmark

Innovation is the survival mantra of today, chanted by everyone, but acted upon only by a few. Companies that routinely invest in innovating for the future are eventually able to putpace their competitors, everything else being equal. However, not everyone is able to kickstart, manage, sustain or nurture an innovation-led culture. Large monolithic organizations often become victims of their own processes, structures and past strengths. Smaller ones generally innovate to survive and succeed, but are they always truly innovative?

I once worked at a large European medical systems company where we worked on workflow automation software for Radiology departments in hospitals. We had not one but three #1 products in the market! We were #1 in Germany and that product had a great database system. We were #1 in Sweden and that had a great workflow. And we were #1 in the Netherlands and that product had a great GUI. However, we were #Nobody in the global market. While this was ‘achieved’ due to a very decentralized governance model in that company which allowed localized innovation to meet that market’s highest priority needs, it also created islands within a global company. Local success in those national markets was super sweet, but it impeded success in global markets. At that point, I thought this was a classic large company problem – until I worked for a small company. We were a typical bay area company with several cool products in a very niche market – the only trouble was none of them looked like they were from the same company. At one time, we counted five different GUIs for our products – all different in technology, all different in style, all different in workflow, all different in product roadmaps, and all different in egos (ok, I made this up, but not by that much!). We had a virtual in-house industry – after all, who needs competitors when you have colleagues like that.

So, I witnessed excessive innovation without any direction or coordination in these two personal experiences, but I was really shocked to learn of more advanced methods, like thwarting or sabotaging innovation in the article Microsoft’s Creative Destruction. Even if just 10% of what the article claims is true (some people might argue that it is sour grapes), it still must be extremely sad and demotivating for any bright, young, enthusiastic engineer to be on one such project, only to see fruits of his labor allowed (rather, forced) to rot.

Continue reading ‘Who is sabotaging innovation in your company ?’ »

Share This Post
  • Share/Bookmark

This was the theme of IIMB-NASSCOM Leadership Summit 2010 where I had opportunity to share my views as a panelist. It was a great evening where we panelists got to share our thoughts, and also learn from each other and from the enthusiastic participants, essentially students of PGSEM and PGP and other courses of IIMB. In this blog, I will share some of my personal reflections that I shared at the summit.

One thing about predicting future is while short-term predictions tend to be conservative, the long-term predictions tend to be optimistic. So, while we still don’t have personal flying machine, fuel cells, foldable LCDs or many of the several James Bond gizmos, it is also a fact that short-term bandwidth requirements, mobile handeset adoption, and even the longevity of recently conclused recession have all been proven wrong and how! The recent controversy about melting of Himalayan glaciers and threat to Amazon forests has only once again vindicated the theory. 

Issues

Continue reading ‘IT industry at cross-roads: Top three priorities for IT companies in years ahead’ »

Share This Post
  • Share/Bookmark

Many project reports are exactly that much – “Aal izz well” (and for those uninitiated to the latest bollywood blockbuster ‘3 Idiots’, it simply is “All is Well”). They speak of yesterday’s weather, don’t help much in forecasting the future and the only thing they help create is the impression that all is well! An important fact about project status report that people don’t realize is that until the time a project has met its objectives and delivered its promised goods, the only ‘output’ from a project is really the communication to its stakeholders and the outside world.

However, in real world, project reporting is often treated with contempt it hardly deserves! I have seen more project managers at the extremities – either too fanatically pushing the project report whether or not it helps anyone, or literally delegating it to an admin assistant to just compile it together and send it out. In the former case, a lot of team effort is being wasted to create worthless pieces of information that no one cares, except perhaps the project manager who thinks his only job is to create beautiful masterpieces that history will remember him for. In the latter case, the project manager perhaps considers the activity a waste of time that serves no one, and hence decides to take matter in his own hands. Whether the intent in both these cases is bondfide or not, the project and its stakeholders are definitely not being served. Those project reports are, thus, not an administrative irritant, but must be treated with due importance.

Here are some of the ways you can improve your project reporting:

Continue reading ‘Aal izz well !!!’ »

Share This Post
  • Share/Bookmark

What is worse then an anarchy ? You might say that is the absolute abyss, but I think blind allegiance is even more dangerous (and that includes following the letter but tweaking the spirit – things like ‘creative accounting‘ or its parallels in every field). Anarchy at least allows for things to become ‘better’ in order to survive – whether it is the idealogy, resistance, or even musclepower, or any other ills (and hopefully at some point, social forces of constructive destruction take over). But in a land where unquestionable compliance and blind allegiance rule the roost, IMNSHO, is like a terminal patient off the ventilator support. When people are on their deathbed, they don’t regret things that they did but much rather the things they did not do!

In project management, life is no less colorful. We have process pundits (read “prescription police”) shouting from the rooftop with a megaphone on how heavens will strike them bone dead with lighting if they ever as much as strayed from the ’standards’. When projects are being postmortemed, we don’t often ask what or why the project did something that they did, but why they did not do things that they did not do. And quite often, you find answer in the map itself – because the map did not factor-in those conditions that were actually encountered on the terrain, the blind followers just followed the Pied Piper and danced their way into the river of death. What a terrible waste of human talent.

Why do we get stuck with methods so much that our result-orientation takes a back seat ? I think there might be many answers, but some that deserve merit:

Continue reading ‘Our methodology is 100% pure, our result is another thing!’ »

Share This Post
  • Share/Bookmark

Last Sunday, we had annual alumni dinner of Bangalore chapter of my alma mater, JK Institute of Applied Physics and Technology. During this event, we also hosted final-year engineering students who were in town on an education tour. I was asked to make a presentation to them on a topic of my choice. Here is what I did – I put together ten things that I felt are the most important non-technical things that anyone graduating from campus to corporate should know – that no one will ever teach them! I am sharing them here. It’s possible your Top Ten list might be different than mine, but feel free to share other things that might be helpful to the young engineers entering workforce in 2010:

1. Ethics

Share This Post
  • Share/Bookmark

It’s not about the project management methodology anymore. Frankly, it never was, even though it has triggered off some of the most senseless wars in the history of project management. Starting with Frederick Winslow Taylor’s Scientific Management to Henry Ford’s assembly-line based mass production system and eventually landing in a ‘flavor-of-the-day’ methodology (CMM, ISO, Agile, XP, Scrum, Lean, Kanban….and add your favorite one here), project management community, especially in software field, has seen it all…and still counting! All these project management methodologies have been eulogized as silver bullets in their heydays (and some still continue to be worshipped as we speak), and have subsequently been improved upon by the next wave of innovation driven by ever-evolving business needs, state of technology and the sociological changes at the workplace. However, each predecessor has been uncharitably rejected and unceremoniously relegated to trash by every successive methodology champs. However, that doesn’t seem to have stopped project woes, certainly not – going by the claims made in their marketing brochures :) . So, whom are we to trust – the overzealous champs or their ever-evolving methodologies ?

For most practitioners, novices and experienced folks alike, project management methodology became this one large target to shoot at, the advertisement to get the project deal, the crutches to hold the project on to, the lame excuse against change in project specs, the insurance against failures, perhaps the…raison d’être for project managers ? “Sorry, the manual says do it this way, we can’t change that”.The process handbook says we can’t take any changes anymore – tell customers to wait until the next release which is just six months away”. “You are not approved to prototype, so stop that effort”. “Our company’s org structure doesn’t allow an engineer to manage the project – the risks are too high”. “Our metrics are within the control limits, so I don’t understand why engineers fear a project delay”. Goes without saying, they come in all hues. 

Little did we realize that the ‘problem’ was a moving target. We continued to ‘evolve’ our ‘solution’ blissfully unaware that the problem was also upgrading itself. Every new fix has led to a newer generation of problem that seems to have outpaced the development of solutions – so far, and I see no good reason why we will never have a ‘perfect solution’ for every type of problem. So, it doesn’t amuse me when people on Agile / Scrum discussion boards try to indiscriminately apply those principles to just about every type of problem under the sun, and then when, predictably, things don’t work, they blame that Agile / Scrum is not being applied in its spirit. Have you ever seen a project manager so baptized that he won’t think beyond the book ? I think those blind preachers are just living like a frog in a well.

Continue reading ‘Does your project management methodology lets you free think?’ »

Share This Post
  • Share/Bookmark

Diagnosing the root cause of a problem is a critical analytical skill. Most often, what you see is not what you get – the symptoms might indicate something, but the root cause might be entirely different. Some cases require a short-term fix – an immediate one, while some require careful investment in the long-term to completely eliminate root cause of a problem. Generally, most problems require a combination of the two. While ‘Process Pundits’ favor a long-term, preventive action, the action-oriented Cowboys can’t wait for eternity and want some short-term, immediate corrective fix to the problem, even if the problem resurfaces a few weeks later. In a way, the corrective-action Cowboys are like John Keynes, who said: “The long run is a misleading guide to current affairs. In the long run we are all dead”. After all, of what possible utility would be a long-term investment if we are not around, say, next quarter. So, no arguments that an immediate need must be addressed first and foremost, but it is like the proverbial firefighting – lack of preventive action eventually leads to emergencies that simply need a big fire hose to douse the fire. Initial trivialization of small incidents only leads to benign neglect which eventually deteriorates into a full-fledged Frankenstien of problems that simply refuse to die.

If initial and repeated trivialization is bad, so is other end of the spectrum – taking every problem far too seriously and calling the army when a watchman will do. In a zest to solve problems, we sometimes make them appear larger than life, and then find solutions that would perhaps address every exception condition, every nook and corner – mindless of the fact that for perhaps 80% of the times, a 20% solution could have done. The result is wasted money, time and effort, and an overbureauracratic process that stifles not just creativity but even the work itself. Look at what happens to our bus driver in this nice story when he takes the problem a little too far: 

Continue reading ‘Are you splurging long-term dollars for a short-term fix ?’ »

Share This Post
  • Share/Bookmark

 (This plog post is contributed by Lt Col (Retd) Rahul Kumar, Managing Director of Srijan Consulting, Bangalore. In this post, he analyses recent failure of the Common Admission Test (CAT) conducted by the premier B-schools of India, the Indian Institutes of Management (IIMs), and raises key questions on how one should have done adequate planning, thorough testing, backup planning and then some more! You can write to him at rk@srijanconsulting.com)

The Business Management Gurus had a PLAN – to go online for CAT. And do I hear that this was all that was required? PLANNING was ZERO!

 

Continue reading ‘What can we learn from CAT’s failures ?’ »

Share This Post
  • Share/Bookmark

Did you check out the Agile Skills Projects yet ? It seems to be a new and interesting initiative to “… establish a common baseline of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices”.

They talk about Agile Skills Matrix that has seven essential skills, or the Seven Pillars, organized into five skill levels.

Seven Pillars include:

Continue reading ‘Codifying Agile Skills or creating more checklists ?’ »

Share This Post
  • Share/Bookmark

I just read a book titled “The eMedha Paradigm – A Project Manager’s Billion Dollar Odyssey” and felt terribly disappointed and shocked.

The author paints a make-believe world in which a sadist CEO does insider trading and makes his kith and kin richer, while his technically incompetent, control-freak and sexually-deprived project manager has a field day sinking the project. The team spirit is in tatters but because of the three-year job bond, they can’t leave their jobs just yet. Sales has promised to deliver the project in 1/3x time period, and now the customer is shouting from the rooftop on grand promises that remain grossly unmet. In short, all real-world ills happening in all permutations and combinations at the same time. While this might not be entirely implausible, I am yet to find such a worst-case view of real-world. This is such a picture-perfect scenario – can you think of anything else going wrong in this ?

The best is yet to come. An honest professional at the client side, Kalpana, with no significant credentials in getting a team out of such worst-case mess enters the scene, thanks to her scheming manager, and gets an anynomous mail from one of the team members on what all ails the project. While she is enroute India thinking about it at 40,000 feet mid-air, she has an encounter. Not a small encounter mind you, but The Encounter. God and his heavenly assistant (literally and figuratively, we are made to believe) Kamayani is an expert in some non-descript technique known as ‘eMedha’ that has the potential to transform any toddler into a veteran project manager. Even though these techniques are so obvious (or so the author would have us believe), for some reason our knight in the shining armor Kalpana doesn’t know these old tricks, and needs divine intervention to bestow that commonsense in her.

Continue reading ‘Are you solving the wrong project management problem ?’ »

Share This Post
  • Share/Bookmark

Cockroaches just love projects. Several projects have loads of them, but most projects have at least a few of them. Software projects are notorious for breeding cockroaches that are not only hard to spot, they are harder to exterminate. They are a project manager’s worst nightmare, and despite our collective advances in project management theory and experience, we still are answerless in face of collective might of those otherwise innocuous-looking pesky little creatures that simple turn the best laid out plans and intentions into history.

What are these cockroaches ? I am not referring to the ugly kitchen pest that refuses to die (it is rumored to be the only living form with capability to survive a nuclear fallout), but the Cockroach Theory, defined as:

Continue reading ‘Does your project love cockroaches ?’ »

Share This Post
  • Share/Bookmark

Just got this in my mail inbox:

ACM Bulletin Service
Today’s Topic: Congress Passes Resolution to Establish Computer Science Education as a National Priority
October 22, 2009

Continue reading ‘Congress Passes Resolution to Establish Computer Science as a National Priority’ »

Share This Post
  • Share/Bookmark

A friend sent this story sometime back:

The Japanese have a great liking for fresh fish. But the waters close to Japan have not held many fish for decades. So, to feed the Japanese population, fishing boats got bigger and went farther than ever. The farther the fishermen went, the longer it took to bring back the fish. The longer it took them to bring back the fish, the staler they grew. The fish were not fresh and the Japanese did not like the taste. To solve this problem, fishing companies installed freezers on their boats. They would catch the fish and freeze them at sea. Freezers allowed the boats to go farther and stay longer. However, the Japanese could taste the difference between fresh and frozen fish. And they did not like the taste of frozen fish. The frozen fish brought a lower price. So, fishing companies installed fish tanks. They would catch the fish and stuff them in the tanks, fin to fin. After a little hashing around, the fish stopped moving. They were tired and dull, but alive.
 
Unfortunately, the Japanese could still taste the difference. Because the fish did not move for days, they lost their fresh-fish taste. The Japanese preferred the lively taste of fresh fish, not sluggish fish. The fishing industry faced an impending crisis! But today, it has got over that crisis and has emerged as one of the most important trades in that country! How did Japanese fishing companies solve this problem? How do they get fresh-tasting fish to Japan?
 
To keep the fish tasting fresh, the Japanese fishing companies still put the fish in the tanks. But now they add a small shark to each tank. The shark eats a few fish, but most of the fish arrive in a very lively state. The fish are challenged and hence are constantly on the move. And they survive and arrive in a healthy state! They command a higher price and are most sought-after. The challenge they face keeps them fresh!
 
Humans are no different. L. Ron Hubbard observed in the early 1950’s: “Man thrives, oddly enough, only in the presence of a challenging environment.” George Bernard Shaw said: “Satisfaction is death!”
 
If you are steadily conquering challenges, you are happy. Your challenges keep you energized. You are excited to try new solutions. You have fun. You are alive! Instead of avoiding challenges, jump into them. Do not postpone a task, simply because its challenging. Catch these challenges by their horns and vanquish them. Enjoy the game. If your challenges are too large or too numerous, do not give up. Giving up makes you tired. Instead, reorganize. Find more determination, more knowledge, more help. Don’t create success and revel in it in a state of inertia. You have the resources, skills and abilities to make a difference.
 
Moral of the story: Put a shark in your tank and see how far you can really go!

Continue reading ‘Where is the shark in your cubicle ?’ »

Share This Post
  • Share/Bookmark

Last month, I sat through an interesting talk by two very senior business professionals, Ajit Chakravarti and Govind Mirchandani. The talk was organized by the Indo-American Chamber of Commerce (IACC), and you can read speaker profiles here. I found their talk particularly interesting because they did not talk any theory, and did not use any complex jargon or bulky models to explain their ideas.

They talked about how and why leadership also requires to be mentored, and how a mentor makes the difference. They used the analogy of Krishna as a mentor to Arjun in the Kurushetra battlefield. Arjun is torn by the value conflict – should he fight and kill his own kith and kin for the sake of getting his kingdom back? He doesn’t require training for the war, nor does he require any coaching for the battle – the fact that he is out there in the battlefield, all decked up means he is fully trained and ready to fight the war. What he needs is someone whom he trusts for his knowledge and his unflinching trust and support for him who can listen to him, clarify the value conflict (which, more often than not, is not between right vs wrong, but between ‘right’ and ‘right’  two equally competing options that are both the right thing to do individually, but when tested against each other, put one’s value system to extreme test), ask questions, show him the mirror – so that Arjun can take the correct decision. In their view, Krishna fills that role as a mentor, and they extrapolate the following traits of a mentor from how Krishna goes on to help Arjun:

Share This Post
  • Share/Bookmark

  Subscribe in a reader

Subscribe by Email

Creative Commons License

Yes We Kanban




free counters


:: THOUGHTS ASIDE ::
search engine submission software promotion,
Work by: praca


Blog directory

Free Blog Directory


Visit blogadda.com to discover Indian blogs