Tag Archives: Project

Why are dry runs are so important?

The visual of Obama’s Beast getting stuck on a speed hump recently was a hilarious sight. Here you have world’s most-secure car caught completely off-guard by a tiny speed hump! The visuals told a sad tale when the car literally came to an abrupt halt – the belly hinging on the speed hump and front and the rear wheels on either side of the hump. Is that how Murphy trumps your best-run projects?

One thing I have learnt over the years is after you plan every detail meticulously, and track the execution closely, when you get close to the showtime – always do a ‘dry-run’ with the entire team to make sure every single detail is executed through as it would on the day of showtime, every contingency thread is covered to make sure the response mechanism will be as per the plan should there be an emergency. While I am sure Obama’s team must have done such dry-runs (and even actual runs) over a dozen time in preparation of his Ireland visit, obviously, something got left out and the result was there for everyone to see!

Dry runs are also known as pilot tests, or fire drills, or many other esoteric names. Irrespective of what we call them, the idea is to walk through the entire sequence of operations on a drawing board. When you crowdsource the process of dry run, the effect is even better, because what one mind misses, the other one catches, and collectively many minds can almost always find a better solution than even the brightest mind working alone can find.

Why are dry-runs so important? For one, it exposes the chinks in your planning that might not ever crop up until the actual execution begins. For example, you are planning for an outdoor event and might have factored-in rains during the initial stages of planning the event. However, over the next several months of planning rest of the event, you might lose track of your backup plan if there is rain. This might appear very trivial, but I have often seen some of the best laid-out plans ignoring some of the most trivial factors. Bryan Adams’s show in Delhi earlier this year had to be cancelled simply because the organizers failed to secure a no-objection certificate from Delhi Police for the show! Bangalore decided to move out its airport some 40kms out of town, but forgot to plan its connectivity with the city – Bangalore Metro is still more of an afterthought, if it at all connects us to the airport some day! When it comes to military, the good old motto of ‘the more you sweat in peace, the less you bleed in war’ still holds true. Every practice, fire drill or dry run allows the team to go back and review their execution and make it little better than the last time.

Another reason is that during a rather long project (say 4-5 months or more), it is likely that the some of the folks who were involved in project risk assessment and planning at start of the project are not there anymore. The new people on project might know the project plans and documents just like anyone else on the project, but might not understand the semantics of why a particular decision was made, and what all options were considered before being discarded (and why). A dry-run can make sure everyone is quickly brought on the same page.

As anyone who has ever undertaken any meaningful creative endeavor knows, the hindsight is always 20/20. We often start project planning with fog around us, and gradually things become more and more clear (and quite often, they become embarrassingly obvious). The assumptions and plans need to change accordingly. A dry-run makes sure we have adapted our plans to the latest situation on ground.

The other day, I was boarding a flight. One of the pilots, an expat woman in mid-forties, was chatting up with the ground staff as they went about fueling and the final pre-flight checks. She seemed genuinely concerned over something and insisted on getting the answer. Of course, I could only watch their body language and gesticulations from the distance – and had just about 15-20 seconds before I boarded the plane. It was not a superjumbo – in fact, was an ATR72. Why was she taking an extraordinary amount of interest to get her queries addressed? I might never know the real answer, but I think she was going through the entire pre-flight sequence in her mind and wanted to be sure of every single detail. Maybe she was new to the airlines, or new to the airport, or was working with that crew for the first time – whatever the reason; I felt she was leaving nothing to chance.

Some people think a dry-run is akin to waterfall thinking, and hence must be avoided like plague. I am a non-believer in such compartmentalized thinking, and hold the view that anything that helps improve your ability to get desired results faster, better and cheaper should be embraced without any prejudice. While a big upfront planning sets the pace for rest of the project, a dry run makes sure it allows you to adjust those very plans based on last-minute changes as well as the learnings from execution so far.

In software development, it is common to build ‘prototype’ to mimic the actual user behavior. Especially for something new, like building a game for new interfaces like iPad or Kinect, you can’t get a feel of it until you have placed the app in hands of a user so that he can play with it. No amount of paper documentation will ever be enough to get a feel of how human-machine interaction would be on some of these new-age interfaces. In aviation industry, especially military aviation, it is very common to build the prototype and do an increasing amount of testing on them before proceeding with the mass production.

In my view, dry runs ensure that you don’t run dry!

How do you schedule tasks in a project?

How do you decide what tasks to schedule first: the complex ones or the easy ones? the short ones or the long ones? the risky ones or the sure-shot ones? Most often, this task sequence is determined by hard logic, soft logic, or some other external constraints. However, how do you decide when there are no such contraints?

If we look at the risk driving the project lifecycle and scheduling, then it is natural to expect high-risk tasks being tackled at the start just so that we are systematically driving down risks in the project and achieve higher certainty levels as we get close to the project. However, it seems inconceivable that someone will cherry-pick the easy tasks first and leave all high-risk ones for the end! Clearly, that is setting up the project for a grand finale of all sorts!

Project SchedulingCould complexity be a good measure then? What will happen if we take high complex tasks first? Surely, that will lead to tackling some of the most difficult problems first, and there might also be a high level of correlation between complexity and risk. So, taking this approach is also likely to significantly lower a project risks. However, not all tasks are created equal. It is likely that high-risk tasks not the longest, so while the project makes appreciable gains in lowering the risk, but doesn’t make a whole lot of progress.

Agile approaches, Scrum in particular, rely on driving the tasks that make biggest sense to the customer – tasks that deliver maximum value to the customer. However, there is no guarantee that this will help lower the project risks, or manage the schedule better. Similarly, Kanban helps manage tasks but doesn’t really spell out how they should be scheduled.

So, what is the best approach?

I read an interesting blog, The Art of the Self-Imposed Deadline, where I specially liked this one from the blog post:

3. Avoid the curse of the “final push.” Scope and sequence a project so that each part is shorter than the one that precedes it. Feeling the work units shrink as you go gives you a tangible sense of progress and speeds you toward the end. When you leave the long parts for last, you’re more likely to get worn out before you finish. Besides, if you’re “dead at the deadline,” those other projects you’re juggling will stagnate.

This seems like a very practical suggestion – often the tendancy is to ‘cherry pick’ while scheduling the tasks – we tend to pick up tasks that are favorite to people, or appear to be easier to take up. However, very often, we end up taking more time, and project gets delayed. If the tasks are scheduled such that big/complex tasks are scheduled first, that might mitigate lot of risk pertaining to last-minute issues (could be due to underestimation, or integration issues, etc.). However, I am not 100% sure that purely scheduling tasks on “longest-task first” basis is the best policy to lower risks in a project. Shouldn’t we be using a combination of top-risk items that are longest?

I haven’t used this approach yet, but seems like something to try. How about you – what’s your favorite way to schedule tasks?

The 5 Goals of a Project Manager

This blog post is contributed by Jason Westland, CEO of www.projectmanager.com  and author of the best seller book “The Project Management Life Cycle“. Jason has over 15 years of experience in Project Management industry, and I am sure you will find his ideas useful.

As a special promotion offer from www.ProjectManager.com, 3 free licenses to “Project Management Methodology” (from www.MPMM.com) valued at US $850 are being offered for the best 3 feedback comments on Jason’s article. So, enjoy reading Jason’s article and don’t forget to leave your feedback…  

As a Project Manager, you need to manage people, money, suppliers, equipment—the list is never ending. The trick is to be focused. Set yourself 5 personal goals to achieve. If you can meet these simple goals for each project, then you will achieve total success. So read on, to learn…

The 5 Goals of a Project Manager

These goals are generic to all industries and all types of projects. Regardless of your level of experience in project management, set these 5 goals for every project you manage.

Goal 1: To finish on time

This is the oldest but trickiest goal in the book. It’s the most difficult because the requirements often change during the project and the schedule was probably optimistic in the first place.

To succeed, you need to manage your scope very carefully. Implement a change control process so that any changes to the scope are properly managed.

Always keep your plan up to date, recording actual vs. planned progress. Identify any deviations from plan and fix them quickly.

Goal 2: To finish under budget

To make sure that your project costs don’t spiral, you need to set a project budget at the start to compare against. Include in this budget, all of the types of project costs that will accrue, whether they are to do with people, equipment, suppliers or materials. Then work out how much each task in your plan is going to cost to complete and track any deviations from this plan.

Make sure that if you over-spend on some tasks, that you under-spend on others. In this way, you can control your spend and deliver under  budget.

Goal 3: To meet the requirements

The goal here is to meet the requirements that were set for the project  at the start. Whether the requirements were to install a new IT system, build a bridge or implement new processes, your project needs to produce solutions which meet these requirements 100%.

The trick here is to make sure that you have a detailed enough set of requirements at the beginning. If they are ambiguous in any way, then what was initially seen as a small piece of work could become huge, taking up valuable time and resources to complete.

Goal 4: To keep customers happy

You could finish your project on time, under budget and have met 100% of the requirements—but still have unhappy customers. This is usually because their expectations have changed since the project started and have not been properly managed.

To ensure that your project sponsor, customer and other stakeholders are happy at the end of your project, you need to manage their expectations carefully. Make sure you always keep them properly informed of progress. “Keep it real” by giving them a crystal clear view of progress to date. Let them voice their concerns or ideas regularly. Tell them upfront when you can’t deliver on time, or when a change needs to be made. Openness and honesty are always the best tools for setting customer expectations.

Goal 5: To ensure a happy team

If you can do all of this with a happy team, then you’ll be more than willing to do it all again for the next project. And that’s how your staff will feel also. Staff satisfaction is critical to your project’s success.

So keep your team happy by rewarding and recognizing them for their successes. Assign them work that complements their strengths and conduct team building exercises to boost morale. With a happy motivated team, you can achieve anything!

And there you have it. The 5 goals you need to set yourself for every project. Of course, you should always work smart to achieve these goals more easily.


32 Reasons Why People Don’t Plan Projects

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:  

  1. Our project is too large to plan
  2. Our project is too small to plan
  3. Planning is waste of time and effort – I’d rather be coding right now!
  4. Planning commits me to something that I must stick to at all times, even when the world around me has changed.
  5. Publishing the plan will expose buffers in the plan to our customers
  6. Publishing the plan will expose buffers in the plan to project team members
  7. If we publish our plan, customer will question our productivity being low
  8. The project is evolving and the situation is changing on a daily basis
  9. We are too deep fire-fighting the project – have no time to plan at this point
  10. 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?
  11. We believe in adaptive processes rather than a predictive planning
  12. Planning involves tracking which means supervision of a person’s time. We think that creates mistrust in the team.
  13. We do burn-down chart which is better for projecting the delivery date
  14. The sub-contractor is responsible for project plan
  15. This is just a simple porting work
  16. Next 2-3 months we will be doing real research. There is no way I can manage that effort to a plan!
  17. Plans are for the weak-hearted, the brave hearts face the tornado head-on
  18. We typically estimate and pad it by 30% to make it a realistic plan
  19. We can’t estimate number of bugs we will get in the testing phase, and hence can’t plan for those phases
  20. Someone or other is always leaving our team or the company. No use building plans around them.
  21. All real work happens in nights and over weekends. Plans have always failed us.
  22. Our customer only cares for working software
  23. Requirements are always changing
  24. Customer has given us fixed end-date, so our plan doesn’t count
  25. My management will always underprovision team resources
  26. Doing estimation won’t speed up the project – it will take the same time even without an estimation
  27. We do Agile
  28. We do Scrum
  29. Plans are anyway changing all the time
  30. I have the project plan – here it is in the gantt chart
  31. Our project is diferent – planning will stifle the innovation and creativity
  32. 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.

What’s your excuse not to plan your project ?

From ‘Project Immortality’ to ‘Project Moksha’

Projects are not living organisms, but they inevitably assume a life of their own. They are born from an idea, they have a lifecycle, they consume resources, they grow, they facilitate development of a social structure around it, they have a hearbeat and a rhythm…and they eventually die. While a natural death looks like the logical end for a project – for it marks successful accomplishment of the initially set objectives – many projects die an unnatural death, only to be reborn as yet another maintenance project, or a feature enhancement on a previously unfinished work! I have seen enough projects where planning for a next service pack would start even before code freeze of the mainline release! How can we ensure that “immortal” projects achieve “moksha” from this non-stop nonsensical cycle of life, pseudo-death and rebirth?

Most projects die of unnatural death because we overpromise the project one way or the other – it might be undeliverable deliverables, or  impossible deadlines, or unreasonable cost, at unachievable quality, or any other deeply questionable and highly unattainable outcome of the project. In a way, there is one single reason: mismatch between project’s ‘supply’ (e.g., time, money, resources, etc.) and project’s ‘demand’ (e.g., deadline, scope, quality, budget targets, etc.), with the former heavily outweighed by the often unreasonably-sounding latter. So, we often blame the this mismatch and the result is an immortal project!

So, why do we still overpromise ? Is is that we pursue the glory of an immortal project, often confusing it with immortality of a project’s creation, or project’s creator? Or, we are too naive or timid to let the project sponsor and the customers know of the reality? Or, we deliberately create such situations and thrive on the resulting chaos because a fighting (even if losing) project looks good on our resume than a rock-solid project delivered without its fair share of trials and tribulations?

It turns out there are really only two main reasons: intentional and improper analysis.


Quite often, stating the cold facts and bitter truth might mean that the project simply won’t take-off. Try telling a customer that you can’t build a compiler in three months and see him taking the business to your competitor. So, a way to get started is to sugercoat the issues and somehow get it started. Once the game is on, the deadlines and budgets keep inflating because aborting the project midway might mean loss of face (or office, or both) for the decision-makers (who perhaps have a hefty year-end bonus tied to that project). So, after some 5x budget overrun and 4x of original schedule, the project finally ‘delivers’ something that might have never happened as per the original business case. Is it a right thing to do? I don’t know, but it surely is a great way to get things started, when otherwise they won’t :). Virtually all megaprojects happen like this. You tell the project sponsor (Government, in most cases) that developing this world-class fighter jet will cost $5 Billion and the file will go in the deep freezer. But tell that in $1Billion, you will develop core technologies and do a pilot demonstration. Then somewhere near the project complete date, you come out with list of Murphys, list of new innovations, blah, blah, blah….alongwith a bill for another $1 Billion funding. The politicians, by then, have been sold on the idea, and they have used that project to come to power – so, there is no reason they can back off from their pet project. And the fun goes on…

In some cases, it is unconventional and extremely rare wisdom to cause project immortality intentionally and avoid a harakiri of one’s professional career. However, there are often accidental geniuses who don’t speak up because they are too naive or too timid to speak up the truth. The result is still the same…

Surely, we can’t help such projects attain moksha because these projects are designed to achieve objectives at any cost, come what may. Such projects have nine lives, and so, they are destined to play their part to the hilt. At the cost of inviting wrath from project management community, I would say that if that is the only way such a project can get started, one might as well plan it ‘incrementally’ and deliver the benefits such that it is never ‘too little, too late’ lest project sponsors forget what the project was all about :). 

Improper Analysis

Ignorance about facts could invariably lead to wrong assumptions, many of which might remain unverified due to carelessness or a perception about its real threat value. These could, in turn, lead to inadequate risk identification, and thus lack of any planned and systematic response to those risks . This, then, leads to an optimistic planning about the real effort required to accomplish something, the number of resources and schedule required to complete the task, and so on. Most people who challenge planning cite the fact that a plan undergoes changes all the time, so any planning is a futile exercise. They couldn’t be more right. However, what they ignore is the fact that a plan is perhaps fourth or fifth order derivative of facts, and by eliminating the process of planning, they are only half-baking their project. If all facts about a project have been objectively verified, we can safely come out with set of assumptions. It is perfectly ok for various team members to have different perception about probability and impact of such assumptions and risks, but by choosing not to analyse those facts, we could never reach that point, could we?

However, such projects finish-off careers, tank companies, destroy health and families, in addition to never meeting their original objectives. If they are fixed price, they spawn enhancement / feature addition / maintenance projects. If they are T&M projects, they just go on and on. If the project is of strategic importance, it continues. If not, they are buried deep where no one can find them. If a key executive was behind the idea, it is never discussed in the company thereafter. Sometimes, such immortal projects are used a proxy for boardroom politics. In any case, the eventual responsibility for avoiding such immortal projects lies with the project manager.

We all know the rhetoric, but still we somehow manage to immortalize the project by making wrong choices abour project planning and execution. As project manager, the following steps could help you avoid project immortality and take you towards project moksha:

  1. Get agreement on project scope in mutually agreeable terms. If you don’t precisely know what is required, you may not be able to deliver precisely what is required.
  2. Validate every assumption. This is perhaps the single biggest source of gaps in project analysis and planning.
  3. While analysing risks, don’t ignore risks that have high impact but low probability – if it materializes, the impact could still kill the project.
  4. Get your team to make and own project commitments, and review them throughout the lifecycle.
  5. Measure twice, thrice or even ten times till you have confidence in your numbers. And only then cut the cloth. Of what use is a commitment to the customer when the team itself doesn’t have confidence in it?
  6. Learn to say ‘NO’ and to substantiate it with your line of reasoning till your project stakeholder and project sponsers are convinced.
  7. Fred Brooks was right – it is the termites that kill the project and not tornadoes. Ignore daily delays at your own peril.

Surely, these simple steps won’t guarantee your project’s salvation. At best they will remind you of some of the critical things you could do to reduce chance of a project immortality. At worst, they will be of no use, simply because something else will come from left field and hit your project. In this blog post, I wanted to introduce the concept of project immortality and project moksha that I found interesting while thinking on those lines. It offers a different perspective to how projects evolve into often unexpected lifeforms.

So, do you want your next project to be immortalized 🙂 ?

Why are more projects failing ?

Standish Group just came out with 2009 edition of their famous CHAOS Report: (text highlighting and underlining is mine)

“Boston, Massachusetts, April 23, 2009 – New Standish Group report shows more project failing and less successful projects.

The Standish Group’s just-released report, “CHAOS Summary 2009,” “This year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions” says Jim Johnson, chairman of The Standish Group, “44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”

“These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures”, says Jim Crear, Standish Group CIO, “They are low point in the last five study periods. This year’s results represent the highest failure rate in over a decade“.

This seems to be quite an anti-progress and is highly discouraging to say the least. The timing of the report itself couldn’t have been any more worse – with current economic situation, not too many dollars are available for projects, and whatever dollars are there, don’t seem to be getting a good mileage. I have not read the report yet, but I am eager to learn why the failure rates have shot up once again. In the last decade, we have certainly improved our ability to manage projects (or so we thought), have migrated to supposedly-better methods, have more virtual projects, more multi-site work, etc. In terms of tools, we probably are sitting on a pile of tools. When it comes to people, we probably have the highest number of professionally qualified and experienced managers than ever before. So, is it that newer challenges have caught up with our current capabilities ? Are these failures primaily because of offshore  work, or virtual teams, or expectations of Web-based projects, or something much more fundamental to a project…the people ??? Either ways, it promises to be a great eye-opener, and I am as eager as you to explore this study further.

Study apart, do you also think project failure rates have shot up in the last 5-10 years ?

Why are more projects failing ?