In project management, it's easy to confuse urgent with important. When something is urgent, it's usually assumed it must be important. No true. The fact that a specific report is needed in five minutes for the board meeting does not necessarily need it's important. Maybe the meeting can go on without the report.

Since the word urgent makes everyone run a little faster, its vulnerability to abuse – as we discussed already – requires more scrutiny. 

When dealing with an emergency, one should answer the following questions:

• Can the project work around it?
• Can the project be completed without it?

 If the task can be late and not affect other tasks immediately, then it is not urgent, even though it could be important. Also, is the project can live without that task being completed at all, it's not even important. However, if the task both stops the project dead in its tracks and is required for completion, then it's both urgent and important.

Better get right to it, then 🙂 

It's part of my job at Websystems to reply to email enquiries about AceProject. I get asked all sorts of questions, from pricing to features to integration with external systems (via CSV files). I enjoy replying to these emails because they give me a good idea of what our clients are looking for in a project management system. I try to reply to all email within one business day, usually faster. 

Every once in a while, I'll receive an email with the red question mark (!), or URGENT in the subject line. Obviously, I'll look at those emails first, in case there is an actual emergency with this client. Most of the time, there isn't. The sender simply thought she would get a faster response by labeling her message as urgent. She did succeed in grabbing my attention. However, a request for our pricing hardly qualifies as urgent, especially considering that the information is actually available on our web site. Often, once I've replied to those "urgent" emails, […]

Do you consider customer service a "cost of doing business?"

In your organization, is sales at the top of the food chain, and customer service at the bottom? 

How's that working for you?

The sales team will talk to your client up and until the initial sale is made. Afterwards, the most contacts your client will have will be with your customer service and technical support teams.  Once someone is your client, the 'cost' of getting more business from them is much smaller than the initial sale. Your customer service team can make this sale. In fact, since their position is one to help the client, it's even easier for them to upsell that client.

Your customer service and technical support should be treated as heroes. Their job is to save clients from their problems and to improve your company's image in their minds. If your customer service teams feel empowered and valuable to the organization, they will do a much better job winning back unhappy clients and upselling the happy ones.

Investing in customer service pays off […]

Tomorrow, June 24th, is Quebec National Day. This made me reflect on what it means for Websystems to be Québécois. 

Websystems is located in Quebec City, Canada. The province of Quebec has a predominantly French-speaking population. Imagine this: we are 6 million people who speak French in North American, surrounded by about 300 million people who speak English.

Some would like to see our situation (linguistically, geographically and culturally) as dire. Some would see it as a disadvantage over our neighbors.

I disagree. I believe being a small company in a small society or French-speaking people, in a sea of English-speaking people, is good. Here's why:

It forces us to stand out: Being different helps us not be just like the next project management solution.

It forces us to take ownership of who you are: We're Quebecois. There is no way around it. We chose to use it to our advantage, Quebecois and Canadians in general have a very good reputation worldwide.

It forces us to set the bar high: Being a small company, the project management industry is huge […]

Before you join a project, before you even start planning it, it's important to take a moment to make sure it's worth the effort you're about to put into it.

What is the goal of the project?

Is the goal of this project clear? Do you know what your deliverables are? Are the requirements for the project spelled out and agreed upon by all involved?

If the goal, the deliverables and the requirements are not clear yet, the project is not ready. If you start something with a foggy idea of what needs to be done, that project already has serious problems.

Can it be done?

Are the goals, deliverables and requirements even attainable? If you cannot be convinced, in your heart, that you can pull it off, you should not take on the project. If you can't believe in the project, it's not use working on it: you've already set yourself up for failure.

Does the organization really need that project?     

Is this a single-client, once-in-a-lifetime project? Is it vital for […]

While it's old news in Europe, happiness at
work is only slowly making its way into North American management values. I
recommend you visit the Chief Happiness Officer to learn
more about happiness at work.

At the project management level, it's time we let go of the myth of performing
under pressure and recognize the boost in productivity that happy people bring
to their projects.

From happy to unhappy in one short year

I remember a place I worked at a few years back. When I joined the team,
everyone was happy at their jobs. They felt that their boss was treating them
well, they enjoyed the team they worked with, and they felt their work had
value. The Christmas party that year was great: people proposed honest toasts
to the bosses, and the bosses in return expressed heartfelt gratitude and pride
in their team. All in all, projects were coming along quite nicely, deliveries
were made on time and that was a very cool workplace to come to every weekday.

The following year, however, things changed. The company got a few big
contracts. We were a […]

Advertising is an effective way to spread information. It gives you (the
advertiser) control over what message you want to send. It also gives you
control over who receives your message. One advertisement can reach thousands
of people, way more effective than talking to each one of these persons personally.

In your organization, who know about your project? Do you and your team
sometimes feel like no knows or even cares about your project – that is, unless
it's late or it's having problems? Do you sometimes feel like the person in the
office next to you has no idea what you're working on?

Often, these situations are caused by the fact that everyone reports up the
chain of command, but there is not process for communicating with your peers.
Taking time to tell your colleagues about your project can be seen as a waste
of time – you could be working on your project instead of just talking. 

However, who else but your peers can understand what you are working on, the
challenges you are meeting head-on and the feeling of accomplishment when you
finally fix that bug […]

Here at Websystems, we are starting to feel the summer groove coming on: we
are seeing more and more vacation automated replies to emails. More than that,
it seems the summer season puts people in a different mood: happier and
mellower. It makes our jobs that much nicer, which is always appreciated 🙂

This reminded me of scheduling and summer vacations. In North America and Europe, most of us will take a few weeks of vacation time
in the summer. From a project scheduling perspective, this can have heavy
consequences on delivery times. With most of the team off work, things will not
get done as quickly as they would in the summer. When assigning tasks to your
team, it should be taken into account, especially with time-sensitive tasks.

One way to keep track of everyone's vacation would be
to create a project called "Vacation Dates" and let everyone create a
task for their vacations, with 8 hours of estimated time per day of vacation.

This way, the person would show up at completely booked on the workload report.

The quality of the leader will influence how the team can pick itself up
from a misstep and go on. Regardless of the event, how one reacts to it makes a
big difference on the consequences it will have.

Bad things happen to good projects.  When something happens, the
project manager's reaction will guide how the team will feel about it.

• If the project manager
  panics, everyone on the team will feel that panic. This will affect how
  everyone works. Panic rarely makes people better.
• If the project manager
  remains calm and focuses on the solutions to the problem, she will take
  everyone's mind off the problem and thinking constructively.

As a project manager, we must remember that our team is looking to us for
clues on how to behave in the team. Respectful managers will encourage
respectful behavior in their teams.

It's a good idea to think about how you want your team to behave, and then
set out to show them how it's done.

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