Month: June 2017

Why Negotiations Fail?

Why Negotiations Fail?

  1. Mismanagement of expectations

Imagine going to a pizza shop and then being told it only serves sushi; disappointment is likely. The same goes for negotiations. If expectations aren’t managed properly, disappointment or frustration may ensue from a misalignment of expectations and reality, and may result in a less-than-ideal outcome for one or all parties.

Properly managing expectations comes from preparation and flexibility. If a party has done its homework –including understanding past precedents and current alternatives—that party is much more likely to have realistic expectations for its encounters. In addition, acknowledging that things may not go as planned can lead to preparation of alternative and backup plans. These plans must lay out acceptance and walk-away scenarios prepared before negotiations begin.


  1. Unwillingness to empathize

It’s like watching someone go fishing and not realizing that some people may enjoy fishing. Often, people do not consider the other side’s points of view and cannot appreciate that the other side has different needs and desires, which have a big impact on how negotiations are approached.

By considering the other side’s goals, needs, and thought processes, a negotiator will be able to anticipate arguments the other party may make and consider alternatives that the other party may find appealing even before they meet. In addition, understanding and acknowledging the other side’s point of view may improve the rapport between the parties and can have a positive impact on long-term relationships.


  1. Lack of preparation

Have you ever gone to the grocery store without knowing what you already had at your house, only to end up getting more of things you don’t need and less of what you do? Going into any deal without a knowledge of the negotiation’s landscape and potential traps can be treacherous for a negotiator and inhibit proper management of expectations.

A negotiator should come in knowing what relevant precedents exist for the current negotiation, what alternatives may be available (or currently unavailable), and what curveballs may be thrown during the conversation. Preparation in the form of a checklist can be especially helpful as a visual representation of what the negotiator has done, is doing, and needs to do in order to fully prepare for the negotiation. This detailed preparation will make the negotiator more flexible, confident, and purposeful than coming in with only a vague idea of what to expect.

Risk Management Failure – Why does it happen?

Risk Management Failure – Why does it happen?


Big projects more often fail because of poor evaluation than poor execution. But many organizations focus on improving only the latter. As a result, they don’t identify the projects that pose the greatest risks of delay, budget overruns, missed market opportunities or, sometimes, irreparable damage to the company and careers, until it’s too late.

It would be easy to point the finger at poor execution. After all, problems occurs as cost or schedule is run over. But overruns are just symptoms of the real problem: poor estimation of project size and risk. As a result, organizations take on projects they shouldn’t and under-budget those they should. H Here are the two drivers of failure and how to avoid them.

  1. Scope and Risk Estimates Are Sourced from Project Advocates.

In a project’s earliest stages, very little is known about what it will take to execute it. So most companies seek out expert internal opinions — usually from stakeholders of the project, since they have the most knowledge around the project. The problem is bias. Research is clear that project stakeholders are likely to fall under its influence, favor optimistic outcomes and produce dangerously inaccurate estimates.

One simple way to expose the impact of bias is with something we call the project estimate multiplier (PEM). It’s simply a comparison of average actual costs vs. average original estimates. The larger the PEM, the greater the impact bias has on your estimating function.

  1. “Big Bet” Risks Are Evaluated the Same Way Smaller Projects Are.

According to research, the risk of failure is four times greater for large projects, and they exceed their already-large budgets by three times as much as smaller projects — enough to cost jobs, damage careers and even sink companies.

Most companies can accurately estimate small projects that may take, say, three to six months, but they are unfortunate at estimating the time and cost of big ones. There are three key reasons for that.

First, large projects usually involve many interdependent tasks, which creates complexity that smaller projects do not have. That makes large projects prone to uncertainty and random events, so they can’t be estimated in the traditional way. Risk-adjusted techniques, such as Monte Carlo analysis, are significantly more accurate.

Second, large projects usually involve tasks whose difficulty is unknown at the time of estimation.

Third, the tipping point between low-risk and high-risk projects is sudden, not gradual. Once a project passes the tipping point, the risk curve changes quickly and dramatically. Unfortunately, under the influence of bias, many companies fail to see the curve, much less correct for it, until it’s too late.

To better assess and manage project risk, develop a process to measure projects against your tipping point. Projects that exceed the tipping point need to be estimated and managed differently. We’ve found the best way is to run the project plan through a series of Monte Carlo simulations. That not only accounts for the risk of uncertainty, it also identifies the tasks with the most risk of affecting the outcome.

The analysis output can then be used to develop a plan for mitigating the risk. This can include techniques like breaking the initiative into smaller projects or running tests to reduce uncertainty.



Task estimation for pert charts:

Task estimation for pert charts:


It is an analysis techniques can be used when the individual task times estimates are fairly uncertain. Instead of putting a point estimate for the duration estimate PERT uses three times estimates.


Most likely


Formula example: (optimistic time+4X most likely time+ Pessimistic time)/6

(8 workdays+4*10work days+24 work days)/6 =12 Days

Where Optimistic time= 8 Days

Most likely time = 10 days

Pessimistic time = 24 days

So most likely time will be 12 days

Estimating duration this way allows managers to calculate a more realistic project schedule.


PERT charts are an excellent training tool for a project controls person to truly understand the underpinnings of a schedule,” says PMFocus’s Patterson.


PERT charts help project teams visualize the order of tasks, milestones and phases within a project. Illustrating the project schedule makes it easy to identify tasks as one of two types:

  • Dependent, or sequential tasks
  • Non-dependent, or concurrent tasks

This allows managers to coordinate work across teams and departments more effectively.

Downside of Agile

Downside of Agile

In case of some software deliverable, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

There is lack of emphasis on necessary designing and documentation.

The project can easily get taken off track if the customer representative is not clear what final outcome that they want.

Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

It’s a relatively new methodology, people not that much used that they are with waterfall

People are afraid of what they don’t know

Without a baseline different incomputable solutions could arise during each iterations.

Without communications different people may produce divergent solutions

People tend to get burned out as the end of iteration is approaching.


Planing for Contingencies

Planing for Contingencies

The goal of contingency plan are to establish a communication systems, create recovery/ respond threshold and define the roles and responsibilities of the employees in case of a disaster. We have all seen that unplanned events could occur  with little e or no warning and bring business operation to a halt as was recently the case with all the flights from and to to London recently

The key goal should be to make sure you can maintain the operation of your organization if the disaster were to occur.

It’s a good idea to have a formal policy spelling out the need for a contingency plan.

The plan should be simple overall. The language and directions in it should be understandable to future audiences. You never know who will have to implement it.

Figure out the specific trigger that will require you to use your contingency plan. Determine how you will measure success so that you can return to normal operations. Identify all operations that are critical to your business continuing.

Making sure your plan addresses each of these three questions will help you ensure you don’t miss anything.

What could happen?

What will we do in response?

What can we do in advance to prepare?

Here’s a brief case study in how a well prepared and executed disaster recovery plan can save a business.

Agile Estimations – How to?

Agile Estimations – How to?

Planning Poker or Scrum Poker.

Estimating a project, in terms of cost and time is always a difficult task for all project managers.  A project manager who have completed a similar project, the estimation would be much easier than a fresh project manager who doesn’t have e a  previous domain experience. In Agile the solution for the problem is doing a Planning Poker or Scrum Poker.


At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.

The meeting proceeds as follows:

  • A Moderator, who will not play, chairs the meeting.
  • The Product Manager provides a short overview of one user story to be estimated. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded by the Project Manager/Scum Master.
  • Each individual lays a card face down representing their estimate for the story. Units used vary – they can be days duration, ideal days or story points. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.
  • Everyone calls their cards simultaneously by turning them over.
  • People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.
  • Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the “consensus vote”, although the Moderator can negotiate the consensus.
  • To ensure that discussion is structured; the Moderator or the Project Manager may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soap boxes.

Procedure source: Wikipidia

Contingency Planning and Management – I should have known better

Contingency Planning and Management – I should have known better

Contingency Planning in IT projects 

Unexpected and unforeseen issues do happen in all projects.  To manage the  negative impacts,  Project Managers plan a contingency arrangement to complete the project on time and within the budget.

Why do we need a contingency plan. 

  • To finish a project on schedule and within budget
  • To avoid unnecessary pressure on other team members

How do we plan to face an emergency situation in IT projects

The first step in contingency planning is identifying the constraints in advance.  The probable constraints include

 Vendor Supply

This issue do happen if we depends on a third party on hardware supply or support on both hardware and software.

How to plan?

*Constantly keep in touch with the vendor directly or indirectly how well they are on their promise on delivery and provide feed backs and manage projects slightly according to the delivery schedule.

*Plan and identify and make arrangements in advance for an alternate supplier and their conditions.

Key Personnel:

Whole project delivery commonly depends on few key people in the project team.  They are mostly domain experts or senior developer or someone who already have a wide knowledge about a similar project or same project.  These people normally have multitasking skills and  often members of other projects as well. A sudden disappearance of these people from the project would significantly effect the outcome of the project. Having a plan in place to substitute an expert by assigning tasks to suitable staff is always a better management policy.

How to plan and Manage this situation?

Always find backup domain experts for consultation before the beginning of project.  To replace these key people normally need more headcounts with individual skills.  From the time of project planning, project managers do assign( most of the time confidentially) a replacement for all key positions called Plan B and ask for extra 20% staff  as float.



Why does the risk management matter?

Why does the risk management matter?

Why does the risk management matter?

The last thing that any project will want to face is risks. Projects are designed to take advantage of resources and opportunities and with these, come uncertainty, challenges and risk. Hence Risk Management becomes a very important key to all project success.

Risk Management: is the project manager’s friend. Done well, it helps you ensure that the ‘appetite for risk’ is appropriately understood at the start; that all risks are agreed upon, prioritised, assessed, communicated and understood in alignment with this ‘risk appetite’; and that you have a solid platform to track agreed actions, including escalation up the management chain if necessary.

Why would you develop a Risk Management Plan?

  • Provide a useful tool for managing and reducing the risks identified before and during the project.
  • Document risk mitigation strategies being pursued in response to the identified risks and their grading in terms of likelihood and seriousness.
  • Provide the Project Sponsor, Steering Committee/senior management with a documented framework from which risk status can be reported upon.
  • Ensure the communication of risk management issues to key stakeholders.
  • Provide a mechanism for seeking and acting on feedback to encourage the involvement of the key stakeholders.
  • Identify the mitigation actions required for implementation of the plan and associated costings.

Risk Management steps:

  • Risk Identification.

It means to engage all the project team to identify what are the possible risks that could happen during the project life cycle.

  • Risk Analysis.

Is to analyse the risks identified based on likelihood and impact and product the Risk matrix.

Risk Matrix:

It is used during risk assessment to define the level of risk by considering the category of probability or likelihood against the category of consequence severity. This is a simple mechanism to increase visibility of risks and assist management decision making.


  • Risk Response.

Once we identify where the risk lies in the matrix then we can identify the best response which can be any of the below:

  • Avoid – eliminate the threat by eliminating the cause
  • Mitigate – Identify ways to reduce the probability or the impact of the risk
  • Accept – Nothing will be done
  • Transfer – Make another party responsible for the risk (buy insurance, outsourcing, etc.)


  • Risk Monitoring & controlling

The level of risk on a project will be tracked, monitored and reported throughout the project life cycle.

A “Top 10 Risk List” will be maintained by the project team and will be reported as a component of the project status reporting process for this project.

All project change requests will be analysed for their possible impact to the project risks.

Management will be notified of important changes to risk status as a component to the Executive Project Status Report.



The triple constraint in Project Management

The triple constraint in Project Management

The triple constraint in Project Management

They are the key attributes that must be handled effectively for successful completion and closure of any project.

These constraints are: TIME…..COST…..SCOPE

If we consider the below scenario:

(Note X, Y & Z are just used for explanation and they represent the units of each e.g: Z TIME = 5 days, X Tasks = 30 tasks & Y Cost = $1000 ->  that means in order to deliver the 30 tasks in 5 days you need $1000 as a cost, etc…)

The below figure represent a triangle that has 2 main dimensions (X, Y & Z)

  • If Z TIME is the required to deliver X Tasks using Y Cost “Budget


  • Y COST is needed to deliver X Tasks in Z Time


  • X TASKS can only be delivered if I have Y Cost and in Z Time
  • Quality is the volume of the triangle – To keep the quality the same then any change in one of the triangle dimensions need to have some adjustment in the other 2 dimensions