Have you ever tried to hammer a nail with the handle of a screwdriver? It doesn't take long to realize it's not going to work. It takes even less time to understand that the time you invest in buying a hammer will be gained many times over when you need to hammer nails.

Having the right tools to do a job is crucial, regardless of the job you're doing. 

When managing projects, using an Excel sheet or a Word document or even the very simple "emailing a task list to everyone" will only make your project difficult, or even impossible to manage. Manual project management forces the project manager to remember a lot of things that software solutions can automate easily.

For example, if you're doing manual project management, you'll need to remember to remind you team when tasks are getting close to their due dates. Project management systems like AceProject will do that automatically. You'll also need to follow up with your team if their tasks are late - another task that can be automated with a project management system. At the end of the week or month, you'll need to key in all the new data in your Excel/Word/Email document, and manually produce reports - which, of course, can be automated with project management tools.

It all comes down to how much time you're willing to invest in learning a new tool, compared to how much time you're willing to wasted doing things manually. 

Websystems is located in Quebec City. This year, it's the 400th anniversary of the city's foundation. While technically, Quebec City is not the oldest city in North America, it is the only one that is still there, in its original location. 

To celebrate the event, we've been having a big party since the summer began. Yesterday, we had one of the biggest events so far: the event organizers invited Paul McCartney (yes, THE Paul McCartney). The show was free. You can imagine the crowd that showed up to see this living legend. People slept in front of the gates before the park opened. about 1 person out of 3 that lives in Quebec City went to the event.

That's how much pull Paul McCartney has. How powerful his brand is.

What I found interesting about him is that he seems to have built his brand on just being himself. People like him because he is a legend in the musical realm. But he's likeable because he seems to be such a nice guy.

That can't be faked or built. 

Murphy is taking over my work day: my laptop has been turned into a brick by the very application designed to save it from becoming one, the Restore program.

My week started looking bright. I had been having problems with my laptop for a while, and I thought restoring it to factory defaults and starting over would fix a lot of issues. Conveniently, my laptop has just the application to do this, in a few clicks. So I make sure to back up all my data, get all my applications' install files and take note of my settings to make sure I could reinstall my work environment in a speedy manner.

As I arrived at work this morning, I got ready to restore my laptop. And Murphy took over.  

At first it felt like my day would be wasted. 

But wait! Some good can come out of this, I promise

It turns out that, like many failures we have to deal with, this laptop issue has a silver lining: My laptop's hard drive is now being entirely checked and reformated. Hence, I will truly get an entirely refreshed, out-of-the-box machine. It will now be up to me to keep the laptop in working order.

YOU turn the problem into a tragedy

When problems happen, how we react to them makes all the difference. If I had thrown a tantrum, my colleague would not be so willing to help me out. I would have become a pain in the neck for him. In fact, no matter how we feel about a problem, it will not change the situation or the past. My laptop is unusable. The laptop won't care how angry I get at it. It cannot be scared into working. Only me and the people around me are affected by my reactions. 

If I turn this event into an opportunity for learning or if I try to see the good side of my laptop being a brick, it changes the whole atmosphere in the office. If I can't work on my own laptop, at least I can prevent everybody else from being peeved about it, no? 

When testing a new product interface, we at Websystems have our ears out for comments that sound like "it's complicated" or "I can't figure out how to do this."

For us, when these comments are made repeatedly about a feature or a page in AceProject, it means we've made a mistake in our design. While we work hard on getting good, usable documentation for AceProject, our goal is that our users don't need to consult it when building their projects, updating their tasks, and going about their daily activities in the system. We think is filling out a time sheet should be self-evident.

Moreover, even if it's really difficult for the developer, he will work on making that feature simple and easy for the user once. The user, on the other hand, will use the feature many, many times. So it's more profitable to invest development time once, since it will save a lot of user time in the long run.

Most projects require that some tasks are accomplished in a specific order. For example, in a publicity project, the marcomm firm will want the client to approve the design before it goes to press. When the client, the representative and the printer are not in the same city, the risk of the file going to print too early can get pretty high. Ask any printing company how pleasant that is.

If you want to make sure that your client approves the design before it is sent to print, set up your client project in AceProject, and link the client approval task to the printing task with a dependency:

Once there is a dependency, you won't be able to open a task, unless the previous task is completed:

And in the Gantt chart, it's easy to see how the tasks are linked:

However, what I like most about task dependencies is how task dates are dynamically linked. For example, let's say your client is gone on vacation for two weeks and won't be able to approve the brochure. All you need to do is change the due date for the approval task and all its subsequent tasks will be moved on the schedule too. Even nicer: everyone assigned to the subsequent tasks will receive an email about the date change.

Talk about efficient!

Last year, we were contact by our local university to participate in a business development mission to India. We would sponsor a graduate student of marketing, who would go to India on our behalf. We could set any business development goals we wanted. The mission was presented as a good way to learn about this huge market and how we could adapt AceProject to increase sales in India.

We figured this was a great opportunity. After all, India is poised to become one of the biggest economies on the planet. Its growth has been above 6% every year in the last decade. This is a market where we definitely want to be.

We would learn more about India. In fact, we thought, why not actually hire someone in India to do our customer service and sales? We knew one reason why our sales are not spectacular in Asia is the time zone difference.

Hence, we tasked our representative for the mission to not meet with a project management association, explore the feasibility of hiring someone in India to work for us directly, and meet with some of our existing clients.

Before take-off: it doesn't look good

Vanessa, our representative for this mission, found challenges even before landing in India. She had a hard time contacting companies by email and phone. In order to call India during the daytime there, she would have to make her calls in the middle of the night. There were very few responses to Vanessa's emails, and the responses arrived several weeks after her sending the initial message.

We were still excited about sending Vanessa to India: it would be a great opportunity to learn about doing business in this country.

On site: we are far from home

As our representative Vanessa, wrote in her emails, India is so different from North America it's stupefying. On the practical level, even in the cities, neither electricity nor Internet access are reliable. Power outages are frequent. In office buildings, they may have generators and be able to maintain power during the outages. Still, the availability of the Internet cannot be relied upon. This would make hiring someone to work from home pretty much impossible.

Hiring someone from a call center would seem like a better option, but with a 30% turnover rate, it would mean having someone new every few month, and we would spend too much time training the person, only to see her move one to another company and have to start over (again).

Moreover, in India, social contact is very important. It's important to meet a representative for the product they want to buy. It's important to them to develop a relationship with their suppliers. Connections and contacts play a very important role in the way business is conducted. For us being so far away, it makes it hard to establish this type of meaningful contact with our clients in India.

Back home: next steps

If hiring someone to work at home won't work, and "renting" someone from a call center will be too unstable, what should we do? 

Our first goal is to improve our availability to our Asian customers, so that they can call someone during their normal business hours. Hiring someone closer to Asia (in Europe, for example), might be easier to manage. The time zone difference is shorter, and the work / business culture is closer to Canada's. It would seem like a good compromise.

As a project manager, we are the team's leader. It's easy to feel that we should have all the answers. 

Leadership is not knowing everything.

Leadership is knowing where to find the knowledge and the answers. It's OK to say "I don't know." It's OK to ask for help from your team. After all, the project team is there to work together with the project manager.

As a leader, admitting that you don't know will make you look more human in the eyes of your team. It will also create an opening for someone on the team to show their value by answering the question.

Saying "I don't know" creates opportunity for creativity. If I don't know how to build an interface screen, it means I have to learn how to do it, to find inspiration from good examples of interface design. This is a great opportunity to work with my team and build something new and fresh.

Not knowing can be leveraged to your advantage.

The opinion one will form of a product will be different along the life of the product. Let's take the example of software.

When you do the first installation, everything is fresh and it feels like the system work perfectly. Once you upgrade (to a new version, for example), you will see the full measure of the product's quality. When upgrading to a new version, the process should be smooth. I am not talking here about an absence of bugs in the system. What I mean is that the system should be able to take the previous version's data (configuration, preferences, etc), and fit them in the new system.

If that process is not smooth - as happened with one of the tools we use at Websystems - you loose the trust of your customers, and they will prefer to stick with the version they have, even if the upgrade brings more usability. If the hassle of the upgrade is too much, there will be an impact on subsequent sales to existing customers.

Sometimes we are so bent on closing a sale that we are tempted to ignore the needs to the clients and push our product. We are focused on the short term (closing the sale), instead of the much more profitable long-term (having a happy client).

AceProject is a great project management system. Unfortunately, it does not contain any feature ever required by a project manager. For example: AceProject does not include any financial data like hourly rates and cost-tracking. While we do plan to include a cost-tracking module in the mid-term, the current version has no dollar signs in it.

Hence, when a prospective client emails us with a requirement to track costs, we have two choices: sell AceProject with a vague promise of implementing those features at some point, or tell the client upfront that AceProject does not fulfill his requirements for cost tracking. We prefer the second option.

Who knows what the future has in store for us? The fact that we plan to implement a feature today does not mean it will be implement within the expected timeframe. If the client buys AceProject, he also buys the promise of the future feature. If we don't deliver - even for the best reasons - we've failed that client.

I would rather turn away a client that we can't help than see a disappointed client leave us.

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, I won't get a response from this person for a few days, further proof that the emergency was not real.

I've also encountered these fake emergencies in person. I had a colleague who would mask her poor time-management skills with emergencies. A rerquest for pricing (RFP) would sit on her desk for a week of more, and she would bring it to my attention only when the deadline was just a few hours away. She lived in a constant state of emergency. The problem was, when she actually had an urgent request, no one would believe her.

This ruins it for the real emergencies

How can I trust that messages marked URGENT are actually emergencies, when 90% of the messages labeled URGENT really aren't? How can I trust someone telling me something is urgent, when ALL they ever deal with is urgent?

It's the business world version of crying wolf. 

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

Anyone that interacts with customers is an investment. All customer-facing employees represent your organization in the mind of the client. How you consider them affects how they treat the client, and that affect what your client thinks of your organization.

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 and very diverse. There are very big players on our field. Aiming to make as good a product as them is the only way to make it.  

It feels good to tackle competition that's much bigger than us - and win! I always enjoy making a sale where our clients will move from a big company's product to yours - because AceProject fits theirs needs better.

To all the small companies and small societies out there, I suggest you read Seth Godin's Small is the new big.

Enjoy your difference :-)

Happy Saint-Jean-Baptiste!

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 the survival of the organization? Will it improve the organization's offering/product/opportunities significantly?

There has to be something to gain from successfully completing the project. 

Is this project profitable?

It's not just about the money. The question is, what is the organization looking to get out of that project? Is it increased revenues, increased market share, increased credibility in the market? 

Once this is figured out, you should know if this project will be profitable. You need to decide what will come out of the project is worth if the effort, time and investment required to make this project a success. It's important to get more out of the project than you will put in. 

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 small team (fewer than 50 people total in the company) and this was more work than we could handle. Everyone was asked to go the extra mile during this temporary "crunch," and most of us were happy to do it: after all, we were happy in our job, proud of our product and willing to spend more time with the great people we liked working with so much! Well, six months later, we were still in this crunch. Everyone was under a lot of pressure to deliver. Deadlines were slipping by. Everyone felt stretched. And very few people were added to our teams. We started feeling that our bosses didn't care so much about us. We started feeling overstretched. Conflicts were breeding in the teams. Soon enough, no one was willing to work late, unless they were forced to.

No one was happy at work anymore. Productivity declined. No one was interested in helping out.  And people started leaving the team.

So, how do you keep your team happy?

Keeping your project team happy is actually simple:

• Remember they are human. Programmers are people too. Keep in mind that they have emotions, likes and dislikes. You should respect them for who they are. If your start developer really hates to fix bugs, keeping him working on new code may boost the overall team's productivity. 
• Observe. It's usually easy to spot unhappy people, just watch and listen to what they have to say. When you spot someone on your project team who is negative and does not contribute to the project, chances are they are unhappy.
• React quickly. As soon as you spot an unhappy person on your team, sit down with them and try to understand why they are unhappy. If it's work-related, see with them how you can improve their morale at work. 

It's contagious

Both happiness and unhappiness at work are contagious. Keeping your project team happy will reflect positively on the project, and before long your project manager colleagues will ask you about your secret :-)