Category: Project Management

Posts on Project Management

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.

 

 

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.

What is PRINCE2 Project Management?

What is PRINCE2 Project Management?

What is PRINCE2?

Projects in Controlled Environments or PRINCE2 for short has become one of the most popular and widely used project management methodologies available today. Employed by both the public and private sectors, it has become the de-facto standard for project management in the UK.

Following the success in the UK, interest has spread across the globe. Countries in which PRINCE2 is becoming established include the Netherlands, Belgium, Germany, Spain, South Africa, Australia, and the United States.

What Does the 2 in PRINCE2 Refer To?

PRINCE2 has its roots as far back as 1975 in the PROMPTII methodology. PRINCE replaced PROMPTII in 1989, becoming the UK standard for all government information systems projects. In 1996, the methodology was re-launched as a generic project management methodology for all UK government projects, hence the 2.

Why Was PRINCE Introduced?

It’s true to say the public sector has hardly covered itself in glory with its ability to deliver projects on time, within budget, scope and to the right quality. PRINCE and later PRINCE2 were introduced to address the common causes of project failure.

How Does PRINCE2 Work?

PRINCE2 is a best practice framework that helps managers deliver projects on time and within budget. It divides projects into clearly defined stages with a start, middle and end. It focuses on the delivery of products rather than carrying out activities. Every project must have a business case, and plan that is periodically reviewed to check the project is still viable.

A PRINCE2 project has the following characteristics:

  • A defined lifecycle
  • Defined and measurable business products
  • A corresponding set of activities to achieve the business products
  • Specified amount of resources
  • An organisation structure, with defined responsibilities, to manage the project

How Does PRINCE2 Structure a Project?

Core to the methodology is the Project Board, made up of the customer, user representative and supplier. The project manager reports to this board through regular status reports. If there are problems on the project, the board decide how the project should proceed.

What Are the Benefits of PRINCE2?

PRINCE2 is about doing the right projects, at the right time, for the right reasons. It gives you standard systems, procedures and language for projects. PRINCE2 also provids:

  • Better control and use of resources
  • A means for managing risks and issues
  • Flexible decision points
  • Regular reviews of progress against the project plan and business case
  • Assurance that the project continues to have a business justification
  • Early visibility of possible problems
  • Good communications between the project team and other stakeholders
  • A mechanism for managing deviations from the project plan
  • A process for capturing lessons learned

Putting all of this together should enable you to save time and money while delivering projects more efficiently.

How Do I Become Accredited?

If you want to become a registered PRINCE2 practitioner, there are two exams to sit, the Foundation and Practitioner exams. Many accredited training organisations exist offering courses ranging from 2-day Foundation, 3-day Practitioner to 1-day refresher courses.

The Foundation exam is 75 multiple choice questions and lasts an hour. The Practitioner exam is eight questions and takes two-and-a-half-hours.

 

PMBOK vs PRINCE2 vs AGILE Project Management

PMBOK vs PRINCE2 vs AGILE Project Management

What are the pros and cons?

There are a range of different methodologies which are often applied to project management, with the three most commonly considered being PMBOK, PRINCE2 and Agile. If you’re trying to weigh up what are the pros and cons of PMBOK versus PRINCE2 versus something like Agile, you may find it useful to consider them in context with the project that you’re undertaking, as well as comparing one to the other.

To help you in assessing what are the pros and cons of PMBOK vs PRINCE2 vs Agile and which of these methodologies may work best in your individual situation, here is an overview of each of these systems for general project management best practice

PMBOK – pros and cons

PMBOK is short for Project Management Body of Knowledge. Users of this system find that it has more substantial frameworks for contract management, scope management and other aspects which are arguably less robust in PRINCE2. However, many users of PMBOK find that they are not entirely happy with the way this system limits decision making solely to project managers, making it difficult for handing over aspects of the management to other parties and senior managers. With PMBOK, the project manager can seemingly become the primary decision maker, planner, problem solver, human resource manager and so on.

PRINCE2 – pros and cons

PRINCE2 stands for Projects in a Controlled Environment and this is a project management program that shares more of the functional and financial authority with senior management, not just the project manager. This program has a focus on aiding the project manager to oversee projects on behalf of an organisation’s senior management. On the pros side, PRINCE2 provides a single standard approach to the management projects, which is why many government and global organisations prefer this option. It is also favoured because of its ease of use, which makes is easy to learn, even for those with limited experience. On the downside, there are users who feel that PRINCE2 misses the importance of “soft skills” that should be a focus for a project manager.

Agile – pros and cons

Agile is a more distinct program from PMBOK and PRINCE2. The Agile methodology is more flexible, making it better able to produce deliverables without the need for substantial changes and reworking. Tasks can be broken down into smaller stages and this allows for substantial risk reduction through earlier assessment, testing and analysis. The main drawback of Agile is that if it is not fully grasped, the methodology could lead to unattainable expectations.

If you’re interested in comparing PMBOK vs PRINCE2 vs Agile and you’re wondering about the pros and cons there are several answers. Each of these has it distinct differences. If you’re project needs to be small and adaptable, then Agile may be the answer. If the project manager needs to be the sole decision maker, then PMBOK could be preferable and so on. Each project manager will form different opinions and they may even change their mind on which is best based upon changes from one project to the next.

What’s the problem with Project Managers saying “no problem!” to all requests

What’s the problem with Project Managers saying “no problem!” to all requests

Rubbing-Head...-Too-MuchWhen one discusses problems that may arise through Project Managers saying ‘no problem!’ to any requests for product changes, one is essentially delving in particular into the realms of scope management.

Project managers need to anticipate and plan to accommodate requirements growth. In software development, requirements change and grow over the course of a project. The key words are plan and control. Scope creep occurs when there is an uncontrolled growth of functionality that a project team attempts to just stick into an already at capacity project phase. An inexperienced project manager saying ‘no problem’ to any request would heighten this problem.

When functionality increases in an unplanned and uncontrolled manner, consequent prioritisation of requirements is inadequate and the expanded targets make it difficult to deliver key points of functionality on time and schedule. Projects can also run into further delays, problems with quality and misdirected energy.

The key point is this: functionality can change and expand, but it must be planned; thus it will be linked with restraints of time (iterations), cost (the budget) and prioritisation of tasks (key functions are delivered first).

Agile Vs. Waterfall: Evaluating The Pros And Cons

Agile Vs. Waterfall: Evaluating The Pros And Cons

Agile and Waterfall are two distinct methods of software development. The Waterfall model can essentially be described as a linear model of software design. Like its name suggests, waterfall employs a sequential design process. Development flows sequentially from start point to end point, with several different stages: Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance.

In contrast, the Agile method proposes an incremental and iterative approach to software design. It was essentially developed in response to the limitations of Waterfall, as a way to give designers more freedom. The design process is broken into individual models that designers work on. There is no pre-determined course of action or plan with the Agile method. Rather, designers are free to respond to changes in requirements as they arise and make changes as the project progresses. Agile is a pretty new player to the development game. However, it has made substantial gains in use and popularity in the last couple of years.

First of all, before you embark on a software design project, make sure you have the basics of software design down.  Before making a choice, it is important to do some research and understand the advantages and limitations of each approach.  Let’s take an in-depth look at the pros and cons of both the Agile and Waterfall methods of software development.

AGILE : The Pros

Agile offers an incredibly flexible design model, promoting adaptive planning and evolutionary development. Agile might be described as freeform software design. Software developers work on small modules at a time. Customer feedback occurs simultaneously with development, as does software testing.  This has a number of advantages, especially in project environments where development needs to be able to respond to changes in requirements rapidly and effectively.

Agile can be especially beneficial in situations where the end-goals of projects are not clearly defined. For example, if you are working with a client whose needs and goals are a bit hazy, it is probably worthwhile to employ the Agile method. The client’s requirements will likely gradually clarify as the project progresses, and development can easily be adapted to meet these new, evolving requirements. Agile is also an excellent option for experimental software design.

Lastly, this method also facilitates interaction and communication – collaboration is more important here than design. Because interaction among different designers and stakeholders is key, it is especially conducive to teamwork oriented environments. Different developers work on different modules throughout the development process and then work to integrate all of these modules together into a cohesive piece of software at the end of the project.

 WATERFALL:  The Pros

The emphasis of Waterfall is the project plan and therefore before beginning any kind of development there needs to be a clear plan and a clear vision in order. Because the Waterfall method requires upfront, extensive planning, you can launch software fairly quickly. You can also estimate timetables and budgets more accurately, which definitely tends to please clients.

Furthermore, Waterfall development processes tend to be more secure because they are so plan oriented. For example, if a designer drops out of the project it isn’t a huge problem, as the Waterfall method requires extensive planning and documentation. A new designer can easily take the old designer’s place, following the development plan without a problem.

AGILE : The Cons

Though highly flexible, Agile simply doesn’t have the structure that the Waterfall method has and this does present some drawbacks. Agile projects tend to be hard to predict, from timelines to budgets. Without a concrete plan, everything remains a bit vague and nebulous.

In addition, as previously discussed, active user involvement and intense collaboration are required throughout the Agile process. This can prove highly problematic for a number of reasons. First of all, this method of development can be quite time consuming, much more time consuming than the Waterfall method. And, it means that designers need to be committed for the duration of the project. If a designer leaves in the midst of a Waterfall method development project, it likely won’t be too big of a deal as the project is plan based. In the case of the Agile method, however, development is much more person based. Having a person drop out of the project could prove catastrophic.

WATERFALL:  The Cons

The Waterfall method is incredibly rigid and inflexible. Altering the project design at any stage in the project can be a total nightmare and once a stage has been completed, it is nearly impossible to make changes to it. So, if you’re planning to use Waterfall, you will need to gather all of the requirements upfront. In addition, the problem with the Waterfall method is that feedback and testing are deferred until very late into the project. So if there is a problem, it is very difficult to respond to it, requiring a substantial amount of time, effort, and sometimes money.

So, What’s Better?

When it comes down to it, neither the Agile method nor the Waterfall method is inherently better than the other. That being said, each method does have its uses. Waterfall tends to be best for static projects, where it’s not likely that many changes will be made throughout the development process. In contrast, Agile tends to be a better option for smaller projects where changes are likely to be made during the design process. Though, keep in mind that these are just rough guidelines and suggestions. Really, when it comes to choosing a method there is not a right or wrong choice. You just need to understand which method is better suited to your project and your needs

 

Waterfall-Vs-Agile