Tag Archives: Project Management

Hard work is killing people. Literally!

Recently, I was reading an article on how Japanese-style manufacturing isn’t working out quite so well in India (despite having been successfully around since 80s), and that there have been several strifes lately. There was an interesting reference to what the Japanese call as Karoshi and Karojisatsu. Now, unlike many other Japanese words, these are really gross words because they mean

  • Karoshi = Death from Overwork
  • Karojisatsu = Suicide from Overwork (and stressful working conditions)

Curious to know more about it, I chanced upon this graphic from ILO page on workplace safety:

Karoshi and Karojisatsu cases in Japan, 1997-2011, ILO This data comes from Japan, and while the numbers might not (yet!) look staggering to many a folks, the trend is unquestionably disturbing, and our own deniability might only be getting compounded by lack of data from our own respective countries or industries, not to mention the social stigma that might be associated with someone refusing to ‘work hard’ on medical grounds lest they suffer an injury, suffer a burnout or commit suicide!

In the last few years, I have heard of small but increasing number of such sudden deaths among senior IT professionals – not just in Bangalore, but also globally. You can read about them here, here, here, and here.

Burnout is a serious issue for several countries, industries and people, even if we don’t acknowledge in as many words. In our industry, where heroism, cowboy programming and all-nighters are considered cool and an integral part of the software subculture, there has been a (really) small effort to address work-life balance by identifying that software development should be ably to proceed “indefinitely” on “sustainable pace” with XP explicitly advocating 40hrs a week (though some might disagree with this interpretation of “sustainable pace“). However, anyone who has ever done any non-trivial piece of software development will point out how hollow this expectation is in reality. When it is the release time, families learn to deal with their family members coming late or staying back office overnight, or working through the night even if home. Those in startup phase don’t have the luxury of ‘closing the day’, and those who are entrepreneurs actually thrive in such environment. So, is the thrill-seeking behavior at work here? Could it even be the case that we are only unknowingly aggravating the problem by hiring more people who think, talk and work like us – thereby creating a tarpit-kind of environment where there is no escaping it?

It is well-known in manufacturing that we never utilize machines more than 80-90% of their rated capacity (global stats on utilization are more like 80%). And yet, we don’t think twice before ‘loading’ human beings to much beyond their 100% capacity! Unfortunately, the data suggests that working more reduces productivity, as below:

Working hours vs. Productivity

Or, our ‘professionalism’ stops us from admitting that if I put out my case for a better work-life balance, I might be considered a loser and be considered unfavorably in appraisals, promotions and salary raises?  

So, how do you deal with it, or rather, ensure that you don’t get burnt out? Or, if you are a people manager or a leader, how do you ensure those supporting you are not getting burnt out?

Important to call out here that the old harmless joke “Hard work never killed anyone. But, why take chances?” suddenly doesn’t look so innocuous anymore. 

Worth thinking…

How do you manage intercultural issues in your teams?

I recently had the good fortune to fly in from Doha to Dubai in a Dreamliner, and later again from Bangalore to Delhi – before they got grounded following a safety advisory. No doubt, it is a marvel of engineering excellence, and I am sure they will figure out battery problems sooner than later.

However, while reading this article “From the Start, Dreamliner jet program was doomed”, I could not help express surprise over some of the issues discussed. While some of the issues reflect a very high-end of engineering being tried out for the first time, and hence some teething troubles could be expected that could be solved by engineering, some other relate to the human aspects, surely not happening for the first time, which perhaps trumped several other issues:

It seemed like the Italians only worked three days a week. They were always on vacation. And the Japanese, they worked six days a week,” said Jack Al-Kahwati, a former Boeing structural weight engineer.

Even simple conversations between Boeing employees and those from the suppliers working in-house in Everett weren’t so simple. Because of government regulations controlling the export of defense-related technology, any talks with international suppliers had to take place in designated conference rooms. Each country had its own, separate space for conversations.

There were also deep fears, especially among veteran Boeing workers, that “we were giving up all of our trade secrets to the Japanese and that they would be our competition in 10 years,” Al-Kahwati said.

None of these are new issues to any student of inter-cultural issues, especially in project management, but what is surprising is that for a program of that strategic importance and such magnitude, these issues were ignored and they eventually came back to bite.

Distributed and virtual teams are a reality of today’s world. It is not just limited to well-heeled MNCs – we see countless everyday examples of such teams with NGOs, startups, voluntary efforts, college project and so on. There is more to working with people from different time zones and cultural contexts than we realize. Problem is, most of us haven’t been exposed to, or adequately trained to handle such diverse teams – not just as a manager but even as a team member. As a result, when there is a need to work with distributed teams, we tend to curl up in our cocoons and shun working with them. It could be due to excessive paranoia due to job insecurity, or it could be due to prejudiced mindset about folks who are ‘out of sight’, especially at a low-cost destination. Sometimes, it might simply be due to sheer laziness. I have once been in a situation where a VP based out of company headquarters wanted to only work with people within his ‘line of sight’ – he hated getting on emails, hardly ever responded to them, and his preferred style was chatting in hallways or at cubicles. Sounds familiar? However effective this strategy might be for his immediate team within a shouting distance, this would lead to his remote teams feeling disenchanted. You might be a great leader, but remember – managing remote teams is also part of your success!

Panel discussion on "Intercultural Issues in Project Management" at Grace Hopper Conference, India, 2012In Dec, I had the opportunity to participate in an interesting discussion at the Grace Hopper Conference, India on “Cultural Intelligence in Project Management”. We discussed some of the personal experiences of a very diverse and highly experienced panel. Some of these experiences ranged from Bangladesh to China, Japan to Israel, and US to Europe and so on.

One of the points I shared was about how to manage inter-cultural teams. This is a big topic and we can spend a day on it and still don’t get it right! In my experience, there is a process that I have developed and refined that works well. Here is how it goes:

  1. Be aware of the intercultural differences – don’t paint everyone with the same broad brush. This is especially important for ‘foreigners’ in your team lest they start considering them as ‘aliens’ in the team! To me, recognition of such differences means respect and that itself is such a motivation for everyone to feel welcomed in a diverse group. In a Chinese company I once worked for, it was common for everyone to be in office till 9pm everyday, 6 days a week, even if there was no work that demanded people to stay back. Meetings would be setup at 5pm and go on until 9pm and beyond. While this was ok for many of the Chinese folks as they were ‘foreigners’ to Bangalore and had nothing better to do in evenings than work at office, this was not so ok for many Indian engineers who had a family. While no one minds occasionally staying staying for work exigencies but everyday was a drain. In that high-performing culture, leaving early for home would be seen as a sign of lesser commitment and effort. While things did eventually get better (at least in my team because I summarily rejected such outrageous ways of ‘measuring’ performance of an individual), it took some time and great efforts to make people realise their intercultural differences that we have grown so subconsciously used to.
  2. Creating common norms – Instead of forcing one set of people to change to another set of people’s preferred way of working, it is much better to arrive at a common way of working, even if that is not the most efficient way of working. Ideally, let the team evolve such norms so that there is a higher buy-in for those common standards of mutual behavior. This will demonstrate tremendous respect for individuals and encourage them to participate in team proceedings that will go a long way in building their individual buy-in and a team camarederie that will set the team on a high-performance trajectory. More than once in my career, I have been involved with diverse teams where simple things like how fast an email should be responded to has been subject of intense debate. We all have different ways to answer them. Some would take the old analogy of a telephone call – just like someone who is physically present is more important than the one calling on phone at their leisure, why should someone sending an email become a priority for me? On the other hand, there are folks who would want to respond to emails within a hour if not minutes! So, what is the best way? Clearly not making everyone answer the mails in one hour, I hope! Let the team discuss this issue and let them come out with common norms such as 24hrs or 48hrs based on what is important for the business. As manager, step in only when you think teams are setting the bar too low, and then also, step in not to dictate your preferred ‘norm’ but to clarify the objectives and provide supporting data and steer the conversation towards why it is important to meet those objectives – teams are smart, they will figure out the rest. For example, if time tracking is a project requirement (either for tracking project effort or for billing the client, or for any other reason), and given people’s propensity to either avoid it completely or do very meticulous time tracking, then it might be a good idea to also identify a common tool, such as a time and attendance software, that makes sure everyone is on the same page. 
  3. Exploit intercultural strengths based on individual strengths – the idea is not to make a rabbit fly or to make a bird swim, but find out who is naturally adept at certain strengths and match their tasks to their strengths. As managers, we don’t want to be parents to the team members, and there is no point ‘forcing’ them to change them to do thing that they don’t relate to (unless of course, that is jeopardizing project objectives). Instead of doing a command and control style management of allocating tasks, managers should walk a few extra steps and undertand what motivates their team members, and if possible, assign them that work. In most cases, that might be a strength they already posses, and in some cases, it might a skill they aspire to possess and might not be the best candidate for it. However, if they can demonstrate that they have taken steps to match their desire to improve their capability in that subject, then as managers, we owe it to them to give them a fair chance. Assigning a mentor as they take up a new task might also be helpful. I once had a great team member who was majorly motivated by helping everyone on the team. Almost each evening as people were winding up their work, he would go to them and chat up with them on their problems and offer voluntary help to stay late and fix it. He would do it in such unintimidating and affable manner that other team members loved it (and I can’t recollect anyone misusing that gesture of benevolence, in case you are wondering). As his manager, the only thing I was supposed to do was just to stay out of the way and cheer him up! He was clearly driven by his own deep passion for the product that we were working on.
  4. Broadbase core strengths – finally, once the team has come to the point where people don’t feel intimated or vulnerable due to their shortcomings but rather feel appreciated for their strengths, it will be much easier to cross-pollinate those strengths among the team members. Since everyone is a mentor and everyone is a ‘mentee’ to someone else at this point, chances are that this won’t create adversarial relations among the team members, but actually stimulate a culture of mutual respect and learning. For example, someone might be an expert with a technology and another team member is great at planning. Once there is a feeling of mutual respect, it will be much easier to make them seek each other’s expertize in furthering their own knowledge.

This four-step process has served me well in multiple scenarios. There is nothing rocket science about it, rather it is based on simple laws of respect to everyone, and that’s why it works. And to me, intercultural is just that – a matter of respecting people for what they are rather than ignoring or ridiculing them for what they are not. After all, we are all perfectly imperfect and similarly different!

How do you manage intercultural issues in your teams?

Role of Integrative Thinking in Project Management

I just finished reading the brilliant “The Opposable Mind” by Roger Martin. He introduces the notion that we all possess the so-called  “opposable mind” which has this amazing capability to simultaneously hold two contradictory views about a problem.

The conventional wisdom is to try to find a via media but that is perhaps meekly surrendering to complexity by taking a short-cut to a suboptimal solution. He argues that the some of the most exceptional leaders do not succumb to the obvious “either/or” thinking but rather work patiently towards synthesizing the best from both of these opposing views to create a best-of-breed solution that is far superior to either of these. He calls it “integrative thinking”.

Martin writes, and I quote:

“…the leaders I have studies share at least one trait, aside from their talent for innovation and long-term business strategy. They have the predisposition and the capacity to hold two diametrically opposing ideas in their heads. And then, without panicking or simply settling for one alternative or the other, they’re able to produce a synthesis that is superior to either opposing idea. Integrative thinking is my term for this process – or more precisely this discipline of consideration and synthesis – that is the hallmark of exceptional business and the people who run them.…Human beings, it’s well known, are distinguishes from nearly every other creature by a physical feature known as the opposable thumb. Thanks to the tension we can create by opposing the thumb and fingers, we can do marvelous things that no other creature can do – write, thread a needle, carve a diamond, paint a picture, guide a catheter up through an artery to unblock it. All those actions would be impossible without the crucial tension between the thumb and fingers.…Similarly, we were born with an opposable mind that we can use to hold two conflicting ideas in constructive tension.”

The book is a treasure trove of how go develop integrative thinking, but I was struck by how much it is relevant to each one of us at all levels, not just for the leaders at the top. The field of project management is all about making sensible but often hard trade-offs. Effective management of Project Management Triangle is literally the holy grail of project management – one that not only is the nemesis of every project manager but is also, in fact, the genesis of modern project management. In layman terms, what we mean is that out of Scope, Cost and Time, you may pick up any two, but can never meet all the three of them at the same time. So, if the requirement is to build replica of Eiffel Tower in just three months and ten thousand dollars, then yes, it can be built but it might look more like a school project. If it is a fixed-scope project like migrating all tax payers to a new software by close of the current financial year, then one might need to look at costs involved without which either one of the scope of the time might not be possible to meet.

However, what ends up happening in reality in many situations is that a project still ends up taking the amount of money that is takes, and yet the scope delivered is too little, too late!

If one were to look at modern project management (though most of us in software industry would probably call it as ‘traditional project management’), I think we just don’t have any similar notion of integrative thinking. The only treatment I have seen is perhaps in the Theory of Constraints where the approach is more holistic.

In software development, the conventional project management is modeled around industrial model of a production process – the so-called waterfall. In a linear, sequential flow done by silos that specialize in a single functional area, there is natural tendency and inclination to optimize the area of responsibility. For example, a design team might be most concerned with how elegant their design is, whether is meets the future issues of maintainability or portability or not. Similarly, the high wall between developers and testers is industry-famous – which is a major reason why developers don’t trust testers (“they will come up with only Sev 3 bugs and kill us with volumes towards the release, and expect us to fix them all before GA”) and in turn, testers don’t trust developers (“they can’t write clean code”, “if only they did better code reviews and unit testing and found all code-level defects, we could do such a better job of finding all Sev 1 bugs and focus on performance and reliability aspects”). Clearly, such a process breeds a mutual trust deficit, and the narrowly focused project roles simply perpetuate it further. What happens is the tragic story of optimization of parts at the cost of sub-optimizing the whole – completely anti-lean approach!

Agile software development (the concept, not a particular methodology) helps by offering to eliminate such artificial boundaries that force “either/or” thinking. Instead of taking a monolithic approach of meeting 100% of the project triangle, it offers to simultaneously meet part of the scope at part of the cost in fraction of time that what would normally be needed in a waterfall model. However being recently introduced to this concept of integrative thiking, I am still thinking if agile philosophy fully addresses it, and on the surface, it doesn’t look like. However, I have been proven wrong in the past, so we will see…

Project Management vs. Program Management

Program Management is often seen as the next logical step for seasoned project managers looking to take on bigger challenges. While project management is more about managing within boundaries of a project and gatekeeping it against anything and everything that threatens the status quo, program management is typically all about breaking those very boundaries and managing across them by taking up anything and everything that threatens the status quo. In this post, I will examine how they differ in its approach on two important aspects – scope management and people management.

Scope Management

Like I mentioned above, a project’s success depends on its ability to retain focus against all odds. Once a project scope is defined, its estimates made, resources  allocated and commitments made, the project manager is pretty much focused on gatekeeping everything else out of the scope lest the project success is threatened. In reality, most projects would have a CCB, or a Change Control Board, of some levels of formal authority, there is still a tendency to bulk up the entire requirements in first-pass and do as much as possible in one breath irrespective of how much time it takes and whether the final outcome is acceptable to the customer or not. While most of the traditional world still likes this model for various reasons, software development community identified this as a bottleneck and created the suite of so-called ‘agile methodologies’ that exploit software’s ability to incorporate late changes to specs without seriously endangering the project or its deliverables. Still, at a high level, a project must work around a reasonably stable set of requirements to ring-fence itself against any potential changes to the ‘core’ of a project – the premise being how can you build a successful product on a shaky and wobbly foundation. After all, don’t we pay product managers to do a better job of defining those requirements upfront rather than changing their mind later in the project and calling it as customer change request to cover up what they failed to think of in the first place! Surely, everyone understands changes in workflow or bells and whistles, but I am talking about the core architecture – the fundamental DNA of a product that must be understand before any further allocation of time, money or resources is made. So, clearly, scope is sacrosanct to a project.

A program is a different beast. As the highest level of body chartered to translate an organizational’s strategic intent to reality, it can’t box itself inside any boundaries of defined or undefined scope. Anything that could impact a program’s ability to accrue full ‘benefits’ envisaged from it must be taken up. While in theory, a program must have a defined scope to plan its activities and resources around its deliverables, in practice it is not so trivial. Any reasonably large program has sufficient number of moving parts, uncertainties, conflicting requirements and rapidly changing priorities. It is very typical in a program for the component project managers to carve out their pieces very sharply. A lesser reported fact of life is that developer’s motivation to work in newer and sexier technology often dictates the choice behind a project taking up (or refusing to take up) a given problem. Program organizational structure and governance plays a very important role in ensureing that component projects are not only cleanly defined, they also identify inter-group dependencies and secure commitments to address them. To that end, a project might safeguard itself by rejecting an inter-group request, but eventually the program needs to address it! Similarly, a project manager might complete the work within her boundaries but it takes much more for the program to be ‘done’, let alone be successful. I have seen many situations where project managers would be so focused on their project that they won’t recognize that unless the program was successful as a single entity, their individual progress was meaningless. This could get aggravated when teams are geographically or organizationally dispersed. However, none of those can hide or discount the fact that a program is only as  successful as it ability to influence things that might not be in its line of control but whose impact is definitely in a project’s line of success, especially if those things were to backfire.

While a project is like a fortress that must protect itself against all invasions to survive and eventually be successful, a program is more like a university, a rose garden, or a mission – they all deal in ‘soft power’ and maximize the ROI of their mission by keeping their doors open and by teaming up with their potential adversaries.

People Management

A project manager in a functional organization wields significant ‘positional power’ and thus has very high ability to influence team members behavior. While today’s organizations are highly flat and democratic, there is still an asymmetric balance of power, for the manager who writes your focal and annual salary revisions also potentially has the power to decide when you should update your resume! Surely we have come a long way in management-worker power-sharing from Taylor and Ford era, make no mistake that there is no such thing as a perfectly symmetric world where a manager and her team member have equal rights. Thus, a project manager has much higher ability to define the work and assign people to it as she feels appropriate. She also has a much higher level of responsibility towards training and career development of her team members, and being the closest face of management to the team, she is the official spokesperson of the upper management. A team will likely listen more to her than to the CEO. She must balance two opposing sets of expectations that, if not aligned properly, can set the project on fire. To that end, people management for a project management must be one of the toughest job.

In high contrast, a program manager manages at boundaries of participating organization in a highly matrix environment, and hence must manage by influence and not by any formal authority. In a software team, a program manager needs to get Development, QA, Product Management, Usability, Documentation, Marketing, and several other functions on the same page. In most organizations, they are organized along the functional lines and hence report to a solid-line manager in the same skill-set pool rather than program manager. Given that many of these resource might be timesharing on a program, their eventual loyalties are still with their respective line managers and hence a program manager can only rely on collaboration and influence as the key measures to get everyone onboarded. In some cases, there might even be a conflict between a component’s goals and the program’s goals and if such issues remain unresolved, the only recourse to make the program successful might be to move the problem up the command chain. Still, there is a big value in managing large and complex endeavors as a program, for it allows an organization to manage its resources and inter-group dependencies and conflicts in a more systemic and transparent manner. Some of the best program managers I have seen were not the ones who stopped managing the interfaces, but went over and above what their jobs required. They established a direct contact with key team members in component projects and created an alternate informal channel to validate project risks and plans, and to feel the pulse of the organization. They would do it very unintrusively without creating any friction between the line manager and them.

How does your organization view these two important functions?

 

Is your project’s team spirit ‘flammable’?

You’ve hired the top experts for your new project. You’ve also found the right coach for the latest development process that you intend to follow for the project. Great! You are all set. You plan the project kick-off in a grand manner, the team seems to bond awesome at the kick-off party and seems like nothing could go wrong with this project…until it hits the first rough patch. And that’s when reality raises its ugly face from under the shiny hood. The same team now shows major ideological, political and behavioral cracks and divisions. People who earlier held ‘falling colleagues’ at the teambuilding outing just a few months back now secretly hatch a plan to push those very colleagues off the parapet! People who teamed up at the impromptu beach volleyball match and left everyone speechless by their sportsmanship and brilliant tactics still seem to be leaving everyone speechless – but this time more by their one-upmanship and dirty politics.

What happened?

Welcome to the ‘day-mare’ of leading a dysfunctional team with highly ‘flammable’ spirit – nothing is perhaps more detrimental to project success than such team dynamics. Assembling a crack team doesn’t automatically transform into a dream team. There has to be something that is the binding glue, the secret sauce that holds the team together through its highs and lows and makes people surrender their individual egos for the team to excel. This doesn’t come from individual skills alone, this is not a monopoly of knowledge industry alone, it doesn’t depend on national or corporate cultures, has nothing to do with age, race or gender, and isn’t something that money can buy. It is freely available to everyone as air but yet as rare as pink diamonds. It is as pervasive as the mythical ‘ether’ and yet it is not able to impregnate some of the most stubborn team cultures and individual mindsets. I call this as the ‘project spirit’.  Everything else being, it is what makes a team alive, vibrant, social, engaged, responsive, interlocked, courageous, agile, risk-taking, entrepreneurial, persevering, result-oriented and a true game-changer. And the absence of it can rapidly send the team spirit into a ‘flammable’ tailspin where mistrusting individual egos rip apart the social fiber of the team and lead it to inferno.

How do you ‘brew’ it?

In a true sense, project spirit is the elixir that gives vitality to the team. Too bad, you can’t buy from the pharmacy. However, if you work sufficiently hard, you too can ‘brew’ it in your teams.

In my experience, the single most important factor that leads to teams strong as steel is presence of a common, often ‘unrealistic’, unprecedented but extremely desirable, shared goal.

Before India’s first war of independence in 1857, India was largely a chaotic subcontinent of individual princely states that were better-off settling egos among themselves at the cost of poor people they ruled. Surely there were local battles and mutinies before 1857 that had limited effect, but 1857 war became a pan-Indian effort for the first time in history to throw Imperial British out of India. The cause made princes and people forget their individual differences and agonies, and they set out as one team, overcoming all obstacles in their way. Even though they were not successful, they set the pace and tone for Indian Freedom struggle that eventually resulted in Indian Independence in 1947.

I compare the great freedom movement like the French Liberation, and Russia’s Red Revolution, in the same league. They made the poor and the downtrodden sink their individual differences and come together as a single voice, single team that pulled down even the mightiest of the empires.

Similarly, JFK’s famous Rice Stadium Moon Speech in 1962 fired the imagination in mints of an entire generation of American scientists and engineers on a journey that no one thought was possible in their lifetimes:

“…But if I were to say, my fellow citizens, that we shall send to the moon, 240,000 miles away from the control station in Houston, a giant rocket more than 300 feet tall, the length of this football field, made of new metal alloys, some of which have not yet been invented, capable of standing heat and stresses several times more than have ever been experienced, fitted together with a precision better than the finest watch, carrying all the equipment needed for propulsion, guidance, control, communications, food and survival, on an untried mission, to an unknown celestial body, and then return it safely to earth, re-entering the atmosphere at speeds of over 25,000 miles per hour, causing heat about half that of the temperature of the sun–almost as hot as it is here today–and do all this, and do it right, and do it first before this decade is out–then we must be bold…It will be done during the term of office of some of the people who sit here on this platform. But it will be done. And it will be done before the end of this decade.”

Misery, common enemy and tragedies are often a great unifier of their victims – they bring people together like nothing else can. Soldiers battling the enemy from their trenches often go through extreme traumatic experiences that they become friends for life. When I volunteered to go to Antarctica for 16 months in 1993, I went through similar life-changing experiences. In that hostile weather, we faced challenges like the fire in our station – on day one of the winter (the ship had just left us a day before!), accidents with our helicopters, and many more. It worked like a charm – what no teambuilding or nightlong parties on the ship could do, the midnight fire brought us all on the same side within a matter of minutes, even though no one had been trained to fight a real-life fire in Antarctica – after all, our survival in that hostile terrain was not an individual matter anymore!

Shared ideology or a sense of purpose is another great way to bring people together and work with extremely high levels of mutual trust – so much so that they can end up taking causes that are beyond normal teams, even if bordering on being illegal. One of the best examples I remember is a work of fiction, “The Four Just Men” by Edgar Wallace published in 1905, where the four wealthy men have a common purpose that transcends the law because they believe they can bring higher good to the society at large by committing murders of people who seem to be above law. Hollywood movies like the Ocean’s series often bring a motley collection of people from different background united by a common purpose, albeit evil.

So, what is the right way to build such project spirit? Surely, cracking the whip to make all foot soldiers fall in line is the idea whose time is simply up. Even the CEO of companies that employ tens of thousands of people have realized the real worth of people. So, while putting the people under unreal pressure of delivery and time commitments might bring them together, but don’t count on it as a means to charge them – chances are that they might charge at you instead!

Creating a shared goal that has never been accomplished before is a sureshot way to build the greatest team ever. Not every project builds Taj Mahal, Eiffel Tower or the Dreamliner, but that’s where the true caliber of a leader is built – to achieve ‘extraordinary’ from ‘ordinary’, that ‘extra’ must come from the leader to raise the team’s desire to fly high.

One of Agile’s cornerstones is self-organizing teams where there is a presumption of unquestionable levels of high trust among the team members, they don’t need any external guidance or adult supervision on a daily basis. However, agile methods don’t really help teams understand the process that builds such ideal teams – it just expects it on day one! If every team could start with such highly mature, technical super proficient, and highly collaborative individuals, they simply won’t require any process to organize their work, let alone Agile! However, in real world, you constantly deal with hiring challenges, attrition, downsizing, delays, reduced resource commitment while the delivery timelines shrink, people who often need to be trained on the job, varying levels of competencies and motivation levels in the team, individual career preferences dictating day to day choices about the kind of work people like to do, and organizational needs and realities that need you to brave more inclement weather than what is romanced in the tiny hamlet where our agile team sits pretty!

The point is: build team spirit is a hard job. It requires endless sweat and blood. If you narrow down the problem by eliminating every single source of noise and self-appointing your backyard as the only problem you are willing to confront, then yes, you can build the dream team over a few beers. But that’s the deal – leadership is not about picking the sweetest of apples from the orchard but taking care of the whole orchard from wild animals, storms, invaders and other natural and manmade disasters. Anything short of it will make the team spirit ‘flammable’.

Is your project’s team spirit ‘flammable’…it might as well be because of YOU!

Just listen…when you can’t see!

Today I sat through a most amazing speech by a celebrated toastmaster. He has a very subtle sense of humor, a great command over his diction, confident body language, uses really simple vocabulary in a beautiful manner and establishes wonderful rapport with the audience. Did I tell he was blind? And yet, he was able to establish a great connection with the audience. This made my thinking: how does one go about ‘getting’ feedback from the audience when there is no way to know how the audience is responding to your speech? How does a visually impaired ‘read’ the language of smile, the language of silence and the language of silent appreciation?

A very important part of every communication, written or verbal, formal or informal, is that the sender of the communication must be able to get a sense of how it is being perceived and understood by the receiver of that communication. The best speakers are constantly searching for those subtle cues among their audience – the slightest sign of boredom creeping in, or the type of anecdotes that elicit a positive response, and so on. The best speaker experiences are simply not about delivering a prepared speech, come what may. Instead, it is all about careful listening, reading their faces, decoding their body language and sensing the general ‘mood’ of your audience while you deliver your prepared speech – but making those right adjustments to enhance the overall experience.

Similarly, a project manager’s reporting and communication is also kind of visually challenged! Many of your important stakeholders are not in your direct line of sight – they might be sitting twelve time zones away, or in another town, or in simply another floor, but pretty much ‘invisible’ to you. You might meet them maybe twice a year (or more, if you have a liberal travel budget) but for rest of the year, you are pretty on your own guessing how they ‘might’ be perceiving your textual communication or phone conversations. In the age of reduced team budgets, tighter deadlines and an overflowing work schedule, chances are that unless the house is on fire, you are not likely to qualify for your manager’s attention. So, how do ensure your stakeholders understand you when you can’t see their reactions to your communication?

Then there are equally important stakeholders who are visible to you, but don’t speak much – yes, your team. It might vary with culture, but generally, I haven’t seen team members speak much, or at least give a lot of feedback, unless you do a major screw-up! This poses a different type of challenge – that of guessing what might be cooking in people’s mind when they won’t share it – not that you can’t see, but a lot of it doesn’t still meet the eye.

So, how do you read people’s mind when you can’t see them? Simple – you ‘listen’ to folks when you can’t see them! You listen to the ambience and understand your communication’s causal and collateral impact! You give enough pauses in your communication that allows you to listen to how people are responding. You speak slow so that you can listen what you can’t see…

What would you do – blame your ‘handicap’ or turn it on its head???

PS: Just search for “Rajdeep Manwani” or watch this video to know more about Rajdeep.

Project Manager and The Three Questions

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 Questions by 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.

Is Planning an old idea whose time is up?

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!

Pillar on a railway trackWhile 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
  •  Before beginning, plan carefully – Marcus Tulius Cicero, Roman statesman and orator (106-43 BC)
  • Long-range planning works best in the short term – Euripides, poet (480-406 AD)
  • Forewarned, forearmed; to be prepared is half the victory – Miguel de Cervantes Saavedra, Spanish writer and author of Don Quixote (1547-1616). 
  • By failing to prepare, you are preparing to fail – Benjamin Franklin
  • In preparing for battle I have always found that plans are useless, but planning is indispensable – Dwight D. Eisenhower, general and president (1890 – 1969)
  • A plan which succeeds is bold, one which fails is reckless – General Karl von Clauswitz
  • Always plan ahead. It wasn’t raining when Noah built the ark – Richard Cushing, novelist
  • 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
  • Prediction is difficult, especially about the future – Yogi Berra, baseball catcher (1925-present)

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:

 

  • It’s a bad plan that admits of no modification – Publilius Syrus, Roman slave and poet (circa 100 BC)
  • 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)?

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?

Your estimates or mine ?

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

Estimates represent a range of possibilities

 

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?

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

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.

It is always a significant challenge to chase such moving targets – but isn’t life all about such non-trivial pursuits? In nineties, a popular slogan was ‘quality is a moving target’ meaning the bar of quality keeps going higher every time. Similarly, whether we talk about performance of individuals (what is good this year might not be good enough next year!) or performance of companies (a company might be growing year-on-year but if it grows slower than the competition or the market growth, that still isn’t good enough), similar sentiments are at play. This even applies to product development – if your product development strategy is basically playing the catch-up game with competitors, you are probably only benchmarking against the ‘present’ and making projections for your ‘future’ but without a meaningful clue on what those competitors have in mind for their ‘future’?

And we see the similar challenges in projects – especially when the project is running late, or having major quality problems, falling behind on staffing targets, having serious attrition problems, major changes in scope, late design changes, late integration breakages, or some such significant deviation from the plan, the project manager is expected to fix the problems. That is natural and quite necessary, but very often the project manager becomes the proverbial dog chasing the proverbial car, which by this time has taken a life form of its own. So, the project manager starts working on fighting the problems of the day, and losing critical oversight of what lies ahead – which means even if he as much as half-succeeds in solving today’s problems, some damage gets carried forward and come another day, there are new set of problems waiting for him :). It could sometimes deteriorate into a rat wheel situation – a feeling of déjà vu every single day, or quicksand where whatever one does only seems to sink the project further. How can we eliminate, or at least minimise such curve of pursuit in project?

Here are three simple steps that I have learnt over the years – they can help you plan better to avoid curve of pursuit, or avoid the impact should such a problem still occur: 

1. Do scenario planning for major potential disasters

Any well-planning project can easily survive one major project disaster, or reasonably manage two major project disasters, but perhaps can’t survive two or more project disasters happening simultaneously. While risk management prepares one to address ‘known unknowns’ and having a risk buffer might even address ‘unknown unknowns’ to a large extent, not too much effort is spent in planning and analyzing scenarios – doing a ‘what-if’ analysis in event of major contingencies. For example, we are in 45th day of Mexico oil spill as I write this post, and we still have no clue how to fix the problem, let alone think of the day after scenario! Even if we are able to somehow magically bpug the oil well, we have no contingency plan to clean up the oceans, provide the so-important succor to threatened marine life in the affected region. So many infrastructure projects end up creating environmental aftermess that is never part of any plan.

2. Identify sub-team to handle project fires

The worst thing a project manager can in a fire is to get personally involved in firefighting until the complete fire is extinguished! While this could erode a team’s confidence in solving the problems, it could also lead to ‘task saturation’ and lead to other fires, or even bigger disasters. I remember attending a great training by Afterburner where they talked about a real-life example of how task saturation brought down a jetliner in the US in 80s because the pilots were fidgeting with the ‘red bulb’ and got so engrossed in troubleshooting it that they forgot the plane was on a descent! No one survived that plane crash. The NTSB video recreation of this event was chilling, and perhaps if one of the two pilots worked on the light bulb problem while the other one kept the plane on course, a grave human tragedy could have been averted.

The key is to identify the best people to fix the problem and empower them while maintaining complete visibility into the rescue efforts. These efforts can’t be on the mainline at the cost of normal project plan, and hence it is extremely important that the project manager doesn’t immerse himself in the problem.

3. Anticipate and plan for tomorrow’s problems

A fire today needs immediate firefighting action, but no firefighting ever led to restoration of original status before the disaster struck! At best, it might just about prevent further spread of fire to neighboring properties. Similarly in a project, a fire today could bring with it unforeseen problems in future. When a firefighting team is facing the extreme heat trying to douse the killer flames, they can’t think of the cost of reconstruction efforts. It is a good idea to initiate parallel efforts to keep an eye on how the fire is affecting the project, notwithstanding progress of firefighting efforts. And for all right reasons, the firefighting team or even the project manage is not the best choice for it. Have another set of team members to start thinking of Plan Bs and Plan Cs (that were created in point #1 earlier) and let the project manager, once again, keep a close eye on this scenario planning exercises.

I can’t claim that I been successful in completely eliminating the curve of pursuit, nor I have seen many people who can do it well. However, there is merit in realizing how such small acts of short-sightedness can completely kill the project, or simply carry it from one fire to the other. Commensurate to a project’s criticality, adequate efforts must be planned accordingly.

How do you avoid the curve of pursuit in your projects?

The Axe Defect!

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:

The effect achieved when a large group of ignorant and insecure pubescent boys attempt to cover up their smell with excessive quantities of Axe while at the same time forgetting to bathe regularly. The resulting smell is a combination of that of severe B.O. and that of a severe chemical spill.

Snake oil adDesired dramatic effects of the commercial aside, there is clearly an attempt to sex-ify things here a bit, and we can certainly remove the innuendos here by using milder terms like “sugercoating” or even the biz jargon “goldplating”, but since this commercial is all about pleasing the Almighty Eros, I might as use a more relevant term here :). Not only do we see many a pitiable morons falling for such outrageous performance promises, this even led to a hilarious piece in Faking News, and saw many more gullible again falling for that story too! And judging by the increasing number of these ads, I think they are working like a charm! So, that brings us to the uber-important question: why are people so desperate about their rock-bottom social esteem that they are willing to try anything to uplift it, or they genuinely believe that is their only way to salvation, regaining their lost mojo, their passport to social nirvana! This promise of instantly curing us of all our imperfections is not only timeless, it is also a thriving business! And sadly, it extends into all realms of life, including project management. I call this as the Axe Defect!

Projects are complex social structures that have a life (ok, some actually are larger than life itself, and some also have an afterlife!). There is a constant struggle between the enabling forces and the constraining forces. Enabling forces includes proper scoping and change control methods, effective estimation methods, scheduling and planning, adequate management oversight and control over the execution, and so on. Similarly, constraining forces include unmanaged uncertainties, unresolved issues, unaddressed dependencies, unmitigated (and quite often unidentified) risks, “unknown unknowns” and so on. In a way, they are like the yin-yang of a project. They both always co-exist, and are interdependent on each other – constraining forces are not really negative in nature, rather they help uncover potential issues that could jeopardize the project. A timely action planning helps strengthen the enabling forces. A balanced or a well-run project is able to systemically address and eliminate most, if not all, constraining forces not just in the beginning of a project, but throughout the lifecycle of a project. That doesn’t mean a well-run project doesn’t have such constraining forces – it just means there is a process in place to systematically collect, analyze, prioritize and address them.

A project manager’s job typically involves balancing the yin and the yang of a project. However, not everyone is equally proficient in this balancing act. Project managers come in all shapes, sizes and shades. In the initial few years, when they are still quite wet behind the years, there is a strong tendency to overdo things (i.e., apply all the theory to the first problem they come across :)). They try extremely hard, often pushing themselves and the team up the roof and are not always very successful. Their intent is not bad, just that their methods are not very refined. Just think of it this way why newbie golfers are not allowed to as much as even wander on the greens and pretty much confined to the driving range until they have learnt the skills to tee off without digging up a pound of mud! Unfortunately, there are no driving ranges for rookie project managers, and the real-life projects become their lab! Nothing wrong about it, except that real-life presents more than fair share of challenges, failures and disappointments. So, when the dirt eventually hits the roof, all hell breaks loose. In the face of high expectations and mounting pressure to deliver, there is a tendency to fall prey to the Axe Defect and gloss over the facts. Sometimes that happens by selectively using metrics to project a healthy image of the project, sometimes it involves using the newest “silver bullet” in the hope that it will cure the project of all maladies. Irrespective, the Axe Defect just makes it worse than what is already is. If people buy the new story, it might only end up deferring the catastrophe for now, but make it more disastrous and costly when it eventually strikes back. If people don’t buy the story, the project manager might further lose his credibility (first incompetence and now attempt to mislead!). Still, it surprises me that project managers, even the experienced variety, so often fall prey and instead of focusing on holistic treatment of the troubled project, go for short cuts that promise to give an instant facelift, but in reality, only sink the project further.

Real experts don't make outrageous claims!Over the last few decades, we have seen dozens of travelling salesmen (read “consultants”) offering all kinds of snake oil (read “methodologies”). The product labels change (and sometimes, they don’t even change that!), but they pretty much recycle the old commonsense and into their jargon. They trade in the Axe Defect, targeting the new and the gullible by promising 10x improvements in half the time. They are the second-biggest enemy of your project’s success. And you who believes in the purported supernatural powers of the Axe Defect is the number one enemy!

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.

Intentional

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 🙂 ?