Negotiation skills for project managers


An absolutely key skill that no project manager can go out without is basic negotiation skills.
From achieving consensus among stakeholders to getting the right procurement contract and managing exceptions, the one thing you absolutely MUST HAVE is the ability to negotiate effectively.

Here’s a few golden rules to help you negotiate more effectively whatever your position may be:

  • 1. Always aim to start and end your negotiation procedure on a high note. Be positive going in and be positive when you walk away from it, whether it is an adjournment for another day or the final handshake time. What I mean by leaving on a high note is that everyone should feel that they have achieved something, even if they worked hard for it and that they could comfortably return to do business with you again.
  • 2. Create a terms of reference at the outset. This will often be a fairly low key statement that frames the negotiations as opposed to a formal written invitation, but one way or another it is important that everyone knows what is at stake and why they are doing it.
  • 3. Decide in advance what your walk away scenario is, and what you want out of it and make sure the negotiating team are all clear on this. Place nobody on the team who might have any reservations about your goals.
  • 4. Research the other side and gather every scrap of useful information that might help you to understand their goals and to predict their walk away positions.
  • 5. Decide your beginning position and bear in mind that this will have a substantial impact on the outcome. E.G. In a sale negotiation it is proven that the higher price at which you begin the higher price you will reach agreement at. It is also useful to recognise that too high a starting point may prevent the negotiations beginning.
  • 6. If possible retain a refer to authority that allows you to take time out before deciding.
  • 7. Drink water twenty minutes before beginning, it is believed to make you concentrate better.
  • 8. Listen attentively to the other side, question every point and every request until it is crystal clear before making any attempt to respond to it.
  • 9. If you reach a situation at any point where you are not able to get agreement, set that point aside to return to later and move on with matters that are easier to agree.
  • a. Return to the set aside points when the negotiations are in a positive mood after a number of easy agreements and a lot of progress has been made, it should be easier then to reach agreement.
  • 10. Aim to reach a final situation where both sides feel that have won. If you can’t do that then keep on negotiating till you reach a position that fits your starting criteria.
  • 11. Be wary of making it personal, stick to your stated goals and avoid being baited, or finding yourself in competition with other individuals, it’s all about reaching an acceptable agreement.


Reblog this post [with Zemanta]

Motivating people for project managers

Diagram of a :en:matrix organisation

Image via Wikipedia


Outside of the area of direct sales and many would argue to include that too, there has been a momentous movement away from good old fashioned man management techniques. (please read Man to mean both genders, this is an old term well worth revisiting).

Some blame Matrix management, others blame the growing influence of HR for disenfranchising managers, I blame managers for simply being lazy and blind to the blatantly obvious. I also blame the prevalence of methodology and process as a substitute for management skills rather than a supporting platform.  Managers who used to read “the one minute manager” on the train are now reading “Idiot’s guide to the latest Microsoft gadget”

As we moved from a blue collar workforce to a white collar one, the importance of personal motivation as a factor in performance has become more and more important.

As project managers, we take responsibility for a very important part of the organisation’s future and in doing so we become the spearhead and leader of select group of people deemed sufficiently knowledgeable and capable to help us make it happen. More often than not, these are the future stars of the organisation. Our job as project managers is to lead them. To do this, we will need to demonstrate ability, skills and personal motivation and we will need to respect and understand the factors that motivate the people we are tasked with leading.

Since this is a blog rather than a book, a detailed discussion is outside of it’s scope, so I will leave you with one big idea to begin with.
“With the possible exception of your mother, nobody will ever do anything for you, they will do it for themselves. The key therefore to getting others to do what you want done is to understand what would make them want to do it.”

If you really believe that you can substitute the fear card for motivation you are simply delusional, even basic humping and carrying can’t be managed this way alone for any length of time and that outpuut is clearly and easily measurable, unlike intellectual products.

Abraham Maslow introduced his theory of human motivation in 1943

 Maslow Hierarchy of needsIn this simple, but profoundly valuable theory, he explained how human motivations are built on each other and how each individual is striving for the level directly above the one they are at. It’s a simple concept and sufficient to understand the basics and begin to probe and understand the motivational needs of your people.

If John has no home he is very unhappy, but as soon as he gets one, he starts to be motivated by making it secure for next year and thereafter. When John has no friends he is concerned about making some, but no sooner has he done that than he wants to be friends with people that will make him look better.

Getting to know people in informal ways reveals things about them and this informal knowledge builds up an instinctive feel for what will motivate them.

The first time I used Maslow to advantage, I was in charge of a sales-force with shrinking sales in the face of a gripping recession. It was a vicious circle, they were de-motivated by recession and hence their performance fell just when it needed to rise. I was told to make cuts and not given much time to do it in. I responded by increasing their salary and removing their bonuses for all but the highest performances.
That may sound contra to every instinct, but it worked incredibly well. When I took away the fear about meeting the spiralling mortgage, they were motivated again.  Just as Maslov had told me, they were not really that motivated by the size of the pay cheque, but I got more mileage out of a few certificates and trinkets and exculsive clubs for high performers.  It worked and it did me no harm either.

Project management is not just about fiddling with Gantts and looking for inspiration, it is about getting off your seat, getting to know people and helping them to help you through helping themselves.

 Further reading

If you found Maslow useful, you may want to do some searches on Hetzberg Motivation-Hygiene theory


Reblog this post [with Zemanta]

Project kickoff – don’t miss an opportunity

The project concept has outgrown it’s initial purpose to become pervasive in all areas of business and government.
This blog is relevant to all projects, but especially to those traditional ones that are created with a new team to deliver a specific project outcome such as a business change.

The challenges faced by Projects

The challenges faced by Projects are immense and not srprisingly, they represent the same issues that lead to the inception of the project as a model, namely:

  1. The shop must stay open while the improvements are made.  I.E. key people can’t desert their posts, so someone needs to come in to lead it.
  2. The project has to have the ability to make decisions and move forward independently if it’s not to grind to a halt..
  3. It must have its own clear structure of reports, responsibilities and consults, separate from the organisation.
  4. It must overcome the tricky and time consuming challenge of forming a new team and getting it up to peak production.
  5. It must coordinate and arbitrate different egos and personalities to work in a new structure.
    It must communicate effectively as an entity
  6. It must deal effectively with sometimes fraught corporate change environments
  7. In order to achieve even a pass mark in these seven key areas, it is vital that a project team is built and structured to support these functions and that the structure is strong, well designed and policed sufficiently until it is functioning efficiently.

If you are not in the habit of producing and agreeing a project structure document up front, then embracing this simple idea will move your project management performance up to a whole new level.
if you are able to go the next level you will not only end up with a sold structure that is sufficient and functional, you will make sure that the right roles are created, the right people are chosen for each role and the new team is quickly marched through the complex process of Forming, Norming, Storming and Reforming.

Project kick-off is almost indispensible

if you have been following my series on Project management, you will no doubt be aware that we place considerable importance on setting up the project correctly with the right structure and the right people. 
The last and very important lap in kicking off a high performance project is team building.

 When I started in this field in Ireland 20 years ago, we had a uniquely Celtic way of doing the job. we took everyone away for a working weekend in a great hotel, We did a two hour stint on Saturday and the rest, the important bit was drinking too much revealing too much about yourself, making friends and building relationships.  Today we hire coaches to set up special activities that are more politically correct and if they are good, they achieve the same things.

Get their attention

I am a great believer in taking the team off site for a few days. Left onsite people will continue to do the day job and they will not engage with your project or your team.
The people who want to remain aloof are the very ones you most need to keep focused and to do this you need to remove all their other toys long enough to get through to them.

Get them interested

A vectorized image of project dimensions.

Image via Wikipedia

The second thing you need t do is to demonstrate to them the business case for your project and have a business sponsor make it very clear to everyone just how important the project is to him/her. This last bit is so important I am almost tempted to repeat it. If you don’t get strong verbal and moral support from the business, you may as well throw your hat at it right now.
The third thing you need to do is to paint a little detail around the vision and make more real or concrete. To do this you need to find ways of demonstrating what wil be different when the project has been completed and how it will effect each of the stakeholders present and the organisation in general. This is ideally an expansion of the business case put forward earlier, but with more detail to fill in the how rather than just the why. Models, diagrams, prototypes and individual contributions form affected stakeholder are all effective tools for bringing the vision to life.

Get them involved

 Project Management Plan

The fourth thing you need to achieve is to make it personal for each member of the team. It is all too easy to play around with concepts and pass comments on them without ever considering them as reality. Like furniture ordered from the internet, It is only when the postman delivers it that you are forced to unpack it and start considering where it will sit i your life and how you will live with it. This is the time you want your people to consider these issues so that when you call on them to do their bit, they are able and willing to deliver.
A simple and effective technique to help with achieving this is to hold joint planning sessions with the entire team whereby they nominate the high level tasks, point out dependencies  and highlight the risks,  issues and assumptions.
It doesn’t matter if you already have a plan that you think is great, I would strongly recommend binning that plan and starting again because of the extra value you can get from this process.
Joint planning is the first time the team work together and it is the first demonstration of who knows what, who does what and where the tensions may exist.
After the first session you can visit individuals and discuss the issues if you feel that things need to change a little in order to keep the peace.
In addition to territorial issues, the process also forces people to consider these commitments alongside of their existing ones and to consider the amount of time and effort required of them and surface any conflicts early on.
The last element of joint planning, but by no means the least, is to discover the areas where the team members depend on each other for knowledge support or assistance of any kind and begin to break down the barriers and start off this process of team building.

Define some real actions

If you are to reap the true benefits of the work you have done so far, you simply MUST get positive proof of your success by way of actions accepted and completed by the team. These actions will deliver preliminary products of almost any nature, but what they will do is
a). They will set the scene for accepting and completing actions on time
b). The actions will be chosen to involve small groups and pairings that begin the process of forming partnerships within the team.

The outcomes of a project kick-off meeting

  • A strong sense of common purpose built on a clear shared vision and sound communication and sponsorship.
  • A well defined and understood project structure that has been explored and proved itself viable.
  • A clear vision of the work to be done the issues and risks and the critical success factors.
  • A high level plan that is commonly owned and understood along with risk, issue and assumptions logs.
  • Initial tasks completed and a team that are comfortable to work together towards the common goal
Reblog this post [with Zemanta]

Why no project should exist in isolation and what needs to be done

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

How requirements language can contribute to the solution

The very thing that brought about the project as a business entity can also be it’s worst enemy, especially when it comes to technology. The project isolates the goal from the rest of the business by providing it’s own governance and budget and treating like a mini company with a project board in place of the board and a Project manager in place of the CEO. The stakeholders take the role of shareholders and the sponsor that of Chairman.
Project structure is necessary in order to get important tasks completed quickly without having to fall in line with all of the political and process barriers that would otherwise smother it. The problem however is that this isolation often leads to forgetting to ask simple sensible questions like ; “Do we have something already that can do this?”.

I once was engaged by a large public sector organisation to look for a solution to their string of failed web projects. In the course of initial investigations I discovered that they had no less than 6 content management systems any one of which could have provided for all 100 plus websites that they managed. Each project had been considered in isolation and nobody had considered whether more software was needed.

How requirements language could have solved this problem.

The reason things happened the way they did is that nobody said “We need to deliver our messages 24/7 on demand”.
Nobody said “We need a way to encourage feedback from our audience” etc etc.

Nobody said “we need John to be able to publish stuff instantly and get it reviewed and in front of our customers within 30 minutes”.
The reason nobody said these things is because nobody asked them, or at least nobody asked them the right questions, or asked them in the right way.

Here’s how it works best.

The Business person says: “ I need to influence the market to purchase more of our products”
Here we have a business requirement/business problem/probortunity. The terms you choose depend on your viewpoint. In this example it could any of the three. The key is that this is the goal which kicks off the business case and which is ultimately measured in the KPIs you define for benefits realisation.

The Business Analyst then adds some deeper definition like ballpark estimates at timescales, size of increase and other key constraints.

The Business Analyst then speaks with Marketing people who tell him:

“We need to reach these segments.
We need to deliver these messages, we need to make these things available at these points in the buying cycle on a 24/7 basis.
We need to encourage them to approach us in these ways.”

Business analyst then brainstorms with technical people, designers marketers and everyone with a stake and they decide on a high level plan of how this goal can best be achieved.

At this point we have high level requirements. I prefer to refer to them as high level process requirements just in case anyone starts designing systems yet, but they have not developed beyond business requirements and are dealing with “how” rather than with “what” we want to achieve.

The Business analyst then draws use cases from these requirements that provide some detail on the everyday activities of users and the systems they need in order to support them. He/she does this iteratively, continuously checking back with business stakeholders until he/she has a clear understanding of everyone’s role and what they will need to achieve/do (use cases) in order to deliver on the high level requirements.

The Business analyst gathers high level costs and timescales and organises a scoping session when the team make a first draft at deciding how much of this they can afford and which bits will give the best returns for lowest risk.

Verifying the detail behind the more complex use cases is beyond the scope of this blog, yet it is critical to at least acknowledge that this verification must be done to bring time, place, and sequence to these simple use cases and to get an understanding of the processes required and how they differ from, or add to, those which exist and equally importantly, how they can reuse existing processes.

At this point the business analyst converts the use cases, business rules, models and scribbles into a formal set of requirements written down in a straightforward requirements language and taking great care not to define the solution at this point, simply to define the requirements so that a technical team can decide how best to meet these requirements technically, while taking into account the tools they already have.

The rules for writing good requirements

Below is a simple list of 10 rules that you can use to test your requirements once you have written them.

Value – Traces directly back to a business requirement in the business case, i.e. it adds value
Clarity – Give it some thought, be aware of your audience and don’t use three words where two will get the job done. Above all don’t use jargon including company jargon and if it is absolutely necessary to use technical terms add an explanatory footnote.
Design Free – This is by far the most important rule. Don’t even hint at the design. Stick strictly to outcomes. How it is delivered is down to the specification.
Achievable – There’s no point in asking for things that can’t be done technically, are beyond the budget, or are not going to be accepted in the user culture. This last part has been the downfall of many CRM implementations. If the culture is not ready, then don’t do it yet.
Complete – The requirement must give the reader sufficient information to work form the document without your standing beside him/her.
Consistent – Language and style always depends on individuals, the most critical thing is to be consistent so that the reader can learn your style and be confident in understanding your meanings.
Unambiguous– Don’t be woolly and don’t be coward. Spell it out clearly. Words like nice, fast good have no place in requirements. Define what will be nice or fast or good and make it measurable.
Verifiable – Assume that you will also have to write the test cases and test scripts and ask yourself how you will test this requirement. If the requirement doesn’t give enough information for this , then it is not verifiable and not complete.
Atomic – Take your requirement down to the smallest unit you can. Always ask, could this be broken into two requirements. If the answer is yes, do it.
User experience – This one applies mostly to products, but increasingly it is important in business change scenarios. Ultimately your user will feel an emotion or reaction when using your product. This the ultimate test for your product, the one where it wins or loses. This is where you describe the reaction you are trying to produce.

The last and very important step in requirements definition

Now that you have a requirements list, and assuming that all the context of this project has been communicated to the recipient of your list, the next step is to take this list to your supplier.

Regardless of whether the supplier sits at the next desk or is Microsoft Corporation, the same rules apply.

Add an extra 5 empty columns to your requirements list with the following headings: OTB (Out of the box), CON (Configurable), CU (Customisation required) New (New feature needed) note (Here they enter the number of any footnote they need to include.

My personal preference is to ask for ballpark time, cost and risk estimates alongside of any new code or customisations

This simple exercise will give you an immediate heads up on how much new code, new systems and other effort, risk and expense will be involved and it will take you one step closer to defining the final scope of your project and/or choosing the best supplier.

Today we talked about the issues of language and viewpoint when setting out to define system requirements and we defined the Ten Commandments of writing good requirements.

We did however gloss over a very complex and important area in terms of exploring, defining and verifying process, rules and business rules in order to write requirements that you can feel confident about.

Reblog this post [with Zemanta]