manage well

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 saved 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.

Continue reading ‘Is Planning an old idea whose time is up?’ »

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!

Could 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.

Continue reading ‘How do you schedule tasks in a project?’ »

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

Continue reading ‘Your estimates or mine ?’ »

Imagine driving down a country road when a street dog starts chasing your car? The dog ‘attacks’ the car but by the time gets it closer to the car, the car has moved ahead, and so the dog changes direction and attacks at new coordinates. This game goes on for some time, but because the car is faster than dog, dog loses the race never quite catching up the car! The resulting curve looks something like this:

In mathematics, this is known as the ‘curve of pursuit’ –  a curve constructed by analogy to having a point or points which represents pursuers and pursuees, and the curve of pursuit is the curve traced by the pursuers. The dog is attacking the problem as it see right now, but by the time it reaches near it, the problem has gone ahead a few steps! So, a problem-solving approach like this is perhaps only going to prolong the time it takes to solve it, and also make is costly in the process (not to mention, create opportunities for additional problems to breed in that time). A far more prudent approach will be to anticipate tomorrow’s problems and address them today.

Continue reading ‘How to avoid ‘curve of pursuit’ in three simple steps?’ »

Those racy commercials look so unbelievable and comical – a scrawny half-man-half-boy drowns himself in a chemical that promises to be the Aphrodisiac Ultimate, and in comes flocking an army of semi-nude women and mob him comprehensively and the Axe Defect is complete! The chemical instantly obliterates all imperfections and turns a below-average Joe into a rocking party-animal Casanova! Well, several project managers also suffer from The Axe Defect!

Urban Dictionary defines “The Axe Effect” as:

Continue reading ‘The Axe Defect!’ »

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…

Continue reading ‘The 5 Goals of a Project Manager’ »

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:  

Continue reading ‘32 Reasons Why People Don’t Plan Projects’ »

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?

Continue reading ‘From ‘Project Immortality’ to ‘Project Moksha’’ »

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?’ »

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 !!!’ »

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!’ »

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?’ »

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 ?’ »

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 ?’ »

 Large teams might be inevitable in certain large endeavors, but there are several benefits of small teams. A small team can build and maintain a strong culture and a character that gets better with time. Small teams quickly learn the invaluable skills in teamwork and interdependence that lead to higher efficiencies while ensuring that individual team members don’t end up competing against each other but rather collaborate on the common objectives. Small teams also mean small egos

One of the biggest motivations of making smaller teams is to provide higher levels of transparency and task accountability to individual team members. A large team tends to hide inefficiencies, both of its structure and of its people. One particular problem in a large team is the problem of “social loafing” – something that is perhaps best described in this poem by Charles Osgood:

Continue reading ‘Addressing the issue of “social loafing” in large teams’ »