Category Archives: Project Management

Notes from 4th International PMO Symposium

I had the wonderful opportunity to attend recently concluded 4th International PMO Symposium at the beautiful Loews Royal Pacific Resort in Orlando, Florida from 6th to 9th Nov 2011. I was invited there as a speaker, and more on that in a little while, but let me share what I learnt there.

PMO Symposium is organized annually by the PMI PMO COP and is the largest and surely the best such event globally. This year saw over 435+ attendees – double from the last year! Though the participants were predominantly from the US, there were folks who flew down from Switzerland, Finland, Mexico and Saudi Arabia just to listen to various experts and practitioners talk about the thoughts, trends and advances in PMO profession. The largest participation still is perhaps from the conventional industries – utilities, nuclear power plants, construction, government regulators, confectioners and then the good old IT departments in many such industries.

This year’s theme was aligning execution to strategy and going by the issues addressed and the participant interest; it seems that is the hottest topic in most organizations globally.

Pre-conference Workshops There were four pre-conference workshops on Day 0, which happened to be a Sunday. While there were far more interesting Universal Studios attractions and thrill rides tempting and teasing us from a very close distance, I chose to use my Sunday afternoon productively and signed-up for “Essential Considerations for PMO Design and Development” by Terry Doerscher and Mark Price Perry, Founder BOT International. Both are industry-recognized experts and speakers on strategic planning, PMO and portfolio management. All four workshops were overbooked, and at $89 pricing apiece, it was a great way to learn of new ideas and trends from the practitioners and experts alike. Terry and Mark reminded us that PMO is a service organization that serves unique needs of organization through servant leadership. As per them, the core PMO functions are:

  • Gather and distribute information
  • Manage Demand
  • Reporting and Analytics
  • Coordination and collaboration
  • Issues and Opportunities
  • Capacity Management
  • Process and Tools
  • Specialized expertise and reporting

The prerequisites for PMO, in their words, are:

  • Significant chronic opportunity for improvement
  • Common to multiple areas of organization
  • Unaddressable by current structure
  • Expected ROI outweigh estimate costs

I think this is a very interesting articulation of why, when or where do we need a PMO. Having seen many instances where executives or other stakeholders struggle to figure out why exactly they need a PMO, it could serve as a simple and smart way to check if a PMO could help them. Significant chronic opportunity means we don’t simply jump with a PMO solution to every problem that comes our way. Also, there could be very specific problems that are perhaps best addressed by other conventional means than having a PMO in place. And finally, the current means must have been tried and exhausted before we turn to a PMO as a panacea (which it surely isn’t :)). The Cost-benefit analysis is simply good business decision-making at work. If any of these are missing, we might perhaps be solving the problem sub-optimally. That is not to say the problem can’t be solved by PMO, but that the PMOs would typically create maximum value when all these ‘prerequisites’ are present.

And finally, the PMOs drive values by:

  • driving consistency and alignment
  • create economies of scale
  • mechanism to provide new service or capabilities

A key thing here is that PMOs of the past were the dreaded and shunned lot because they drove consistency and alignment via ‘process terror’ (not Terry or Mark’s term, but rather my own take at it), but today’s PMOs are really all about facilitation and collaboration. Instead of the conventional ‘push’ approach that hardly works anymore (if at all it ever worked!), the PMOs today are expected to ‘pull’ the organization together and create an alignment.

Overall, it was a good workshop where we strangers got working together on each table and got to know each other as we identified and discussed PMO functional roles and responsibilities, structure and reporting, operating assumptions critical success factors and PMO development and operation in our respective organizations and learnt a great deal in that process. I would always recommend signing-up for such pre-conference workshops irrespective of your experience level – there is always something new we can learn in such sessions J, and it is such a wonderful networking opportunity, especially if you traveling out of town to the conference venue.

Keynotes I am a big fan of keynotes because they allow prominent thought leaders in the subject space to come forward and share insights and also create some controversies. To me, a keynote is not worth it if all the speaker does is confirm the conventional thinking. It should bring new ideas to the audience and dare to raise pertinent issues that set the tone for the conference and beyond.

There were two wonderful keynotes. Iain Fraser, an internationally recognized thought leader and a PMI Fellow, talked about governance and Jim Furfari, and ex-airforce pilot and instructor regaled the jam-packed Pacifica Ballroom in his unique way. Iain shared the mantra for good governance in his keynote “Governance: What does it really mean for a P3M Environment?” as – Future Focus, Identify Issues and Communicate, Compliance and Risks, KPI Monitoring, and Skills and Succession. He also shared some findings from the EIU Survey of 600+ C-level execs where the most important skills at individual level was identified to be ‘Execution: the ability to get stuff done’ and the most important capability for organizations is to find leaders to implement change. 72% of the respondents stated their organizational performance suffered due to lack of skills. Now, that’s lot of food for some serious thought! Finally, to sum it all, he elucidated the key attributes of successful governance, and two of them that resonated extremely well for me were – align horizontally and vertically, and use balanced scorecard approach to align policy, people, process and performance to create roadmap to excellence. This was music to my ears as my recent work has been on these lines and I have come to believe that organizations that can scale-up and sustain their success can only do if they are able to create and maintain such alignment and lockstep processes and people to create blueprint for excellence. Even my talk at the PMO conference had this alignment as one of the key themes and a critical success factor – it was a great validation of the approach from an expert.

Jim is an ex-airforce-pilot who used a lot of humor in his talk “Finance is Not an Option! The PMO Role in Enterprise Strategy” to talk about what maturity (rather, the lack of it) can do. He claims to have a unique expertise on both – building and bombing bridges! If you don’t believe in ‘maturity’ of your project managers, all you had to do was look at five video clips of airplane landings that he showed with progressive competency to handle higher complexities and constraints. If you don’t want to be piloted by a lower maturity pilot, why should expect your customer to accept his project being managed by a lower maturity manager? In his views, PMOs should be seen as ‘tough and competent’ – tough when the situation demands them take-over the situation and lead from the front.

Presentations There were 29 speakers from Australia, Greece, India, New Zealand, South Korea, Switzerland and the US. The presentations were top-notch and represented the growing importance of PMO in today’s business, especially concerning alignment of strategy to execution. It was pity that one could only choose one presentation from the three simultaneous ones, but the program guide and the symposium CD circulated at the registration provided enough information about the presenter and synopsis about the talk.

After every presentation, there was a generous 15-minute transition time for the next speaker to set their session. This gave ample opportunity to audience to network among each other and also catch up with the speakers.

My presentation was around my current work on business excellence where we are looking at creating a holistic program and not just focus on hard metrics. We have identified four pillars – culture, execution, innovation and operations as the key drivers of organizational excellence, and creating the lockstep is the key to achieving holistic results. The organization goals are broken down into horizontal and vertical goals which are then executed and tracked in quarterly reviews using a homegrown scorecard that allow us to track holistic progress for the organization. You can view my presentation “Orchestrating Excellence – The Yahoo! India way” and also the paper “Strategic Alignment of Horizontal and Vertical PMO Goals” that was earlier selected at the PMI National Conference, Bangalore, 2011. The paper talks about the approach taken in more details while the presentation is a high-level introduction to the framework.

Networking and Socials Microsoft hosted the day one social at the beautiful Hard Rock café. We pretty much had the entire care at our disposal and provided great opportunity to mingle with like-minded PMO professionals from all over the world over cocktails, fun games and Xbox. I met some very folks who are doing business with India and some of the very interesting learning was that almost everyone had similar situation – I have a team in India and these guys never open up. They remain quiet in meetings and I can never get them to participate enough in proceedings of the team. How do I change this situation? Not meaning to sound rhetoric, I did offer my 2 cents, but it left me thinking – on one hand where we are talking about raising the game for PMOs to get a seat at the table, most of them are also struggling to get their India teams to get onboard. Are we, the India teams, going to be the bottleneck? I hope not, but I also realize that I haven’t seen much change in this situation in last twenty years. If only we had a magic formula!

Vendors Vendor participation was simply fabulous. Right from Microsoft, Oracle, Planview, Eclipse, BOT International, to IIL, George Washington Universtity and even the PMI Bookstore, they were all there. Most of them were competing in the PPM tools and I thought Planview was the
only one where I saw the good old familiar “product funnel”. However, if you were shopping for the latest and greatest PPM tool in town, that the place to be. It indeed was an excellent forum to compare and contrast vendors and tools.

The highlight of vendor booths was the to-die-for sweepstakes! With iPads, Kindles and Laptops up for grabs, it sure made it even more worthwhile to go over to booths and check their offering out. I waited with bated breath to hear my name among winners, as were most of us, but alas, perhaps some other time :).

Conference Organization and Logistics If ever there was a conference going to be organized by the PMO professionals, it was only expected that it lived up to the highest expectations of meticulous planning and flawless execution that the PMO profession has come to be  synonymous of. And it surely exceeded expectations on every count! From the initial call for presentations to the selection of venue, scheduling of events, organizing logistics, not only everything was on time, it was also done absolutely error-free.

The venue choice was superb and the hotel service was flawless. The lapel mikes and on-screen projectors simply worked without any support staff! The break-out areas were large and allowed good resting places for those tired legs. I especially liked the small device that converts Blackberrys into handheld scanners. Whether you went to a presentation or to a vendor booth, your name card was scanned and lo and behold, all your contact information was instantly loaded in their back-end system. Vendors used it for their own visitor data, and of course, the sweepstakes. The conference organizers used it to record the attendance for PDUs! Their promise is that the PDUs will be uploaded for all participants! How about that?

Lessons Learnt This was a unique session that I never thought could be such a powerful way to end such a wonderful conference. We were down to the last hour on the last day and with less than 80-odd participants left who got together in this last session that stood between them and their flights home or Universal Studies park tickets, I for sure didn’t know what to expect. At best, a boring session and at worst, people walking out of the session!

Rommy, Frederic and Craig got us together and asked us to make groups of 5-6 folks sitting together and share what we felt came across as the two most compelling takeaways and then whittle it down to 4-5 per group. I think it was only apt to do some introspection, both individually and as a group, to condense so much of knowledge download over the past four days into the most important learnings. Then we went round the room and each group shared their views, and here are the themes and ideas that came up loud and clear:

  • Strategic role of PMO
  • Focus on organizational PMO – not just methods and consistency but benefits realization
  • Show value of PMO to organization
  • PMO is really to solve a problem, not to find a problem
  • Strategic attractiveness is not just about money
  • Change driver within the organization
  • Importance of communication – eve level and with stakeholders
  • Focus on strategic alignment
  • Involve more than just the leadership team
  • Focus on value provided to business
  • Org structure: where should the PMO report – it is important to adapt to reporting level
  • If you can drive your strategy through the organization, you make yourself valuable
  • Integrating agile in the org
  • Ingantibles can be part of the expectations
  • Project management is not a certification but a profession
  • Need to move out of the weeds and become more strategic and ask org how they can provide more value
  • Don’t just track the deliverable but the value of deliverables
  • Move forward from measuring project metrics to business value
  • Voice of the customer
  • Raising the level of PMO to influence the org

Hopefully this gives you a flavor of what was discussed and what people walked away with.

Road Ahead I was fortunate that my presentation was accepted and event organizers extended me the opportunity to come and present. To sweeten the deal, they waived off conference fee, offered complimentary hotel accommodation during the conference and even offered to reimburse the airfare to the venue (though my company picked that up as I was traveling for work at the same time)! Could there ever be a better incentive to become a presenter! I am thankful to my employer Yahoo! for allowing me to make my presentation. I got some good takeaways from the conference that I intend to put at work. I also hope reading these notes will inspire you to put up a proposal for next year, and if I could be of any help to you in this regard, I will be happy to oblige. I am surely looking forward to making another good proposal for the next year’s conference…

More details You can get more details at or Frederic also wrote about it in a blog post.

What are the program management competencies?

Program managers are the glue that bring your best people and teams together to collaborate like never before. They crack the hardest problems by cutting through the red tape in your organization and aligning them to the single goal. Clearly, a lot depends on having the right program manager in place. How do you hire or groom good program managers? Or, in a large organization, how do you ensure that your program managers have similar minimum competencies across the organizations? You might or might not have a single program management framework, but it might still be a good idea to have some model that allows you to baseline your program management competencies.

Levin-Ward Program Management Competency Model

Levin-Ward Program Management Competency Model

Last week, I sat through an evening session by J Leroy Ward, who has recently co-authored a book on “Program Management Complexity – A Competency Model” with Ginger Levin. He talked about the Levin-Ward Program Management Competency model that they have created. They have identified two categories of competencies – six performance competencies related to the functional ones and another eight personal competencies relating to the soft-skills. While the specific competencies are not really new, and the performance competencies are more like the specific ‘stages’ in a program lifecycle – Defining, Initiating, Planning, Executing, Monitoring and Controlling and finally Closing, they have put in efforts to specify what exactly contributes those competencies. The personal competencies relating to soft-skills are Leading, Building Relationships, Negotiating, Thinking Critically, Facilitating, Mentoring, Embracing Change and finally Communicating. I would recommend it for any newbie to program management – it could serve as a good roadmap on what to learn and focus on. The book also gives self-evaluation questionnaires for organizations, program managers and prospective program managers.

During the Q&A with Leroy, many folks (incidentally, majority were from Indian service companies – which is a very interesting phenomenon because most of them don’t have a company-wide program management function today) asked questions that seemed to indicate that the ‘Indian’ context was missed out. For example, there were specific references to cultural sensitivities, managing globally distributed teams and so on.

I also pitched in with my 2 cents and offered my views on two program management competencies that I consider fundamentally different from project management. I mean all those 8 personal competencies in Levin-Ward model are kind of ‘similar’, or linear extension to what you would expect a project manager to possess – albeit in little lesser proportions. However, these two competencies, at least to me, represent a fundamentally different and additional skills required without which a program manager can’t simply operate. Let’s discuss them:

Lead by Influence

Influence and Authority are extreme ends of a continuum. When there is very high authority, the ‘leader’ need not have any personal credibility – the followers have no option but to simply follow the ‘orders’. Needless to say, this is the old world that is rapidly falling out of favor. The new world order requires leadership to embrace influence to bring about necessary change.

In majority of organizations, more so in today’s matrixed organizations, a program manager has no direct or indirect people responsibility. He has no ‘positional power’ to lead by ‘authority’ anymore. This is a significant change from the classical project manager who typically has solid line reporting of his team under him. Even though the command and control model is long dead and buried (but perhaps still alive and kicking in some old world industries and governments), the project manager still wields ‘reward power’ for he allocates responsibilities, approves resources, writes their appraisals, determines their salary revisions and makes recommendations for their promotions and other career progression avenues. So, while on a day-to-day basis, we can argue that teams are ‘flat’, there is always this invisible hierarchy that is present at least in our minds. Contrast to this, a program manager is devoid of all such ‘reward powers’. He might have a bigger responsibility mandate than the component project managers, but he still has considerably less ‘power’, both positive and negative, to motivate (or coerce) team members to achieve the program objectives. In today’s complex problems, it takes more than a monolith silo to deliver! There might be individuals and teams spread across the organization, or even outside, all of whom must collaborate in real-time to deliver a solution.  In such scenario, the program manager must rely on his ability to lead by influencing the component teams. What does it mean?

Leading by influence means establishing personal credibility and accountability and earn trust among rest of the program team. It doesn’t mean doing everything by himself, but by facilitating collaboration of work within and across the team. It doesn’t mean dropping names to coerce the teams to somehow reluctantly agree on some artificial top-down resource and schedule constraints. It means listening to issues from all component projects and adjusting plans to achieve the program goals. It means tearing down the silos by establishing trust and transparency and helping people succeed with each other – not at the cost of each other. This article “The Language of Leadership” by Nancy MacKay nicely identifies ten leading by influence skills. I think that makes a great list.

Tony Wagner has identified it to be among seven survival skills (and I would strongly recommend checking out other six skills as well). Leaders like Mahatma Gandhi and Mother Teresa led by influence. It’s high time we learnt this fine art.

Manage at Interfaces

Project management requires fortifying a project to maximize its output. In a way, it is like a small tribe that must protect its interest over everything else. However, a program is like a much larger state that must not just look after interest of its multiple tribes but ensure that that the sum total of it all is maximized. Its primary interest is in the ‘outcomes’ that lead to creation brand-new or significant and sustainable enhancement in existing capabilities of an organization or a society. For example, Bangalore Metro is a program, whereas its components like individual metro stations, or the tracks, etc. are its component projects. While a component project manager is interested in ensuring that he hits the deadline and quality bar for his project, the overall program manager must work with all individual project managers to create a program plan that identified and manages interdependencies and allow the most optimum outcomes to be created at program level. To that end, the program manager doesn’t have micro-level control over what goes on inside each project. He must resist the temptation to micro-manage each of the component project les he loses the oversight of overall program (and also, quite possibly, upset the component project managers by such intrusion). He must manage at interfaces.

What does that mean? First of all, this is not a recognized term (a search for this phrase led me to just two pages on the net, both of which were in a totally different context). Managing at interfaces means establishing a two-way trust with the project managers that allows everyone a space to perform while focusing on the higher-order ‘outcomes’ of the program. It means involving all key participants and collaborators, identifying establishing interdependencies and establishing collaboration mechanisms that allow the program to flow smoothly without anyone getting overinvolved in other component’s inner details. The aspect of managing at interfaces is not just limited to program manager alone – it is also required that other component project managers also establish similar levels of trust among each other. Why is all this important? Well, there is a segregation of responsibility. Unless you are working in a trivial program (in which case you might argue why do you need such elaborate management structure overhead?), there is every need to establish structures and mechanisms that would allow smooth flow of outputs from one component project to another, and if we allow them to get involved in white-box details of each other, we will not only lost the focus very soon, we also run the risk of back-seat driving – that of louder voice getting what it wants. We run the risk of breaking down common agreement and running the program on side-deals instead. Needless to say, this would be contrary to achieving common goals of a program.

Managing at interfaces symbolizes a sociological setup where teams trust each other and the program manager. It allows decentralization and appropriate division of responsibilities by eliminating any overhead that could breed mistrust. Obviously, this is an end-state that is achieved by upfront investment by program manager (and the organization as a whole).

So, there you have it. Do you recognize that program management is not just an overgrown project manager? Does your organization realize that more of whatever the project managers have been doing in past just won’t qualify and train them for program manager roles? Do you recognize that apart from performance competencies, your program managers need a completely different set of skills that allow them succeed? What are the program management competencies?

Opposite of risk is not safe!

Risk-seeking behavior has been stereotyped and templated over the years. We routinely associate rash and optimistic planning, aggressive schedules, seeking new gold, banking on unproven technology, and building for newer markets as some of the risk-taking behaviors. Unfortunately, we automatically assume that things that are non-risky are safe. But are they?

Risk is measured as a potential (and most often negative) impact on a project’s deadlines, cost or quality of its outcome due to uncertainty around a future event. To that end, we think buying a new house with a 20-year loan is a risk because we can’t predict and plan for what all could happen in next 20 years. Similarly, planning a multi-year project is a risk because so much can happen that impacts a project in those several years – technology gets obsolete, requirements change, key stakeholders move out and the new ones have a different expectation from the product, users figure out better ways to organize their needs, etc.

All this makes sense. However, somewhere our thinking has gone wrong from here. The opposite is risk is not safe – in fact, it is also risk. Let’s take some examples:

Leaving a job or starting out on your own might be risky – you might land in similar or even worse situations, or take forever to prove yourself in a new company, new culture, new people, new way of working, or your startup might just crashland after a few months. However, staying back in the job might also be risky – you might not learn and grow, or could get laid-off, or your company might go out of business!

Using a new unproven technology could be risky – you might be addressing a lot of first-time issues, or deal with more than a fair share of unknowns and uncertainties. However, sticking on to old technology could mean lesser opportunities for innovation, limitations on scalability and performance and eventually being the long-tail customer for some stone-age technology with no customer support, no upgrades and unavailable parts.

Creating a new drug in pharmaceutical sector is a typical risk of $600-800m over a period of multiple years. After all that investment, which essentially is a ‘sunk cost’, there is every risk of just writing-off entire hard work, effort and money, and start afresh. But, by choosing to not undertake that route, you might miss the opportunity to create a worldwide patent to produce, own and market that drug, not to mention, the lost opportunity to serve the mankind better.

If you promote people from within, you run the risk of making an old guard lead the change brigade – chances are that the old guard might not personally prefer that change, or is very comfortable with it. However, if you bring an outsider, he might lack the initial political or social capital to get everyone together on a page and lead such ambitious change.

When I read message boards on entrepreneurship, I find an almost universal contempt for people who are not entrepreneurs. The general thought is that this set of folks is too risk-averse. And then I think about folks who are investing their blood, sweat and tears into their jobs and pushing against organizational inertia to bring out changes that are just as challenging and sexy as what entrepreneurs outside those organizations are pursuing. Who says it is easy to pursue such innovative ideas in a large organization?

In fact, Peltzman Effect is a great way to explain how derisking something in fact creates a completely unintended effect by encouraging people to indulge in a behavior that again raises the risk, thus effectively nullifying the very intent to reduce risk in the first place.

So, I have come to believe that our thought process around what constitutes risk and what is considered as safe is essentially flawed. There is an inherent risk in every endeavor – and opposite of that is not safe. Opposite of that is just another type, shape and form of risk, and requires just as much, if not more, systematic analysis.

Why are dry runs are so important?

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

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

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

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

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

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

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

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

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

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

Do you know the safety margins and wastage in your project?

How do you estimate and plan when your project has too many unknowns and uncertainties? A common shortcut and a wishful thinking is to ‘pad-up’ the estimates with some ‘magic number’ based on past experiences, like +30% effort, or +10% costs, etc. These numbers are then very carefully added at each activity and its sub-activity level. We thus end up inflating the final estimates completely beyond shape. However, many of such projects still end up with delays and cost overruns. Why?

It is human nature to seek comfort in safety. Whenever and wherever possible, we add buffers to trade risk with increased duration or effort for the task. Sometimes, this might be the right way (or, even the only way), but many a times we do it without analyzing if this is the best approach. Consider this nice little story:

It was autumn, and the Red Indians asked their New Chief if the winter was going to be cold or mild. Since he was a Red Indian chief in a modern society, he couldn’t tell what the weather was going to be.

Nevertheless, to be on the safe side, he replied to his Tribe that the winter was indeed going to be cold and that the members of the village should collect wood to be prepared.

But also being a practical leader, after several days he got an idea.  He went to the phone booth, called the National Weather Service and asked ‘Is the coming winter going to be cold?’

‘It looks like this winter is going to be quite cold indeed,’ the weatherman responded.

So the Chief went back to his people and told them to collect even more wood. A week later, he called the National Weather Service again. ‘Is it going to be a very cold winter?’

‘Yes,’ the man at National Weather Service again replied, ‘It’s definitely going to be a very cold winter.’

The Chief again went back to his people and ordered them to collect every scrap of wood they could find.

Two weeks later, he called the National Weather Service again.

‘Are you absolutely sure that the winter is going to be very cold?’

‘Absolutely,’ The man replied. ‘It’s going to be one of the coldest winters ever.’

‘How can you be so sure?’ the Chief asked.

The weatherman replied, ‘The Red Indians are collecting wood like crazy.’

Do you plan your project the same way? While an Indian Chief might have all the resources available to collect every scrap of wood to derisk the winter, you might not have such luxury! And even if you do have such luxury – guess what, we actually end up eating the safety margins. Hofstadter’s Law is a colloquial oversimplification of this reality – “It always takes longer than you expect, even when you take into account Hofstadter’s Law”.

This eponymous law seems to hold itself extremely well in software development, which has also been compared to ‘wicked problem’ thus making it extremely difficult to solve. Perhaps, if you include the aspect of time running out and the fact that those seeking to solve it are the ones also causing it, then we can perhaps call it as the ‘super wicked problem’!

So, it is only natural that people add a safety buffer in every task in the hope that the buffer will address all ‘force majeure’ events. However, it could be argued that the statistical probability of all events needing to eat up that safety buffer on a single project is near zero. Surely, some of those events might need such buffer, but certainly not all the activities.

Goldratt discussed this problem so eloquently in Critical Chain that people add-up ‘safety’ to ensure very high chances of completing it. From taking the 50% probability to complete a task to over 90% probability, we probably end up adding 200%-300% schedule to it. However, for primarily three key reasons discussed below, we often still end up not hitting the deadlines:

  1. Student syndrome: it is natural to negotiate for more time to do something – just so that you have enough contingency buffers to deal with any delays, reworks or simply underestimation of the task in the first place (“planning fallacy“); but once you have that extra buffer, we tend to take it easy for the initial part, and then sprint to somehow complete it just when the deadline start looming over. I believe this happened at Harvard. Students were typically given one week to complete end-term assignments, and pretty much all students would stay awake most nights and somehow complete on time. The professors felt this was too much for students, and decided to make their life easier by giving them two weeks for the assignments. Guess what – the students would party in the first week, and then again sit the whole night in the second week to somehow complete the tasks! Most of us don’t take up the opportunity to ‘early start’ a task until it is inevitable – by which time, it has already eaten up the buffers that were created for precisely those reasons – to handle any uncertainties, delays or rework.
  2. Multitasking: multitasking is the killer of productivity. If someone is working on several activities at a time and must constantly move back and forth between them, there is a context-switch time that slows down immediately starting the new task. Similarly, even to ‘suspend’ a currently running task, we must ‘save’ its current state so that we can pick it up easily the next time. The worst part is that none of the tasks get completed earlier then if they were take up sequentially – even with assuming zero downtime during the task switch. So, multitasking creates a false impression that progress is being made on all tasks, but doesn’t lead to any improvement in lead time to complete any of the tasks.
  3. Delays accumulate while advances do not: what happens when you complete a task early? The normal tendency is not to inform your manager – lest you be given lesser time to complete similar tasks in future! Other reasons could simply be do more testing just to be just that before-time completion was not a fluke. Whatever the reason, the end result is that and time saved, or advances, don’t accumulate – we tend to use to completely, but any delays in the task travel downstream. Now imagine if you had buffers in a task that got completed early. Theory says it that you check it in early and start work on the next task thus leading to gaining crucial time in a project. However, in reality, human behavior trumps such wishful thinking, and hardly ever people ‘deposit’ the advances back into project’s buffers. However, the delays, one day at a time, continue to accumulate and suddenly you realize that you are running a month late!

Goldratt presented compelling logic to highlight this problem, and presented a deceptively simple solution – take away individual buffers and manage with a much smaller centralized buffer. Obviously, this is easier said than done – for, how do you change people behavior to forego their safety margins? If people are going to be made accountable for deadlines, it just makes it little tougher for everyone involved. However, each meaningful journey must begin with a small step.

To begin with, do you know the safety margins and wastage in your project?

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 does manager’s proximity to team affects team dynamics and decision-making?

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

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

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

On the other extreme end are managers who think it will dilute their no-nonsense macho image to deliver results if they start mingling with the team. They maintain a two-mile distance from the team, and as a result, are not generally very popular, sometimes feared and often ignored from the social circuit of the team. They start moving with the ‘upper crust’. Even if such behavior might help those managers in maintaining a healthy professional-personal balance, sometimes they might lose their ability to influence their teams and motivate them to do that extra bit just to make sure the job is not just done, but is done well. At times, they might not even understand the team’s motivation levels, or their collective decision-making process, or their unappointed power centres, etc. I once had an expat manager who had never written code in his life and was clearly unfit to be a software manager. He regularly ‘bought’ respect and support by ‘delegating’ most of his work to the team. Actually, abdicating his responsibilities was more like it. While he sat in (literally) a corner cabin, the team toiled in a meeting room next door, which was ok – the team members got a lot of additional responsibilities in the bargain. What became a problem was when we ran into some some design bugs during system testing – he came and started getting angry at the team. What he clearly didn’t realize that by ‘delegating’ his responsibilities, he didn’t stop owning the consequences of the decisions the team was making without him! Within next few months, most of us left him and that company. Then I had another boss who was promoted from within as a group manager. While he was some sort of a poster-boy success as a first-line manager, he was all too-new as a second-line manager and without much mentoring on how to effectively lead first-line managers, he started behaving in an autocratic manner. When he wanted us for a quick conversation, he would simply shout names of us lesser mortals from inside his cabin! Goes without saying that none of those managers exist in my LinkedIn network :).

What’s a better approach – sitting with the troops in the trenches and drinking beer till neighbors call the cops, or working from that corner office (or whatever that is called nowadays) and keep a safe distance from the ‘guys’? I guess there is no single universal answer – they come in all hues. Excess on either sides seems like something to be avoided. Also, this doesn’t seem to be a unique behavior associated with someone promoted internally or someone brought-in from outside the company. Newcomers also tend to be equally tentative in their first few weeks – they are not sure of their property rights, the holy cows in the organization, the informal power centrers, and so on. So, while they test new waters, there might be tendency to soft-pedal issues in the beginning. If they act too swiftly and aggressively, they might already make ‘enemies’. If they start weeding out the garden too early, they might not have enough ‘context’ and hence might lack the finesse to do the job well. On the other hand, if they start befriending people and build the right network, they need to invest time – something that they might not have. 

Striking the right balance

What are some of the best practices and strategies you have seen around? Are there some ideas with timeless appeal and culture-agnostic applicability? I am sure we can sensitize new managers on the nature of the beast, but one must read the terrain and decide what is the right approach at a given point in time.

Do you care about positive risks?

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

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

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

Surely, these are simple examples, but demonstrate there are always positive risks in pretty much any project. However, we generally ignore them, and hence are not able to capitalize on them (we typically end up using the ‘accept’ strategy without even recognizing there might be other better ways of maximizing those risks or its returns). In addition to identifying positive risks, these four risk response strategies are identified to maximize the risk or impact of such positive risks:

  1. Exploit – this strategy aims to eliminate the uncertainty associated with a particular upside risk by ensuring the opportunity definitely happens. Since this is a positive risk, the outcome is likely to be positive. However, there is an uncertainty to it, so if there is a way to eliminiate such uncertainty and make it a certainty, it ensures that you reap the benefits of such a positive risk. The idea is to virtually guarantee that a given risk becomes a certainty! Let’s consider some examples:
    1. Suppose you are developing a prototype. If your customer likes it, your order book could be full for next few years! You have been diligent so far, and now have the prototype ready a week before delivery date. You are 70% sure that the customer will like your prototype, but instead of deliverying early, you decide to subject the prototype to even more stringent testing and analysis. Ideally, you will want to raise such probability to 100%, but that might not always happen. However, you put all efforts to make such event a certainty.
    2. Another example – you have to make product release next weekend – if that happens, your customer might be able to roll out new services to its customers. You pull out some of the best technical folks on other projects and put them on this task to ensure that it happens.
    3. Your biggest customer might be willing to give you 2x, or even 3x business if only you stopped working for his biggest competitor. You take the call to stop working with the competitor and make that event happen.
  2. Share – Sharing a positive risk involves allocating some or all of the ownership of the opportunity to a third party who is best able to capture the opportunity for the benefit of a project.  Here, the idea is to involves more players who also becomes stakeholders so that collectively raise the winnings. This strategy might be handy for some types of risks that might have have a positive uncertainty, but chances are that by yourself, you might by constrained in how much you can win. By involving other complementary players, you not only push the envelope, you get others to the game, make the game bigger and help everyone win, thereby also maintaining your own interest.
    1. You are building a cool product that you expect to be a best seller. However, you lack the product design or marketing expertize to fully explout this opportunity. Instead of home-growing those capabilities, you decide to get experts on this project who are fired up with this challenge.
    2. Apple uses this extremely well. By making its iPhone APIs available to larger developer community, it has been able to ensure that there is a dedicated army of developers constantly working to create highly innovate apps. This has resulted in over 100,000 such apps being available on iPhone!
    3. You have developed a new intellectual property that promises to be a revolution. Instead of patenting it, you decide to open-source it to create a major eco-system of other vendors who might get interested to develop tools and apps around that technology thereby pushing the envelope.
  3. Enhance – the idea is to increase the probability or impact of a positive risk. Increasing probability might not make it a certainty, but does improve the chances of the positive event happening. Improving the impact might not be necessarily associated  with an increase in the probability itself, but might lead to a higher yield should the event happen. Of course, there is also an opportunity to do both of them simultaneously!
    1. Let’s assume there is a cloud cover over a drought-hit region and there is a 20% possibility of rain. What do you do? You can utilize scientific methods like cloud-seeding to improve the possibility of rain to, say, 40%. In this example, you can’t increase the impact, but you are able to increase the possibility of that event.
    2. This strategy is used quite well by retailers, especially in apparels industry. Studies have shown that home labels (or we can just call them the unbranded stuff) has a higher chances of being bought when carefully placed alongside branded apparels than standalone. This simple placement trick increases the chances of customers picking up home labels.
    3. Companies and industry trade association hire lobby firms to influence lawmakers and citizens to look at some important regulation more favorably, thereby maximising chances of its adoption and eventual success.
    4. While pushing for a new idea, sometimes you want to socialize it with a key voice in the organization, or perhaps get some industry references that generally extol benefits of that idea, thereby increasing the chances that your idea gets accepted.
    5. This story illutsrates a great example of how one can both increase the probability and the impact simultaneously. I blooged about it in a different context, but you can read the story Are you helping your competitors succeed?
  4. Accept – Accepting the opportunity is being willing to take advantage of it if it comes along, but not actively pursuing it. When I earlier said most of us ignore positive risks, we probably work in a passive mode, and pick up those low-hanging fruits. While this might not be a bad idea, in some cases, you might not want to incur the cost of ensuring that a certain risk does happen. So, this is like a zero-cost effort where if the positive risk happens, you are willing to grab it.
    1. For example, you have just started out your consulting venture and are busy doing the legwork for it, and don’t want to take up an assignment for the coming month lest it interferes with your initial preparations. You hear about a business in distress that needs exactly the kind of consulting that you are offering, but decide not to actively pursue it. However, when they call you up, you are willing to take the call.
    2. A competitor is likely to go out of business and you might benefit when that happens, but you don’t want to be seen as a bad rival trying to accelerate his downfall. So, you decide to take it easy and monitor the situation, but when that happens, you gladly step in.
    3. You want to take homeloan. There is a chance that interest rates will come down in the coming quarter. Instead of waiting for that to happen (or, it might not even happen), you decide to take the loan right now. If the interest rates go down, you benefit.

Identifying and exploiting positive risks doesn’t require any special talent, but it does require a systematic effort to spot such opportunities. While negative risks are typically more dangerous and hence it makes great sense to avoid, transfer or mitigate them, positive risks could make a significant difference to your project’s chances of success. As we see in these examples above, many of these opportunities will fly under your radar if not proactively pursued. A holistic risk management strategy should always consider all types of risks and identify appropriate responses.

Do you care about positive risks?

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?