in

User Community

MAKING IT IN THE BIG WORLD OF PROJECT MANAGEMENT.

Go Ahead, Manage

The life of a small company in the great world of project management software: from marketing to product management, software development... and project management, of course.

Subscribe to this blog by Email or add it to your RSS feeds

Even better: add Go Ahead, Manage to your Technorati favorites

June 2008 - Posts

  • Urgent VS important

    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 :-) 

  • Fake emergencies ruin it for the rest of us

    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. 

  • Customer service: cost or investment?

    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.

  • Being different is good

     

    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!

    Posted Jun 23 2008, 08:31 AM by Karine with no comments
    Filed under:
  • Before it gets started

     

    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. 

  • A happy project team means better results for the project

    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 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 :-)

  • Advertising your projects

    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 you were hunting down?

    As a project manager and as a team leader, it is your responsibility to give your project visibility inside the organization. It's simply internal marketing. It can be as simple as a weekly email with a summary of what's been done and kudos to the team members for their good deeds. It can be a simply sheet tacked to the kitchen billboard. You can also make it more elaborate, with a monthly lunch event or happy hour. It really depends on the organization's culture and energy. What's important is that everyone on your department, and even the whole organization, knows what's going on with the project.

    Imagine IT taking the time to tell you about their latest server upgrades, and the challengers they overcame?  If you knew more about their day, you would understand how much work it takes to make everything run smoothly. Because they usually don't advertise about their job, they are a mysterious bunch, and it's hard to know what their day is made of. 

    The same goes with your project. Wouldn't you team feel better about the project if they felt it was important enough to be talked about by the whole organization?

  • Do you account for summer vacations?

    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.

     

    You could also print a Gantt chart of your team's vacation schedule, as a reminder.

     What's your technique?

    How do you keep track of vacation schedules and meake sure someone doesn't get scheduled to work during their vacation? 

  • 10 good things about projects

    It seems we spend a lot of time talking about the negative side of project management: why it's there, how to fix it, how to prevent it. Projects are a good thing in an organization. Here are 10 good things about projects:

    1. Projects have a beginning, a middle and an end.
      Well, they should always have! It's motivating to work towards a goal, to start and to finish things.

    2. Projects give a sense of accomplishment.
      Most projects are about building something or completing something. Whether it's a customer installation or a new software release, when the project is done, it feels like we've brought something new to the world.

    3. Projects give perspective.
      Seeing a whole project planned out in a Gantt chart will let anyone on the team understand what's ahead. Seeing the project's task list also helps cut the project in manageable chunks.

    4. Projects are great for learning.
      Each project is different, but what one learns from one project can be applied to the next. It can be time management or more accurate estimates or even a better understanding of a task.

    5. Projects help manage time.
      When the project is spread out over several tasks, estimates can be put in for each task. With realistic estimates, it's easier to plan a project's timeline with reality in mind.

    6. Projects help build teamwork.
      Most projects require a team to make it a success. This is a great opportunity to strengthen the team and improve the group's efficiency.

    7. Projects make a great portfolio.
      Whether you are a project manager or a team member, each completed project becomes part of your track record. It's nicer to see a list of successful projects than just "5 years working as a developer."

    8. Projects provide metrics.
      Good project managers will keep data on their projects, usually via project management software. Metrics are unbiased data that help understand how well (or how bad) a project is doing. It's not longer about gut feelings and impressions. It's about objective things like time, assignments and task progress.

    9. Projects can have personality.
      A lot of teams like to give funny names to their projects (like movie titles or cartoon characters). It makes working on the project more fun: "I'm working on the Donald Duck project!" sound more fun than "I'm working on project 50289-4."

    10. Projects make expectations clearer.
      Well-defined projects make it easy for everyone on the team (including the project manager) to know what is expected. From description to deliverables, when it's all there, everyone knows what their goal is.
  • Tragedy is made

    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.

  • Now that you're late, how do you deal with it?

    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 late

    When we start trying to understand the delay, something can be done about it. However, understanding the why of something is only the first step in fixing the problem. And that's what we want to do: find a way to reduce or eliminate delay.

    What are the consequences?

    Is your project linked to a contract that includes penalties if you're late? Are you working on the President's pet project? Has your organization committed publicly to a date? It's important to know the implications of the delay, since they will affect how much effort is required to correct the situation.

    It's also important to find out is the project team knew about those consequences beforehand. Even though it's always important to be on time, knowing there's a 10% penalty for delivering a product late can help your team take measures to prevent delays, or plan countermeasures to correct a delay.

    Get over it

    Time only goes forward. The project is late, and there is nothing that can be changed about that, unless you have a time machine. No good will come out of commiserating about the delay.

    How are you going to fix this? 

    This is the tough question. How can you fix what made the project late in the first place? How can you gain time to recover from the delay by the end of the project? How can you prevent this type of delay from happening again?

    Think of the future

    If you treat each challenge as an opportunity to improve your project management skills, then no delay or failure is entirely negative.

  • Information overload

    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 I'm wondering if there really is a system that can really do everything that is listed in there. 

    For me, most of the times, too much information will actually make it harder to take a decision.

    In the case here, I'm not even the one taking the decision and I'm already suffering from information overload.  

    Posted Jun 04 2008, 10:05 AM by Karine with no comments
    Filed under:
  • Off-the-shelf or custom-made?

    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, AceProject needs to be customized to work how the clients need it to work.

    At first glance, it makes more sense to put our time and energy in the standard system. After all, the time we put in developing a feature used by everyone benefits more people and gets us more sales.

    Not necessarily so.

    In our experience, when we customize AceProject for a client, they tend to stick with us in the long term. So the revenue we get from this custom system is not just from the custom work itself, but also from the long-term relationship we build with this organization. Moreover, doing custom work is a great source of inspiration. It's an opportunity for us to explore adding a new feature, from usability to the actual usefulness of that feature.

    In the end, we would not be able to do custom work without a standard system that works great as it is. But AceProject would not be what it is today without the support of those clients who had their account customized. 

Copyright © 2001-2008 Websystems Inc.