Project Management
Time Management Tip #1 – Get to Know the Enemy
Jan 12th
On frequent request from both participants and people interested in our Time Management courses (http://www.simplyefficient.ca/training.php) , we will publish handy Time Management tips and tricks.
In the first installment of this miniseries, we will start at the basics. There are some fact we cannot change, like: There are always only 24 hours in a day. That’s a constant, no matter how organized we are, all we can actually manage is ourselves and what we do with the time that we have.
In order to do so, the very first thing we have to do is find out where and how we are spending our time. It’s like driving a car: If you want to find the best route to a better place, knowing where you are now is just as important than knowing where you want to end up! One additional result the following exercise is to give us a benchmark we can measure our progress against.
So how do we actually spend our time? We all wear many hats during the day (and sometimes at night, too). But what does this mean? What tasks are we actually performing and how much time do we spend on each activity?
For the following week, I invite you to find out by tracking your daily activities lets you see where your valuable time is being spent, and gives you the data you need to set goals and make the changes to your work habits that will make you more successful.
Our goal is to get a 24h coverage – without any gaps – of a “normal” week of your life. Don’t distinguish between business and personal activities at this point. You need to have a complete picture of your schedule so you can more easily see where to make the changes that will make you more successful.
Daily Activity Tracking Tips
Use a device to record your daily activities that is constantly accessible to you, so you can record exactly what you do when you do it. Memory is fallible – and kind.
A Day-Timer or calendar, a PDA, an organizer software program, a digital recorder, or an ordinary notebook will all work to record your daily activities; choose whichever method you are already comfortable with and find the easiest to use.
Don’t record unnecessary information; it’s the activity and the time you spent on it that’s important for our purposes. For example, in the morning, we only need to record “get ready for work” followed by the start and end time.
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