Archive for the ‘Project Management’ Category

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

Share This Post
  • Share/Bookmark

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

Share This Post
  • Share/Bookmark

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

Share This Post
  • Share/Bookmark

Congratulations! You’ve got the long-cherished promotion that will make you manager – of your own buddies! You don’t quite know what it means for your relations with the team – are you better-off as their manager or as their buddy?

One key challenge with first-line managers, especially those fairly new in their roles, is how to strike right balance between formal reporting relationship and informal personal relations with the team. Considering that most people “leave managers and not companies”, this seems to be a critical issue, but seldom discussed. In my career, I have also seen similar issues when people became a second-line manager or a group manager for the first-time – so, this is not a one-time issue.

I have often seen managers who have been promoted from within going all too out to please the team that “nothing has really changed” and they are still the good old buddy that they have known him all along. In their earnest to earn brownie points from their once-colleagues-but-now-team, they behave and act like one of the guys. Nothing could be wrong with it, except when personal proximity limits or blurs their professional judgment, especially when pulling up low performers. At times, I have seen this was the ‘bribe’ such managers were willing to pay to buy their team’s ‘respect’. The team definitely loves such managers (“I drank till 3am last weekend with my manager”, or “We plan to watch movie with our manager this evening”), and the manager also has surely found a way to make peace with his team, some of whom might be secretly jealous of his growth. Sometimes, they also overdelegate, or recommend promotions too-soon for their teams – which could be an indication of the secret guilt or discomfort they carry inside them. Surely, this is not an easy seat to occupy, and with little preparation or onboarding support given to rookie managers, it is not surprising that people find what appeals to them best. Surely, these managers are extremely popular with their teams! I call them Santa Claus – they come to office with a goodie bag, and fulfill their team member’s wishes every day.

Continue reading ‘How does manager’s proximity to team affects team dynamics and decision-making?’ »

Share This Post
  • Share/Bookmark

Risk is generally assumed to have negative impact. However, a ‘risk’ can also have a positive impact. PMBOK 4/e talks of positive risks and calls them ‘opportunities’. Given that most project managers only have a passing knowledge of managing risks proactively (our industry still seems to reward crisis management notwithstanding the fact that most often people who fix a crisis were responsible for it in the first place!), it is extremely likely that most such opportunities are wasted.

A risk is just a future event with probability of occurance between 0% and 100%. If such probability is 100%, surely that is a certainty, and hence can be put on the plan. If it is 0%, again it is a certainty and hence you can plan accordingly. Risks are also known as ‘known unknowns’ because we know about those events – just that we don’t know what it exact outcome will be. So, it quite likely that the outcome could be positive, and need not always be negative. Sample the following examples of events that could have a positive impact:

  • You have made an offer to a manager whose company is fast running out of cash. The grapevine has it that they might not get any funding, and have just weeks before they fold up. If that happens, there is a strong likelihood that the manager whom you have made an offer will join you. Even though this is a negative event par se for that company, but for you, that is a positive event.
  • Your competitor initially undercut his prices and won the bid, but now he is in the danger of being disqualified on technical grounds. His loss means business for you, and hence that is a positive risk.
  • You offer “no-questions asked product replacement warranty” within 60 days of purchase. You allocate 5% of your your operating margin. Your new product has proved to be a great hit among teenages, and is flying off the shelves, and you expect that cost of product replacement might be within just 2%, thereby improving your overall profit margins on this product.
  • You need to arrive at airport on-time, and your commute is through the rush hour. You leave home well in-time, but it is tough and go. However, there is a football match that evening, and it is likely that you find the traffic very thin – possibly because most people are glued to their TV sets.
  • Your new software provides a workflow for managing personal finances. An NGO needs a low-cost software to manage its micro-finance product, but best-matching product is out of their reach. Your product *might* meet most of the requirements, including being in the budget, if only they can tweak their workflow a bit.
  • You are in construction business, and learn that government is toying with the proposal to reduce duties on cement and steel by 20%.
  • A major competitor who is also a large employer in the city is likely to announce lay-offs.
  • Because of an early delivery of an input component, you might be able to shave-off weeks from your delivery schedule.
  • City administration is likely to announce construction of a new  flyover that will cut down city commute and decongest the downtown.
  • You are a tour operator and the international travel association is likely to name your region in “Top Ten Places to visit before you die” list.

Continue reading ‘Do you care about positive risks?’ »

Share This Post
  • Share/Bookmark

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:

Curve of Pursuit 

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

Share This Post
  • Share/Bookmark

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

Share This Post
  • Share/Bookmark

Let’s face it – being a project manager is not for everyone. We place a truckload of expectations on a project manager and then use an extremely asymmetric yardstick to evaluate their work – when a project succeeds, we attribute it to the organization, the culture, the team, and the management support, but when the project fails, we simply blame the project manager for it! Yes, life is often lonely and unfair for a project manager.

The other day, my wife got me “1001 Things it means to be a Dad” and while flipping through the pages, I thought don’t we have so many things common between parenting and project management? Both the roles have changed drastically in the last few decades – no longer does the disciplinarian / command and control approach work, the divide between ‘management’ and ‘labor’ has everything but disappeared, and so on. The result was a lighthearted but realistic take on what does it mean to be a Project Manager? Enjoy :)

  1. Being a Project Manager means being a braveheart in front of the team, but starting the day with a small private prayer.
  2. Being a Project Manager means having a self-belief that can survive against all odds, but still having everyday blues.
  3. Being a Project Manager means fiercely protecting your team in front of the Customer and the Management, but getting back and having the tough talk with the team right after that.
  4. Being a Project Manager means knowing that it is not a wise thing to adopt every new methodology unless it is at least five years old, whatever the team members have to say about it.
  5. Being a Project Manager means realizing that anything of lasting value was not built in a day. Rome, for example. And then rushing the team into delivering as per the deadline.
  6. Being a Project Manager means telling yourself “aal izz well” – seven times a day, everyday, even on weekends.
  7. Being a Project Manager means saying everyone is equal, but still finding out-of-turn opportunities for underlings in the team.
  8. Being a Project Manager means telling your team not to believe in miracles, and then looking for a silver bullet.
  9. Being a Project Manager means beginning to appreciate other thankless jobs.
  10. Being a Project Manager means still maintaining a cheer while knowing that the last two resignations in the team will definitely kill the project.
  11. Being a Project Manager means sometimes taking a Sunday off.
  12. Being a Project Manager means making someone’s day even when you feel like committing suicide.
  13. Being a Project Manager means having a personal copy of “The Mythical Man-Month” and reading it at least once every year.
  14. Being a Project Manager means tolerating team members dozing off in their cubicles or in the middle of a meeting.
  15. Being a Project Manager means realizing that you are only as good as your last project.
  16. Being a Project Manager means losing the popularity contest among team members. Almost always!
  17. Being a Project Manager means success is the multiplication of several factors, and when any one of them becomes zero, the result is a failure.
  18. Being a Project Manager means working with supersized egos.
  19. Being a Project Manager means knowing the meaning of ‘tough love’.
  20. Being a Project Manager means maintaining two different dates – one for customer and one for the team, but never admitting it.
  21. Being a Project Manager means not falling for the ‘it will be ready over the weekend’ trick, but still cheering up the guys for their enthusiasm and support!
  22. Being a Project Manager means keeping the team first, customer second and the company third, but always telling the team that customer comes first.
  23. Being a Project Manager means having more confidence in the team then they have in themselves.
  24. Being a Project Manager means showing up first in the team meetings and waiting patiently for team’s ‘prima donnas’ to show up late (or simply not show up at all!).
  25. Being a Project Manager means knowing that there is no such thing as bad times, but then wondering when will good times return for you?
  26. Being a Project Manager means building a culture that welcomes all forms of diversity without any conditions or prejudice.
  27. Being a Project Manager means knowing that every promise made to the team and the Customer must be kept, but promises made to family need not be!
  28. Being a Project Manager means playing ‘different strokes for different folks’.
  29. Being a Project Manager means sometimes acknowledging in front of the team that there are things beyond your control.
  30. Being a Project Manager means knowing that meritocracy might not always win, but merit must always be promoted.
  31. Being a Project Manager means knowing what doesn’t kill you, only makes you stronger.
  32. Being a Project Manager means knowing that if team members don’t oppose you, something is wrong.
  33. Being a Project Manager means knowing what goes around, comes around.
  34. Being a Project Manager means sometimes ordering pizzas when the team is working late.
  35. Being a Project Manager means being a human being first and foremost.
  36. Being a Project Manager means knowing that all mails sent on Saturday 2:00am are not always about working hard.
  37. Being a Project Manager means learning new things all the time. For example, learning new technical things from new college grads.
  38. Being a Project Manager means holding the proverbial mirror to the team, and telling them that you (and not them) alone are responsible for the mess.
  39. Being a Project Manager means having rock solid ethics.
  40. Being a Project Manager means not falling in love with the project plan.
  41. Being a Project Manager means knowing that bricks must be used to create bridges and not walls.
  42. Being a Project Manager means knowing when to sit down with the guys, and when to let go.
  43. Being a Project Manager means telling war stories to the troops, hoping against hope that will inspire them.
  44. Being a Project Manager means getting your own coffee just like everyone else in the team.
  45. Being a Project Manager means joining the guys at the water-cooler when in good times, and avoiding the water-cooler when in bad times so they can gripe and bitch against the management together.
  46. Being a Project Manager means agreeing with team members that frameworks like PMBoK are useless, but then going back and referring to it once again :) .
  47. Being a Project Manager means dressing up in Santa Claus suit at least once in your career.
  48. Being a Project Manager means never ever speaking ill of your manager in front of your team.
  49. Being a Project Manager means not feeling ‘threatened’ letting team members sit at the head of the table.
  50. Being a Project Manager means cheering up the rookie on the team for a screw-up when you really want to strangle him for that costly and dumb mistake!
  51. Being a Project Manager means playing the good cop for the team.
  52. Being a Project Manager means knowing that success is useless – it is only the failure that teaches something worthwhile.
  53. Being a Project Manager means protecting the team, but not overprotecting them.
  54. Being a Project Manager means at times, slowing down is the fastest way to results.
  55. Being a Project Manager means emphasizing the value of relationship to team while dealing with a separation at home.
  56. Being a Project Manager means mentally visualizing an overloaded plate while signing up for additional work beyond what the team can sign-up for.
  57. Being a Project Manager means posting Dilbert comic strip on the project wall to show what a fun guy you are, but in reality, hoping that no one else posts comics nastier than that.
  58. Being a Project Manager means knowing it’s just a project after all, but then going out and giving all you got!
  59. Being a Project Manager means dying a slow death – in a fast lane.
  60. Being a Project Manager means neither having the cake nor eating it too!
  61. Being a Project Manager means you have that something special that everyone aspires for but no one really wants.
  62. Being a Project Manager means having an unflinching faith in life after death :) , especially the kind of death that comes typically at the end of every project.
  63. Being a Project Manager means finally realizing after twenty years of school of hard knocks that the real outcome of a project is not about delivering against the set goals, but rather building a great project manager!

Continue reading ‘63 Things it Means to Be a Project Manager!’ »

Share This Post
  • Share/Bookmark

In today’s times when budgets are tight, promotions are slow and the amount of new product development opportunities rare, it is not easy to motivate your team members. As a project manager, you don’t have so many tools or resources at your disposal to engage your team members in a meaningful dialog to enhance their motivation, intrinsically or extrinisically. Really?

Most people (and people managers) believe you can’t really motivate your team members if you don’t give them obscene salary hikes every year, award annual bonuses that put shamed Wall St bankers to shame, promote them every second year and throw lavish parties every month! Sadly, they can’t be any further from truth. Most of us don’t realize (or perhaps, don’t want to realize) that the most effective means to motivate people are two simple things: match people’s assignment to their passions, and appreciate them for their efforts. And none of them require a dime :) . Granted that we often can’t match people’s assignment to their passions (though most managers don’t even make a reasonable attempt and a genuine communication when that can’t be done), in this blog post, I want to talk about the second one. To appreciate someone needs no capital budget, no planning, no strategy, no right timing, no resources, no MBA degree, no technical expertize, no PhD in creative writing, no big slogans, no special finesse, no world-class oratory skills, no big-banner problems, no game-changing events, no ‘senior-enough’ title, and most importantly, no approval from anyone! All it needs is an open mind and a geniune will. And who says an appreciation has to be in an email, with a gift voucher, or a memento at the next town hall or limited by some monthly quota on number of appreciations possible? I think the most effective appreciation probably needs no more than 5 minutes (or even less!) of genuine conversation to let the other person know what a sweet job they have done and how you feel about it. Yes, that’s it. If your words are genuine, they could change someone’s life like never before. Read this small story from The Simple Truths of Appreciation, which is a great example of how it changed someone’s life and pretty much set him up for lifelong success!   

Continue reading ‘Is appreciation the most underappreciated tool in your toolkit?’ »

Share This Post
  • Share/Bookmark

A recent headline caught my attention - Tevez jumps 120 spots to 27th in Castrol football rankings. Another noteworthy event this EPL season has been the virtual dominance of Wayne Rooney. This set the amateur football dad in me thinking, what could be the root cause behind a sudden surge in their performance in just one year?

Let’s look at how Rooney’s performance has moved this year against Ronaldo’s performance (source):

Ronaldo vs. Rooney

Continue reading ‘Leave that all-star team. NOW!’ »

Share This Post
  • Share/Bookmark

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

Share This Post
  • Share/Bookmark

Prior to the industrial age, the world was essentially an agrarian and a trading economy. Production methods were often a craft and top secret, fiercely protected within a family and handed down from a master craftsman to his sons, and with no machinery for mass production, pretty much every product was handmade and unique, perhaps also customized, for its intended user. Industrial revolution made mass production and rapid movement of goods possible, and among other things, catapulted Britain into forefront of global economies. Gutenburg’s printing press was perhaps the first mass production system built by man. Subsequent inventions like harnessing of steam power made railways possible, spinning machines, and other advances in iron founding and chemicals pushed the envelope. However, a lot of these advances were limited to Europe and even more within the UK, which thrived on these advances and became the economic (and imperial) superpower well until the start of twentieth century.

However, by the start of twentieth century, America too woke up to industrial advancements and contributed to some of the most important advancements that still continue to touch our lives. The pioneering work by Eli Whitney on ‘interchangeable parts’ on his now classic cotton gin introduced the concept of modular design, followed up by Frederick Winslow Taylor’s groundbreaking work on scientific management led to the concepts of standard work and division of labor  (even if somewhat questionable and controversial in today’s context) and created the foundation for Henry Ford to envisage a mass production system with a moving assembly line where finished goods could be assembled from standard parts by semi-trained operators, e.g. Ford’s most famous Model T car in black color (“Any customer can have a car painted any colour that he wants so long as it is black”).

In essense, a production run, say in an automative parts production or even a car assembly line, is the repetition of a process that produces similar (or similar-looking) objects. Once the ‘process’ is ‘designed’, the job entails repeating the process till the desired number of objects have been produced. Clearly, the faster you produce those objects, the sooner you can put them up in the market for sale and start getting money. The more you produce, the more you are able to amortize the capex, and get lower per unit price over the long run. Intuitively, if you have to produce objects that are exactly alike in properties, shape, size, color or any other physical attributes achieved by the production process, you can ensure that your production machinery will need to be ‘programmed’ once and re-used several times later. So, if you run the paint shop (which seems to be the largest bottleneck in terms of time in a modern production setup) and need to produce purple colored chasis, once you set the process, stock the paint to desired levels, you are pretty much all set. Now imagine if you have to produce first 200 cars in purple, then next 30 in wine red, then next 70 in pearl white colors. Surely there needs to be some way (manual or otherwise) to alter the production process to suit such job order. Similarly, instead of producting 300 sedans, if you have to produce a mix of automobiles – say, 50 SUVs, 50 compacts, 150 sedans and 50 hybrids, your process will have to be different from the one that just produces 300 sedans in a single production run. While the customer desires options (don’t we all?), the manufacturer incurs additional time, money and resources in creating such options. From the manufacturer’s point of view, producing each piece exactly similar as the last one makes such great economic sense that he can create huge economies of scale made possible by principles of mass production. It simplifies the machine (and machine operations) required in plants, it standardizes the components required, there is no downtime to alter the production process, people don’t have to be retrained every now and then on different type of products, and all this make the entire production process very ‘controllable’ from throughput and quality perspective, and hence highly predictable. Elaborate statistical charts can be created based on prior experience on how much time it takes for a given production run, how much men (and women) and materials are needed to meet a given production target, and what levels of quality can be achieved based on statistical experiences. 

Continue reading ‘Why are we in this mess?’ »

Share This Post
  • Share/Bookmark

A Software Project Manager’s job is often thankless. In a small team, this role is not differentiated enough, and is more ornamental than functional, the project manager being a regular individual contributor just like other team members, for most part of the project. In a large team, project manager often quickly loses respect from the foot soldiers as he is not seen ‘techie’ enough anymore. From a people management perspective, it is all about staying out of a popularity contest, if there ever was one. From project management point of view, there is an assymetric or non-linear reward-punishment scale: when a project succeed, more credits are given to the team, stakeholders and other environmental factors, while when the project fails, the responsibility squarely rests with the project manager. And as if that was not enough, new-age methodologies like Agile have altogether eliminated this role, I must add, rather prematurely. 

So, what is it that a software project manager really ‘manages’? What are the decision-points that have potential to shape the successful outcome of a project? Quite often, they are ‘invisible’ to naked and untrained eyes, and rest of the times, it is encapsulated in an organization’s standard process (whether written down, or unwritten). So, it doesn’t come as a surprise when the team is naive about the real value-addition by a project manager, or the upper management discounting its importance. However, as our dear friend Sherlock Holmes has taught us – absence of evidence doesn’t mean evidence of absence. So, let’s take a stock of characterstics of software projects – things that impact design and management of a software project, whether or not they all apply to every single project:

  • Scope: Fixed, changing, feature creep, “Featuritis”
  • Size: Size of software, development cost, number of people
  • Schedule: Length of schedule, fixed schedule, variable schedule
  • Complexity: Volume Complexity, Cyclomatic Complexity, Innovation, NPD (New Product Development) 
  • Project Management Methology: PMBoK, PRINCE2, CMMI, Agile,
  • Development Paradigm: Waterfall, V-model, W-model, Spiral, Scrum, XP, Kanban,…
  • Location of teams: Collocated, distributed, virtual
  • Quality requirements: 6δ, Mil-Standards, FDA, Carrier-class or Five Nines (99.999), Enterprise Class, Web, HA, Mission-critical
  • Technology: Existing, obsolete, brand new, evolving, pre-standards
  • Team Structure: Command & Control, Democratic, Self-organizing, Self-managing, etc.
  • People: Skills mix, Experience, Domain Knowledge
  • Tasks/activities: Unpartitionable vs. division of labor, expertise vs. fungibility, task dependencies, uncertainties, risks, estimates, 

Continue reading ‘How many balls does your project manager juggle?’ »

Share This Post
  • Share/Bookmark

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

Share This Post
  • Share/Bookmark

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

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