Posts Tagged ‘Risk’

Programmer to Team Leader:

“We can’t do this proposed project. **CAN NOT**. It will involve a major design change and no one in our team knows the design of this legacy system. And above that, nobody in our company knows the language in which this application has been written. So even if somebody wants to work on it, they can’t. If you ask my personal opinion, the company should never take these type of projects.”

Team Leader to Project Manager:

“This project will involve a design change. Currently, we don’t have any staff that has experience in this type of work. Also, the language is unfamiliar to us, so we will have to arrange for some training if we take this project. In my personal opinion, we are not ready to take on a project of this nature.”

Project Manager to 1st Level Manager:

“This project involves a design change in the system and we don’t have much experience in that area. Also, not many people in our company are
appropriately trained for it. In my personal opinion, we might be able to do the project but we would need more time than usual to complete it.”

1st Level Manager to Senior Level Manager:

“This project involves design re-engineering. We have some people who have worked in this area and others who know the implementation language. So they can train other people. In my personal opinion we should take this project, but with caution.”

Senior Level Manager to CEO:

“This project will demonstrate to the industry our capabilities in remodeling the design of a complete legacy system. We have all the necessary skills and people to execute this project successfully. Some people have already given in house training in this area to other staff members. In my personal opinion, we should not let this project slip by us under any circumstances.”

CEO to Client:

“This is the type of project in which our company specializes. We have executed many projects of the same nature for many large clients. Trust me
when I say that we are the most competent firm in the industry for doing this kind of work. It is my personal opinion that we can execute this project successfully and well within the given time frame.”

An year into the project…


Source: dailytenminutes.com

Read Full Post »

I’ve reblogged here for a reason a post from my other light-reading blog at http://ksriranga.wordpress.com/2014/01/31/how-to-hit-the-bulls-eye-every-time/ for your perusal.

Will catch up with you on the other side.

Begin Post:

How To Hit The Bull’s Eye Every Time?

The myth of 10,000 hours needed to become an ace at anything is busted. Read on to find out how.


One morning a Duke was riding inside the woods together with his men-at-arms and servants when he caught the sight of the usual target of concentric circles painted on a tree trunk and smack inside the center of each was a bolt.

Some distance away, he came up on another tree that too had the target and the arrow in bull’s eye.

He found more trees of the same kind.

“Who is this amazingly skilled bowman?” wondered the Duke. “Fetch him wherever he is. I have to meet him!”

When his retinue looked around they found a young boyish looking man with a bow and bolts. They produced him before the Duke.

“Lad, fear not. Who is the great bowman that had hit the bull’s eye every time? Do you know him?”

The young man shook his head to say he did know who did it.

“Is it your father?”

He shook his head again this time to say it wasn’t him.

“The teacher from whom you’re perhaps training?”

It wasn’t him either.

The Duke persisted with his query.

Finally the young man mumbled it was him that shot the bolts plumb inside the middle of every last one of targets.

The Duke laughed aloud: “I know – you didn’t essentially stroll up to the targets and sledge the shafts into the middle, did you?”

“No, my master. I shot them from 100 paces. I swear it by all that I hold holy.”

“That is really astounding, you’re the best archer I’ve ever seen. I herewith appoint you as a trainer to my archers.”

The young man thanked the Duke profusely.

“I still have a question to ask of you. How did you get to be so good hitting the bull’s eye every time? Did you spend all day practicing? If you’re so good, your teacher must be a wizard. Take us to him, will you?”


“No, No. It is like this. I stand upright, take a careful aim, hold my breath, see it with one eye and shoot the arrow at the tree.”

“Well, that’s what we all do too.”

“And then draw the target circles around where the bolt went into the tree.”

End Post .

Well, jest aside, it is the same thing with some projects. Result is what happens.

Result is not what is committed to the management or to the customer. And usually there are enough good reasons to explain why it happened. Such as extraneous environmental factors like weather or political sensitivity like a civic disturbance. Such as a customer deliberately or otherwise taking advantage of a poorly worded contract to expand the scope or demand services beyond originally envisaged. Etc. Etc.

The project manager is expected to foresee at least some of these risks and plan out mitigation strategies. If it is not done so or if the mitigation strategies are not effective, it is strongly advisable for the project manager to stop the continuing week-after-week agony, step back, rethink and re-plan with customer’s help.

What one finds, instead, is insufficient thinking and action to contain to whatever extent the impact of such uncontrollable developments. These are protrayed as given and the project lives from week to week.

If the factors are absolutely immitigable, then these must be factored into the contract and the original plan. Example: doing field survey in monsoon or severe winter. Though uncommon, I’ve seen projects executed in a start – stop mode these factors permitting. Another interesting example is where a more fundamental change in approach was needed as a solution to insurmountable problems – given the difficulties in freezing requirements with users in advance despite best efforts, the very methodology of developing software has undergone a transformation now using agile methods for success.

Barring those outliers (usually the R & D kind), can project outcomes also be as certain as taxes and death? We may not be there yet, but it certainly helps a long way if project management does not let reasons override results.


Read Full Post »

Here’s a fairly simple little story. Listen carefully.

It’s 4-00 pm and I call you in.

‘Look, there is a Mr. Singh staying in Hotel President. Do you know where it is?’

‘Yes, in Cuffe Parade (in North Mumbai). I’ve seen it.’

‘A proposal has to be reached to him before 6 pm. He has a flight to catch. It’s absolutely important that he gets this proposal before he leaves. You understand?’


‘I can’t trust this job to anyone else. I want you to drop whatever you’re doing and take this envelope to him. And there must be no goof-up of any kind. You get it?’


‘Now quickly tell me what else you want to know and get going. It’s a little tight going from here (Andheri, in South Mumbai). It’s like a project and how do you plan to go about?’

The story ends here.

This is one of the several scenarios I had devised to push the aspiring project manager and assess his responses. Back in those days we did not have PMI certification or any other equivalent to go by!

At this point some of you aspirants wanting to try out this role-play – stop reading further, as the game is given away in what follows.

If you’re done with the role-play, it’s time to look at the ulterior motives of the story.

This scenario, though crafted, is not very unlike real-life situations in projects. It has several questions to be resolved for the candidate even before planning the execution:

– Mr. Singh’s full name – ‘Singh’ is a very common name, to be found even among non-Sikhs. How is he identified on the guest list and visually too?

– How could one reach him on phone directly for coordination? No cell-phones, then.

– How much is the budget for transport?

– Is 6-00 pm absolute and non-negotiable or there is a margin?

– In the event of a delay despite best efforts, what should be done?

– What kind of an acknowledgement is due from Mr. Singh on receipt of the envelope?

– What kind of confirmation is desired during the execution and at the conclusion of the ‘project’?

The answers to these questions fill up important gaps in the definition of the project, the customer and the handshake and also ascertain performance parameters and prevailing constraints, at least the major factors.

Next is the planning process. There are 2 hours available to commute from one end of the city to the other end. In the slot of 4-00 pm to 6-00 pm the traffic on roads in Mumbai could be notorious in spots. Are these environmental risks factored, in addition to the permissible expense budget, to plan the route and the mode of transport?

In the execution process, again questions arise:

– How goes one sense the deadline would not be met staying on the current course? Are there intermediate milestones or check-points?

– If so, what are the switching options available to recover from or mitigate the delay?

– What office support could possibly be drawn upon during the execution process?

The story and the role-play go this far.

While the above is a direct presentation of the issues involved, in the assessment exercise I push the candidate helpfully towards some of the issues that he overlooks.

The scoring of the responses is not very relevant here as the main objective is elucidate on the issues and practices in project management through this story.

It was quite interesting to see how the candidates handled this simple ‘project’. The responses ranged from naïve, funny to some unexpectedly new insights that contributed to subsequent evolution of the story.

One candidate did not know any of the half-a-dozen destinations I pulled out one after another. She was new to Mumbai.

I remember how I had to plug the story after another aspirant steered the story entirely on a different course! Innocently, he asked: Couldn’t he meet up with Mr. Singh and handover the envelope when he reaches the airport, only fifteen minutes away, he asked, instead of trudging all the way to Cuffe Parade?


Credits: openclipart.com (jabernal) for the image.

Read Full Post »

Hitoshi Abe
March 11’2011 – it was the first year anniversary of the disastrous tsunami that devastated Hitoshi Abe’s home-town, Sendai in Japan. The award-winning architect, chairing the Department of Architecture and Urban Planning at the University of California, Los Angeles, sifted the heart-rending scene for valuable learnings on designing for disasters and human behavior brought out under the circumstances, for the benefit of humanity at large.

Here is an interesting extract from a Q & A interview of Hitoshi Abe by Reena Jana for Smart Planet:


SmartPlanet: The devastating events of March 2011 prompted Japanese architects, engineers, and designers — and those around the world — to rethink how to react to damage from earthquakes and tsunamis. In the last year, what have you learned and observed in this area of design?

Hitoshi Abe: I have learned that modern technology has really helped to expand the current environment we live in. For example, the man-made structures on the coastline like the fishing villages and the ports themselves are the cornerstone of numerous industries of the Tohoku region. Without these structures, it would be difficult to sustain those industries. However, I also learned that there are limitations, and we should not be overly confident about these modern systems.

It has become extremely clear that we have to “negotiate” with nature, and we need to set the right boundary between nature and any man-made environments. Furthermore, these boundaries must be more flexible. In other words, we should not try to work against nature, but what we need to do is create a new type of community and urban design that will make the area more disaster resilient. Of course, it’s not efficient to make every structure tsunami-proof because it’s not economically feasible. But what we can do to minimize future damage is to understand these boundaries — there needs to be certain areas where man-made structures should not be built and areas where the structures are more resilient to natural disasters. An investment into these types of structures is crucial. But in order to make this truly work, we need to be creative and figure out where this interesting, flexible boundary is, so when disaster strikes again, these structurally resilient buildings will be safe and the tsunami will have a natural path where it can come through.

SmartPlanet: The photos from “Moving Forward” show everyday citizens acting as rescuers, in essence “designing” solutions for transporting people or coping with devastation after a natural disaster. How have these photos inspired you as a designer?

Hitoshi Abe: What I realized is that most people in this day are extremely dependent on large systems to sustain our daily lives. These large systems include anything from the government, food supply, police, hospitals, etc. When such a large disaster strikes, the entire infrastructure is affected, or worse, it comes to a complete halt. This has happened in the Tohoku area. The large system could not sustain the new environment, and it became very fragmented. The system that had made all our lives more efficient no longer worked.

The TV reports and news have shown that many Japanese people had to wait in very long lines to get gasoline, food, and shelter, but what was so memorable was how they kept their composure and maintained order in a system that has failed them. From this, a new order has been born with new laws that made the people look to each other for help and support — a new sense of order has emerged among the individuals from within, not by a force from outside of them.

This type of informal network naturally emerged in the case of the Tohoku disaster. For example, the large supermarkets could not restock their items for as long as two weeks while the local, smaller-scale shops were able to replenish their inventory because they did not rely on the “system.” The smaller shops were the ones who were able to continue to provide food for the community. Even Twitter played a huge role — during the disaster, it was difficult to find information. It was hard for individuals to find out if any shops were open for business. With a car, the journey to the store can be about 15 minutes, but without a car, it could take over an hour. Basically, if the store was closed, you would have just lost two hours of your day trying to get there. People were able to use the local network of people through Twitter to share information that the large infrastructures were unable to provide. It really helped the day to day lives of many people.

What is inspiring is that the people adapted to this new community of individuals and created their own network — a community and network that is more resilient and flexible to this type of event. It’s also more democratic. It is interesting because it clearly shows that there is a different way modern society operates, compared to the older society that has been enforced by large systems.


Hitoshi Abe makes several points of learnings. I find two of them particularly interesting, marked in italics below:

* Respect for nature’s awesome force and the futility of a head-on confrontation.

* Faith in and need for modern technology to come up with technically and economically viable solutions:

– Firstly, he points out these solutions would not be one-size-fits-all – not every structure could be made tsunami-proof.

– Next, he also talks about a ‘flexible boundary’ between man and nature that allows in some manner for nature to have its own way past the man-made structures causing none or little damage. Steam-letting by a pressure-cooker in the kitchen comes to my mind, a trivially simplified analogy.

* The most impressive display of equanimity by the common folks and the effectiveness of informal networks forged instantaneously to help each other. What would communities in other cultures do in times of a disaster? Difficult to say. While on this point, hot off the press is an article from Sweden that analyses survival chances of women and children in maritime disasters and if social norms hold up in these events (See Source below).

* To me the most interesting and scary observation that he makes is on our enormous dependency on large infrastructure systems in our lives. And, these systems that spelt efficiency and economy on a normal day are very failure-prone under adverse conditions, with their numerous points of vulnerabilities. A subject dealt with in many movies with end-of-the-world themes where the daring protagonist restores normalcy somehow in the end. Immense forces of nature do not play to such scripts. In sharp contrast, note the success of local solutions in these times.

The failure-proneness of large infrastructural systems is intuitively obvious owing to a) the large number of components required to work together and b) geographic dispersion and the consequent vulnerabilities; there may even be probabilistic models already formulated in the realms of mathematics and engineering to predict the failures in such systems. Tsunami and Abe’s concerns merely dredged it up into our collective conscience.

The good news is we are able to build these systems in a way that failures at one point do not ripple outwards to cause the services to collapse all over. The bad news is as of today usually there isn’t a full-service (or thereabout) back-up from within to kick in seamlessly in the event of a failure at a point.

Local solutions provide some critically needed relief – mom-and-pop stores for provisions, gen sets, inverters and solar panels for electricity, bicycles or boats for transport, etc. However for many of them the odds of survival (or operational readiness) in peace times are stiff – the local mom-and-pop store, for instance, is pitted against the onslaught of the large-format supply-chain optimized store.

Does the solution lie in recognizing the local solutions formally for their important role, incentivizing them for their sustenance and integrating them with the large systems to kick in seamlessly (or near about) at times of need? Or, the large systems would be built with an entirely different architecture to overcome the observed weakness?

While on the subject of large infrastructure systems, other examples of large systems come to our mind, essentially made of large number of components and possibly widely dispersed geographically: community of citizens (!), galaxy in space, human body, VLSI chip, a large piece of software…What constitutes a disaster for these systems and how do they behave and even recover possibly under those conditions? Are there some useful learnings for building large infrastructural systems? Or, they – the man-made systems – too cry out for some re-architecting, suffering from the same infirmities?

Source: The article is available in full at http://www.smartplanet.com/blog/design-architecture/q-a-hitoshi-abe-on-design-lessons-from-the-great-east-japan-earthquake/4873. The paper from Sweden ‘Every Man for Himself! Gender, Norms and Survival in Maritime Disasters’ may be downloaded from http://www.ifn.se/eng/publications/wp/2012/913.

Read Full Post »


Recently I learnt about an alarming situation regarding a system rolled out in a utility service for rendering emergency help to public users. It is quite imaginable that similar conditions may be prevailing in number of other towns in various utility operations.


It appears that these systems are not developed centrally under controlled processes as one would have thought, but more as local initiatives. And these are developed with the help of freelancers or part-time professionals and not with employees on rolls. This is understandable for reasons of skills shortage and also costs involved. And dealing with an individual developer is a lot easier than dealing with a service provider company especially for carrying out changes. In this mode of development, the changes, more often than not, are occasioned by requirements originally missed out due to lax ways of specifying rather than requirements evolving over usage. So it is not unusual to see a spate of changes lined up soon after the roll-out.


The code rolled out in the production server does not match with the code on the development server. Perhaps some code pieces are lying somewhere on the development server not easily traceable, or they are lost, or some changes were made directly on the production server. The seriousness of the situation has not sunk in yet. The ability to maintain and enhance the software is seriously compromised. For those of us who have been in this business long enough, this is not unusual. But what is scary is these are public-facing applications rolled out in the field, whose malfunction could cause personal injury or, worse, loss of life.


Further, there is no concept of version control or a sand-box for thorough testing before roll-out. It is not known if the system is piloted first before the full roll-out to iron out wrinkles.


As if this is not enough, I understood the freelancer has gone away for reasons not known. May be it was a cost cutting measure or the freelancer hiked his fees or he had to put distance between himself and the mess that was created (may not be entirely his doing). Needless to say there has been no formal hand-over process. When even the live-code inventory is incomplete, code or system documentation is too much to ask.


Into this scenario, the freelancer’s replacement walks in. Can you imagine his/her plight? And, there is a pile of pending enhancement requests waiting for him/her to take up right away. What it takes to maintain software is not always appreciated. What is at stake is not the individual’s performance, but safety of public users for whom the system is in operation.


Since public safety is involved, it is important that some minimal norms are enforced for developing and subsequently maintaining these systems and, the compliance to these norms are audited from time to time. May be these norms and audits are already an established practice in some  geographies.


This is not a call against freelancers who deliver great value, flexibility and responsiveness (and skills too) required by users whose requirement for software development is light and sporadic. It is a call for controlled processes for developing software especially for moderate-to-high impact applications.


Processes must be recognized as a mandatory piece of any scenario wherein software is developed or used for a serious application. The processes are not meant only for the developers; importantly, they also discipline the users (not the end-using public) who commission the developers and whose laxity is also often the root cause of the ensuing mess. It follows that both the developers and the users must be educated on the processes to be followed.


Of course, the processes must be right-sized to suit the customer and the application. Else, they could enormously slow down the software development efforts. Admittedly, right-sizing processes may not be a trivial exercise. Further, it is not required to induct a full set of processes which could be quite intimidating for a light-load user. It is sufficient to implement some key processes at a level of simplicity that serves the purpose. 


This could be done with some minimal professional help. May be there are sources from which it is possible to buy right-sized processes; and, get the freelancers to follow them.


On part of the software service providers, there is money on the table for those who come up with innovative models to develop and service systems for these light-load customers at affordable TCO without compromising on the norms. 


Of course, an off-the-shelf package solution significantly mitigates the risks and must be strongly considered as a solution over custom development.

Read Full Post »

Today the amount of code developed per project has dropped dramatically from the days of Cobol. Microsoft routinely bundles in a few thousand pre-coded classes along with its Dot Net Framework in the attempt to reduce coding largely to drag and drop. Organizations all over have bought into the benefits of adapting ready packaged solutions over custom developed software. But coding is not yet an ‘endangered’ job and is not likely to fade away anytime soon. So standards in coding continue to be relevant at least for now.

Many coders are young freshmen from college. They may not yet appreciate how coding realizes, on the ground, architectural objectives set out for the software. Coding standards, for them, are much simpler ready recipe to follow without deep knowledge of these architectural objectives. Adherence to the standards thus mitigates the risk of inexperience or lack of higher-order knowledge.

There is a second source of risk. Today, code is no longer monolithic – it resides all over the place, inside the browser, server pages, beans, cgi code, apps server, sql procedures, xml, css, etc. These are different technologies, each commanding its own best practices. You tickle anyone of them in the wrong place you are in for some grief. For accomplishing a small function, code from many of these fragmented technologies must be threaded together. Things never got simpler under the hood! In such a mixed-up scenario, pre-packaged wisdom by way of standards or best practices reduces the risk of inappropriately using these technologies.

I still recall from past how someone in a remote support team, working on an emergency patch, caused a blood bath by writing a short sql snippet disregarding some set norms, that inadvertently wiped out data partially from the end-user’s production server.

OK, that’s enough of reasons to have standards and best practices. So, what’s the point?

When I interview developers, I quiz them on coding standards. Most organizations have coding standards that run into several pages. We seriously think that any developer allows himself to be guided by these pages of do’s and don’ts every time he keys in a snippet of code? Fortunately checking adherence appears to be more manageable with tools available now which can zip thru developed code against a few hundred coding rules and spew out the violations. The rules could even be customized. But can you imagine the effort involved in removing these violations? The only way to operationalize these voluminous standards for real would be to put together a tool that would clean up the code generated by the developer automatically or in an assisted mode or have the IDE enforce these standards while the code is being developed. To expect the developer to manually adhere to the standards is impractical. If the organization’s Quality System or the Process Model expects this adherence or if someone out there claims all these pages of standards are scrupulously adhered to in the manually written code…

There is another serious angle to these voluminous standards. These standards rarely have architectural attributes as one of the keys. So when I ask ‘What parts of your organization’s coding standards help you to develop an application with very low number of defects?’ most often candidates have heard it for the first time. We all know that an application cannot be developed with equal emphasis on some 20+ architectural attributes. The question of classifying the standards by architectural attributes and prioritizing them for a given application is real.

It is common to find the standards keyed by the subsystem covered. Of all standards, those covering the database subsystem are most crucial because any damage thru incorrect coding in those parts could be permanent, affecting large number of users and recovery painful. With most other subsystems, the worst case may be an aborted user session. External Systems, it is assumed, are capable of rejecting wrong usages.

It would be interesting to contemplate on other possible keys (technology is another obvious candidate).

Later we will look at some real life examples of what goes into the coding standards and how to put some real bite into them.

Read Full Post »


I call up the SP later and say to him: ‘You’re a senior guy and you have been with us for some years now. You have, on past occasions, taken up work, at personal inconvenience. You also know how important this assignment is to us. If I tell you to continue working, you would regard me as also insensitive. If I tell you to pack up and return, it means upset customer and possible loss of business. So I trust you to take the call yourself. And I will back your decision.’

PS: The SPM decided to return from the assignment prematurely, he did undergo a minor surgery that put him out of action for a few weeks; he appreciated that we stood by him. He went on to do well with us for a few more years. The customer did hit the ceiling initially; we explained the compulsions and he saw us going to great lengths to protect his interests and he continued to stay with us thereafter. 

These are tough times for a manager to take decisions. Trusting (a good) employee’s judgement in such adverse conditions is a kind of employee empowerment of high-order that corporates often shout about. A strong message such as this willingness to bite the bullet has enormous pay-back. Nevretheless, the manager must exercise due-diligence and be seen to be in firm control of the situation right thru. And he must quickly resolve in a way that takes into account divergent interests. If one thinks hard enough, numerous ‘gray’ solutions would pop up between the ‘will’ and the ‘won’t’ that the two parties in conflict could be persuaded to accept. Or, there are ways to soften the ‘will’ or the ‘won’t’. In any case, time is the essence; the more the situation festers the more difficult becomes the acceptance of a middle ground. 

Did I put the employee’s interest ahead of my customer’s interest, against the credo of a service provider? No, I was bringing back alignment of the two stake-holder interests as much as the situation would allow, still swearing by the same credo.


Read Full Post »

A senior Project Manager (SPM, for short) is at customer site on one of those door-opening kind of assignments. He is doing a good job and the customer relates to him quite well. One day (in fact it was the middle of the night, owing to a mix-up on time zones), the account sales guy (AM, for short) calls me up and without exchanging any preamble pleasantries, shakes me up with ‘there’s trouble, man’: the SPM wants to return home prematurely in the middle of the assignment. And if he does, we can kiss off all the downstream work the customer is planning to give us. The SPM does not understand the seriousness of what he is considering. He (the AM) fears that one of these days the SPM is going to inform the customer about his pull-out plans. Hell will break loose, then. So, the AM wants me to put some sense into the SPM and make him continue with the assignment until closure.

Towards the end of this one-way worked-up verbal download, I gather my wits and manage to ask the AM why in the world SPM wants to get off midstream. Aggrieved AM informs me non-believingly that the SPM cites ‘some’ back pain as the reason, while he is in no discomfort cavorting about in the city quite openly with a pal in his car in the evenings and the weekends. SPM is just making it up to get back home for reasons not known. I assure him that I would talk to the SPM and try to persuade him to stay back on the assignment.  Now I am fully awake and I get onto a call with the SPM who starts off ‘right’ by solicitously asking me why I am troubling myself with a midnight call.  After the small talk, I get to the point.  I explain what is at stake and how important it is for him to stay put, especially when the customer so impressed with his work. He hears me patiently without interrupting me and then proceeds ‘logically’ to tell me: he has always thought and acted with the org’s interests uppermost in his scheme of things; it would be no different this time. Unfortunately he has this severe back pain at the base of his spine that makes it impossible for him to sit in any posture for a long time. He has consulted a local doctor who advises a bed-rest followed by a minor surgical procedure. Obviously he wants to return to his base and get treated in some hospital nearer home. I gently bring up the point of his being fit enough to be going around with his pal; the SPM has quite a plausible explanation for it – at least for some time he forgets his pain this way. Do we expect him to lie around in bed, wincing in pain?       

And he rests his case with: ‘Now, you tell me what do you want me to do. The AM does not understand what I am going through.’ I note I am not clubbed yet with the AM.

I pause here. How should I be taking this forward?


(To be concluded)


Read Full Post »

One of the biggest reasons for project shedules going awry (and Project Managers sporting ulcers) is the involvement of third-parties and their inability to perform as per their commitments. The third- parties could be vendors supplying equipment and services or statutory bodies such as local government; they could even be internal functions such as HR, Finance and Administration too. This is despite the SLA’s given out by the third-parties for their performance. Under these circumstances, what does a Project Manager do? The obvious response of cutting the third-parties out completely is not a sensible option today.Firstly, it is necessary to recognize there is a risk associated with the performance of a third-party. The risk is more or less depending on the third-party’s track record and the protection built into the contract. How is then the risk mitigated? It involves interacting with the third-party on its side of the turf and not on play the ball at the SLA interface (the normal buyer-seller interface). At the SLA interface, when the third-party fails to perform, it is already fait-accompli. The trick is to have checks on the third-party behind the line which would alert us to its non-performance before it actually happens, as far as possible.

To give an example, in the past, we ordered a bunch of PC’s from a premier vendor in the beginning of March to be delivered later in the month. We needed these PC’s for a project where we had accepted penalty clauses for delays with our customer. Usually all vendors are flooded with orders in March and hence there was a definite risk of the vendor not shipping the PC’s as promised in March. During the order placement and price negotiations, we got a direct line to the vendor’s factory. After a week of placing the order, we used our factory line to check shipment status. We learnt that the factory’s monthly production schedule and allocation did not include our order at all! We got back to the vendor’s sales function and made enough noise to get our order scheduled for shipment in March. That’s not all. When the shipment was finally made, we actually tracked the truck all the way from the factory to our premises to guard against any delays in transportation – a very likely prospect since the shipment moved across several state/toll boundaries. Inspite of all the care we took, we still ended up paying penalty for a week’s delay. Had we not taken the ball and played it in vendor’s court, the delays would have been much more.

Of course, if the third-party has an unblemished track-record of performance, perhaps one can deal at SLA interface without running too much risk of nasty eleventh-hour shocks. The extra price one may be paying to a proven vendor could be seen as the cost of mitigating the risk of non-performance of a as-yet-unproven vendor, other things being equal. This could even become the basis for looking at the price differential between a proven and an unproven vendor!

More to follow on Secrets of Winning Project Management Practices.

Read Full Post »