Posts Tagged ‘Project Management’

you getting monkeys is not just with hires. Goes for vendors, contractors, third parties…

This is for the managers and executives priding on their ability to squeeze every freebie, concession and discount out of their beleaguered vendors.

Here we go:

The  headman from the painting cum landscaping company  was speaking with the hard-driving customer about the job awarded to them.

Laying-Turf  jokesoftheday.net

In the first room, she said she would like a pale blue. The contractor wrote this down and went to the window, opened it, and yelled out “GREEN SIDE UP!”

In the second room, she told the painter she would like it painted in a soft yellow. He wrote this on his pad, walked to the window, opened it, and yelled “GREEN SIDE UP!”

The lady was somewhat curious but she said nothing. In the third room, she said she would like it painted a warm rose color. The painter wrote this down, walked to the window, opened it and yelled “GREEN SIDE UP!”

The perplexed lady then asked him, “Here I’m telling you what to do and you keep yelling ‘green side up’?”

“I’m sorry,” came the reply. “them…are laying sod in the front and around.”




Source: Adapted from jokesoftheday.net


Read Full Post »

Project-Management premium.wpmudev.org

There was a news item recently in the press about Tata Consultancy Organization (TCS) planning to lay off 30,000 professionals accompanied by words on the ‘big corporate for-profit exploiter’ from some of those impacted or to-be guys for the human element in the story. The guys, it seems, are largely managers with 8 to 10 plus years of experience.

The company has denied it saying the annual weeding out exercise would be only to the extent of 2% to 3% of total strength as it has done in preceding years.

Let us assume for a moment the company is true to its word and there are no compelling reasons of business downturn warranting a bigger-than-usual axing.

While the development is certainly unfortunate especially for the affected, it is hardly surprising. And I’m sure it is neither sudden.

Why does this happen?

When it comes to weeding out, the organization looks at the value an employee brings to the operations in a series of assessments. This is even more significant at senior levels as these guys are pricier and hence most vulnerable.

The avenues available to a senior (a project lead or a manager) to enhance his contribution are essentially in two directions: a) He contributes to the project he is managing/involved or b) He contributes to some corporate objectives not linked to his project. In many organizations seniors are mandated to wear both the hats to get more out of their strengths and maturity.

As far as direct contribution to the project goes, opportunities are many:

1. Of direct and high impact for the organization of curse is to mine the project/account to increase the billing incrementally/strategically. Or, to wow the customer on scope,cost, time, performance or quality parameters of the project.

There are a number of other ways to step up the value (not in any order):

2. Reduce income leakage by handling the lost hours.

3. Increase productivity by using tools, cutting waste, streamlining processes, etc.

4. Flatten the cost pyramid by substituting more junior resources in place of seniors

5. Get the customer to sponsor an incentive plan and other recognition schemes for the team. While the costs incurred in these schemes are low the returns are manifold.

6. Develop it as a reference account/project by putting together, solution stories, application/technical notes, and other marketing/sales assets.

7. Get the customer to agree to site visits by prospects.

8. Get the customer to speak in the organization’s promotional events.

9. Generate newer views of the project by formulating imaginatively metrics to address his pain areas. For example, mapping the change-requests to physical pieces of code would be useful in pointing out which modules are hit by poor articulation of requirements, lack of coding skills or sheer business volatility.

10. Reduce the hassles of dealing with the team in some perceptible manner. For example, cut back on the communication load.

11. Alter some service parameter to customer’s advantage like coverage/turnaround times.

12. Engage the customer to gain a business perspective and his plans, to support mining efforts.

13. Harvest reusable/training assets.

14. Validate and refine quality assurance/productivity/staffing/estimation/methodology models/norms.

15. Groom junior resources in technical and soft skills. In one project, juniors took turns to be present when the lead reviews with the customer to improve their reviewing, communicating and objection handling skills.

16. Stand by him by going beyond the letter during his crisis time.

I’m sure you have a few other ideas too. The opportunities are many limited only by imagination.

So what is holding you back, friend?

If the project is a dead-end kind offering no scope for any initiative at all over an extended period of time, it’s time to move on to another project or even organization.


Read Full Post »




Sitting around in a group, discussing why a deadline was missed or a project failed, and who could be (made) responsible for the same. If it is not ‘an unfortunate combination of factors’ someone not part of the discussion (example: the customer) is usually a preferred candidate.

Credits: arcamax.com, openclipart (neocreo_Round_Table_Discussion, discussion bitterjug)

Read Full Post »


Any organization, mature or not, from time to time gets into initiatives.

These initiatives focus efforts often for short duration for quick results and some run over longer timeframes. Their impact, by no means, light.


Reduce incidences of sudden leaves of absence of its employees.

Improve employee engagement in terms of contributing case-studies.

Manage a project escalation to satisfactory closure.

Implement a risk assessment model in projects.

Etc. etc.

Unfortunately it is also true many initiatives peter out without delivering results for various reasons becoming the staple for humor in office corridors and canteen. No dirt attaches to anyone.

Even a cusrsory examination of these initiatives shows they exhibit certain common characteristics:

– An initiative is expected to deliver intended results

– The timeframe for achieving the results is also constrained.

– There is a team of resources to roll out the initiative.

– Importantly, not by magic, there is a set of tasks that need to be done to reach there.

If this is not like a project, what else is it?

A project view of the initiative immediately gains the established rigor of planning and monitoring. Additionally it demands the commitment of various stakeholders towards their roles at every step. Any non-performance is easily visible thru the monitoring process.

Why not give it a try when you kick off your next initiative?


Read Full Post »


Credits: From the net

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 »

duckhunter j4p4n

A Group Project Manager, HR Manager, Manager (Legal) went duck shooting with a trailing Project Manager .

A duck flew over, and the Group Project Manager aimed, but didn’t fire.

“Why didn’t you shoot?” asked the HR Manager, deferentially.

“Are you certain it was a duck,” answered the Group Project Manager. “It could have been another bird.”

Another duck flew over. the HR Manager aimed but didn’t fire.

“What now?” asked the Group Project Manager.

“Does the duck actually know it’s a duck?” asked the HR Manager.

Another duck flew over. The Manager (Legal) aimed, but didn’t fire. “This duck, I suspect, is a little larger than the limit stipulated in our permit,” he explained.

Another duck flew over. The {Project Manager pulled the gun out of the Manager(Legal)’s hand and fired.

“Are you sure it was a duck?” asked a slightly crossed Group Project Manager.

“We’ll find that out from our SME(Subject Matter Expert),” said the Project Manager.

On the way back, they met the Accounts Manager. He heard it all.

“You have used a shot one size too large, friend,” he said to the Project Manager.


Credits: openclipart (j4p4n)

Read Full Post »


While the toilet scene is quite earthly, I think the lesson must be about projects managed on the moon!


Source: Internet

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 »

Milestones are important in any paradigm of project management regardless of what tools are used to assist in project management. Carefully planned milestones go a long way towards success of a project and satisfaction of its stakeholders.

While a project may be reviewed in great detail by looking at the level of tasks, it is the milestones and their dates that aggregate the impact for easy comprehension of the bigger picture.

Now, is there a basis for setting up these milestones in a project?

While it is not exactly a science, some useful guidelines can certainly be framed to help in defining the milestones. A word of caution, of course, is in specific situation, these guidelines may be required to be adapted to fit the occasion.

Here we go:

Every important event in the life of a project is enshrined as a milestone. Usually these events mark the completion of a phase of the SDLC cycle for a module or piece of the system under development.

Associated with a milestone is a deliverable (code, document, bug-list…) of value to the stakeholders.

It is often overlooked the acceptance of the deliverable by the customer is also a milestone. It implies the deliverable is adequately tested by the vendor before delivery and is also sufficiently tested by the customer for its acceptance. The principle applies to all committments required from the various stakeholders for the successful execution of the project. And these milestones represent the committment of their owners (stakeholders) to the project. This must be impressed up on all at the very outset. It is not a solo show by the vendor driving all the milestones.

As far as possible, a milestone has a single stakeholder responsible for the deliverable. For instance, QC testing is normally done by an independent Quality group and hence gives rise to a separate milestone to mark that activity.

Obviously the definition of the milestones and their sequencing are settled jointly by the stakeholders, usually guided by the customer’s priorities and any inherent dependencies and risks.

Often a simple step is missed out of making sure all stakeholders are in the know and in agreement with the schedule of milestones. It has the potential for causing serious consequences. How often do we find the customer has planned his vaccation when the deliverable is required to be tested by him for acceptance!

A corollary of associating a deliverable with a milestone is to also link a quantum of payment by the customer to the vendor commensurate with the efforts towards the milestone.

The milestone’s deliverable must be ‘executable’ (verifiable), must represent a significant addition to the functionality delivered in the earlier milestones. And, even usable especially in the later stages of the project.

For this reason, it is a good practice to ensure the deliverable of the current milestone is completely integrated with the earlier deliverables.

In all but the simpler projects, at any instant of time, activities may be current on more than one milestone.

A key question still remains is: How many milestones should be defined in a project?

More milestones a project has, it is less risky for the customer. He has greater visibility into the project and sees it being ‘conquered by divide and rule.’ It is also less risky for the vendor as any lack of alignment of the deliverable with the customer’s needs is detected at the earliest point of time for correction. The down-side of having too many milestones is the overhead associated with readying the deliverable by the vendor and its testing by the customer for each of those milestones.

Obviously, it is the other side of the coin if there are too few milestones in the project. Besides, the vendor also gets paid later in the day for his efforts.

What is the golden mean?

Of course it depends on the size of the project. Well, a thumb-rule could be a vendor’s milestone for every 15% of the project efforts completed or for every 3 to 4 weeks of elapsed time whichever is earlier.

It is also not unusual to define a hierarchy of milestones in larger projects.

It is a normal practice to estimate and track other performance parameters besides the timeline for each milestone individually.

Hence, a high-level milestone or a set of milestones at lower level may be planned so as to include the all the phases of the SDLC cycle as completely as possible. Only then many performance parameters are meaningful. For instance Defects Density is meaningful for a milestone only if all the development efforts are included in that milestone.

And, finally, it is possible for the vendor to set up internal milestones not visible to the customer as part of the strategy to split it up into manageable pieces.


Do share your experiences in this regard.

Source: Image form Wiki

Read Full Post »

Older Posts »