Being late happens, even to the best projects. And when it happens, you need
to deal with it. The longer you ignore a delay, the higher the chances of the
delay growing longer.

So how do you deal with a task being late in your project? Or the project
itself being late?

Oh my god Oh my god Oh my god Oh my god Oh my god Oh my god

Panic. Run around in circles. Feel really bad about it.

Does it make the delay better? It at all, it makes things worse. There is
nothing to gain from panicking about a delay.  

It's not my fault 

Trying to avoid the blame maybe understandable, I fail to see how it gets
you on the track to being on time. Would it be worse if it was your fault? At
least you could do something about it!

It's [insert name]'s fault

While the blame game is an all-time favorite, here again I fail to
see how that helps the project. Pointing fingers takes time and if you're late,
you can't afford to waste time focusing on who messed up.

Why it's […]

I am currently filling out an RFP for a potential customer. It's not the
first RFP we've received. While some people and organizations will shop by instinct
and choose the project management tool that feels right, others will try to gather
as much information as they can on those tools. In the end, I wonder if there's
a difference in the proportion of unhappy customers between the methods.

The RFP I am filling out now is by far the most detailed I've ever received
for AceProject. It contains questions about Websystems' business philosophy and
background. It contains questions about the project management system, and it
contains a very detailed list of features, where we must answer whether
AceProject supports or includes such a feature.

On the one hand, it's a great tool for us to understand what our customers
want. On the other hand, I am starting to feel overwhelmed by the amount of
information that is requested of me. I'm wondering if trying out AceProject
would not be a more efficient way of knowing if it's the right project
management tool for the organizations. And […]

When you are shopping for a product, do you like that it's available off the shelf, requires very little configuration, and works right away? Or do you like to tinker with the product until it works just right?

At Websystems, while most of our customer are using AceProject standard, we see a growing trend towards having some customization. For a lot of our clients, customizing AceProject includes putting their own logo instead of AceProject, and choosing a color scheme that is closer to their corporate image.

The thing is, everyone has their own way to managing projects. Everyone needs to track specific data. Some teams like to keep statistics on how long it takes to complete a project. Some teams like to track how many hours a specific piece of equipment is in use. Some managers want to know who hasn't filled out their time sheets for last week. Some managers like to know what constraints their projects are experiencing. 

Most of the time, AceProject can work for those teams as it is. Sometimes, […]

Not, it's not how much fudge you can cram in yourself before you start feeling icky (although I wish!).

The fudge ratio, as explained in this post from LifeHacker, reflects how good you are as estimating the time required to accomplish something. To get your fudge ratio, you must compare your time estimates with your actual times.

Here's an example:

• You estimate it will take 1 hour to implement changes to the company's website. It turns out Murphy had his way and it took you 2 hours to implement the changes, meaning 200% of the estimated time.
• You estimate it will take 2 hours to correct a database query, but you found the error faster than you though you would and it only took 30 minutes to fix it. In this case, your actual time is 25% of the estimated time.
• You estimate it will take 5 hours to design a new application logo, but you forgot about the approval process and it ended up taking 8 hours, 160% of the estimated time.

If you keep tracking estimate […]

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 […]