some indie thoughts on management, leadership, strategy and execution of software development

Tag Archives: Planning

Plans have a huge credibility problem. For large part of recorded history, they have always had this problem. With all the advancements we have made in estimations, forecasting, scheduling, risk management and planning, our execution still continues to challenge us, at times even confound us. It almost makes one feel that real doers don’t plan, they just do it! Or, putting it in more bluntly, a project plan is at best a reference, a guide, maybe even a map – just like Eisenhower said “In preparing for battle I have always found that plans are useless, but planning is indispensable” – but never the single, eternal source of truth that is much-needed for you to face the battle? If that is true, does it mean that the project gets done irrespective of the plan? Despite the plan? What if your plan was not so accurate and detailed, but more like “just do it” – would you still do just as fine? Does it mean that execution is really the most important part of the whole puzzle?

Every business school and startup mentoring clinic would tell you that you need to have a business plan, or at least some business plan to get started (well, some of the good ones like Ycombinator will tell you that you don’t need a business plan), and yet every entrepreneur would tell you, as the German military strategist and Field Marshal Helmuth von Moltke the Elder famously said, “No battle plan survives contact with the enemy”. All the romantic visions of a rosy future of millions of customers with wallet full of greenbacks thronging your ecommerce website come crashing down when the first assumptions turn out to a sand castle, and after that, it is just responding to the events, setbacks, challenges and opportunities in real-time, ad nauseam.

When I talk to business schools occasionally, the professor of management is devastated when I say we didn’t have any plans when we started. The idea of having a business came before our invention of the audio oscillator. We were just opportunistic. We did anything to bring in a nickel. We made a bowling alley foul-line indicator, a clock drive for a telescope, a thing to make a urinal flush automatically, and a shock machine to make people lose weight. Here we were, with about $500 in capital, trying whatever someone thought we might be able to do. So we got into this thing not by design but because it worked out that way.

This is from circa ~1937-38. If this story doesn’t convince you because you believe a lot has changed since then, just sample Intel’s business plan from 1968 in this graphic. If no one told you it was Intel’s business plan, you probably won’t give it a second look, let alone fund them.

It might seem very improbable, but just think about it – they could have written just any other business plan for Intel and yet be equally successful? So, was this piece of paper just meant to sell some dreams to potential investors, or on a lighter note, sell them something that they badly wanted to buy so that we could go out and do what we badly wanted to do without any external interference? Or, is the eventual success all about execution – staying focused on the task at hand and quickly learning what’s working and what’s not while quickly pivoting on stuff that’s working. So, the starting point doesn’t really matter as long as there is a process that allows for being able to get feedback from the market and then quickly iterating through subsequent changes? In that case, the plan becomes a placebo, and because we have been conditioned to believe that a plan is supposed to help us, and hence we end up eventually ‘following’ it in some shape or form?

Or is the eventual success all about serendipitous luck and a great timing that some are born with, while some others acquire it but most of us don’t have a clue about? It could seem like the case with so many one-trick ponies out there. Take Hotmail. A great success that justifiably rewarded its founders with riches but only never to replicate even a fraction of that original success. People often question if Google is also a one-trick pony? While something like that might/not be a great strategy can only be eventually determined by how the market responds to it. Some might say putting “all woods behind single arrow” is a great strategy because it allows laser-sharp focus, while some other might seek safety in numbers and might want to diversify and have a product for all pockets. However, in all those cases, it is likely that even if there was an initial luck that led to some technological or a market breakthrough, the long-term success only came from systematic planning and methodically executing on what was the most important or business at that time.

So, we come back to original question – is planning, or having the benefit of a plan just a placebo? Some people might argue that a placebo works only when the subject is not aware of the existence of a placebo agent. If we go by the data by Placebo Research Center, there seems to be data to suggest that a subject could still demonstrate same results even while fully knowing of the existence of a placebo agent. So, it might not be long shot to say that existence of a plan, even if the manager or entrepreneur believes it to be just a work of business fiction, is completely redundant. After all, if writing something on a piece of paper becomes a self-fulfilling prophecy and eventually leads to a success, that seems like a very small price to pay given the rather high odds of success in such an uncertain environment?

I am investing this subject further, but would love to hear back from you if your plan is just a placebo, or something much more methodical and meaningful?

He was newly appointed as the Project Manager for a moderately complex project. Prior to this assignment, he was trained in the best of methods and had access to the latest of tools. And yet, he was struggling.

He was struggling to get the right answers to the three most basic questions:

What is the right time to do begin each activity?

Who are the right people to listen to, and whom to avoid?

What is the most important thing to do?

He understood how to apply the tools and techniques to plan his project’s activities, but did not yet have the finesse to determine answers to those above questions. He called out all his stakeholders, his Customer, Senior Management, Team members, Program Managers, and process champions to an offsite to brainstorm on those three questions. While some team members were very excited to participate, some were very reserved to stick their neck out. He realized the challenges, but decided to give it an honest shot.

To his first question, his team said the best time to do an activity is naturally when the resources are available – how else could one undertake an activity otherwise? His customer felt the best time was when the requirements were clear and the design was complete. His manager felt the best time was when all risks had been appropriately mitigated. Like in the original story, The Three Questionsby Leo Tolstoy, some people told him he must plan up all the events in his project plan upfront so that there is nothing left to chance – they were clearly favoring the old maxim “if you fail to plan, you plan to fail”. However, there were a small number of people who argued that it was actually impossible to plan everything, and hence the predictive planning was a flawed process – it simply was much better to do an adaptive planning instead. All these seemed to be good answers to him, but were neither comprehensive enough by themselves or actionable even if considered collectively.

To his second question, he got even a bigger variety of answers. Some felt the most important people to work with were the requirements analyst – how else could one hope to build and deliver the project if requirements were not clear? Then some said it was all about design. A few felt the developers was nowadays being seriously underrated, and that was the root cause of all problems, while some others felt testers were really the make-or-break guys on the project. He then talked to some methodology gurus and got additional answers that said the most important person was himself – the project manager, and yet followers of a new cult said it didn’t matter because everyone was expected to have cross-functional skills (or, at least that’s what he gathered from their conversation). Some folks also talked about the Customer, but mostly because they were such a nuisance to work with – you better take care of them! Again, to him, all these roles were integral part of the entire project, and even if some role got more important than others in a given phase, when taken holistically, you couldn’t afford to ignore anyone!

To his third question, he got shock of his life when he saw people donning their emotional self and drawing battlelines to defend their argument! The Cowboy Programmers felt the most important thing to do was to just code, code and code (and don’t even bother to fix it – you could always outsource maintenance to a low-cost location – and gave a really sincere thank you to Globalization!). The Feature Brigade was no-nonsensical about getting the PRD right – how else are we going to build the right product? Testers felt developers will mess up the code (as usual!) and hence they were the ones who had divine rights and the ability to find the problems and somehow ship the product. Process Terrorists were hung up on adhering to the process come what may, and the Customer was only interested in when are we shipping the product? Once again, our Project Manager found himself at crossroads because none of them were wrong individually, but none of them could be pitted against one another at the cost of picking just one out of two.

They all came back from the offsite with a new-found camaraderie that would sail them though for the next few weeks, but our Project Manager knew there were some really big chinks in his armor and the real answers to his three questions were still eluding him. He realized that his plans howsoever detailed and meticulous were doomed from the start because everyone among his stakeholders and his team got their individual part, but no one got the entire picture right. As project progressed, his worst fears were that the blind love for one’s own trade would drown the project. The only time to save the project was now or never!

While coming back, he suddenly remembered that he had promised to take his family out over the weekend. On one hand he wanted to call of the outing fearing he would not be at his best, but then he thought why not go for it – if nothing else, at least he will come back little freshened up and hopefully take another crack at the problem.

They went to the nearby water park. It was a great day, and the kids loved every moment of it. He was trying his level best to be the familyman and enjoy his kid’s silly jokes, even though his mind was clearly pre-occupied with things from workplace.

During lunch, he felt uneasy and felt breathless and he was profusely sweating. His family got worried, but he tried to brush it aside. He know they had bought the tickets to an afternoon gala show which his kids had been planning to watch for last six months, and he didn’t want to spoli their plans over what he thought was some minor medical condition that would be over in next few minutes.

Medical emergencies it did turn out to be, but it was not to get over in next few minutes. He wife made the call to cancel their plan for the day and told the family that they need to rush him to hospital. The kids didn’t even once protest – they just picked the things up and got ready while their mother arranged for some help to get their father moved to the car. She drove all the way to hospital, while his kids were besides him. His son was feeding him water, while his daughter was constantly chatting with him and softly massaging his hands. The entire family was focusing on making sure they reached hospital in time, and during the journey to hospital, he stays well take care of. Once in hospital, the medical staff took immediate care of him.

It was due to food poisoning, the doc told them. Though it was not severe, but since he got to hospital in time, they were able to help him much better, and he could leave the hospital by the evening. He felt very embarrassed and apologetic in front of his family that they all had to cancel their plans because of his minor problem. However, his family didn’t agree with him. They were all so concerned about his health there was no way they could have ignored him – wasn’t that the most important thing to go for the most important person in their lives? And right then and there, it hit him! All his questions had just been answered:

The right time to begin anything is now. The present is the only time over which we have power. If his family had not acted so swiftly, the situation could have turned worse.

The most important person is whoever you are with. During the last few hours, his family was only concerned with his welfare.

The most important thing is to do good to the person you are with. He smiled to himself thinking of how his little daughter was softly massaging his hands, and how son was making sure he was doing ok while his wife probably violated a couple of traffic signs to reach him to hospital.

So, that’s it, he realized. I guess I was looking for some cookbook answers. It’s not so much about finding those answers externally or in some process framework as it is about oneself being purposefully aware of own behavior and relationship with others at a given point. It is more about being there for the person in front of you than working with a static set of prioritized relationships, or personal biases or mental models that dictated your behavior depending on where someone was in the pecking order. He thought it was imuch more mportant to address even the smallest issue that was presented to him as compared to even the most complex risk identified in his plan, and of course â€“ the best time was always â€œnowâ€ for anything and everything. He had found an explanation to his answers, and even though he still didn’t know how they fitted in his project plan, he felt he was going in the right direction.

In the age of nano attention-spans of people, the tendency and respect for planning things upfront has taken a serious beating. The mainstream logic is to simply “play by the ear” because there are far too many moving parts to be completely accounted for and properly factored-in – and in any case, by the time the plan goes to execution, ground realities would have changed beyond recognition, thereby rendering the plan completely useless by that time. In software development, an inaccurate predictive long-range model such as Waterfall has been replaced by more accurate adaptive short-range Agile methods that solve the line-of-sight problem but don’t address the original problem – that of planning a large project with its own share of uncertainties.

While none of those arguments might be wrong par se, we conveniently ignore the fact that that is the nature of the beast, and we need to understand that planning is not a single-pass 100% process that stays current forever. Further, just because things will eventually change is not a good enough reason to abandon any systematic efforts to understand it, if not to tame it altogether!

While preparing my lecture notes for a recent class on planning, I decided to explore the subject of planning through the ages using various quotations over a period of time. I sorted them in chronological order in order to understand how human mind has evolved the thought process behind planning. What came out from this exercise surprised me – it seems like the values associated with planning are as timeless as the fundamental human nature. The age-old wisdom was that a “stitch in time saves nine” and hence there was a focus that “prevention is better than cure”. Some might argue their world was not so complex and dynamic. I disagree.

There world was highly uncertain, and hence inherently complex. With perhaps 95% of reasons behind mortality unexplainable, with perhaps 95% of scientific events being attributed to the Gods (mostly of the angry variety!) and no protection from animals, predators and even their own tribal enemies, how much more complexity do you need in a day? When faced such levels of uncertainty, the modern man is more likely to live life one day at a time. And yet, the thought process from yesteryears seems to indicate that they didn’t simply abandon long-range planning, on the contrary, they reinforced the values of such long-range planning as the only real way to deal with such uncertainties!

Here are some of the quotations that I discovered during my research:

If you are planning for a year, sow rice; if you are planning for a decade, plant trees; if you are planning for a lifetime, educate people – Chinese Proverb

A man who does not plan long ahead will find trouble at his door – Confucius (551-479 BC)

Â Plan for what is difficult while it is easy, do what is great while it is small. The difficult things in this world must be done while they are easy, the greatest things in the world must be done while they are still small. For this reason sages never do what is great, and this is why they achieve greatness – Sun Tzu, Chinese General, The Art of War, 400 BC

Whatever failures I have known, whatever errors I have committed, whatever follies I have witnessed in private and public life have been the consequence of action without thought – Bernard Baruch, A stock broker, advisor to presidents Woodrow Wilson, Harry S. Truman, (1870-1965)

Those who plan do better than those who do not plan even thou they rarely stick to their plan – Winston Churchill, British Prime Minister

In the space of two days I had evolved two plans, wholly distinct, both of which were equally feasible. The point I am trying to bring out is that one does not plan and then try to make circumstances fit those plans. One tries to make plans fit the circumstances – General George Patton (1947).

A good plan today is better that a perfect plan tomorrow – George S. Patton

Planning is a process of choosing among those many options. If we do not choose to plan, then we choose to have others plan for us – Richard I. Winwood

Plans are only good intentions unless they immediately degenerate into hard work – Peter Drucker

Another interesting discovery was that planning didn’t mean people simply fell in love with their original plans. On the contrary, there are instances that people advocated not only adapting to changes, but rather incorporating mechanism to accommodate them upfront. Look at some of the quotations on this:

Observe always that everything is the result of change, and get used to thinking that there is nothing Nature loves so well as to change existing forms and make new ones of them – Marcus Aurelius, emperor of Rome (121-180 AD)

It is not the strongest of the species that survive, not the most intelligent, but the one most responsive to change – Charles Darwin, scientist

So, is the concept of ‘planning’ an overrated and old idea who time is up? I don’t think so. It only means that there is more need to refresh our understanding and explore how to evolve long-range planning methods to incorporate short-term changes such that agility is not lost at the tactical level, while near-sight changes don’t create a bullwhip effect on strategic plans.

Do you think inaccurate and uncertain proactive planning should be completely abandoned in favor of a highly accurate and definite reactive ‘planning’ (if that can still be called as ‘planning’, that is)?

For decades now, the project management world is divided between top-down estimation and bottom-up estimation. While a top-down approach might have limitations, it perhaps is the only way to get some meaningful estimates at the start of a project. A bottom-up approach might be a great way to get more accurate and reliable estimates but you might have to wait for a problem to be whittled down to that small a level to get such reliable estimates. Both are required for a comprehensive and useful project planning, but unfortunately, most people see one over other, and the Agilists abandoning top-down in favor of the highly accurate but low-lookahead bottom-up methods.

A top-down estimation is a great way to abstract the problem without worrying about itsÂ nitty-gritties, and come up with a workable estimates when there is no other source of getting any better estimates. At the start of a project, when making a realistic WBS is a remote possibility, the only way one could get some estimates is by top-down estimation techniques such as

Expert Judgment

Wideband Delphi Method

Analogous Estimation

Parametric Estimation

They allow an ‘order of magnitude’ estimate to be made available to set the ball rolling. We know that such estimates suffer from cone of uncertainty, but it is better to get imperfect estimate now than to get perfect estimates much later in the project – which we still need to get – the point is that we also need to get some estimates here and now!

Another key reason why we must use such top-down techniques at the start is because if we straightaway jumped into bottom-up estimation, we might face challenges because

Details about requirements are still emerging, and hence likely to get refined as our understanding about the problem gets better

Requirements might keep changing, thereby changing the scope of work all the time

Too many low-level details could introduce too many moving parts in the scope of work, thereby forcing one to skip “vital few” and start focusing on “trivial many” clearly not a prudent approach at that stage

So, we need to accept the ground conditions and accept those high-level estimates with a boulder of salt and keep moving. As we get deeper into the project, we decompose the problem better and have a more granular WBS that helps us zoom into the problem and get more refined estimates. At that point, a bottom-up approach is much more relevant, as it allows us to plan and track the work much better.

Agile methodologies clearly favor bottom-up estimation methods and the idea is to slice down every task on the project into ‘stories‘ that could be ideally done by an individual team members within a couple of days. It helps you to win daily battles but takes your sight off the big war that you must win to eventually succed. We can’t really scale up these stories for large projects even if we assume that every product scope could actually be broken down to meaningful stories of that grain size. So yes, in theory, that’s great. But the real world is not obligated to obey the theory!

A prudent approach is to adopt rolling-wave planning – start with big grain size when details are not very clear and gradually move down to small grain size as you get closer to the task. However, you don’t just abandon the overall planning simply because you are now doing task-level estimates and planning! On the contrary, it is even more important to keep track of dozens of small-task estimates becuase, to quote the great Fred Brooks in The Mythical Man-Month, it is not the tornadoes but the termites that eat up your project’s schedule! So, a delay of one day here and one day there repeated for a couple of tasks over next few sprints and you suddently are sitting with a month-long delay on your overall project. You might be hitting each timebox but that’s one problem with timeboxes – it could give you a false sense of comfort that all is well, when clearly you are being forced to jetsam things that you are not able to accomplish within a timebox. On the other hand, if you go by a task-driven schedule, you atleast have a clear idea of how much late you are to complete that task.

A frequent criticism of top-down estimates is that they are at best a wishful thinking, and at worst a highly unrealistic estimate forced upon a team against their free will. Again, we should be careful in such judgment because the reality is not always what is presented to us, but rather what we do with it! So, if you take a top-down estimate as the word of god and make it ultra-resistant to changes, than you have yourself to blame when those estimates don’t reflect the reality anymore. They should be taken as a map and should be continuously refined from the data coming from the terrain. To that end, top-down estimates and bottom-up estimates play a complmentary role and an effective project manager blends them together. A good top-down estimate covers the ground fairly well, thereby allowing realistic bottom-up estimates to happen (by allocating them sufficient, meaning as close to the actuals, time and resource available), and good bottom-up estimates at task level help reinforce assumptions made in the top-down estimates of the overall project.

So, at the end of the day, it is not about which estimation technique is superior. It is about using most appropriate tool for every type of problem.

Next time, think again before you ask the question your estimates or mine?

The concept of planning has a very intuitive appeal, irrespective of the type and size of endeavor. Who wouldnâ€™t want to undertake an activity without a little bit of upfront planning? Will you take your car and just head out for the next family weekendÂ in the neighboringÂ town â€“ without first checking if your car is roadworthy for the long drive, has enough gas, or needs a visit to the garage before the long drive? Will you buy a house without first checking your cash flows and other commitments for the next couple of years? Will you get your kids admitted to the nearest school you come across, or you will do little bit of investigation and plan is based on your specific needs and childâ€™s comfort?

Still then, it comes as a great surprise when many among us disregard the benefits of planning things upfront. While they might still succeed in a trivial pursuit, for it might present very predictable outcome, require relatively risk-free approach, is generally easy to recover from a bad position, have virtually all resources at oneâ€™s disposal, etc. While such trivial â€˜projectsâ€™ might not demand a rigorous planning, we should also note that often such planning is a very intuitive process, one that happens very effortlessly and unconsciously in our minds. Such planning, or several of its elements, have been executed so many times that one doesn’t have to think of anything else – it just happens. To an untrained eye, it might appear like a careless approach where nothing is being planned, and yet the actors seem to be in supreme control – it is nothing short of magic! However, let the vision not get the better of logic.

However, for any non-trivial problem, or a trivial problem with a few key changes, or some last-minute unpleasant surprises, the life is not that easy. They transform into wild beasts that donâ€™t obey their masters anymore, they behave randomly (or at least unpredictably), and unless you address them proactively, they are only more likely to make things increasingly difficult for you. What followsÂ then is the endless loop of firefighting (often leading to ‘immortal projects’ that I conceptualised in my earlier blog post “From Project Immortality to Project Moksha“).Â So, why is it that some people refuse to plan their projects, choosing instead to clean up their mess over long evenings and frustrating weekends over the next several months? Here are some of the reasons that I have come across:Â Â

Our project is too large to plan

Our project is too small to plan

Planning is waste of time and effort â€“ Iâ€™d rather be coding right now!

Planning commits me to something that I must stick to at all times, even when the world around me has changed.

Publishing the plan will expose buffers in the plan to our customers

Publishing the plan will expose buffers in the plan to project team members

If we publish our plan, customer will question our productivity being low

The project is evolving and the situation is changing on a daily basis

We are too deep fire-fighting the project â€“ have no time to plan at this point

Why plan things that are too simple, and as for things that are too complex â€“ well, you anyway canâ€™t manage them, so why plan?

We believe in adaptive processes rather than a predictive planning

Planning involves tracking which means supervision of a personâ€™s time. We think that creates mistrust in the team.

We do burn-down chart which is better for projecting the delivery date

The sub-contractor is responsible for project plan

This is just a simple porting work

Next 2-3 months we will be doing real research. There is no way I can manage that effort to a plan!

Plans are for the weak-hearted, the brave hearts face the tornado head-on

We typically estimate and pad it by 30% to make it a realistic plan

We canâ€™t estimate number of bugs we will get in the testing phase, and hence canâ€™t plan for those phases

Someone or other is always leaving our team or the company. No use building plans around them.

All real work happens in nights and over weekends. Plans have always failed us.

Our customer only cares for working software

Requirements are always changing

Customer has given us fixed end-date, so our plan doesn’t count

My management will always underprovision team resources

Doing estimation won’t speed up the project – it will take the same time even without an estimation

We do Agile

We do Scrum

Plans are anyway changing all the time

I have the project plan – here it is in the gantt chart

Our project is diferent – planning will stifle the innovation and creativity

Any version 1.0 product will be like that only!

You might have seen variations of these, or brand-new excuses. Feel free to share them here. We need to deglamorize these lame excuses for they serve no one’s interests. At best, they handcuff us into existing methodology, and at worst, they ensure project immortality (discussed above). Both are fatal for your project’s success.

Â (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!

Â

Plans are Nothing â€“ Planning is Everything â€“ Dwight D. Eisenhower

Â

Surely the top most Management Institute of the country would be teaching this day in and day out to the numerous batches passed out till 30 Nov 2009!

The difference in the teaching which they should realize now â€“ better late than never â€“ is that there is a world of a difference in â€œteachings in class roomsâ€ and â€œsituation on groundâ€!

Responsibility – The recent failure of CAT has thrown up a big question mark as to how the prime institute of Management defaulted. Itâ€™s easy to pass the blame on the conducting organisation. Agreed that the conducting organisation is the executive arm but the responsibility rests with the management. Just by allotting the responsibility to someone else and hoping that everything will be fine is not a management rule!

Load Testing – The management of the institute should have monitored the progress, carried out a hundred dry runs on the systems? Simulation of a number of students undertaking the test simultaneously should have been done â€“ This is known as Load Testing!? I remember after setting up the best ever technical infrastructure at Digital (now HP) back office in Bangalore when we proudly placed our credentials for picking up the business from HP-US, the first question from their Head of Call Center shot out was â€“ â€œHP will have a 24 hrs load testing on the infrastructure?â€ I confidently welcomed it and subsequently conducted the same accepting a large number of simulated calls (a few thousand) simultaneously, switching off the mains and checking for back up power, plugging out the IPLC (International Private Leased Circuit)Â and noting the call breaks if any, recording the wait time of the calls before they are attended and so on. Itâ€™s a different matter that the infrastructure came out absolutely error free and we got the business but what learning we carried along was that the ONLY way to ensure 100% reliability is to actually take the process through a number of times with equal or larger volumes than expected.

Approval for Battle Readiness – How was the â€˜all clearâ€™ report from the vendor accepted? Who from the conducting authorities checked the same? Did they physically go through the process? Were mock runs conducted and the management satisfied with the Infrastructure in place?

Efficiency Check – It is said that the â€œefficiency of a machine is inversely proportional to the number of people watching it!â€ CAT is being watched by world over apart from the few lacs that experience it. Shouldnâ€™t someone have checked the efficiency of this system? Itâ€™s prudent not only to have a working system but an efficient system.

Check Back – In the forces we give a command to our troops. It is essential to â€œcheck backâ€ as to what they have understood. Was there any process of check back with the vendor?Â If so what were the parameters and the process defined in it? A mere verbal assurance is not the management game â€“ at least not what is taught!Â Â Â

Back up Plan – Failures are a part and parcel of life. While accepting the same, one needs to have an alternative plan in order to have 100% success. What was the back up plan? The management lesson says that the back up has to be as robust as the original. Failing twice will not be accepted. One needs to carry out similar tests on the back up plan also. Did anyone check on the back up plan? When and who orders to switch to back up plan? Three days down on CAT and still the problem continues.

Once Bitten Twice Shy – We have only seen the execution part of CAT. Learning from the experience the authorities need to be extra careful in ensuring that the selection of questions from the question bank is as per the design and error free. Management needs to check and recheck a thousand times.Â

Finally â€“ the evaluation. Itâ€™s a question of make or break for many. Each appearance for the candidate is critical and hence a foolproof software which is tested a hundred times. One may even consider it cross checking manually – at least for the first time and also since one goof up has already taken place.

Wake Up Call – Its time that our Management Institutes wake up to the realty and link itâ€™s teaching to on ground work. Foreign institutes are not fools to have the obligatory requirement for students to have at least 4 / 5 yrs experience before they plunge into this course. Ground realty is different than classroom! How will the product of such institute who fails to execute a process sell in the market?

Itâ€™s hard to believe that this was a show from the Indian Institutes of Management â€“ or should we say Indian Institute of Mis-Management?