April 2008 - Posts

• It's not about the mistake, it's about how you fix it

  In life like in project management, stuff happens. People make mistakes. While some mistakes are stellar and go down in history, what most people remember about a mistake is how it was fixed. You screwed up: admit it In the end, the sooner you and your team can admit to screwing up, the faster you will get back on your feet. With a good strategy to correct the mistake and a plan to prevent it happening again, you are ready to get over the problem and move on. ...and get on with your life When a problem occurs, one should react quickly and take control of the situation. One way to achieve this is to answer the questions below: What exactly happened? You should understand the sequence of events. If people are arguing over what happened, you need to come to an agreement before you can get to the next step. Why did it happen? This is not about blaming someone of something. It's about the cause. The cause is seldom a person. It's more often a action of decision or a failure to act. Could it have been prevented? Did you fail at communicating with your team? Is there anything that could have been done to avoid this problem? Could this problem happen again? This question is crucial. If the problem could happen again, you absolutely need to have a plan to prevent it from now on. How can you prevent this problem in the future? This is the opportunity for improving processes or creating new ones. Are apologies required? If you did something that affected your customers, your teammates or your organization, you should apologize for it. Recognizing a mistake will go a long way in improving your reputation and repairing the damage that was done. How do you correct the problem and reverse its consequences? This is the difficult question. Sometimes a mistake cannot be undone. If you annoyed your customers, you may want to give them a discount on their next purchase. If you slighted your teammates, you might want to treat them to a special snack or activity. By doing this, you are replacing the negative feeling you left in people's mind by a positive feeling that may stick longer than the memory of the problem. The blame game: the best way not to fix the problem You may have noticed "Who caused the problem?" is not in the list of questions. Finding out who's fault it is often a paralyzing endeavor. It seems, once we've found who made the mistake, everything stops. And often the correction is to avoid this person in the future. This is no productive, constructive way to deal with problems. If you do this with every problem you have, soon you won't have a team to work with. Understanding why the mistake was made will yield much better solutions than pointing the finger. Posted Apr 30 2008, 09:00 AM by Karine with no comments Filed under: project management

• How do you stand out in a sea?

  In the project management business, our market is the world. However, so is our competition. There are hundreds, if not thousands, of project management software products on the market.  Every week, I find a new competitor. Project management software had become a sea of products. There are desktop software products, web-based products, open-source products, free products, very expensive products and everything in between. Ruby on RAILS was even invented to develop a project collaboration software. There are so many project management systems available it becomes overwhelming for those people who are tasked with the mission of choosing a system to manage their projects. So, how can AceProject stand out against its competition? What makes AceProject remarkable, as Seth Godin writes it? Us. What makes AceProject remarkable is the people behind it. We believe in giving great customer service, before and after the customer has given us money. We believe we should make a product that people what to use. And we eat our own dog food: AceProject is also our project and product management system. So when something's wrong with AceProject, we see it as fast as our customers. The test of time. On the web, it's easy to start something up. As easy as it is to close up shop. Being around since 2001 makes us look like the older brother on our market. Being around since 2001 also give us the stability and experience many of our clients are looking for in a supplier. While most organizations are no longer shy about buying online or using a system online, they do want to be reassured that the company they trust with their data won't be gone next month. What makes you remarkable? Posted Apr 28 2008, 01:18 PM by Karine with no comments Filed under: business, product development

• AceProject 4.5 is out! Now what?

  It's finally online: you can use AceProject 4.5 online now! What's new? You can read the release notes here, but in a nutshell: New, cooler, shinier Gantt charts Dynamic templates Easier time sheets Better custom reports Skins AceProject 4.5 took about 6 months to make, and we are very proud of it. I think it makes AceProject nicer to look at and easier to use, and that translates in happier customers. Now that it's out, I can stop talking in the future tense when I give demos to future clients. A new version release always boosts my pride in AceProject, puts a spring in my step and my voice . Now what? On the development side, we get the great question: what do we do now? Which features are we going to develop? What's the next big step for AceProject? On the product management and marketing side, this is an incredibly creative period, where I feel anything is possible. It feels awesome.  I can't wait to see what we will put in AceProject 4.6, which is due this Fall.  Posted Apr 25 2008, 10:35 AM by Karine with no comments Filed under: product management, AceProject, product development

• Training: the best usability test

  Today I'm going to give a training session at an insurance company. I always enjoy giving training, because it shows me, in real time, how easy it is to learn to use AceProject. I like to see how new user navigate AceProject, where they click, how they make sense of the system.  Here's why I like to give training:  It's great to be able to observe how our users really interact with AceProject. It's inspiring to see which questions the trainees ask. It's eye-opening when they can't fingure out something we thought was simple.  When I get back to the development team, I can share this experience with them and we can focus what needs improvement, at the interface level and at the usability level.  After all, we're making a tool for people to use. Giving training is a great source of user input.  Posted Apr 23 2008, 09:00 AM by Karine with no comments Filed under: product management, training

• It's a tool, not a magician's hat

  Tools are only as good as those who wield them. What good it the project management software if no one is willing to use it? What does it take to convince a team to change its ways? Patience It takes a while to change a team's habits, and I have yet to see a team who is not at first put off by having to report to a system. Persistence However, patience has its limits. If using the project management software is not enforced, it will be difficult for the team to change.  If a new system is put in place to manage projects, one should make it clear that the data has to be up-to-date and the reports produced from the system.   Support from above  If management is truly supporting the project management software (and using it themselves), chances are better that the new method will take hold. Again, requesting that reports be produced within the system will get the project team to use the system, and learn to like it. A good tool Any tool has to bring benefits over the old method. Is it the email notifications? Is it the Gantt chart? Is it the ability to easily know how good someone is at estimating time for a task? If the team has something to gain by using the new tool, they will be more open to trying it.  A team that works together If your project team is at each other's throats and not working together, they are very unlikely to adopt a new method as team. You will have more success having a successful team use the tool first, to demonstrate its benefits - and get more people advocating in from the inside.  Let the good times roll! Any tool can have a very positive impact on a team. However, tools cannot perform magic. When a team is broken, no system or software can replace some good old people management. When a team works well together, a good tool like a project management system can make a world of difference. Posted Apr 21 2008, 08:02 AM by Karine with no comments Filed under: product management, software

• When the project is too big, break it down

  I remember that first term paper I had to write when I was in school. It seemed so long! How could I ever have 20 pages to say about any subject? I felt overwhelmed by the size of the task. I think the teacher saw the same look of discouragement on all our faces, so she gave us a hint: make your table of contents first. When I sat down to make my paper's table of contents, I realized I wasn't going to write 20 pages on the same subject: I was going to write 4 4-page sections on different aspects of the same subject. This was much easier to deal with, in terms of planning my work and feeling more in control of the paper. The same happens when I have a huge project to work with. For example, with the release of AceProject 4.5, which is almost ready, we had to plan for documentation, promotional material, web site updates, email blasts, etc. Taken together without any structure, I felt like there was too much work and I was going to either be late or forget something. So I created a project in AceProject. In this project, I created a task group for each part of my project: Documentation, Web Site, Announcement, Email campaign, Logistics. Each of these task groups contains all related tasks. This way, I can easily focus on the Documentation tasks without feeling overwhelmed by the other parts of the project. It feels a lot better. What's also nice about structuring my project this way, is that I can know how many hours I've worked on each part of the project, and then plan ahead next time. For example, if it took me 20 hours more than planned to complete the email campaign, I can use this data to estimate my time better for the next AceProject release. Small chunks are easier to process It all comes down to how much you can chew. When the project feels too big, people will tend to procrastinate because they are afraid of it, or don't know where to start. A big project can simply be broken down into smaller, more manageable pieces.  Posted Apr 18 2008, 08:00 AM by Karine with no comments Filed under: product management

• The importance of clear deliverables

  Vague deliverables make everyone unhappy. They create misunderstandings and unfulfilled expectations. They tarnish reputations.  Projects should always have clear deliverables. Too often, the project's deliverables are so vague that no one can agree that the project is complete. Take software development for example. If the project's deliverable is the new version of that software, the project manager should be able to spell out exactly what constitutes the new version. Is it the Beta version? The Release Candidate? The Gold Master? The first client installation? Moreover, it should be clear who accepts the deliverables. Should the development team decide when they're done? Should QA sign off on the new version? Should management, sales or customer service have a say in it? Without a clear deliverable, there's the inevitable gap between what the project team thinks they should deliver, and what the project's client expects.  But how can one get a clear deliverable from the project client? Often, the project's client, be it management, the market or an actual client, has a hard time expressing what they want precisely.  It's up to the project manager to provide a clear deliverables list on which both parties can agree on.  The project's preliminary task list can serve as a good basis for the deliverables. Which features should be included in the software? Which bugs should be fixed? This is a good starting point to answering the who, what, where, when, why, and how of your project: Who decides when the deliverable is ready? What will the deliverable include? Where will the deliverable be provided? Online? As a hard copy? When is the delivery planned? Is there any leeway in this date? Why are we even doing this project? This serves as a good reminder of the project's objectives. How will the deliverable be produced?   If it's hard to answer all those questions, or if your client refuses to answer some of them, you should be worried. Posted Apr 16 2008, 09:00 AM by Karine with no comments Filed under: project management, deliverables

• Forget pressure: Great products sell themselves

  Do you remember the last time you shopped for a car? As you get in the dealership, you start looking at cars in the showroom. A salesperson helps you out, answering your questions and guiding your choice for a new car. Once you've decided what you wanted, the pressure is applied.  As you are sitting at the salesman's desk, you hear the fatal question: "What would it take for you to buy this car today?" Why? Why would I need to buy the car today? If the car is so great, and the deal I'm offered is so good, why can't I sleep on it? Or shop around some more? The answer is in how much confidence the salesperson has in the product.  If the sales person has enough confidence in their product and the deal they have for you, they will have no problem wishing you a good day and waiting for you to return to buy the car. If the confidence isn't there, they will want to seal the deal as soon as possible, before you have the time to change you mind. You will see these two types of sales online: the hard sell (buy now!) and the soft sell (take your time). At Websystems, we prefer the soft sell approach.   We know we have a great product. And we prefer to have customers that took the time to make sure AceProject was right for them before committing their money. This is why we have a free trial of the AceProject available online. People don't need to call us or email us to setup their free AceProject account. They don't need to give us a credit card number. No one will bother them while they try the new system. When they are ready to get a paying subscription, we are more than happy to count them among our customers. In fact, we encourage our clients to purchase a package that fits their needs now, and upgrade as they grow. There is no sense in buying more licenses than required, since upgrading later is not more expensive than purchasing the full licenses now. Our results? Happy clients, with more money in their pockets. Clients that don't feel ripped off. And the feeling of doing business right. :-) Posted Apr 14 2008, 01:23 PM by Karine with no comments Filed under: marketing, sales

• Sometimes, you just have to listen to something you don't want to hear

  No one likes to fail. No one likes to admit that they went wrong. That's why sometimes we keep trudging on with a doomed project for a long time, before we finally accept that it has failed. We can see this more clearly with software and product development: the product launch keeps getting pushed back, the features included in the product keep getting reduced.  Development teams seem to be spending more time fixing the product that building it. On the human side, the people working on the product are no longer proud to say they are on the team. They start looking more like prisoners than professionals. The excuses start flying. It's nobody's fault if the product is late. Marketing says it's the development team's fault for not building a good product; development points the finger back at marketing for ever-changing requirements. The fact is, no one wants to hear that the project has failed. It's not failing right now. It failed a few weeks (or months, or years) ago, but no one wanted to hear it. And now the organization is stuck with a very big money pit. That money pit is often the reason why the failed project keeps on. After all, so much money was invested on that product, no one wants to write if off as a loss. The fact is, the earlier you can face the truth about a failed project, the less money, time and effort you will loose. Posted Apr 11 2008, 07:01 AM by Karine with no comments Filed under: project management, product management

• Drowning in things to do?

  Sometimes you end up with a little more in your plate than you would like. Do you ever get that feeling that you're about to forget something? It's like you're juggling with too many balls and it's only a matter of time before you drop one. Only, when what we're dealing with is projects, the consequences of dropping something can translate in dollars for your company. When this happens to me, I start having problems sleeping at night. I wake up in the middle of the night, and turn on my computer to make sure I have not forgotten something. It's no way to get a decent night's sleep, and it makes for a grumpy marketing girl the next morning.  So, how can we keep control or a long work list? How can we make sure nothing is forgotten and everything is done on time?  Sure, the good old excel sheet will work well to make a simple list. But I find with Excel sheets, I just keep reprinting it everyday, to make sure it's up-to-date. I end up spending a lot of time working on it. And when I have too many things to do, I just don't have time to play with Excel. What's worse, Excel won't tell me when something is due, so unless I keep me eyes on that Excel sheet, I can still forget. This is where project management software makes things better. Project management software will tell you when you're about to forget something. With AceProject, for example, you receive an email everyday with the list of tasks that are about to be due, and the tasks that are late. No need to be logged in the system all the time. Just keep an eye on your email and you're done! Now that makes me sleep better!    Posted Apr 09 2008, 09:02 AM by Karine with no comments Filed under: project management, spreadsheets

• 5 best customer service practices

  There is no shortage of articles about the importance of customer service.  Last week, Guy Kawasaki published an interview with Bill Price,  titled "Why The Best Service is No Service. Bill Price's premise is that products should work so well and be so easy to use; clients never have to contact customer service. I agree completely. Our clients should not have to contact us to understand how the product works. It should be self-evident from the get go. Documentation should be readily available to help the client along. The only problem with this philosophy is that nothing is ever perfect. Products sometimes have flaws. Clients sometimes use the product in a way that was unforeseen by its creator. Even though AceProject is an Internet-based company, our clients still like to talk to us, and get a feel of who we are in the offline world. Hence our customer service rules at AceProject:  Humans speak to humans No one should have to find their way through a automated system, or talk to a machine. When people call us, they want to speak to us, not our phone system. We make a point of answering our phones and returning our calls as soon as possible. Customer service should be free At Websystems, customer service is always free. We think our customers should not have to pay to have their questions answered. Actually, technical support at Websystems is also always free. We prefer to invest in making AceProject work flawlessly and making it a success, than taking money from our clients when it fails. No matter how many versions behind a client is, when they call us, they still get free support. A bug by any other name is still a bug No system is perfect. When AceProject does something it's not supposed to, it doesn't matter who the client is, their bug gets fixed. And it's free. AceProject has no "undocumented features" or "unexpected issues." When AceProject is not working correctly, it's a bug, period. Happy people work better Over the years, we've noticed that when we're happy, we work more, we're more effective and we have a more positive impact on the business. So we take notice when someone is not happy. If it has to do with their job at Websystems, we take steps to fix that. Great products are so much easier to maintain It pays more to invest in making AceProject great than to add people to answer the phones. We spend a lot of time and effort in the testing stages of development, to make sure that AceProject is ready for release. Without this testing phase, all our users would be our guinea pigs. We think they deserve more than that.  ... and a classic: Under-promise, over-deliver. Always. It makes clients happy, our team proud of their accomplishment, and an all-around better experience for everyone. Posted Apr 07 2008, 09:00 AM by Karine with no comments Filed under: business, customer service

• Intuition or Analysis

  Do you take decisions based on a hunch, or do you take the time to analyze everything carefully? In project management, your type of decision-making can profoundly affect the rhythm of the project. Even more, your team's decision-making style can also affect the project. For example, I am an intuitive decision maker. I will focus on a few parameters, and take my decision on how I feel about the situation more than on what the data says.  Daniel, on the other hand, analyzes all aspects of the situation. He likes to sleep on it. Daniel wants to make sure we make the right decision. When Daniel and I work together, we are very complimentary. While I will become very enthusiastic and come up quickly with ideas and solutions on how to address a situation, Daniel will calm me down and take the time to think about every solution that I proposed. While I can to push Daniel a little bit to make a decision at times, he will keep me from running with an idea without thinking about its consequences. Whether you are intuitive or analytical, you must be careful to avoid pitfalls   Runaway decisions This happens when intuitive persons start taking decisions just to get it over with. It's not about the decision anymore; it's about having taken the decision. When in this state, intuitive people will loose sight of the whole project. While I take my decisions quickly, I like to let my decisions sit for a while, to see if they will stick.   Analysis paralysis Analytical people can often loose themselves in the data. If they feel uncertain about a decision, their solution will be to acquire more data, always more data. But the fact is, at some point, more data starts to have the opposite effect: it confuses the issue rather than clarifying it. When he feels that way, Daniel will take a leap of faith. And 99% of the time, life goes on J.   Posted Apr 04 2008, 09:00 AM by Karine with no comments Filed under: project management

• It seemed like a good idea at the time

  It seems product development - like project management in my opinion - requires adjustment from the theory of it (or its planning) and its reality (how things actually happen. Case in point: Last year, before we closed for the holidays, we sent a nice email to every AceProject user, thanking them for their business and wishing them a merry Christmas and happy new year. The intention behind the email was good. We just wanted to send good wishes to all the good people who made AceProject the success that it is today. However, we did not think this through. We sent the email to every user of AceProject, not just the account administrators. Usually, when we send a email to AceProject users, we only contact the account administrator.  While we had some very nice email replies and warm wishes from our user community, we had some very unhappy customers as a result as well. Some of our clients are using AceProject to keep in contact with their clients. They have customized AceProject with their logo and company name. To their clients, it looks as if they are using an in-house project management system. Most of them don't even know that they are using AceProject, they think they are using Company A's Project Management System. Hence the problem: they received an email from a company they didn't know, whishing them happy holidays. Some of our clients were very unhappy that we had taken the liberty of communicating directly with their clients. So, while our intention was good and it seemed like a good idea at the time, we realized (too late) that we should have kept our habit of emailing only the account administrators. The challenge The tricky part is to guess unforeseen consequences. Fortunately, when you are developing a product or managing a project, there is a whole team of people with different outlooks that can be consulted. With product development, there should always be beta testing phase, your last chance to realize the new feature is actually a hassle for the user. There is no way to realise you are wrong like trying you new idea for real. Sometimes it turns out to be a great idea, sometimes it turns out to be an awful idea...but bad ideas can be turned into great stories! Posted Apr 02 2008, 10:13 AM by Karine with no comments Filed under: project management, product management