When planning a project, we usually try to schedule tasks from memory, trying to fit dates. And then, when something new has to be done and we try to fit it in the schedule.

Gantt charts are not just a great way to report on the advancement of a project. They're a great planning tool. You can instantly see if there is a whole in someone's schedule to add a task.

Visualize workload

Just make a Gantt chart that shows someone's workload, across all projects.

Maybe you would prefer to see it sorted by date, instead of by project? It certainly looks cleaner this way:

With a chart like that, you instantly know if you can fit something else in Jane's schedule. In this example, we can see that Jane has some free time towards the end of this week, and in the week of June 8.

Create a project visually

Or, when setting up a new project, work directly from the Gantt chart. When you add tasks directly form […]

Today is Memorial Day in the USA. In Canada, the May holiday was Victoria Day, on May 19th.

Since a good part of our business is done with organizations outside of Canada, we have
to pay attention to holidays happening in other countries. This means a slower
day today, but it also meant someone needed to field the phones last Monday,
even though it was Victoria Day.

As the planet grows smaller and project teams can easily spread across
continents, it's becoming increasingly difficult to manage people the
traditional way. For the team to work well, one cannot assume everyone knows
most people don't work today in the USA, while in the rest of the
world, it's business as usual. While there might be a danger to loose one's
culture and individuality in the globalization, I think there is another way to
see this.

It's not loosing one's identity, but rather enriching one's world, gaining
different ways of seeing things and getting things done.  Managing across
cultures requires openness from all parties. This is harder than it looks. It's
no fun being the one […]

It's easy to say you trust someone. It's harder to put it into practice.

Let's say to assign a task to someone on your team. When the teammate flags that task as complete, do you trust her to have completed it, or do you go behind her back and check it? 

While there are tasks that should be double-checked (after all, this is why there is code review and sofware testing!), many tasks do not require to be rechecked after they are completed. Trusting your team means taking the risk that, once in a while, a task will need to be reopened. This is the price of empowering your team.

Jason from 37signals made a very good point in this post: "When you trust people to make a reasonable decision, they’ll usually
make one. When you require everything someone writes to go through an
approval process they’ll probably write less and be less interesting.
We don’t want people to be afraid to write or afraid to think."

The question is: can you afford not to trust […]

What does it take for your customers to love you? A great product? Great service?

We can go further and ask: do you want all your customers to love you? Without exception? How much are you willing to do get that result? It would take a lot of effort for all your customers to love you. Even if you have the best product and the best service, there would still be customers who would not love you.

I prefer to see things differently: make a product you love to use and like-minded customers will love you.

There is just too much diversity in this world to aim for 100% love from all your customers. Furthermore, setting unrealistic goals online breeds failures. And while one failure can be cathartic and motivating for a team, multiple failures are just demoralizing. 

How much energy are you willing to spend to make your customers love you?

I read an excellent post from
Guy Kawasaki's blog, How to change the world. The post was an interview with
Jerry White, the co-founder of Survivor Corps. 
The interview focused on the art of survival. How do you go on after a tragedy,
how do you move away from that event?

It made me think about the aura that failure can give you. When you project
fails, you can surrender to the failure or move on, determined to make the next
project a success. You can also choose to become a victim of that failure, a
let it taint the next project with defeatism.

So, let's apply Jerry's recipe for surviving a failed project. 

Face facts.

The project has failed. There is nothing that can be done about it now.
Don't try to blame circumstances or other people or anything that takes the
failure away from you. You may not be the sole architect of that failure, but
finding reasons to escape responsibility is not the way to go.

Choose life, not death.

Jerry talks about creating options for a positive future. […]

I was reading this excellent post about being taken seriously and it made me realize how important it was to product management. The first element of David's post is about telling people what you have done instead of what you will do. It seems like common sense at first, but how many times have you talked about your product's future features? How great it is going to be?

What about now?

Your product should be great already. If it's sucessful now, it's because of what it is in the present, and not because of what it may become in the future.

I have too often seen sales people become caught up in the future of the product, and selling the product's next version instead of selling the product's current version. In a situation like this, the only thing that can happen is a sales rep who has to go back to the client and recant her promises. She will look bad to the client, and the company's image will also suffer.

Mind you, this is […]

PITA is for pain in the a**. People who are PITAs really put a dent in any
project.

How can you detect a PITA?

He/She focuses only on the negative aspects of the projects. What's going
wrong, what's late, what hasn't been done correctly, etc. However, the PITA is
not interested in solving those problems. All the PITA is interested in is to
whine about the problem, and possibly blame somebody or something.

A PITA also tries to get attention like children do: by throwing tantrums,
bullying and manipulating others around him or her.

When you habe a PITA in your team, it can be a weight on everybody's
shoulders. It can significantly impair the project's progress.

How do you deal with the PITAs in your project team?

You must remember that PITAs are trying to get energy from you. Their
screaming and crises and drama and blaming are all about getting people to feel
sorry for them or agree with them or follow them in their blaming mission. As
long as you're playing along, you're encouraging this behavior from your PITA.

Now, if the PITA is the project manager, […]

When working on a project, do you try to think about what could go wrong or do you wait for the problem to manifest itself before fixing it?

When looking back on your career, did you try to see or create opportunities for yourself and yor organization, or did you trust life to send you the right challenges?

When managing a product, do you try to anticipate where your users will have issues, or do you fix those issues as they are reported?

Does it have to be either/or?  

Think ahead: be proactive 

There are numerous benefits to being proactive. It avoid problems down the road. It minimizes the damages a problem could cause. It makes you, your team and your business look good. It's very trendy to be proactive. After all, it makes sense to solve the cause of potential problems before they spawn actual problems.

However, sometimes being proactive makes you spend too much energy on a potential problem which may not have the estimated impact. Sometimes, by trying to look so hard into the future, you […]