Posts tagged Project Management
Negotiation – Lessons Learned
Dec 15th
There were four key lessons that I learned from several interest based negotiations that I have undertaken in the last year. The following will either improve the outcomes for you or lessened the risk of not achieving a win-win:
1) An often overlooked aspect is that of timing. You should allow ample time to complete the negotiations. A relationship must be established in most cases before any long term negotiations can take place. Your negotiating partner must understand what to expect of you. Not doing this could be very detrimental to the exact long-term relationship that you are trying to protect and nurture. Pushing for an outcome with short notice, can also negatively effect on your reputation.
2) Making your BATNA (best alternative to a negotiated agreement) stronger in advance, for example by confirming and bettering your options, will improve your confidence in the negotiations. If you do this, you will have the confidence and objective criteria to ask for more – within reason.
3) On a personal note, it is important to separate rational choice from your personal predisposition. You must not only be able to control the display of negative emotions to your negotiation partners but when matters are highly personal you must also try to minimize the role of your personality and predisposition. Increased separation of your emotions will make the whole experience far less stressful for you. This is not an easy task, but well worth the effort.
4) Above all else, the power of preparation in negotiation can not be overemphasized. The time and effort spent obtaining information on and analyzing the interests, style and BATNA of the other parties are always well spent. If you do not do this, you will go into the negotiations blind which may result in positional bargaining instead of interest based negotiation. A great book to read on the subject is “Getting to Yes”.
Software Development Project Requirements
Dec 15th
An interesting study titled “Requirements Engineering and Software Project Success: An Industrial Survey in Australia and the U.S” ( click here to read the pdf version ) looks at 400 projects in the U.S., Australia, and Chile.
While most of the findings can be shrugged off as “to be expected”, the study reveals some interesting, maybe even surprising facts:
The Surprises (Are They Really?)
- Most projects that had no schedule were successful
- Requirements are needed for project success, but not necessarily early in the project
- Projects often continue successfully for some time with unclear requirements
- The choice of requirements methodology does not matter; UML was “no help”
- Using a development methodology was a success factor, especially when it was “appropriate to the application”
- Very few projects use risk management, and those that do rarely manage those risks
- Post mortem reviews are rarely held, and when they are it is almost always on successful projects
- In the U.S. (but not elsewhere), developers are involved in project estimation only when there are poor requirements (Verner speculated that this is because the powers that be were looking for someone to blame!)
The Predictables
- Success comes from a culture that investigates and deals with problems
- The vision for the project (its business goals) must be shared among all project personnel, especially the project manager
- Project managers should be involved in the estimation activity
- Project managers should be good at customer and developer communication; they need not be good at the technology
The study also provided some interesting numbers:
- 60% of organizations have no process to measure benefits
- 86% of projects had a business case, but 60% ignored it
- 33% of projects said they had no risks, but 62% of those failed
- 49% or organizations have had (one or more) project failures
- In one-third of the projects, the project manager had no say in schedule/budget targets
- 75% of projects were underestimated, none were overestimated
- 5% of projects had no project manager; 16% changed project manager at least once (and that was correlated with project failure)
The study also asked developers what they would call a “successful project”:
- They had a sense they had delivered a quality product
- They had a sense of achievement
- They had enough independence to work creatively
- The requirements were met and the system worked as intended