Go Ahead, Manage

With the Agile methodologies gaining momentum, there is a lot of talk about process. How projects should be managed, how to implement methodologies in an organization, which method is best to achieve project goals on time and on budget. But what is project management really about? Is it about processes and forms and reports? It's all about humans Project management is about a group of people working together to achieve a common goal. It doesn't matter if it's a house, a piece of software or a book. None of it can happen if the humans don't work together. The best processes can be thwarted by a key team member who suddenly becomes unavailable for the project or a project manager who leads like a dictator. The best project management methodology will fail unless we convince the team to accept it. Five things to remember about humans Humans have feelings. We may not always show it, but we are driven by emotion. It's important to take your team's reaction into account when choosing how to present a decision. Humans like to feel good about themselves. This is a classic: praise in public, criticize in private. When we feel good about ourselves, we are happier, more productive and more willing to go the extra mile for the project. Humans need to feel useful. We don't like to feel left out of the big activities, at work or in our personal lives. Make sure to distribute the high visibility work evenly in your team, as much as possible. Humans need to have purpose. Even if it may seem obvious to the project manager, the goal of an activity may not be clear to all team members. Taking the time to explain our decisions helps the team feel that they have a comprehensive view of the project. Humans don't like to be wrong. Even when we know we're wrong, we hate to admit it. A little diplomacy will go a long way to keep your team members happy and proud of their work. What about you? How do you manage the human factor in your projects? Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

One thing most bloggers won't admit to is how they often find inspiration for their posts: in other blogs and tweets. Anywho, I found my inspiration for today's post from this Tweet: " Why do so many professionals say they are project managing, when what they are actually doing is fire fighting? - Colin Bentley" from Greg Cimmarrusti, PMP Firefighting is a management style not only used by project managers. When someone spends all their time putting out fires, they look very busy, and they have a great sense of purpose. Why so much fire fighting? It's a vicious circle. It's difficult to think long-term when fighting fires. And not thinking further than the immediate will create problems in the long run. Planning is hard. It's much easier to fix issues as they occur than the sit down and try to avoid the issues before they happen. Long term planning is even harder. Who can tell the future? Only with experience are project managers better and better at anticipating problem areas. Methodologies require discipline. One way to reduce fires is to implement a method for doing things like project initiation. Implementing a methodology and keeping up with it is difficult: it's tempting to skip over the risk management process and just jump into project execution. When we do that, we invite fires into our project. It makes people look good. Fire fighters (the real ones) are heroes. When the project manager saves the day by fixing a big, urgent issue, he becomes a hero too. And that is very addictive. How can we move from firefighter to forest rangers? While fire fighters are very visible and have a high-risk, dangerous job, forest rangers a just as important: they keep fires from starting in the first place. It's not as glamorous as fire fighting, but it causes less damage. Plan, plan, plan . Thinking ahead is the most important skill for forest rangers. They must know where the problem areas are in their projects, and figure out a way to fix the problems beforehand. Listen . Ears open, mouth closed is the best way to get information about a project's sensitive areas. Learn from the past. Those project closing meetings and lessons learned documents should not gather dust in the archives. Invest a little time now to save a lot of grief later. Not skipping project planning processes may seem time-consuming (especially from the point of view of project stakeholders), but this time will be repaid many times over in the emergencies that will be avoided. Ask for help when you need it. The problem with heroes is they sometimes try to do it all on their own...which may make things worse. If you've got too much on your place, ask for help from your team, other project managers in your organizations, or your project sponsor. Fire fighters may be glamorous, but forest rangers prevent fires Which would you rather be? The firefighting project manager that is always running around and fixing emergencies, or the forest ranger project manager who keeps projects running smoothly?

Background on the posts I wrote these two posts because I got tired of reading how complicated it was to compute project metrics. Project metrics are NOT complicated, it's simple math! So I thought if I wrote my understanding of those metrics, it might help some people. It turns out these two posts are the most popular ones on the blog! I hope you enjoy them :-) Project metrics: earned value management with a 6-function calculator Project metrics have a bad reputation. Things like Earned Value and Schedule Performance Index are presented as complex calculations that only experts can master. Nothing could be further from the truth Actually, most project metric calculations can be done by anyone with grade-school math skills. The challenge in project metrics calculations is not in the formulas themselves, but in mixing project management concepts with mathematical operators. Still, these concepts are basic to project management. Every good project manager should understand them. Start with the basics: Earned Value, Planned Value, Actual Cost These three are not really formulas. They are the three figures project metrics use to create all the other ones, like the Cost Performance Index and the Estimate to Complete. Planned Value is how much you were supposed to do in a given period of time. For example, let's say you're half-way through a 6-month project. Normally, you should be half-way done as well on the project. This means your Planned Value is 50% of the total value (or budget) of your project. Earned Value is how much you've really accomplished in the project. Let's stick with your 6-month project. Let's pretend that you're only 40% done with the project. That portion of your project budget is the Earned Value. Actual Cost is how much you've spent on your project. Still with the 6-month project, let's say you've spent 60% of your budget already. That portion of your project budget is your Actual Cost. Now, let's take those percentages and turn them into numbers. We'll work with a 50 000$ budget. 50% of 50 000$ is 25 000$ . This is your Planned Value . 40% of 50 000$ is 20 000$ . This is your Earned Value . 60% of 50 000$ is 30 000$ . This is your Actual Cost . But what does it mean? 25K planned, 20K earned, and 30K in expenses. Doesn't it look simpler this way? If we've earned less than planned, one would say the project is late. Moreover, if our expenses are higher than our earnings, one would also say we're over budget. That's all those pesky metrics are about. Now, we (and our project sponsors) will want to know the actual numbers. I found that understanding those formulas was easier than just learning them by heart. The Cost Variance is about the difference between how much has been done and how much it really cost. Earned Value - Actual Cost = Cost Variance This makes sense. The Earned Value figure corresponds to how much of the project is done. And this proportion should also (more or less) be the same of the project budget. If you're under budget, you'll have a positive number. If you're over budget, you'll see a negative number. For our example: 20K - 30K = -10K OK, now we know we're over budget by 10 000$. What does it mean? Is this a big number or a small number? 10K on a small project would be a big deal. 10K on a million-dollar project may just be normal variance. This is why we need a ratio. The Cost Performance Index is about how bad (or how good) the project is going, budget-wise. Earned Value / Actual Cost = Cost Performance Index Basically, we use the same two figures from the Cost Variance formula, but we change this symbol ( - ) for this one ( /). We'll compare how much we've accomplished with how much we spent to accomplish it. If we're under budget, the number will be above 1 (100%+). This means we've produced more value than it cost us to produce it. It means we're making a profit in the project. If the number is less than 1, it means it's costing us more to produce the project than we'll earn from it. We're losing money on the project . For our example: 20k / 30K = 0.666 OK. This is bad. We're losing a lot of money on that project. In fact, we're only making two thirds or the money we're putting into the project in the first place. However, we need to see if the project is just more expensive, or if we're late too - which would mean we're really in trouble with the project. For that we'll need to compare Planned Value and Earned Value. Essentially, the Schedule Variance formulas are the same as the Cost Variance formulas. You simply replace the Actual Cost with Planned Value: Earned Value - Planned Value = Schedule Variance Here, we're comparing how much we were supposed to do (Planned Value), with how much we've really done (Earned Value). For our example: 20K - 25K = -5K Earned Value / Planned Value = Schedule Performance Index Here, we're making a ratio to know the proportion that this difference represents. For our example: 20K / 25K = 0.8 If we look at those numbers, we're quite late as well, about 20% slower than planned. With three simple numbers and two formulas, we were able - with only two of the six functions on that calculator , to tell that our project is late and over budget. Was that complicated? Hardly. Variance and Index calculations are simple. In fact, they use the basic math we learn in grade school. You could put these 4 formulas in a spreadsheet can compute your project metrics with one hand tied behind you back. Estimates Estimates seem even trickier than variances and indexes. Because a lot of the original estimating process is fuzzy, it's easy to assume figures like Estimate to Complete and Estimate at Completion would be hard to understand and hard to believe that - Gasp! - they can be computed with a pen and paper. Just like last time, we'll work with a 6-month fictional project with a 50 000$ budget. In order to compute Estimate to Complete and Estimate at Completion , we need the following figures: Budget at Completion is your project's total budget. This is (usually) decided when the project is approved With our project example, the Budget at Completion is 50 000$. Earned Value is how much you've really accomplished in the project. Working with our 6-month project. Let's pretend that you're only 40% done with the project. That portion of your project budget is the Earned Value. Actual Cost is how much you've spent on your project. Still with the 6-month project, let's say you've spent 60% of your budget already. That portion of your project budget is your Actual Cost. Now, let's recap our figures. 50 000$ is your Budget at Completion. 40% of 50 000$ is 20 000$ . This is your Earned Value . 60% of 50 000$ is 30 000$ . This is your Actual Cost . Estimate to Complete: what's left to do in your project? The Estimate to Complete is the remaining work to be done on the project. In order to know how much is left to do, we'll need to know what's been accomplished - this is the Earned Value. Budget at Completion - Earned Value = Estimate to Complete Contrary to the previous project metrics, this is just a number. It tells us how much is left to do on the project. For our example: 50K - 20K = 30K . There is another method to compute Estimate to Complete. You can account for higher costs using a typical variance. An example of a typical variance would be if the speed of work was overestimated, and it takes longer to do the work than expected. When you are in a situation like this, you can apply that variation to the rest of the project, and thus have a better Estimate to Complete to work with. Estimate to complete / Cost Performance Index = Estimate to Complete with typical variance Since we already computed the Cost Performance Index in the last post, we'll use it here. For our example: 30K / 0.666 = 45.05K That makes a BIG difference in how much it's going to cost to finish to project, don't you think? Estimate at Completion: how much is it going to cost? Essentially, the Estimate to Complete figure is just a number. We don't know if it's good or bad, until we can figure how much the whole project is going to cost. This is the Estimate at Completion. This is also a very easy number to compute. You simply add what you've spent already (Actual Cost) and what you think it will cost to finish the project (Estimate to Complete). Actual Cost + Estimate to Complete = Estimate at Completion For our example (let's use the typical variance): 30K + 45.-5K = 75.05K Variance at Completion: how off target are you? The last thing we want to know now, is are we over budget, and if so, by how much? This is another simple computation that gives us the Variance at Completion, the difference between the original budget and the forecast cost. Budget at Completion - Estimate at Completion = Variance at completion Just like the Schedule Variance and the Cost Variance we worked with last time, if you're under budget, you'll have a positive number. If you're over budget, you'll see a negative number. For our example: 50K - 75.05K = -25.05K The -25.05K tells us we are 25 000$ over budget. For a 50 000$ project, we could say your project is in trouble. Was that so hard? I don't think so. For all of you who are worried about passing the PMP exam because of the math skills required, you've just read 80% of the math you are expected to use in the PMP exam. As long as you understand these formulas, you have nothing to worry about. Here is a spreadsheet with all those nifty formulas . Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

While working on a project, I realized the project team was not clear on the roles and responsibilities of the project sponsor VS the project manager. Who's the sponsor anyway? The project sponsor is the person who pays for the project. Because he or she is paying for the project, they get to decide on the project scope, schedule and budget. They're the ones really taking the big decisions. Don't confuse sponsor and client, however. The person who buys the product is not necessarily the one investing in its development. For example, we develop AceProject and then sell it to our clients. The clients get the product after the development project is completed.While their opinions are very important to the development process, they are not the ones funding the project. When we are developing custom features for a client, then the client is also the sponsor, because they are privately funding the project. Otherwise, the project sponsor here at Websystems is Daniel, our President. What about the project manager, then? The project manager makes sure things get done. The project manager takes the sponsor' decisions on the scope, schedule and budget, and does her best to deliver what's required. The project manager does not take decisions as to which features get developed, or how long the team has to do the work. That's the sponsor's job. Imagine you're going sailing Let's say your team is the crew of a sailboat. In this case, the sponsor (that would be the captain) decides where the boat goes, and when it should arrive. The sponsor also decides how big the crew will be. These decisions are transmitted to the project manager, who organizes the work shifts, works out an itinerary, and does everyting in her power to motivate the troops and get the boat where it's expected to be, when it's expected to arrive. If something happens and the project manager realizes that the boat can't reach its destination on time, she takes that problem to the sponsor, who decides what to do about it. The travelers on that boat (the clients) just enjoy the ride. Everyone on your team should understand this Understanding the differences between sponsor, client and project manager is crucial to your team working well together. When things aren't clear, people will make up their version of the truth, and it's rarely what it should be.

Whenever someone wants a walk through of AceProject, I am the one who sets up the web meetings and shows them how they can manage their projects and their clients efficiently with our system. I have been giving demos every week for the last 18 months, and I have yet to see two clients with the same needs. Of course, the higher-level needs are more common (collaboration, project management, document management, etc.) But how each client wants to implement this processes in their organization is different every time. Now AceProject is a tool. It's something that will help you get things done. It's not going to do the work for you. It's not going to force you to go things a certain way. All tools should be flexible. Not everyone who wants to manage projects needs milestones. Not everyone wants dependencies. Each organization is unique, and each project manager is unique. Project management tools should accommodate this uniqueness in their product. After all, who are we to tell you how to run your business? Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Nowadays, we hear more about wikis, blogs and tweets than forums. Actually, forums are not as "Web 2.0" as these collaboration tools. Nevertheless, discussion forums are incredibly useful in a project management application, from a collaboration standpoint. Everybody's talking about Twitter and how cool it is to post 140-character messages. I definitely agree with that. However, let's not forget that a forum enables you to post both short and long messages. With Twitter, if you have a lot to say, you'll have to post several short messages, which is not always convenient and interesting to read. A forum still remains the best of both worlds. In AceProject, there's a comment thread at the task level and a discussion forum at the project level. Both empower involved users to share ideas, knowledge, tips or any other useful information. The discussion forum is more powerful however. In addition to general discussion, it permits creating topics. Messages are then posted in a specific topic and replies to these messages can be posted thereafter. Hence, collaboration capabilities using this feature abound. From building a knowledgebase to simulating a helpdesk, the discussion forum is much more than a simple conversation tool. Here are a few practical examples of how the discussion forum can be used in a project: Build a knowledgebase that can be used for troubleshooting. Users can easily search for keywords using "Text-to-Search", which helps them find answers to their questions in a flash. Create a wishlist (gather customer requests, potential enhancements, etc.). Simulate a helpdesk system (allow customers to post messages when they encounter issues and have every issue handled by your support staff). Thanks to the email notification feature, the customer can get notified when their issue gets fixed. Use it as a blog (why not?) Discuss issues Share knowledge Build a FAQ And more... Here's a video that highlights the discussion forum feature in AceProject. Connect with Sylvain Traversy and the AceProject team via Facebook , LinkedIn and Twitter .

We're working on the second development phase for AceProject 4.7. There will be three phases in AceProject's 4.7's development cycle. In phase 1, we modified task dependencies . In phase 2, we tackle how user workload is managed in AceProject. We found that the User Workload report was hard to read. It was difficult to assign several people to do the same task, and yet count their assigned hours efficiently. Here's what we did: A typical work day In AceProject 4.7, you'll be able to set a typical workday length, in hours. This is useful to avoid setting the same work day length for all your users. Once you've set a default for the account, you'll be able to enable that feature for your users. Moreover, you'll be able to set different work days for users that don't follow the main schedule. For example, if someone on your team only works half-days, you'll be able to set it up accordingly. Divide the effort amongst your assigned users...or not Currently, AceProject only permits dividing the effort amongst assigned users in the user workload report. With AceProject 4.7, you'll be able to choose if the estimated hours in a task should be divided between the assigned (so a 20-hour task assigned to 2 persons means 10 hours of work each), or not (so a 20-hour task assigned to 2 persons means 20 hours of work each). Better project estimates With this feature in place, the total effort for a project will be estimated more accurately. AceProject will take into account whether a task's work is divided amongst assigned users or not, and compute the total project work to be done accordingly. A workload report you can use The current user workload report is hard to read. It's a list of numbers, and nothing stands out. Hence it's hard to identify who has too much work assigned. With the typical work day feature, AceProject 4.7 will compare the work assigned to each person daily, and highlight the days where your team members are over-allocated. Coming soon! AceProject 4.7 is scheduled to release at the end of spring / beginning of summer.

We were sitting at the table in the conference room, discussing how we'll implement the new cost tracking features in AceProject. And I realized the difference between budget and estimate was not clear at all to everyone sitting at that table. What's the difference, anyway? Budget is defined as: A sum of money allocated for a particular purpose An estimate is defined as: An approximate calculation of quantity or degree or worth; "an estimate of what it would cost." A budget is often something that is decided before estimating how much something will cost. The organization decides how much they can invest in the project, then they decide on the scope of the project, and finally the project team estimates how much it will really cost to do the project. When the estimate is higher than the budget, the fun begins. Here's an example: I want to buy a new car. I know I can afford to pay 15 000$ for the car. That's my budget . I go to the car dealer and I pick the car I want, with all the options I want on it. The salesperson tells me that car would cost 25 000$. That's the estimate . Now I have two choices: change my budget or choose different options on my new car to reduce the estimate so it fits my budget. Why do you need an estimate if you already have a budget? Sometimes budgets are not realistic. Sometimes, the technical complexity of a project can be underestimated at the initiating stage. If we take the budget and run with it, we may end up with no money left half-way through the project. Why do you need a budget is you already have an estimate? Estimates can change. A budget can work as a limit or a threshold that raises flags when there are overruns. Also, once the estimates are done, good project managers will add reserves to address risks or unplanned work. Why compare the two? Usually, a preliminary budget is decided at the project initiating stage. Then, during the planning phase, once the scope is approved and the estimates are done, this budget is adjusted. As the project goes forward, estimates may change. For example, there may be some work missing in the work breakdown structure. Or there may be unforeseen complexities in the project. Comparing the new estimate with the budget helps keep costs in control so as not to exceed the budget. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Last week I had the pleasure of meeting Bruno Larouche from Génération Agile . He helps businesses implement agile methodologies. We had a conversation on Twitter earlier about AceProject's compatibility with agile project management. Bruno gave us a very enlightening presentation. While I had read about agile before, I don't think I had ever had the chance to talk with someone who lives and breathes agile. One thing that hit me as Bruno was explaining what agile project management was about, is the importance of the human in Agile development methodologies. What I learned about Agile project management and humans Agile is about adapting to change. The Agile project team must react to changing conditions in our environment. Agile project management stresses fulfilling a need . It's important to manage stakeholders' expectations well. It's crucial to involve the client (or at least a representative of the end users) early in the process. There's no point in asking for feedback when it's too late to change anything. Communication and motivation are essential to deliver early and often. The project manager is never alone: the team provides estimates and participates in sprint planning. Is Agile project management simply really good teamwork? When I was listening to Bruno, I felt that Agile methodologies stress the importance of teamwork: assigning the right people to do the job, trusting people, empowering the team in project planning. Those are all important notions that all good project managers should apply, even in more traditional project approaches. It seems to me that Agile has reintroduced important concepts of working together. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

We've started testing phase 1 of AceProject 4.7 last week. So far, we're really impressed with Pascal's work. Not only is the software working as expected, but there are very few bugs to fix. Phase 1 was mostly focused on improving task dependencies. Most AceProject users will tell you task dependencies are very rigid in AceProject. We use only hard logic: the predecessor task must be completed before its successor can start. Dates are mandatory. It makes it difficult to use task dependencies efficiently in the current system. In AceProject 4.7, we introduce non-mandatory task dependencies. For dependency chains that can accept flexibility and overlap between tasks, you'll be able to start a task even if its predecessor is not completed. (Click to enlarge) Even better: if your task doesn't have dates or has incompatible dates with the predecessor, AceProject will propose some dates to you in a pop-up, so you don't need to remember when the previous task ended. (Click to enlarge) We are getting ready to start working on phase 2 of AceProject 4.7. This phase will include improvements to the user workload report, and a new dashboard feature! I can't wait to show you what it looks like.

With AceProject, we support 5 browsers: Internet Explorer, FireFox, Safari, Opera and Google Chrome. At Websystems, most of us use FireFox or Internet Explorer. Hence, we tend to want to test AceProject with our preferred browser, in our preferred language. But we still support all the other ones To make sure all browsers and languages are used to test AceProject, we've decided to rotate browsers throughout the development cycle. Right now, I'm testing on Opera. I poersonnaly use FireFox and Chrome as my primary Web browsers. Opera is a different animal. Everything looks a little bit different in this browser. To the point where, as I am testing, I wonder: "is this an AceProject bug, or is it one of Opera's quirks?" Suffice to say, the way someone experiences a web site can be significantly different from browser to browser. It's worth trying out other browsers, to surf the web though someone else's browser.

With the Vancouver Olympics project getting a lot of attention worldwide, the Candian chapters of the PMI have organized a Project Management Week. This is a great time for all Canadian project managers to inform and train their teams about project management today. The Globe and Mail and the French paper Les Affaires will be running a special insert next week, and your local Canadian PMI chapter has events lined up for you to attend! To get involved virtually: join the LinkedIn group for the Canadian Project Management Week.

Go Ahead, Manage is over one year old. I know, it's young compared to most of the blogs out there. I've been writing the majority of Go Ahead, Manage's content. After a year, I find that the greatest challenge is to have something to say . This blog is not about my personal life, but about the life of the whole team here, the life of our product, AceProject, and the life of our field, project management. When we began this blog, I had a lot of things to say, I even had a backlog! As time passed, I got through that backlog and now I find my inspiration a few minutes before I start typing the new post away. The biggest lesson I've learned about blogging is that it requires discipline to produce new, fresh content three times a week. In the last few months, with Twitter taking the world of project management by storm, there is even more content out there about project management, project managers, and managing a business. It becomes a challenge to create content that is remarkable and unique, amid all the other great blogs out there! However, keeping up with all those blogs and Twitter hashtags is keeping me and the whole team here at Websystems on our toes. It is also a great source of inspiration, both for the blog and for the future of AceProject.

There is a lot about control in project management books and best practices: we need to control scope, budget, schedules, quality, etc. It's expected of project managers that we have control over the project. But what about the uncontrollable? What about people? People are not as easy to plan around as machines or supplies. When we put a printer on a table, we don't expect it to call in sick or start printing badly because it's having troubles at home. But people do. Our developer Pascal is very important to our team. He's the main developer for AceProject. When he's not around cranking out awesome features, AceProject development slows down noticeably. Yesterday, Pascal's girlfriend was hospitalized as a result of getting the A H1N1 flu. When we heard the news, no one thought about Pascal being absent of a few days, or the impact it would have on his projects. We were all worried for him and his family. There is nothing any of us can do to help Pascal, and his absence will impact his projects. I hadn't realized how it would affect the whole team here. And this cannot be controlled either. How much control do we really have on our projects? I think we have as much control as our team gives us, as long as luck is on our side. What do you think? Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Yes, it's finally ready! AceProject server will be upgraded tomorrow night to version 4.7. Here are the release notes . Congratulations to the team for such good work, and I hope you like the new version! Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

The excellent post " The Lazy Project Manager " over at pmstudent got me thinking. A common way to manage projects is management by exception. The rationale behind it is that we should only give attention to parts of the project that are not going according to plan. It makes sense. If parts of the project are going well, there is no use scrutinizing them. However, if we're only focussing on what's deviating from the plan, we may be missing opportunities for improvement. If we use Pareto's 80/20 principle, 80% of the work in the project is on 20% of the project value. This is no doubt the most expensive part of the project. Even if it's going well, we may gain significant performance improvement by looking at the 20% most costly or most difficult part of the project, and looking for areas of improvement. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Virtual teams are a fact of today's projects. With outsourcing and increased mobility for the workforce, there is a higher proportion of people who either work in satellite locations, or simply work from home. The project team becomes virtual. How can we keep up with everyone when we can't see them? A huge part of project management is getting a feel of how the team is doing How can we do that without seeing the people we work with? After all, the biggest part of a person's message is not conveyed with words. It's transmitted via pitch and intonation of voice, the way she sits or stands, her facial expressions and hand gestures. These are all things someone can't show in an email, a tweet or a chat window. And while video conferencing and conference calls can help getting a bit more from that team member, it's still not the same as being right in front her. Another issue is created by writing instead of talking. In writing, people have different personalities. When we write something, it's not spontaneous. We get to re-read it, improve the message and control the information we send more closely. This means that someone can be very unhappy about something in the project, and never express it in her communications. Weeks or months later, the problem has grown exponentially and it may not be fixable anymore. A third issue with virtual teams is the ability to hide things better. Since the project team is not in a war room and the team is not physically together, a team member who would have difficulties would be able to hide it from the team and her project manager. This can cause significant delays in projects, and even compromise the whole project. As a project manager, how can we adapt to the virtual team? Step 1: Remember the eyes. One very important thing is to keep something visual going on during a conference call ( this article has good examples of desktop sharing applications). I'm sure everyone has been on a conference call while doing email at the same time :-) When there is a visual element to the virtual meeting, it's easier for everyone to stay focused on the subject. Step 2: Don't skip the one-on-ones. Even if it's only by phone of chat, it's important to dedicate time to each of your team members. The easiest way for me is to plan a weekly 30-minute meeting with each person. When someone works from home, it's very easy for her to feel left out if no one takes time to talk to her personally. The one-on-one is a great time to get a feel of how things are going with this person, without everyone else listening in on the conversation. Actually, with virtual teams, this a must . If you don't have those one-on-ones, you have very little chance of learning that a team member's kid has been sick lately, or that she's having technical issues with one of her tasks. Step 3: Keep it social. If at all possible, have a face-to-face kick-off meeting, and have a party when a big milestone in you project has been delivered. The fact that people don't work in the same place doesn't mean they don't work together . Getting the team to know each other (and their project manager) will help everyone adapt their working habits to suit the team.

I've had my Linkedin profile for while now, but was not very active on the network until a few months ago. That's when I discovered Linkedin Groups. I signed on for project-management related groups. The discussions on Linkedin groups are insightful, interesting, and go deeper than those on Twitter. On Linkedin, we are all individuals, not the companies we represent. We become part of the community. And this is a much more powerful sales tool than one would expect. At first, it may seem like a big investment in time, that yields no direct sales. This is not true. Linkedin is about people. And people need tools and products in their lives. Guess who people will listen to when they are looking to buy something? Their network. It's simple really. And the great thing is it really works. I follow and contribute to Linkedin groups when I feel relevant to do so. I am not pushing anyone or spamming groups to promote AceProject. However, when someone is looking for project management software, I'll tell them about AceProject . It's not a sales pitch. It's a simple suggestion to check out AceProject. The interesting thing is you never know who you end up talking with, who will see the discussion, or the company behind this person. Sometimes, I'll suggest AceProject to a consultant, who has a mandate from [insert big company name here] to find a project management system. Being in the community builds trust. There is no better sales tool than someone's trust. The trick is we have to nurture this trust: Be part of the community. If your only interventions are aimed at selling your product, how will people know they can trust you? Be honest. With the amount of information online, people will figure out if you're lying. Don't push. No one likes a pushy sales person. Instead of manipulating people into buying, let them decide for themselves.

Your interface should not be noticeable. It should not take from the work that's being done.

...

Since blogs are online, I thought it would be fitting to begin reviewing eBooks. This time, I'll tell you about "Getting Started in Project Management" by Josh Nankivel. Josh is the founder of pmStudent.com , a website dedicated to those learning the skill of project management - a skill we may never be finished learning! pmSutdent is set apart from all the other learning-oriented sites for project managements, who are usually focused on PMP certification, and little else beyond that. With pmStudent, the focus is on learning , and getting certified is a subject secondary to that. Josh wrote "Getting Started in Project Management" to help others getting started with project management, basically to provide a resource he would have liked to have when he got started in 2004. The book is divided in two parts. In the first half, Josh tells his own journey into project management, from his last lay off in 2004, until he was asked to lead a major project in the aerospace business. This was an interesting read, especially where he writes about his job search for a project management position: "Reading through multiple position descriptions from the same company even gave me an idea of what the project environments were like." Josh also stresses a little-talked about aspect of blogging: "I think it was then that I discovered the benefits of being completely open and public with your thoughts, and how amazing it can be to be told you are absolutely dead-wrong on a topic." The second part of Josh's book is filled with advice on getting started with project management. He addresses the technical skills VS project management skills debate: "The key is being able to effectively communicate with the techies and business suits ...you need a foot in both worlds for this." He also covers the topics of certifications and higher eductation: "Always emphasize your opportunities to gain real-world experience." Overall, "Getting Started in Project Management" is a quick an inspiring read. Josh's writing is easy to relate to and flows naturally. This is an ebook that deserves to be read. "Getting Started in Project Management" is available on pmstudent.com . Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Since it's Canadian Project Management week, I thought I would start the week with a PMI-related post. When I happen to discuss the PMI project management method, I often hear the comment that the PMI's method is too heavy and creates too much red tape. The Project Management Book of Knowledge (PMBOK) is pointed as the big culprit. Truth is, the PMI and its PMBOK a misunderstood. Time and time again, the PMI stresses that the PMBOK is a collection of best practices in project management. It's not a set of regulations. It's not a list of obligations. It is simply a repository of information for project management. The PMI does not expect small projects to go through all 50-some processes. That would turn a 6-week project into a 12-week project. In fact, the PMI states: "The PMBOK Guide identifies that subset of the project management body of knowledge generally recognized as good practice. [...] Good practice does not mean the knowledge described should always be applied uniformly to all projects; the organization and/or management team is responsible for determining what is appropriate for any given project." Source: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Fourth Edition, page 4. Project management is more than following rules blindly. Project management is about knowing that to do for a specific project, team, stakeholder or sponsor. It's about giving people the information they need, not the information we think they want. It's about adjusting techniques and practices to our own organization, our own people, our own industry. The PMBOK is there to provide a reference of common vocabulary and tools. It's a source of inspiration. It's a guide. It's not an obligation.

I've been reading on HR management for my upcoming PMP exam. According to the PMI, HR management is about getting the right team for the right project, and developing that team so that the product of the project is delivered on time and on budget. As the project manager, what do you bring to the table? It's is easy to know what the software developer brings to the project. It's harder to know what the PM brings to the project. We're usually the cat herders: we do our best to keep the project on track, the team happy, the stakeholders under control and the deliverables...delivered! It doesn't feel like a productive job. But without a project manager, how many projects would ever end, let alone on time? That's what project managers bring to the table: cohesion and coordination.

We've been working on a project with a client for the last 6 months. The challenge of the project was not so much the technical aspect of the work, but understanding the needs of the client. We were working via email and phone conference calls with the client. The problem was that it was difficult to get a clear decision from the client. Especially with email, the delay between the questionn and the answer made communications difficult. When we were on the phone, we were also missing an important part of communications: non-verbal. We were stalled . We decided to invite the client to our offices. With all of us sitting at the same table, we were able to reach an agreement as to what needed to be done and how we were going to do it. It was easy to reach the agreement because we were able to communicate more efficiently. Being face to face gives us all the information that someone transmits: the verbal AND the non-verbal. Virtual meetings are not as rich It's easy to give the wrong impression in a virtual meeting such as a webmeeting or a phone conference. For example, someone's sarcasm can be interpreted more negatively than it really is if we don't see her smile when she makes the comment. We have to remember, in these situations, to check with the person who's projecting a negative image if that is really her intent. The other side of the situation is also true: someone can interpret our comments wrongly because they are not getting the whole message. It's up to us to remember the limitations of the virtual world. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

The world of project management is a crowded place. There are multiple profesional accreditation options, multiple project management methodologies and countless books, blogs and tools to manage projects. This is a good thing. I have never talked to two organizations who managed projects the same way. It makes sense that there would a wide range of options. In most markets, when you sell something, the other products that are sold to do the same thing as your product are called competition. The customer base is finite and the game is to win over the heart of a majority of those customers. When we talk about AceProject and the world of project management software, this feels wrong to me. There are many, many, many project management tools out there. Open source tools, free tools, affordable tools, expensive tools, web-based and desktop-based. The Google search for project management tool comes up with 188 million results . With that many players in the race to win over users and fans, how can we even see it as a competition? I prefer to see other companies making project management tools as colleagues. Colleagues are more civilized. We work in the same field, but our products are aimed at different needs, different types of companies and project management methodologies. Our vision of doing business at Websystems is not to talk against other project management tool providers, but to show potential clients how AceProject fits with their project management needs. We don't want to cheat people into creating an account with us. If AceProject is not a good fit for the project team's needs, it's fine. We'd rather see that team succeed with a tool better adapted to their needs, than have them struggle when AceProject is not what they're looking for.

I keep finding websites that NEED Internet Explorer to work correctly. On the last website I visited, a government directory, the search function would only work with Internet Explorer. This is inexcusable. While Michel, our graphic designer, keeps telling me how hard it is to make AceProject look the same across five browsers (Internet Explorer, FireFox, Safari, Opera, Chrome), it can be done. It doesn't have to be perfect. But it has to work. Forcing your visitors to stick to a specific browser or a specific screen resolution will only increase your bounce rate. On AceProject's website, only 49% of all visitors use Internet Explorer, while 40% use FireFox, 4.75% use Chrome and another 4% uses Safari. If we only support Internet Explorer, we would turn our backs on more than half our visitors.

Jorge Domingez asked the question: is project management science or art? I agree with Jorge that project management cannot be reduced to only art or only science. Rather, I see project management as a craft . Wikipedia defines craft as "a skill, especially involving practical arts. It may refer to a trade or particular art." Project management is about skills Project management is being able to put people together, to organize work and to motivate the team to achieve the objective. While some are from the art world and some from the science side, these are all skills. Project management is about the practical world Project management is about achieving a defined goal. Projects are not theoretical endeavors. Project managers are craftsmen and wormen Project managers must bring together skills from different, almost opposite worlds (art and science) and work with their team to deliver something tangible at the end of the project. What do you think? Do you see project management as a craft? Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Project management is a big world. With the PMI's PMBOK running at 400 pages or so, it can be challenging to keep up with methodologies. Even more challenging is keeping up the practice of closing projects well. It's easy to sign-off on the work and to do the administrative closure stuff, but building good, usable project achives is harder. It takes time, and the value of this time is not seen in the short term. I recently attended a conference from Laurent Bellavance, the director of Rimouski 's economic promotion society . His role is to facilitate the projects: he puts together the local governments, specialists and investors to create innovation and prosperity in his city. Bellavance has been in his post for about a year. One of his challenges is to get information on past projects. While the other directors who preceded him at the head of his organization can still be reached if needed, they are focussed on other goals and do not always remember the specifics of projects that have been closed for years. There are paper archives, but those aren't convenient for searching. It takes time, there's not index...and what were people doing before Google? Project historical information must not be allowed to live only in the heads of the project team Desktop-based project management systems are not convenient for storing information. Even if you can keep the project schedule, there is little room for documentation, notes, lessons learned. And most of it lives on someone's hard drive (and we all know how fickle these things can be). Organizations like Bellavance's should use a collaboration tool, to keep all the information centralized. With online project management and collaboration, the data lives in a place that is accessible from anywhere, easily. It's searchable. With an online project management and collaboration system, you get a chance to store project archives outside the project team ' s memory . A few years later, you can go back to a closed project and find that contact information that got lost in the email system changeover, or you can search your issues knowledge base across projects to fix a problem with an SQL query. When that kind of information lives in someone's head, it can be forgotten, or the person can move on to other challenges and no longer be available. And that's when a lot of organizations understand the value of project archives. Well, what do you know? AceProject does just that! One reason that people like AceProject is because no project is ever deleted. All the information that was entered in AceProject during the life of the project can be searched: documents, discussion forums, comment threads in tasks, reports, etc. There is no need to transfer all that information in a knowledge base, when you're using AceProject, you're building the knowledge base as you go!

When selling a product or service, we tend to focus on the attractive traits of the product. Having the best features. Meeting the bestest, newest requirements on the market. Making the prospective customer's eye twinkle when they see our product. That's very important, because if there is no seduction, no twinkling in the eyes, there is no sale. The product has to be attractive. However, once the client has been won over, we have to keep her interested in the product. If the product is aggravating to use, all the seduction in the world won't keep the client using the product. You see, it's like dating On the first date, we're on our best behavior. We're dressed in our best and we make every effort to shine a positive light on ourselves. As the weeks go, we become more comfortable and that's when we find out if we can tolerate the other's quirks. That's when light sleepers find out if their new love snores, and when neat freaks figure out that they're dating a slob. Don't let your clients be irritated away from your product Things that clients complain about frequently should be as important on the fix list as feature requests. If people have a bad experience every time they use your product, they will drift away. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Ah, Twitter. Possibly the most misunderstood tool online. A lot of people wonder "what's the deal with Twitter? Why would I tell the world what I had for lunch?" For us at Websystems, Twitter is a learning tool. The amount of information, wisdom and discussion that happens on the twitternets is simply amazing. Since each post is only 140-characters long, not only must people be concise and to the point, but it's also very quick to browse through all those tweets. The secret to getting good information from Twitter is to use hashtags. Hashtags are like search terms that people will put at the end of their posts. Then, through a simple search on the Twemes website or with your favorite Twitter application, you can see everything that's going on for that keyword. The popular one related to project management is #pmot (for project managers on twitter). There's also #pmi , #pmp , #agile and #pmiagile Here is what was posted recently: Essentially, when you keep an eye on the #pmot hashtag , you get valuable information from over 300 different project managers. You don't even have to use Twitter to follow a hashtag! Just grab the RSS Feed for the #pmot hashtag and you'll get all the valuable information coming from the Twitterverse, without having to create and account. Try it. It's worth your time. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Seth Godin has a very insightful post about ignoring your critics . I agree with him. From a sales standpoint, critics are everywhere. People who are shopping for project management software often have a very definite set of features they would like to see in their tool. And when they are faced with the reality of an actual project management system, which cannot possibly include all the features everyone ever wanted, they may say something like "I would definitely buy AceProject is it did X." The problem is, if we added every feature asked during the sales process, AceProject would be a mess. It would have so many features, it would be unusable. And no one would want to buy it. So, we need to balance what we choose to add to AceProject. If it keeps coming back (like task dependencies being too hard to use), we should do it. If it's been asked only once, we'll wait.

We think a lot about schedules and costs and quality when planning a project, but do we spend enough time thinking about our project team? When's the last time you thought about you team's happiness? I worte an article for Project Management Tipoff's May editiion, about the importance of human resources in your project. Read my article here , and the entire newsletter here .

Sub-tasks are definitely one of the most requested features to add in AceProject. We are still unsure as to whether they will be added someday or not. There are technical reasons, but also usability reasons. Actually, sub-tasks wouldn't be used by everyone, and most users who would, don't need all the sub-tasking properties available in products like Microsoft Project. Our biggest challenge is to keep sub-tasks as simple as possible, and usable by anyone. That being said, there's a workaround for sub-tasks in AceProject that works for many users. It simulates sub-tasks, although it doesn't replace them per se. All you need to do is use integer task numbers for tasks and decimal task numbers for sub-tasks. If necessary, you may set dependencies between specific tasks. Here's an example: We are aware that this is not ideal, but it works pretty well for basic sub-tasking. Connect with Sylvain Traversy and the AceProject team via Facebook , LinkedIn and Twitter .

Last week at the Webcom conference, the big buzzword was open: open networking, open mesh, open social, open products, etc. The era of the Web 2.0 is over. It's now the Web ME.0. ME.0 is about the individual. Not the products. Not the technologies. Not the businesses. The people. And those people are not interested in remembering 15 different passwords, or recreating 15 diffierent profiles on 15 different sites and products. Already, we're seeing most sites using the email address as the username to log in. We're seeing initiatives like OpenSocial getting attention from the likes of Google and Yahoo. We're seeing more and more products opening their databases via APIs. We're seeing more products designed to centralize social network updating. Businesses are making their products easier to use, instead of locking their customers in. Everyone wants an open product, an open platform and an open relationship with their suppliers and clients. Open is THE online business and technology trend this year, just like green is THE brick-and-mortar business trend this year.

Well it's finally time for me to go on vacation! While I am away, I've prepared an update on some popular posts from this year. I hope you enjoy them. Have a great month of August - I'll be writing again in September. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Everyday I receive unsolicited emails selling my 'high-quality" email lists to market AceProject. All those emails promise me that the lists are 100% opt-in, qualified buyers who just can't wait to learn about my product. I also see the same offers from magazines and online community sites. Magazines and community sites will often have nice colorful graphics about their audience. And the price is interesting too. For a few hundred bucks, I can bug thousands of project managers and try to convince them that AceProject is the tool for their needs. The problem is they don't know me Those people whose email addresses are on those lists may have accepted to be contacted, but they did not agree for me to email them. This is a problem. They did not give me permission to market to them. Furthermore, what really is the probability that someone on this list goes "Wow! This is exactly the product I was looking for! I must purchase it right this instant!" Slim to none. Because my email is just one of may spam messages she'll receive today. Because she probably won't read it. Because she did not ask for me to email her . I would rather put a banner ad on that community site or the magazine newsletter. Then, I give those readers the choice to know more about my product. I am not forcing it down their throats. Moreover, if I didn't give those marketers permission to email me to sell me their mailing lists, what guarantee do I have that these lists are really legitimate? I would rather not wager AceProject's reputation on that.

We'll be attending Webcom 2009 in Montreal on Wednesday. It's refreshing to see an event with such interesting speakers close to home (Websystems is located in Quebec City ). An event like WebCom is a great source of inspiration. It's a way to look at the world through other people's eyes. Here are the conferences I'm looking forward to attending: Corporate Identity through Social Networks The New Normal: the Web as a High-Performance Tool in a Shifting Economy Digital Identity : Major challenges of Web 2.0 Risk Management and security of confidential electronic documents Sales, Marketing, and Product Development 2.0: Doing More with Less in the Facebook Era Panel : The Open Web. Really Open to all Users? If you'll be in attendance, drop us a line and we'll meet up in between conferences! info@aceproject.com

Who makes decisions in your project management team? Do you have a dictator, a group of decision-makers, or does eveyrone on the project participate in the decisions? Democratic project teams: the quicksand trap Taking everybody's opinion into account is a great idea, it opens up new avenues of thinking. It's good for creativity and solving problems. However, if decisions are put to a vote, there is always the risk of taking the wrong decision, because not everyone in the group has a 360-degree view of the problem. For example, if the team is composed of a majority of developers and only one person who represents the interests of the clients, should the client representative's vote weight heavier in the balance? Another issue with democratic decision-making is the quicksand effect: discussions can end in a stalemate. Where does the team go from there? Autocracy: distribute blame, dilute merit This is project management by committee, where only a select few take the decisions, not the whole team. While this decision-making style can be more proactive than a democratic style, it is style vulnerable to stalling. An advantage of autocratic ruling is that the decision committee usually includes all stakeholders, so decisions are taken with all the facts in hand, and everyone usually understands them. However, it has the disadvantage of distributing blame, so bad decisions are less traceable; and diluting merit, so good ones are not traceable either. Dictatorship: I leader, You team Dictatorship is as great (or as bad) as the dictator. When the project lead knows how to listen to her team and accepts suggestions, she can be quick and effective, taking important decisions when they are needed and keeping the project going smoothly. Unfortunately, when the project leader is a certified ---hole , she can turn any project into a miserable failure. With dictators, there is always the risk of more distance between the leader and her team. If she spends too much time being a leader and not enough time being part of a team, it may affect the cooperation that she gets from her team. It all comes down to the humans Regardless of the decision-making style your organization privileges, they are as good (or as bad) as the humans taking them. At AceProject, our style is democratic, with our benevolent dictator having the last word :-)

It seems I made a mistake in the link for my last post, here is the correct link: Project Processes INs and OUTs

We are entering out third and last cycle of development for AceProject 4.6. So far, the agile method has been working well, and we think AceProject 4.6 will benefit greatly from shorter iterative development cycles. Today, I want to show you three really nice improvements we've made to AceProject. No need to close the task to save your changes We were getting a lot of comments from our users about the inability to just Save a task in AceProject. Before 4.6, you need to navigate to another tab or close the task in order to save your changes. It was annoying and a waste of time. Well, not anymore! We've added a new option to the Update button: Update + Keep Open . Documents go public Another request we had from our user was about documents, that it woul be nice to permit some documents to be seen by people outside their AceProject team. We thought that was a great idea! Now, AceProject task and project documents can be public. When a document is public, anyone who has the link to that document can see it, without the need to log in to AceProject. This is a great feature if you want to show your client a screen mock-up, for example. You'll know when you can start the work With AceProject 4.6, when your tasks are controlled by a dependency link, AceProject will tell you when you can start working on them. You won't need to check if the predecessors are completed, AceProject will do it for you and send you an email like this: Expect AceProject 4.6 for Christmas We're starting out last development iteration today. Our goal is to make it available in December for online accounts, and early 2009 for the Source Code package.

By Cameron Watson, QAIassist I was sitting in the park last week and my mind began to reflect on how the IT industry has evolved over the past 50 years. What once was loading registers in binary code into a computer the size of a room has evolved into everything from worldwide communications to interactive games to artificial intelligence (and everything in between) - and all at the speed of light. Suffice it to say the world has changed and the world will continue to change. The card readers and weekly batch reports have been replaced with ever evolving technology and gadgetry. As the children laughed and played on the swings and ladders my mind began to drift into the varying technologies I have had the opportunity to witness. I have to admit we should tip our collective hats to COBOL - still alive and kicking. Between the kids hoops and hollers, I came to a very basic understanding that there was a distinct difference between technology for the sake of technology and technology for the sake of business utility. More and more, we hear "if something cannot prove it is contributing to the corporate bottom line, then it brings little value." As I got up to go over to the ice cream booth, it hit me. The little light bulb when on. "No wonder business stakeholders are beginning to understand, contemplate, and even leverage the whole IT "outsourcing" delivery model. They are coming to believe its potential and trust it can contribute to the bottom line. As market conditions force organizations into achieving greater degrees of operational efficiency, additional expectations are being placed on IT to deliver products/services in a timely, cost-effective and consistent manner. Successful organizations have already recognized the correlation between increases in operational and IT efficiency and the process/methodology they are applying. As I started to indulge (butter pecan - it was perfect) I realized that business stakeholders are evaluating the ROI of their IT budget and looking to optimize operational performance. One option is to increase internal IT efficiency via process, metrics and methodology. The other option is to utilize the IT outsourcing model. Though the operational impact of these alternatives is significant, the intent is the same - to obtain more effective business solutions at a much lower price - IT "value" is the bottom line. By the time I got to the cone (ice cream all but gone), I had recognized that outsourcing vendors can not only provide estimates and costs for project development and maintenance, they can also include metrics and measurement performance benchmarks into formal contracts. Many business stakeholders are surprised that the outsourcing vendors can commit to these promises and do not understand why they can’t get them from their own IT staff. Cone now gone and a drop or two on my shirt, I realized many business stakeholders are faced with evaluating IT ROI scenarios. As outsourcing vendors continue to deliver and penetrate the IT market they are quietly and frequently proving they can deliver on their claims. The outsourcing model, once perceived to be fraught with danger and risk, is now turning into an acceptable and routine approach business stakeholders are leveraging to obtain greater IT value. As I got up from the bench I tried to understand why and how outsourcing vendors could continue to perform so well in IT markets. My initial perspective was that they have recognized the fundamentals of method-based approaches: a methodology must exist and be applied to create any product or deliver any service; a methodology must exist and act as the basis to establish, obtain and assess metric and measurement information; methodology metrics can be used to justify IT service and delivery ROI value; if IT ROI value cannot be quantified, business stakeholders will pursue alternative approaches Tired from all of the thinking, I got in the car to leave the park. I turned on the ignition and on came the radio, down went the automated windows, on came the onboard computer with the voice communication to tell me the route I should take to go home. Ah, technology. Though a beautiful thing, its continued evolution dependent on its ability to deliver ROI to business stakeholders. About QAIassist QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist Context I am hoping to spend some time this week to discuss methodology structure. A multitude of methodologies or lifecycles exist and are routinely applied by the IT resources of most organizations. Just to name a few, here are the better known ones: project management, software development, software testing, etc. Commercially purchased methodologies are similar in many ways. They establish a set of terms and vocabulary that remains consistent throughout the methodology. They all rely on a phased naming structure, for example : Initiate, Plan, Execute & Control, Closeout. This phase terminology is used as the basis to guide a project through the methodology. They all have a pre-defined set of deliverables and/or activities that must be addressed within each specific phase. The pre-defined activities and deliverables of each phase can be scaled to reflect the methodology needs of the project. The following generic example provides a description of a structure, naming conventions, and terminology used to describe a project management methodology. Project Management Methodology A project management (PM) methodology consists of four unique phases: Initiate , Plan , Execute & Control , and Closeout . Within each phase, PM deliverables are created and administered. Progression through the following phases is dependent on obtaining the appropriate authorizations from the designated project owners and stakeholders. Initiate is the first phase to be performed within a project management methodology. It is the process of formally recognizing that a project exists and has obtained the appropriate level of authority to continue. The purpose of this phase is twofold. First, to assess and determine a business need. Second, to translate high level business requirements into a document so the project team can confirm if the project requirements can be fulfilled. This phase begins when a business case has been prepared and approved and a project has been authorized to proceed. This is traditionally an iterative process between the business stakeholders and the designated project manager. Plan this is the second phase to be performed within a project management methodology. It is the process of recognizing that a project has been authorized and requires further resources to devise, maintain and execute a workable plan to ensure the business solution is effectively implemented. The workable plan must address matters associated with project scope, resource requirements, project team roles, deliverables to be prepared throughout the project, a schedule to define how and when the project will be completed, and the activities to be applied to ensure "quality" is incorporated into the solution. Execute & Control is the third phase to be performed within a project management discipline. This process is three-fold: Coordinating the activities of the project team resources to ensure the project can be completed according to the project plan, Monitoring the progress of the project activities against the project plan Taking the appropriate corrective action when the project is deviating from project plan. The Project Manager prepares and uses a number of specific deliverables to ensure project procedures are available to the project team, the project management deliverables are maintained throughout the life of the project, deviations to scope, schedule and resources are addressed in a timely fashion. Closeout is the final project management phase. Its purpose is to document a true reflection of how the project evolved from start date through to its completion so that future organizational projects can benefit from the knowledge and experience gained on the project. Future project teams can then leverage this knowledge to increase the efficiencies on delivering business solutions to their clients. Wrap Up Although Project Management, Software Development and Software Testing methodologies and lifecycles have been created and applied to address unique and specific needs, they are similar in that they all rely on a phased structure, unique terminology, pre-defined set of deliverables and/or activities that must be addressed within each specific “phase”. A methodology context diagram illustrating these three methodologies, the phases applicable to each and a list of specific deliverables can be viewed here. (LINK to PDF placemat file – I can also add it as an image in the post) About QAIassist QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

What are you? Are you a technical specialist? What's your specialty? What about your team: what's their specialty? How would you feel if your team members tried to manage the project in your place? How would you like the software engineer trying to replan the project to meet the deadline? I bet you would not like it. Not one bit. Yet, how often do we do this to our teams? How often to we try to be specialists in their own discipline? It's one thing to want to be helpful and to makes suggestions. It's another to assume we know better than they do. After all, we're the project managers because we are good a managing . She's en engineer because she's good at engineering . Project Managers: we don't need to know everything about everything It's ok to defer for the technical expert in your team. It's ok if they answer the question and not you. They don't get to do that often. If they fix an issue, they should be rewarded for it. If you fix a team conflict, that your accomplishment. It's OK to say "I don't know." As project managers, our job is not to know everything. Our job is to know where we can find the information. Our job is to trust and believe that our teams are the best team to deliver on time and on budget. And if they're not, it's our jobs to develop the project team into the best team to deliver on time and on budget. That's our specialty. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

This week Josh from pmstudent.com contacted me to update a study help Excel sheet I built back when I was studying for my PMP exam. With the PMBOK update, the spreadsheet was obsolete. As I was updating the processes, inputs and outputs, I noticed that while the processes themselves hadn't changed much, the inputs and outputs terminology has changed quite a bit - and for the better! For example, instead of listing all the management plans (human resources management plan, comminucations management plan, quality management plan, etc.), the PMBOK nos simply lists "project documents." A much simpler term. I saw two new things in the inputs and outputs: Requirements traceability matrix. It's a table designed to link requirements with their origin, like a business need or a project objective. Stakeholder register. Similar to a risk register, it's a document where information about the stakeholders is kept. This is useful to make sure all stakeholders are involved in the project at the proper level. Download the study helper: Excel 2000-2003 2007 Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

It's that time of year again: most of us are getting ready to a well-deserved break from projects and business. On behalf of the whole team, I would like to give you my warmest wishes for the holiday season and the coming year. Yes, we're taking a break too! We would like to inform you that the AceProject team is taking a break during the holidays. Our offices will be closed from December 24nd, reopening January 5th. If you encounter an emergency during this period, please send an email support@aceproject.com . We will keep an eye on our inbox during that period. Note that our servers will remain online during this period. There will be no interruption of service for Hosted accounts. Thank you for using AceProject AceProject would not be the success it is today without you. We would like to thank you for using AceProject. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

At Websystems, we have IP phones that forward our voicemail messages to our email addresses. This is very convenient, since we can forward the message to the appropriate person easily. The voicemail notification also contains any special information entered by the caller, such as confidential or urgent. Naturally, when I saw a voicemail marked urgent in my inbox, I listened to it right away. It could be a client with a problem that is keeping his team from working. It wasn’t. About 20 seconds into the message, I realized the call was not an emergency; it was a sales pitch, for an outsourced sales call service. I immediately stopped listening to the message and deleted it. My only regret is that I didn’t catch the product’s name. If I had, I would have made sure I never buy that product or any product from that company. Leaving a fake urgent message to make sure I listen to it is disrespectful. It’s bad salesmanship. While it did get me to listen to the message, it had the opposite effect. It convinced me never to buy the very product he was trying to sell. You get only one chance to make a good first impression. He blew it. This salesperson blew it for his product and his whole company. If he had left me a regular voicemail message, I would have called back, if only to let him know whether we are interested in the product. It’s the decent thing to do. The first contact with a potential client is so crucial. The impression they will get of your company and your product will be shaped by the way they feel they are treated on that first contact. Guess who’s the first contact? Sales. Sales is one of the most important parts of the customer service team. They should be held up to the same standards of respect, courtesy and integrity as the rest of the company.

As any software development company will tell you, there are always more features to add to a version than there is time to implement them correctly. Hence, we face a challenge: implement more features with limited functionnality, or implement fewer features will full functionality. It may be tempting to implement as many features as possible: spread-sheet product assessments and feature comparisons would proudly bear the YES checkmark next to all the lines in the requirement list. However, being able to say "yes, we have reports" quickly followed by the limitations of the feature is no way to win your prospective client's heart. As they use the feature, they will quickly realize that, although the feature is there, it is stripped-down and not what he or she expected. I believe that if we are going to implement a new feature, not only should it work, but it should also be complete . It should have all the functionnality that is expected. If you can import user data, you should be able to import all user data, not just the user name and password. The end result is a piece of software that is truly usable, that clients will enjoy using. So, how to choose, then? This is the difficult question. How do we choose to implement a feature over another? There is the what the market wants, what the users want, what the developers want, and what the boss wants. Who wins? With AceProject, we keep an updated wishlist where we record how many times a specific feature has been requested. When we get ready to start working on a new version, we look at the file and choose what we will include. It's a good way to stay up-to-date with what our clients want and at the same time, get a bigger picture view of what people ask to add or change in AceProject. Once we've chosen which requested features to add in the new version, we discuss what we would like to add to make our system kick butt, so AceProject is not only user-driven, but remains the brainchild of our President. A team effort AceProject's development is very much a team effort. Our users are a big part of AceProject's team, and their suggestions never fall on deaf ears.

Project management is, in my opinion, much more about soft skills than processes and forms. In this short ebook published by the government of Canada, we get valuable advice and techniques to improve our leadership. Coaching Practices for Managers is a handbook to learn how to understand beyond what the person is really saying. It's built to make the reader think about their own acts and their own situation, so it makes it less theory and more practice. For example, the book teaches us how to see the hidden request and commitments on complaints. If someone is complaining that it takes too long to receive approvals, we can see that this person is committed to delivering on time, and that she is looking for ways to speed up the approval process. None of what's in Coaching Practices for Managers is rocket science. It's simple stuff that we can take away and use to improve how we manage our project teams. Something I especially likes about the ebook: it can be turned into a half-day workshop. There are even instructions right in the ebook to help us organize it. If you've been looking for a short read on leadership and coaching that you can put in practice easily, I highly recommend Coaching Practices for Managers Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

In most of the places where I've worked, the sales team was never seen positively. It seemed working in sales made you a worse person for it. It seems sales is seen as a manipulation effort to extract money from people, barely above theft. It's time to adjust our perspectives, no? I was once travelling with a sales rep and he told me "you know, sales is the team that goes and gets the money for your paycheck. It's great that I get to sell a product that works so well." There is the symbiosis. We need sales to develop relationships with our clients and we need a great product and great service to keep the client coming back. Sales is really only pre-sales customer service. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

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.

Sometimes, that new feature that took so much time and effort, that was so complicated to implement, is not important to the client. This can be heartbreaking for developers. I've seen it often: my press release is sent for approval, and the project manager comes to me, asking why the new feature is not mentioned in the release. I see disapointment in his eyes. After all, they worked really hard to make it work. All that effort should translate into a killer feature that customers will flock to, right? Not always. Sometimes the effort translates into something that is taken for granted by the client. Sometimes, the little-worked-on feature turns out to be the big selling point for a product. The case of the one-client feature There was this product launch where the development team had implemented a very complex algorithm in the product, at the express request of a client. The client himself was very pleased with the algorithm. However, he was the only one in the market to use it: this client was such a pionneer in his field, no one else was ready to implement that kind of reporting. And so our development team felt like they worked hard for nothing. About this they were wrong. Their work was worth it. The client who adopted this feature was one of the biggest accounts in the company. Unfortunately, it did not have the right appeal for the market at the time. So it was left out of the press release. The case of the feature taken for granted It may be really complicated to develop something, but it has nothing to do with its perceived value by the client. Sometimes the work that goes behind a simple button goes unrecognized. Or sometimes, the market simply expects this feature to be in the basic system, and is not willing to buy a product solely based on that feature. Case in point: Task dependencies. Task dependencies were a tough cookie to implement in AceProject. Our development team worked really hard, for a long time, to make it work. However, for our clients, it's only normal that we support task dependencies. How hard we worked on it had not effect on the value of that feature to our users. The case of the widely popular feature Sometimes, the opposite happens: this one feature, that was very easy to implement, turns out to be a key selling point for the software. A few years back, a developer on the team had time left from his debugging schedule, so he decided to clean up the code for a file import feature. It made such a difference for the users! We were able to sell more copies because importing files from our competitor's system worked smoothly. This was amazing to the developer: to him, it was just a few hours of improving some code. For the users, it was a time-saver. The lesson to be learned As the title says, effort and value are not equal, simply because the effort involved in accomplishing something is not always perceivable to the client. However, internally, we should recognize the effort, even if it's not the star feature. After all, if the "taken for granted" features were not there, we would have no software to sell.

By Cameron Watson, QAIassist I am very pleased to have the opportunity to share my knowledge and experience with the readers of the AceProject blog. I want to say thanks to AceProject (and Karine Simard) for granting me this opportunity. My intent in writing is to help the various audiences and users of IT methodology obtain a more in depth knowledge of how IT methodologies (project management, software development, software testing) can be utilized and leveraged to contribute to increasing IT efficiency, operational performance and organizational bottom line. The ancient Greeks first coined the term "methodos" - its definition meaning "path". They applied this term in various contexts - as a noun "a path that could be followed to reach a destination" and a verb "the journey to be taken along a path". Though several millennia have passed since the ancient Greeks first used the term, it is still applicable in today's world of Information Technology (IT) - it’s called "IT Methodology". As simple as the term IT Methodology may appear, it is intriguing to see how it can be applied in such a variety of contexts, by such a wide array of experts, to such a diversified set of audiences. Suffice it to say, this lack of clarity and context has introduced its own share of confusion, misunderstanding, miscommunication and misadventure. Let’s provide a context around the term "IT Methodology" IT Methodology – the road you take As a noun, "methodos" can be equated to a road on a map. For example, the highway that connects Boston to New York. It has a beginning and an end. It is tangible. It has a predefined set of destinations that must be passed along the way, such as a city, a town, a river, a crossroads, etc. The road is constant and indifferent to how many vehicles use it, what vehicle is to be used, how many people are in each vehicle, how fast each vehicle travels or how many times the vehicle starts and stops during its journey. As a noun, "IT methodology" is much the same as the road. It has a beginning and an end. It has a pre-defined set of criteria that must be passed along the way: lifecycles, phases, deliverables, work products, etc. It is consistent and indifferent to how many projects utilize it, the scope of each of the projects, the size of the project team, the speed at which a project team completes it, the number of iterations a project team employs. Examples include ITIL, Rational Unified Process (RUP), CoBit, and QAIassist Integrated Methodology. IT Methodology - how you travel that road As a verb, "methodos" describes how the road will be used. Travelers using the road between Boston and New York have the option to travel in the vehicle of their choice at the speed they wish, and to make as many stops as they wish along the way. As a verb, "IT Methodology" is the delivery approach a project team takes to get to its destination, a completed project. Examples of delivery approaches include Waterfall, Spiral, Rapid Application Development (RAD), Agile, Joint Application Development (JAD), and Scrum. IT’s not all Greek Though the effort to understand the term "IT methodology" may appear to be long, winding and Greek to many, there is a difference between the “road” used to get to the destination and the “activities” that will be performed while on the road and heading to the destination. While most people will agree that it’s important to agree on the goal of a project, we tend to forget that agreeing on how we will achieve that goal is just as important. About QAIassist QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

I'm sitting in the train, coming back home to Quebec from Montreal . Via Rail, the train company, offers WiFi connectivity for 8.95$ per day. That seems a little expensive to me, so I decided that me and my laptop would go alone. Offline. That’s when I realized how much time I spent online, for my personal and my work life. AceProject is an online project management system. Everything we do at Websystems is somehow connected to the Internet: the CRM, the system, our VOIP phones, the email server. If we were to lose our Internet connection at the office, most of us would be sitting idly until it comes back. So here I am, sitting in a train, without Internet access on my laptop. And my laptop feels useless. If I can’t read my RSS feeds, check website performance statistics, stay up-to-date on customer requests, manage my projects or even keep up with the daily email, what’s left to do for a project manager/sales & marketing person? I'm still looking.

Scott at WebWorkerDaily has a very good point: "Please let my account die gracefully, peacefully and with dignity." I think a lot of us share Scott's problem: We try a new web service or product, we setup a free account, and quickly forget about it...only we can't. Because we keep receiving emails from these services. Even though we haven't logged into those accounts for months, and have never clicked on any link in the email or responded in any way to the call to action, we still receive about an email a week from these services. I classify them as spam, and forget about them. The problem I have with these is that they pollute my email inbox, and they waste my time. AceProject has a free account anyone can create. It is limited to 5 users, 5 projects, 50 tasks and 25MB of file storage. It gives prospective clients a chance to take AceProject on a test run. If they like AceProject, they can upgrade their free account. If they don't like AceProject, they can forget it. Free AceProject account that are inactive for 30 days are deleted automatically, and we will never contact these people again. While some people may think it's nice to have a very large database of people to spam, I doubt there is any money to be made, long term, from annoying people. Whatever happened to doing the right thing?

We are proud to announce that all paid accounts will have their own private SQL Server database from now on. Previously, only the Hosted Gold package and the grandfathered Hosted Pro used to have a private database. As a result, Hosted Standard and Hosted Advanced accounts will get the following benefits: FTP access for downloading your database backups (*.bak files) and project/task documents. The ability to query your SQL Server database remotely in real-time and generate custom reports using tools like SAP Crystal Reports or Microsoft SQL Server Management Studio. All branding options (including application rename and logo/header background upload). Get your sub-domain (new for all packages), that is, AccountID.aceproject.com . No more generic login page URLs. Performance is better in a private environment than in a shared one. Do not hesitate to contact us should you have any inquiries in this matter. Connect with Sylvain Traversy and the AceProject team via Facebook , LinkedIn and Twitter .

Recession is on everyone’s mind these days. Whether your organization is currently affected by the economic conditions or not, most of us are looking at your spending, to see if where we can save. Another place to look is your partners: your business partners, your suppliers, your clients. If your main supplier goes bankrupt, it could affect your business as significantly as if your biggest client cancels all orders. In a recession, the businesses that survive are those with the least debt and those with enough cash flow. As sales may dwindle from lower demand, businesses that are debt-free will be able to weather the storm, while those with a lot of debt would fold under the pressure of the payments. Furthermore, recessions are good times to invest, to be ready with new offerings when demand picks up on the other side of crisis. Because demand always picks up, sooner or later. However, if all R&D activities are suspended while money is tight, the business falls behind its competition, and it’s very difficult to pick up that lag when times get better. Websystems is debt-free. Our business strategy has always been to spend money we have now, and not the money we hope to get. Websystems was born during the 2001 dot.com crash. We started at a time where businesses were closing all around us. Being debt-free makes it possible for us to invest in our product. In a way, this is our second recession, and we will go through this one the same as 7 years ago: by working hard at building the best AceProject we can. We are planning a complete rebuild of AceProject. We are taking advantage of the slower times to focus on our application and rethinking the whole thing. These are very creative times here at Websystems.

I love our product, AceProject . I have unwavering faith in the system as it is now, and its potential in the future. When the whole gang here sit down to have lunch, I really like to dream up the future's AceProject together. To share our vision of what AceProject could be in five years. And it's all good. Because the team and I know what can really be done, and how much of our dreaming is just dreams. When we sit on the next version planning meeting, things get more practical: what CAN we do? True, we could recode the entire system, but that would mean no new features for our users for a long time. That would make our users unhappy. We need to balance both the expectations of people who use AceProject everyday, and the expectations of the visionaries we have on the team. Our clients expect us to release new features at least twice a year. Our dreamers on the team (and I am one of them) expect AceProject to kick butt. The thing is, AceProject can be great and be updated often. We simply need to manage expectations on both sides that push development. How do you manage expectations in your project? Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

It seems to me marketing is about convincing people to buy a product. In so doing, should it not tell people something that makes sense? Especially in business-to-business marketing, I don't want to insult my reader's intelligence by telling them a bunch of nonsense. Do they really care about how great I think my product is? Maybe they do. I think what they care about is what my product can do for them, for real. How much time will they save? How much more money could they make? How much easier will their life be with the product? I understand that it may be difficult to make precise statements in reply to those questions. But in the end, that's what most of us want: more time, more money, less difficulty. Which translates in more happiness. I firmly believe we can market products concisely, clearly, without resorting to complicated statements. Marketing should make sense.

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.

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.

By Cameron Watson, QAIassist Context I was invited out to lunch last week by an old friend and colleague. We had worked at the same organization many years ago and had stayed in touch throughout the years. Once seated and our meals ordered, he broke the news. He had recently accepted a senior management position at a reputed fortune 500 company’ His role would be to guide the project managed office (PMO) for the company. After receiving my congratulations, a somber and concerned look came over his face – he stated “I think I have just made a serious error with regard to my career.” As we discussed things further I began to gain an appreciation for his statement. He drew an analogy to a train wreck that gets replayed day after day after day – a perpetual circle of point the finger and lay the blame – without a beginning and without an end. He began citing a number of instances. The users were in a constant state of wondering why changes to existing applications took so long. The IT application maintenance staff did not have any documentation to scope or verify changes being made. The development staff were creating applications in days without reviewing the development iterations with the user community. Testing (of any kind) was not performed on any of the applications being placed into the production environment. As a result, the work environment became tainted with a “watch your behind,” “never trust a user”, “never trust a tech” mentality. Upon completing the description he looked at me with a bewildered look and said “what am I going to do ?” I asked “what IT methodology is the organization using?” He responded “there is no recognized or formal IT methodology being used. Every project and maintenance team has their own approach and none of them are documented or communicated to the user community”. I told him the more difficult the problem the simpler the solution must be. I suggested that he could do one of two things. 1. He could call his boss from his previous position and get his old job back; 2. He could accept his new organization for what it was and make an effort to turn things around and point it in the right direction. He acknowledged my point and we started down another tangent talking about what could be done at his new position to remedy the situation. He told me “the floor is mine” and asked for suggestions on how I would address things. I said that my most immediate concern would be the poor communication between the various departments and staff in the organization. Poor internal communications is often the root cause for a culture of finger pointing and lack of accountability. Then, I mentioned that the lack of formal IT methodology appeared to be the most significant deficiency within the organization. Although many people subscribe to the notion that an IT methodology is used to consistently deliver quality applications in a timely manner, it can also provide additional benefits to an organization. More specifically, it would Provide a common tool and language that organizational staff (business and IT) can utilize for developing and maintaining applications; Create a framework that organizational resources could leverage to perform project management, software development & maintenance, and software testing; Establish a deliverable-based and scalable process to address a multitude of IT projects to ensure organizational resources could be proficient on a multitude of applications in a multitude of environments. As we left the eatery he thanked me for getting out to lunch with him and was appreciative that I was able to toss my two cents into the discussion. I then asked him if he was going to call his old boss back. He smiled with a glint in his eye and said, “no way – there is an organization that has to be saved and I’ve got to start that effort this very afternoon.” Suffice it to say, I am looking forward to getting back out to lunch with him in a month or so. I am interested to hear how his effort is going and hoping to be able to add another two cents. I’ll keep you posted. About QAIassist QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

The short answer: no one. When we are not the person who has decided the change, it automatically creates uncertainty. There are very few people who like uncertainty in their life. When project managers decide to change their methods, it creates uncertainty. This uncertainty shows up as resistance to change: in you project team, your organization's direction and your client. As the project manager, it's your job to communicate the change well: Why are you changing your methods? What is expected to be gain with this method? What is the impact of the change on the team, the direction, the client? Moreover, as the project manager, it's your job to pay attention to how your stakeholders react to the change. Are people "getting with the program?" Is resistance getting stronger or weaker? It's important to be close to your team, direction and clients. It's your responsibility to sell the change, and then make sure it brings the benefits you sold your stakeholders.

Normal 0 false false false false EN-US X-NONE X-NONE Context From its inception Information Technology (IT) has recognized the significance and importance of developing and applying a set of “standards”, “methodologies”, “lifecycles” and “best practices” that can be leveraged by all practitioners. As the industry has evolved, the technologies have become more complex, increasingly faster, and forever changing, however, there remains a set of basic principles and concepts that are as applicable today as when IT was in its infancy. One of initial concepts created and applied by early IT practitioners was the “V” Model. It was created to ensure project teams had a mechanism with which they could · accurately define and refine user requirements · design and build an application according to the authorized user requirements · validate that the application they had built adhered to the authorized business requirements The “V” model evolved in the 1960’s – since that time various institutions and authors have revised, enhanced and extrapolated on it. It is possible to see a multitude of versions of the “V” model – each with its own customized terminology, phase names, and depictions. Though the IT industry has made significant strides since its inception, the principles defined by the “V” model are as applicable today as when the model was first created. “V” Model Diagram – Construct For the sake of this document we have used the above diagram as a basis to illustrate the “V” Model. It consists of shapes, arrows, and terminology - this structure will be used to explain the underlying principles of the “V” model. Circles - At the upper left and upper right corner of the diagram are two green circles – they are used to denote the origin and completion of a project. The “V” model does not address the factors or activities an organization utilizes to authorize the startup of a “project” nor does it address the procedures or organizational infrastructure required to support an application once it is developed and made available in a production environment. Rectangles – Seven rectangles are identified on the diagram. The generic terms (Requirements Definition, High Level Design, Detail Design, Coding, Unit Testing, Integration Testing, Acceptance Testing) have been used to reflect the phase names that are applied by a number of industry recognized methodologies. The “V” model does not suggest, imply or demand the terms an organization uses to define its development process, phases or methodology (i.e, an organization using the term “Preliminary Analysis” as its initial phase to define requirements would use that term rather than “Requirements Definition” depicted in the illustrated “V” model). Diagonal Arrows – Two diagonal arrows are used to distinguish the flow of a project. One arrow originates at the top left (Project Startup) and flows through to the coding phase of the project – this arrow reflects the development portion of the model. The other arrow originates at coding phase of the project and flows through to the project being delivered to the maintenance and support team – this arrow reflects the testing portion of the model. Horizontal Arrows – Three horizontal arrows are used to illustrate that there must be a correlation between the development portion (requirements definition and design) of the model and the testing portion that has to be performed to verify that the application being built reflects the authorized requirements and design. These horizontal lines have been labeled with “Review/Test”. “V” Model – Principles The following principles are inherent when the “V” model is applied. Large to Small - This principle states requirements, standards, testing from a hierarchical perspective. For example, requirements (left side of the diagram) are identified and defined as a project team evolves through the Requirements Definition, High-Level Design, and Detailed Design phases of their project. As each of these phases are completed the requirements they are defining become more and more refined and detailed (when defining the requirements to build a space shuttle a requirement defined during the Requirements Analysis phase may be that the space shuttle required landing gear whereas a requirement defined at the Detailed Design phase would be that the wheels of the landing gear are to be made of rubber and able to withstand the force of landing at 300 mph – the requirements get further refined with additional granularity as the project evolves). Data/Process Integrity – This principle states that the successful design of any solution requires the incorporation and cohesion of both data and process(es). As the requirements are defined data and process elements must be identified for each and every requirement. Scalability – This principle states that the “V” concept has the flexibility to accommodate any IT project irrespective of its size, complexity or duration. The “V” concept is as applicable to a large mainframe development project applying a waterfall approach as it is to a web-based development project applying agile techniques. Cross Referencing – This principle states that there must be a direct correlation between every requirement that has been defined with a corresponding and verifiable testing activity and result that substantiates that each and every authorized requirement has been incorporated into the completed application. Tangible Documentation – This principle states that there must be tangible documentation (electronic and/or hardcopy) created as the project evolves. This documentation is required and applied by both the development project team and the support team that will be maintaining the application once it is available in a production environment. The “V” model does not suggest specific document titles or templates or formats. The “V” model does not suggest how many documents must be prepared or authorized or utilized throughout the projects life. “V” Model Flow - Seven Steps Step I - At this level (Requirements Definition and Acceptance Testing) the project team is accountable for three primary responsibilities. The first responsibility is to begin defining the high level (most broad) requirements of the application being developed. The second responsibility is to begin planning the testing activities that will have to be performed to verify the high level requirements have been incorporated and satisfied. The third responsibility is to establish the pre-defined conditions that will have to be tested to verify the high level requirements (most broad) have been incorporated and satisfied. Step II - At this level (High Level Design and Integration Testing) the project team is accountable for four primary responsibilities. The first responsibility is to further refine the granularity of the high-level requirements established during the Requirements Definition phase. The second responsibility is to begin creating a high level solution design based on the requirements established during the Requirements Definition. The third responsibility is to begin planning the testing activities to be performed to verify the requirements (at the High-Level Design phase) have been incorporated and satisfied. The fourth responsibility is to establish the pre-defined conditions that will have to be tested to verify the High-Level Design phase requirements have been incorporated and satisfied. Step III - At this level (Detailed Design and Unit Testing) the project team is accountable for four primary responsibilities. The first responsibility is to further refine the granularity of the requirements established during the High-Level Design phase. The second responsibility is to continue refining the design and solution based on the requirements established during the High-Level Design phase – this includes the creation of specifications (functional and/or technical) used to create the application. The third responsibility is to begin planning the testing activities to be performed to verify the requirements (at the Detailed Design phase) have been incorporated and satisfied. The fourth responsibility is to establish the pre-defined conditions that will have to be tested to verify the Detailed Design phase requirements have been incorporated and satisfied. Step IV – At this level (Coding) the project team has one primary responsibility. That responsibility is to translate the specifications created in the Detailed Design phase into technical code (in whatever platform or language). Step V – At this level (Unit Testing) the project team is accountable for three primary responsibilities. First, to execute the Unit Test phase activities according to pre-defined Unit Test plan (established in Step III). Second, to identify and document deviations between “pre-defined anticipated results” with “actual testing results” for each and every unit/program. Third, to ensure all pre-defined Unit Test cases have been executed and all the expectant results have been achieved. There will be one or several iterations of this step between the development team and the testing team to ensure all of the appropriate requirements have been defined and successfully tested – once this step has been finalized the project team will continue with Step VI. Step VI – At this level (Integration Testing) the project team is accountable for three primary responsibilities. First, to execute the Integration Test phase testing activities according to plan (established in Step II). Second, to identify and document deviations between “pre-defined anticipated results” with “actual testing results” for each and every sub-system. Third, to ensure all pre-defined Integration Test cases have been executed and all the expectant results have been achieved. There may be one or several iterations of this step between the development team and the testing team to ensure all of the appropriate requirements have been defined and successfully tested – once this step has been finalized the project team will continue with Step VII. Step VII – At this level (Acceptance Testing) the project team is accountable for three primary responsibilities. First, to execute the Acceptance Test phase testing activities according to plan (established in Step I). Second, to identify and document deviations between “pre-defined anticipated results” with “actual testing results” for the application. Third, to ensure all pre-defined Integration Test cases have been executed and all the expectant results have been achieved. There may be one or several iterations of this step between the development team and the testing team to ensure all of the appropriate requirements have been defined and successfully tested – once this step has been finalized the project team will have completed its work and the application can be made available in the production environment. “V” Model Diagram – Benefits Applicability – the “V” model affords organizations and project teams a guide to performing and completing projects in a consistent and repeatable manner. Applying the principles of the “V” model ensures the user requirements are identified and documented, the authorized requirements can be traced into the functions of the completed application, and the application reflects the user requirements. Flexibility – the principles of the “V” model are applicable in both development and maintenance/support environments and can be applied using one or many (spiral, rapid application development, prototyping, waterfall, agile) approaches. Formality/Process – in applying the principles of the “V” model an organization can establish a formal and standardized process they use to develop and/or maintain applications. Having a standardized process enables them to quantify the quality being delivered by the process, establish and leverage process metrics to continually evaluate and improve the process, increase versatility of staff to work on varied applications, reduce training costs by limiting the number of lifecycles, methodologies, deliverables being used by multiple application teams. Support Documentation – there is always a balance that must be considered when developing a new application. The equation – the time saved to create the application by accelerating the development process versus the time lost in trying to find information to maintain the same application without effective reference material and documentation. Every organization is unique as are the environments, methods, tools, and techniques they use to develop and maintain applications – the amount of documentation needed is subjective to the organization. The “V” model provides a logical and practical framework to ensure the appropriate amount of documentation can be created during development and referenced in support. Adherence – all of the principles of the “V” model can be applied using the majority of all industry recognized methodologies, lifecycles and project management tools. Cameron Watson is the President of QAIassist. QAIassist helps organizations increase and optimise their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website — www.qaiassist.com

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.

Yesterday I wrote about my heart-breaking separation from my beloved Xobni. So how can we keep this from happening at our company? How do we keep our clients happy? 1. Close mouth, open ears It's the most basic part. Listen to your clients. REALLY listen to them, don't just hear them talk while imagining reasons why they're wrong. If you really pay attention to what your product's users are saying, you'll know exactly where the pain points are in the product and you'll have your priority list all drawn up for you. A few days after people create an account with AceProject, we send them an email and ask them what they think of the product, if they can suggest improvements or missing feature. The response we get is a very good source of inspiration for us. 2. Aggravation is really bad An exasperated client should never be ignored or dismissed. If you let aggravation at your product go unchecked, it only grows and never brings anything good to you, your product or your users. When someone is angry at your product, it should by your duty to get some one-on-one time with them and try to understand what's making them so unhappy. In my experience, frustrated clients often start by stating something like "your product sucks!" When I call them for details about the suckiness, I realize the true source of the frustration is something different: it might be that they feel they didn't get good service, or they don't understand a part of AceProject, or that there was a misunderstanding. 90% of the time, their aggravation is defused by having a real human call them, listen to them vent their emotions, and be willing to work with them to fix what makes them unhappy. 3. The personal touch works Customer service should be answered by a human, not a machine. It's just better . In our business, most of our clients do business with us without ever talking or emailing us here at customer service. They do it all online. When they need help, it always makes them really happy to hear a real human's voice on the line. 4. Test, test, test Of course, the basics of keeping customers happy is to deliver a functioning product. The key to this is not just to build a good product, but also to test like a gang of madmen. At AceProject, we test on 5 different browsers in two languages. We'd rather keep AceProject in beta longer than deliver something that's full bugs - there's nothing like a buggy system to make your users aggravated, and we've established that was bad . 5. Check your pride at the door That's the hardest one. You've worked on our new product for so long. In your eyes, it's perfect. You've spent a significant amount of time and effort in making flawless. How could someone find fault with it? Surely they must be wrong. Actually, you've been working with our nose so close to the tree, you don't see the forest anymore. You don't see the big picture. The product may be perfect for you , but you're not the ones who will buy it. The thing is humans hate to be wrong. With a vengeance. So when a client pipes up and says "you product sucks!" our first reaction is disbelief. I have so many times heard people in marketing and development say thing like "oh, this client doesn't know what she's doing, how can she criticize our product?" We must remember that we are building products that people will want to buy. If no one likes our product but us, there is no point trying to sell it. So we have to let go of our pride and be willing to admit we're not the only ones who can bring good suggestions to the table.

Webcom in Montreal today was a very stimulating conference. While the last one, in May, was all about being open (APIs, OpenID, etc), this one seems to be all about 2.0. The revolution in marketing, medias, products and doing business in the modern world. In the spirit of the conference, I decided to use Google Wave to document the conferences I was going to attend during the day. A few participants joined me in my documentation of the wave. I’ve had a Google Wave account (and the envy of more than a few of my peers) for a few weeks now, but I hadn’t had a chance to really use it. With Webcom, everyone was taking notes and sharing their impressions of Webcom. While I was more inclined to summarize what was being said, others we adding context and reference links. The result is a rather complete document of the talks. It was more than a wiki (no coding required) and it was more than simple collaboration (everyone is in the same document and types without affecting everyone else). Here are some screenshots of what it looks like: Anyway, back to Webcom As I wrote earlier, the theme was definitely change. How social media is changing everything: how we do business, how we work together, how we market our products, how we manage our projects. Social media could very well be our generation’s quiet revolution. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

A new default skin will be introducted in our next version (4.8). All users who are currently set with the "Classic Blue" skin (the default right now) will see the new skin as soon as they get upgraded. Michel, our graphic designer, has been working hard on that skin for quite a while. The skin is still under development, but should pretty much look like this: The header tabs look more modern, as they have no rounded corners. We also added a touch of our logo to the skin. Actually, Michel decided to use the circled arrow's red for the "Print the Main Page" button. Furthermore, the skin uses our upcoming new website's colors. Feedback is always appreciated! Connect with Sylvain Traversy and the AceProject team via Facebook , LinkedIn and Twitter .

During my vacation we traveled to Europe. We originally planned to stay one week in Paris and a second week in Madrid. After 4 days in Paris, we realized we would get bored if we stayed the whole week. We had two options: Stay and be bored. Pull a map of Europe and choose a place to visit for a couple of days. We chose to take the train and visit Brussels. Project plans should allow for flexibility While it's important to have goals and to know how we will achieve them, it's also crucial to remember that the one thing that is certain about your project plan, is that it will change. It may be tempting to stay with the plan at all costs. The plan was thought through and approved. It's the path that was chosen to get complete the project. However, as time goes, what you and your team know will improve, and that will change how you see completing the project. One's aversion to change should not be an obstacle to adjusting the plan. As @threew said: a plan must allow flexibility. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

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?

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.

In AceProject, users may be given two statuses: "Can Login" and "Can't Login". The default option is "Can Login", which means that the user CAN access the application. On the other hand, "Can't Login" means that the user CANNOT access the application. In other words, the user is blocked. There are a two main reasons why an administrator may want this: Block employees who no longer work for the organization Usually, when someone leaves the company or gets fired, their access to the corporate intranet and other internal systems gets revoked. If they don't belong in the organization anymore, they don't belong in the internal systems either. That's usual procedure. If you need to keep an history of the user's activity in the account, you can't delete their profile as AceProject will ask you to delete all the user's data altogether. In this case, setting the user as "Can't Login" is ideal as they still exist in the account but can't access it. Create non-human users (i.e. material resources) We've seen clients who created user profiles for material such as hardware, meeting rooms or vehicles. When they assigned resources to their projects, it looked like this: Assigned Users: John Julia Peter Room #209 LCD Display Projector Since material can't login (can it? :-)), there is no need to set it as "Can Login". While not being a workaround for material resources management, this is way to assign non-human resources to your projects and tasks nevertheless. Connect with Sylvain Traversy and the AceProject team via Facebook , LinkedIn and Twitter .

I have a bachelor's degree in journalism. If I met my former classmates, they would frown at my career in marketing, thinking that I had gone on the dark side of force, so to speak. I think they're wrong. In my mind, journalism and marketing are not quite different. What changes is the audience and the product. Let's face it, the more papers a story sells - or the more viewers a TV newscast gets - the more successful the journalist seems to be. And if a newspaper does not have enough readers, the content is the first to be blamed. Marketing and journalism are about reaching out to people For the marketer, the audience is the clients, actual, and future, for the product we are selling. We want our clients to know about our company and our product, or at least interest them enough so that they will check it out. Journalists want to reach their market as well, except they call it an audience. They're still the same humans, and what they provide is information and opinion. Journalists want to reach people so that they will read the next paragraph or stay on the TV channel during the commercial break. Good marketing and good journalism have strong ethics Both in journalism and marketing, there are dishonest people who will manipulate their audience into a specific frame of mind, to form the desired opinion. However, both good journalists and good marketers will achieve this without hiding the truth or presenting opinions as facts. A marketer who believes in her product doesn’t need to fabricate facts to convince her clients to buy her product. The same way, a journalist who believes in fair and balanced reporting is not out to promote an agenda and will publish her article, even if the facts are not how she expected them to be. Marketing and journalism are about selling It's pretty obvious that marketing is about selling: selling a product, selling sympathy to orphans in the third world, selling an idea. If there is nothing to sell, there would be no marketing. Now, not everything is bought with money. In politics, marketers are trying to get people's votes, not their money. On the other end, it's not always obvious that journalists are also selling something: their media. Let's face it, without newspapers sales and advertisement sales, there would be no news.

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.

Why do we hate to be wrong so much? I don't know if it's misplaced pride or the fact that being wrong makes us vulnerable. What I know is that this hate of being wrong hurts projects. Have you ever been working on a project, where collectively the team refused to realize the project was going in the wrong direction? How long did it take before the team accepted the facts and moved on to fixing the problem? Being wrong is OK. Not facing it is not OK. We need to have our eyes peeled for our own mistakes, and be on the look-out for our own denials. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Software bugs by FlapJack Last week we held our Q&A webinars. The idea was simple: we wanted to answer everyone's questions about AceProject. Also, we had put together a little surprise for our attendees: screen shots of the upcoming cost tracking features. The first webinar went well and people we really happy with it! We were delighted at were looking forward to the second one. And that's when technology happened. As people were logging in the second webinar, we lost audio. Not just some attendees. Audio was down for everyone. It was bad enough that after 15 minutes, I gave up an rescheduled the webinar for this week ( December 16, 2pm EST ). I felt awful about having to strand everyone who showed up to get their questions answered. After all 60+ people showed up for the webinar, and I couldn't get it to work! I was pleasantly surprised to see how supportive the messages were during my failed troubleshooting. People told me not to worry about, that technology happens, and that they were not holding it against me. What's the lesson here? We can't control everything. People deserve more credit than we give them when it comes to technical problems. Acknowledging a problem and apologizing for the inconvenience is a simple and effective way to deal with the uncontrollable. What about you? How do you deal with the uncontrollable? Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Can our project management style affect the environment? Most of us would say yes, as long as we're working on a type of project that is physical in nature. For example, if we're building a bridge or a building, it's obvious that the project has an environmental impact. It's also obvious that the building style and practices chosen will have an impact. But we don't think about the environmental impact of office work. Beyond telecommuting to reduce our carbon footprint, here are three areas where we can affect climate change in our project management practices. The paper-free office is not a dream. As project managers, we have an impact on how we produce our status reports and other documentation to support the project. We have a choice on the media we use to distribute this information. Let's keep this in mind when we have a choice between printing and emailing a PDF file! Kick-off and team building activities with the planet in mind. Even if it's only choosing reusable glasses and mugs, our project team's carbon footprint reduction, however small, counts. Repair VS replace. Whenever possible, let's try to repair equipment instead of just buying a replacement. It's often less expensive and we are slowing the accumulation at the landfill sites. What can each of us do to reduce humanity's adverse impact on the planet? I wrote this post today to support Blog Action Day . The theme this year was climate change. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

I am very happy to introduce Method Thursdays at Go Ahead, Manage. Every Thursday, we will have a guest post by Cameron Watson, from QAIassist . Cameron is an expert when it comes to project management methodologies. I was very happy when he accepted to post weekly here! First and foremost, here is a short interview I did with Cameron this week: Tell us a little bit about yourself My name is Cameron Watson. I spent my early years growing up in a small town near Ottawa, Ontario. After graduating from college (over 25 years ago) I began my IT career as an IT printing operator with a service bureau in Toronto. After several years I was offered an opportunity to try my hand at programming a simple costing application written in Lotus123. This opportunity was the seed that got me started along the road of information technology (IT). During my first decade in IT, I followed a traditional career development path: programmer, analyst, team lead, project manager. The past 15 years has been a steady progression of applying this expertise in the disciplines of organizational process improvement, project managed office, and organizational change initiatives for a number of large organizations such as Boeing Aeroplane, OAO Technologies, and Aviva Insurance. In 2006 I began translating the lessons I had learned while attending the school of hard knocks into a company called QAIassist. Since start-up, we have helped organizations increase and optimize their IT delivery and support efficiency. Our flagship product, our Integrated Methodology, incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Away from the office, I enjoy the outdoors and wildlife, getting out for a slow drive on the back-roads, hitting a little white ball around a field, and sharing discussion and company with good friends and family. How did you develop an interest in project management? My initial interest in project management was more a result of fear than of wanting to learn. It was sink or swim time for me – either grasp the concept of project management and contribute to the team or look for another career. My primary interest was on ensuring I kept my job, and the only way that was going to happen was if I was able to learn the principles and tools of the project management discipline. My first programming assignments were a true baptism of reality. I remember my early undisciplined approach: build some code, test it, build some more code, test it. This eventually evolved into having a well defined schedule, predefined set of deliverables, roles and responsibilities, change log, etc that were used to plan, control and guide the project team. Suffice it to say I was able to retain my job. Since the fright of these early programming days, I have come to appreciate the significance of project management, the tools required to apply it, and the positive contribution it can have on delivering product, operational performance and bottom line. And how did you get interested in project management methodology specifically? While working at The Bank of Canada I had the good fortune of working on a large project team of about 60 resources. We were responsible for developing an elaborate and complex application that would administer Canada’s domestic market debt. At the same time, the Banks Information Technology Department was in the process of implementing DMR’s P+ Methodology, so we decided to apply this methodology on our project. As the project evolved, it became apparent that its success would be based on how the project was managed. The seasoned project manager developed, communicated and leveraged the project management deliverables of the methodology throughout the life of the project – these deliverables kept the project team in sync and communicating on the same page. It was intriguing to watch the project manager use the project management methodology to successfully deliver the application on time and within budget. Working through this project provided me a firsthand experience in knowing the significance of applying project management – without it the project may have failed. It was this project that made me realize the success of any project could be traced to how effectively a project management methodology was applied . In your opinion, what is the biggest challenge organizations face when implementing a project management methodology? Although most organizations rely on information technology (IT) to optimize operational efficiency and bottom line, they all apply varying degrees of project management. A major challenge any organization faces is to recognize there is a direct correlation between the degree of project management they apply versus the productivity, product, and operational efficiency that can be delivered. In some organizations, they recognize this correlation, effectively apply project management, and routinely deliver quality products and services on time and within budget. Other organizations are unaware of this correlation, do not apply focus on project management and remain in a constant state of wondering why the products and services they deliver are of inferior quality, late and over budget. The key is to ensure stakeholders are made aware of the benefits that can be derived by applying a project management discipline and providing them the support they require to better appreciate that project management will afford them a mechanism to implement a repeatable process to consistently deliver quality applications accurately define and control project scope, schedule and costs effectively monitor and communicate project progress within (business and IT staff) the project team deliver accurate status (schedule, risks, issues) to stakeholders apply organizational governance and quality assurance to application development and testing establish organizational metrics for ongoing improvement of application delivery and maintenance What's the biggest methodology mistake you've made? How did you fix it? The biggest methodology mistake I ever made was to assume if I worked less on creating and monitoring deliverables, it would save time and money as the project evolved. Although this decision saved some time and effort at the beginning of project, it soon became apparent that this lack of initial effort on the project management deliverables caused confusion. Project team members did not know their roles, the deliverables they were responsible for or which deliverables were on the critical path. The team was also unable to provide an accurate status to the project stakeholders, etc, etc etc. In a nutshell, chaos with a snowball effect. After eating a generous helping of crow as the project floundered - and getting some advice from a senior project manager, I took a step backward and created a number of project management deliverables: project charter, project plan, project schedule, etc. Once these project management deliverables were created, the project team began to focus and started working together as a united team with a common purpose to deliver the project. Suffice it to say, I learned a valuable lesson from this project. What sometimes seems to be a shortcut can lead you down a path that is longer, riskier and more costly (never mind the foul and lingering taste of the crow). Next week: IT Methodology - A long and winding road Find out more abour Cameron and QAIassit Visit QAIassist's website and get in touch with Cameron! Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Our colleague Jason from 37signals had a very interesting blog post lately. His post was elegantly summarized in this sentence: "By building products we want to use, we’re also building products that millions of other small businesses want to use." Getting a taste of one's own medicine can be an very humbling experience. Granted, not all products can be used by their makers (think industrial products). Nonetheless, both the creators and the sellers of a product would benefit from using their own stuff, if only to understand how easy (or how hard) it is to use it. In the software business, we often see interfaces that were built by people who never actually use the system. The way the system works is logical, but it simply doesn't make sense from a usability point of view. For example: confirmation pop-ups (are you sure you want to close this window?) are more a nuisance than anything else. Honestly, how often do you actually read the text of those windows? Those things are so annoying we click on OK as fast as we can, to make them go away. If you are trying to create a truly user-friendly product, you should: Enjoy using the product yourself. Listen to your user's comments about the interface very closely. Pay attention to what new employees have to say about the product: they are not assimilated in the culture yet, and they are looking at the product with fresh eyes. A lot of traditional marketing will prefer to focus on the market. Who is the market? Is it someone? Is it something? Is it a global entity? Does it have a personality? A market is a vague group of people that have varied ideas, tastes and needs. Who can really say what the market wants? Who can really build a product to fit a market's needs? What we do at Websystems is build a system that works well for us, listen to our fans and users, and deliver the best product we can make.

Todays is the 20th anniversary of the fall of the Berlin Wall . For almost 40 years, a wall divided Germans and on this day twenty years ago, the wall was taken down and the reunification of Germany was initiated. During reunification, there was much difference how people on both sides of the wall had changed since 1961, when the wall was put up. When people loose contact and live in their own separated worlds, they tend to evolve apart. A parallel can be made for the silo effect we often see in bigger companies. People are regrouped along their department: research and development, administration, management, marketing, sales, etc. While we would expect people to work together to achieve a common goal, in bigger teams, sub-teams form and have a tendency to work independently. After some time has passed, the whole project teams reunites and the project manager is confronted to two team whose idea of the project may not be compatible. These social walls - where hermetic teams are created and function independently from the rest of the project team - end up creating more conflicts than they solve in the long run. Before we can think about ways to tear those walls down, we should understand them. A walled team or just a good team that works well together? Close-knit teams are good. They are teams where people work well together and have high cohesion. These teams are not necessarily closed: they will accept new members and input from outside the team. Hermetic teams are bad. The team will not accept new team members or input from outside their team. Typically, those teams will also not interact well with the rest of the project team. Why put up walls? People create walls in their environments to protect themselves. Sometimes it's to be able to focus without interruption. Sometimes it's because they prefer to work in a smaller team. Other times, the corporate culture creates distrust between departments. How can we remove the walls? Those walled-up teams sometimes evolve naturally, and the people in it may not realize what's going on. Talking with the team is a good starting point. The second step would be to weigh the benefit of leaving the team together, compared to breaking the team up and assigning the members to different projects or different parts of the project, to encourage them to work with others more. In more extreme cases, it may be required to involve a neutral party - external to the project - to help solve the situation. Where are the walls in your projects? Walls are not necessarily physical or social in our projects. They can also be informational, technological, or even financial. In honor of the men and women who fought to tear down the wall between Eastern Europe and Western Europe, let us identify a problem barrier in our projects and think about ways to remove it. Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Regular status meetings are boring: everyone goes around the table and rehashes what they did in the last week or month. No one really cares. If the project dates are slipping, the team wants the meeting to be over with so they can get back to doing something useful. But status meetings can be fun! Yes, I know, it's a strange concept. But I've seen it happen. I was doing documentation on a software development team. The team was implementing agile development practices, and they were planning to do a release every month. This meant a big meeting with marketing, sales, the whole development team. It was important for the project lead to include the whole company in that project. She felt that it would bring the two worlds of development and marketing/sales together, that it would help people understand the other side. Since everyone had things to do in the project, I suggested that we make something visual, like a board, to monitor out progress. The rest of the team thought I was crazy, they humored me. So I built this huge board and pasted a giant photograph on it. It was about the size of 6 letter-sized pages. Then I cut out squares of colorful cardboard and pinned them over the picture, so I was the only one who knew what was behind the cardboard. Each one of those pieced of cardboard corresponded to a task in the project. It could be a feature, or finishing documentation, and even the first sale was there. So developers, marketers and sales reps all had at least a square or do to "unpin" from the board. The first month, when we did the first "unpinning," people thought it was really lame and corny. But something happened. People kept their pieces of cardboard and pinned them on the walls of their cubicles. Those pieces of yellow and purple cardboard became trophies. On the second monthly meeting, people were clapping those who got to "unpin" and there was a feeling of pride in the room. The board was displayed at the entrance of the R&D department. It gave a very visual impression of how far along the project was. And so people came to like those status meetings. Making status meetings fun means changing how it's done Status meetings should not be just about reporting what happened. They should be about accomplishment. They should be there to reward the people who did good, and motivate those who are having difficulties. If no one wants to go to the meeting, what's the point of having the meeting?

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 VS actual time, you will be able to get an average fudge ratio. In the example above, if we make an average of the individual fudge percentages (200, 25, 160), we end up with the fudge ratio of 128%, or 1.28. When you know your fudge ratio, as the LifeHacker post explains, you can pad your estimates accordingly. This will help you give more accurate estimates. The problem: most of us aren't very good at taking notes Let's face it: most of us will start with good intentions of keeping a spreadsheet somewhere with the estimated numbers and the actual numbers. Unfortunately, as deadlines get closer and the task pile keeps getting higher, we'll forget to keep the spreadsheet up to date and we will never be able to accumulate enough data to get a good fudge ratio. Most of us, however, use a project management system. Most project management systems already include estimated times for tasks. As you work on your task in AceProject, you can log your time for that task very easily: Fill out a time sheet at the end of the week Add to your time sheet directly from the task Just start a timer. To get your fudge ratio, all you have to do is go in My Office and customize your task list with the Actual % Done field included: With a task list like this, you can automatically see whether you tend to be optimistic with your estimates. Export your list to Excel, get an average from the Actual % Done and there you are. You have your fudge ratio. Now that you have it, don't be afraid fudge things up Now that you've got your fudge ratio, use it. When you're making estimates, remember your fudge ratio and apply it. If we use our example's fudge ratio (1.28), when estimating a task to take 10 hours, you should put in 13 hours (10 multiplied by the fudge ratio of 1.28). This allows breathing space for Murphy's Law to affect your project.

When managing a project, it’s important not to lose sight with who you’re working for. Your client is not always an actual customer. Not always the person who pays for the project, your client can also be the person who will use the product or service you are making. For example, if you’re reorganizing archives at your work, the client could be those who need to search the archives: administrative and customer service teams. It can be quite disheartening to deliver something that disappoints the client. After all, you worked hard on that project, and you would like people to be impressed. If you want to make sure your client is happy with your work, involve them from the start, and keep them involved all the way through. Start from a client request A project for the sake of a project is useless. Find something that someone needs, and do it. Most organizations have wish lists where clients or other employees contribute; they are a great starting place. Right from the start Even before you start planning your project, contact your clients and get them involved right away. It’s better to know right away what they really want than to have to change everything at the last minute. It also helps understand why they want things a certain way, and makes it easier to plan your project to meet those requirements. Meet often As you work on your project, you should get your clients’ input regularly. This will ensure that you are still on track, and enable you to adjust as necessary. Prove to your client that their comments are useful If your clients are involved at every step of the project, they must have a sense that their time is not wasted. That doesn’t mean you have to implement every change they request. It means that you should give them feedback on whether or not the request will be implemented, and if it won’t, why you took that decision. Make client signoff mandatory It’s easy for a client to say that they are happy with the project’s result, and then turn around and deny that they accepted it. Getting clients to sign-off on the project delivery makes them accountable. Before they sign, they will make sure that the project is really done to their satisfaction.

Background on this post This post started from a tweet that resonated with me. I realized that if we spend all our time managing emergencies, we leave the project at a standstill, without a leader or a vision. Project management and firefighting One thing most bloggers won't admit to is how they often find inspiration for their posts: in other blogs and tweets. Anywho, I found my inspiration for today's post from this Tweet: " Why do so many professionals say they are project managing, when what they are actually doing is fire fighting? - Colin Bentley" from Greg Cimmarrusti, PMP Firefighting is a management style not only used by project managers. When someone spends all their time putting out fires, they look very busy, and they have a great sense of purpose. Why so much fire fighting? It's a vicious circle. It's difficult to think long-term when fighting fires. And not thinking further than the immediate will create problems in the long run. Planning is hard. It's much easier to fix issues as they occur than the sit down and try to avoid the issues before they happen. Long term planning is even harder. Who can tell the future? Only with experience are project managers better and better at anticipating problem areas. Methodologies require discipline. One way to reduce fires is to implement a method for doing things like project initiation. Implementing a methodology and keeping up with it is difficult: it's tempting to skip over the risk management process and just jump into project execution. When we do that, we invite fires into our project. It makes people look good. Fire fighters (the real ones) are heroes. When the project manager saves the day by fixing a big, urgent issue, he becomes a hero too. And that is very addictive. How can we move from firefighter to forest rangers? While fire fighters are very visible and have a high-risk, dangerous job, forest rangers a just as important: they keep fires from starting in the first place. It's not as glamorous as fire fighting, but it causes less damage. Plan, plan, plan . Thinking ahead is the most important skill for forest rangers. They must know where the problem areas are in their projects, and figure out a way to fix the problems beforehand. Listen . Ears open, mouth closed is the best way to get information about a project's sensitive areas. Learn from the past. Those project closing meetings and lessons learned documents should not gather dust in the archives. Invest a little time now to save a lot of grief later. Not skipping project planning processes may seem time-consuming (especially from the point of view of project stakeholders), but this time will be repaid many times over in the emergencies that will be avoided. Ask for help when you need it. The problem with heroes is they sometimes try to do it all on their own...which may make things worse. If you've got too much on your place, ask for help from your team, other project managers in your organizations, or your project sponsor. Fire fighters may be glamorous, but forest rangers prevent fires Which would you rather be? The firefighting project manager that is always running around and fixing emergencies, or the forest ranger project manager who keeps projects running smoothly? Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

Next week, I'll be hosting Q&A webinars. This is the perfect moment for you to ask any any question you've ever had about AceProject! The webinar is not a sales pitch or a scripted demo. It's a simple chat with between our users and us, about our project management system. For one hour, you can ask any question you want about AceProject. Clarify how features work Give feedback on the application Ask about future development Register for the webinar here: Wednesday December 9 2009, 9am Eastern Time Wednesday December 9 2009, 2pm Eastern Time There is also a webinar in French on December 10, 2009 at 9h30 Eastern Time . I look forward to chatting with you and answering all your questions! Connect with Karine Simard and the AceProject team via Facebook , LinkedIn and Twitter .

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.

A while ago we went grocery shopping at a different shop than our usual place. It's surprising how we get used to a specific customer experience. Long story short, we were confronted with rules that seemed illogical in the purchasing of apples. It made our experience at this store negative, and we are very unlikely to shop there again. A few days later, we bought more apples from our regular store, and the experience seemed even better, because of the frustration we experienced at the other store. Which apples do you think were eaten first? We kept looking at the "apples of frustration" and just didn't want to eat them. The apples themselves were fine, but the memory of buying them was so negative that it spilled on the product. In the end, we ate those apples, but not before all the other options were exhausted. Do you want to be that choice? How people interact with you influences how they see your product. If their experience with your organization is good, they will see your product favorably, maybe even better than on the product's merit alone. Inversely, if your customer's experience with you is frustrating, they will feel that frustration every time they use your product, even if the product in itself is fine. How we treat customers is something we should strive to keep as positive as possible. The payback is high, and lasts a long time.

The blog KillerStartups reviewed AceProject, calling it: "highly effective for keeping track of all your tasks." Please go to KilleStartups and vote for us. Even better, add your two cents to Killer Startup's review with your own comment!

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.

We are back from a 3-day trip to Seattle, where we met our client, AT&T. It is so refreshing to meet clients face-to-face! With a web-based business and communications at the level they are now, we tend to forget how much more we can get out of meeting with someone in person. There is so much to learn from someone's non-verbal communication: attitude. facial expressions and reactions, gestures, etc. Now that we have met the team we work with at AT&T, we have a better understanding of who they are as persons, and this will help us serve them better. We have a feeling that wen now them as persons, and so do they. When we talk and email, we'll be able to imagine the person we are talking to. Meeting clients puts the human back in customer relations.

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?

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.

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

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.

Spore is the computer gaming world's most anticipated release. Well, it was in 2005, and in 2006, and 2007. It should be released this month. Wired has a nice recap of the release dates' evolution. Two whole years late. Spore has been set to release "in a few months" for the last two years. How does that happen? While it's perfectly understandable to have problems and delays in the development of such a groundbreaking game, I am curious to know what made the game so late. When the creators demoed the game at the E3 conference in late 2005, they expected the game to be finished and ready to ship. And yet, we are almost 3 years later and it has not been released. Is this a good example of bad project management, or a yet better example that, no matter how well the project is managed, sometimes Murphy weighs heavily in the balance?

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.

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!

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.

It it better to make the tool easy to use the first time, or everytime afterwards? For the newbies, if the use of the tool is not self-evident from the start, you're making their experience difficult. This will cost sales at first. However, if you design the tool to be incredibly efficient to use once you've figured it out, the people who've pushed through the learning curve will stick with you longer. It all depends if you target mostly one-time buyers, or focus on long-term business relationships.

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.

Hello everyone! It's finally here: AceProject's community site. Not just a blog, but a user forum too. Not only do we get to talk to you, you get to talk back as well. A Blog In AceProject's blog, we will talk about everything from project management, software development, product management to marketing in a Web 2.0 world. In essence, we want to talk about our life as a small team making it in the great big industry of project management. We will also have product announcements, where we will let you know what's brewing at Websystems. A user forum The forum is for you. What do you like most about AceProject? What do you dislike about AceProject? How would you like to see the system evolve? More than that, it's a good way for all of us (users and creators alike) to get to know each other and share our experience and knowledge. Tell us what you think! We are looking forward to hearing from you. Don't hesitate to drop us a note . About Websystems Websystems is the creator of AceProject. Founded in 2001 in Quebec City, Canada, Websystems is a true child of the Internet age. All our products and systems are online. Every time we release a new feature, it is based upon our customers' requests and needs. We like hear your ideas because, after all, you are the project managers and we are the software developers. For us at Websystems, it's a great opportunity to have this new tool to talk to you, and hear from you. I hope you enjoy it! Karine Simard Marketing and Customer Relations Websystems, Inc. support@aceproject.com

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?

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.

We've added two case studies to AceProject's web site. Those are stories from real clients, telling us how AceProject helps them work better with their clients, with their employees, and with their students. How AceProject helps a video game creator to manage time sheets Beenox, a video game studio from Quebec City, needed a new employee time management system. Véronique Lessard, recruitment coordinator at Beenox, explains: "We needed to be able to manage vacations, time off and banked time. Since we are a video game company, it is essential for us to be able to know how many hours were worked on each project, and even per trade." Read more Teaching project management - the hands-on approach The engineering department at Quebec's University in Rimouski (UQAR) regroups three disciplines: mechanical engineering, electrical engineering and electro mechanic systems engineering. During their academic journey, students must pass three courses that include a real design project, during their third and fourth year of training. Read more

It seems to me it's only a few years ago that Internet Explorer took 80%+ of the browser share from my website visitors. How things have changed. Internet Explorer is now used by only 49% of AceProject's visitors, while FireFox is preferred by 40% of them. FireFox and Internet Explorer are now nose-to-nose.

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.

I would like to take this opportunity to thank all fo you for believing in AceProject and for your continuous feedback. AceProject will be closed for the holidays, between December 24th and January 4th, 2009. We will still be monitoring the servers and the support email inbox, so if you have an emergency, write us at support@aceproject.com . Everyone here will take this time to relax, recharge our batteries and have some quality time with our families. We wish you the same :-)

Since we are in the final testing stages for AceProject 4.5, I thought I would show you how easy it is to work with project templates in AceProject. Once we start using a project management tool, as more and more projects are created and completed, a need arises for project templates, also called master projects. It's very useful to be able to import another project's structure into the new project: no need to reconfigure task groups, statuses, priorities, etc. However, once we have that, wouldn't it be nice to also be able to import the template project's documents as well? And what about tasks? For repetitive projects, it saves a lot of time if you can avoid recreating the same tasks. Once you've imported the template project's tasks, you may want to adjust the task date according to the project dates, so the first task starts on the same day as the project, and so on. That was the easy part. Now comes the real challenge: it would be interesting to be able to dinamically connect a project structure to its template. This way, if you change a task status in the project master, it's also changed in the projects attached to that master. But what if you want to disconnect the project from its master? And what if you want to start from a project template, and adapt it to that specific project? This whole project template business is becoming sophisticated. The easy way out would be to make project templates complicated and hard to use. Project templates with AceProject In AceProject, we've made project templates quite simple. Any project can be a template, simply by checking a box called "Project Template" in the project configuration page. There is nothing else to do to make a project template. Once you want to use this template, you can choose how much of the template you need to import: only the structure (task groups, statuses, types and priorities), the project documents, and tasks. Again, a simple checkbox will tell AceProject to adjust task dates based on the new project's dates. With AceProject 4.5, we introduce parent/child project relationships. Do you want your new project's structure to be dynamically linked to its Parent project? Then simply check the box called Link with . When you change something in the parent project, it will be reflected in its child projects automatically. This helps you maintain a standardized way to manage and structure projects. Change your mind? Now all is fine and good, until you realize you want this project to work differently from the Parent project. Maybe you want to add task groups that are specific to the new project. Disconnecting a child project from its parent is just as easy as it was to connect it in the first. You simply click a button called Remove Link... and you're done! That's what I call easy templates No hassle. No complicated wizard. Just a project template. AceProject 4.5 is coming out in April 2008, and I can't wait to show it off :-)

The results from the survey are in. It was our first-ever survey here at Websystems. Here's a summary: Which feature do you use most? Task management Time Sheets Project management Gant charts Task comments Which feature do you like the most? Email notifications Task Management Time sheets Tracking task and project status Reports Which feature do you like the least? Time sheets Email notifications Reports Task creation workflow (tabs) Search What's interesting is that then time sheet module, email notifications and task management are present in all three answers. It seems time sheets and email notifications are either loved or hated. Among the comments we received, being able to edit the time sheet for the whole week (like a grid) and being able to customize how email notifications work were the most frequent. However, people told us they loved to receive those email notifications. We were also told that time sheets are very easy to use. Overall, what you told us is that you think our reports and our task creation workflow should be a lot better. We hear you. Your comments were very insightful and we will make sure to keep the good stuff and fix the bad stuff.

Are you tired of being too succesful at project management? 1. Don't give details It’s important to give very telegraphic instructions in the tasks, so that your team has to guess what you really want. 2. Communicate on a need-to-know basis And when your team asks questions about the project, don’t give clear answers. In fact, your collaborators don’t even need to know what the project is about and what you’re trying to accomplish. It’s not like it would help them do their job! 3. Be an optimist Assume everything will happen as expected. Your planning is perfect, the way you created tasks exactly follows the way things should be. And what should be is definitely how it will be. Murphy’s Law does not apply to project management, after all. 4. Leave no margin for error in the timeline No one ever gets sick, leaves the company or needs to take time off unexpectedly. And your team is so great that they are never late in their tasks, in fact nothing ever takes longer than planned with your team. 5. Take no suggestions from your team It’s not like they know anything about the project, right? After all, you didn’t tell them anything about it. 6. Live in an ivory tower Since you don’t need to inform your team and they have nothing of value to add to the project, no need to talk to them, or even sit in the same room with them. 7. Stick to project management Managing a project is a very important task. This is why you should do nothing else in the team. There is no need to manage your teammates; this is why there is an HR department in your organization. 8. Rely on assumptions and your own guesswork Only you know what the project needs. Don’t listen to any feedback from your team, simply take your guesswork for reality. 9. Rely only on your project management software to know how your project is going There is nothing more to the project than the sum of its tasks. As we said earlier, HR can take care of the rest. 10. Believe in perfection Once a project is completed, everything is finished and there will be no need to corrections and improvements. There are no such things as bugs Happy Easter eveyrone!

Last week, we saw how AceProject can help consultants ensure their budgets stay on budget. This week, we’ll see how teachers and schools can improve communications with their students and keep track of all their classes in a central location. For workshop-oriented classes, AceProject can make your class like a project team. One project, one class AceProject helps prepare your materials for your classes. Simply setup each class as a project. (click to enlarge) Then, you can create a task for each thing that you need to do to prepare the class, such as your class presentations, exams, or handouts. You can also create a task for each important event when you give the class, such as exam dates and paper due dates. (click to enlarge) Not only can you upload all your documents to the task, you can even keep several versions of the same document right there in the task. (click to enlarge) Once your class is all setup, you can keep it as a template and recreate the project for each term that you teach it. (click to enlarge) Get your class in on the action As you give your class, your students can become part of your project team, with restricted access. For example, you can give them read-only access only to certain tasks. This way, they won’t be able to see everything you put in the project (like answer keys). They will only see the tasks that you assign them. (click to enlarge) Once your students are assigned to a task, they will be able to see and download the documents that as in the task. For example, they would be able to download supplemental materials for the class. Share documents with your class You can also choose to simply share documents with your class. You can do this by emailing them the link to public documents. Public documents in AceProject can be opened by anyone and do no require a login and password. (click to enlarge) Send announcements Once your students are AceProject users, you can send them messages without having to keep their email address list, and without them knowing your email address. This is also a great way for them to ask questions from their teacher! You can send a message via the message center, and choose All members of a project as the recipient list. (click to enlarge) Get reminded AceProject will tell you when something is due in the next few days, or late. Moreover, if you work with another teacher on a class, you’ll receive an email whenever she adds content to a task. How do you do it? How do you manage classes and students? Add a comment or send me an email at karine.simard@aceproject.com.

Last month, Melinda Cline gave a presentation about using AceProject to teach her students about management information systems and project management systems. Here are her conclusions: "Using AceProject, students have an effective tool to increase their understanding of planning, organizing, controlling, and monitoring projects in a global environment. It is a cost effective way for instructors of project management and other IT management topics to introduce students to project management software without having to buy Microsoft Project licenses, which may be very expensive. It also has the advantage of being a web based tool with 24/7 access by students and instructors." You can download her PowerPoint presentation here .

Back in 2001, AceProject started out as FreeTaskManager. In fact, FreeTaskManager only became AceProject in 2003. It's fun to look at the old screen, they feel so...obsolete. And yet, a lot of what make AceProject powerful today was already there. Here are a few screen captures. Enjoy!

I saw this comic this morning. The text reads: "Do a million things right and no one notices, do one thing wrong and it gets cc'ed all over the office." Why does failure get more attention than success? As much as we should learn from our failures, it's also important to learn from our successes. What went right? Why? How can we replicate it in the next projects? It feels strange to think about successes that way, but knowing the recipe to your success ensures you can succeed consistently.

Most of us have been in meetings that drag on forever: it seems nothing useful is said, and instead people are just repeating information everyone knows already. It seems like a waste of time. Everybody dreams of having meetings that focus on the important stuff, what requires attention and decisions that need to be made. Especially in time-sensitive projects (aren't they all?), no one has time to waste in meetings. Harness the power of reports Instead of listing everything that needs to be done on the project, why don't you simply focus on what needs to be discussed? Late tasks and tasks that have been worked on in the last week, for example. On order to do this without forgetting a task, simply 2 reports in AceProject: tasks with a due date in the past, and tasks with a last update in the same week. With those two reports, you'll be able to only see the tasks that need attention. You can export these reports to Excel, print them or simply display AceProject on the conference room's projector screen. This provides a simple working list to follow in the meeting. And since all the info is entered directly on the task, no need to rehash it. These simple reports will greatly speed up your meetings - and free more time for doing actual work

When working on a project, do you try to think about what could go wrong or do you wait for the problem to manifest itself before fixing it? When looking back on your career, did you try to see or create opportunities for yourself and yor organization, or did you trust life to send you the right challenges? When managing a product, do you try to anticipate where your users will have issues, or do you fix those issues as they are reported? Does it have to be either/or? Think ahead: be proactive There are numerous benefits to being proactive. It avoid problems down the road. It minimizes the damages a problem could cause. It makes you, your team and your business look good. It's very trendy to be proactive. After all, it makes sense to solve the cause of potential problems before they spawn actual problems. However, sometimes being proactive makes you spend too much energy on a potential problem which may not have the estimated impact. Sometimes, by trying to look so hard into the future, you end up neglecting the present. A good way to be proactive when developing a new product is to look at the problems reported with previous version or even with the competition. Even though being proactive is about looking into the future and preventing problems, it can also be about learning from your mistakes and working to avoid repeating them. For example, when we detect a problem with AceProject 's hosted accounts , we will send the fix to all our source code clients, even though they may not be affected by the problem. Just covering all bases. Think now: be reactive Being reactive had a bad reputation these days. It's seen as slow and not customer-centric. Waiting is not popular in 2008. However, going ahead of the customer's needs has its limits. Sometimes, no one could have guessed event would unravel in a certain way. Or that someone would use the product in that specific way. Sometimes, only one person will have that problem. It's all about fixing the problem. If there is no problem, there is nothing to fix. In terms of customer satisfaction, fixing someone's problem may make you rank higher in their minds, because you fixed it. No because the product was perfect. Not because you foresaw every possible delay in the project. Not because you guessed when the time was perfect to send you resume. But because you were quick to react. At Websystems, we make a point of fixing customer issues as quickly as possible, even if it's a small problem experienced by only one account. It's not the customer's fault she's doing something unique with AceProject. It's our responsibilty to ensure that AceProject works correctly for her too. The curve balls are always there No matter how proactive you are, life will always throw you curve balls. Being reactive cannot be avoided. Reacting quickly and reacting well when a situation arises is as important as being able to see things coming.

When planning a project, we think about how long it will take to complete it. This is what we ask our team members: how long for you to code this module/wire this house/print these brochures? We forget how hard it will be, how much effort we will have to put into the task to complete it. It may take 3 days for paint to dry, but there is not much effort involved in this. It may take 3 days to code a module, for a team of 3 developers who will have to rewrite part of the software core to make it work. Same duration, different effort. If something has a high level of difficulty and requires a lot of effort, the risk of delay is much greater, and you should plan for it in your schedule, that is, how long you allow for the task to be completed.

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 who is working while everyone is off enjoying spring. However, it's good to be the one who's taking the day off when everyone has to go to work. I think managing international teams is like turning the tables on yourself. It can be scary, but it can also be fun!

I'm sure most of you have had this situation when they deliver a product: Situation 1: What the client wants and what the client asks for are two different things Client: It's really nice, but that's not what I wanted Supplier: This product was built to meet the specifications you gave us. Client: Yes, but that not what I want. Supplier: ... Situation 2: What the client needs and what the client asks for are two different things Client: This product is great, but it's not doing what I need it to do. Supplier: We built the product you wanted. Client: I know, but it turns out I need the product to do something different Supplier: ??? What do you do? Now, you end up with a dilemma in these situations: should you rebuild the product so it does what the client wants/needs, at you cost, or at their cost? After all, you built a product to meet their specs, and it's not your fault if it's not what they really wanted. Or is it? What should you have done? As the project manager, you should have made sure you understood what the client wanted , needed , not just what they were asking for. See, the problem is clients often approach us with a solution: I want X feature added to your standard system. However, if you dig deeper, you'll find out what they really need is something else. Here are some questions to ask your clients: What do you want? - This question is easy enough to answer for them. Most of the time, you'll know what they want from the get go. Getting the specifics of what they want might be a little trickier, though. What the problem are you trying to solve? - This is harder to understand. The best way to get this answer is to have the person show you. What do you need? - The difficulty in this question is to get a precise answer. Here's an example: Client: I want a new report in AceProject. Supplier: OK, why do you want this report? (what's the problem?) Client: Your Time Report gives me all the weeks one by one, I just want a total for the whole period. Supplier: OK, and what do you need the new report to do? Client: Well, I would like the report to give me monthly totals for each project, and email it to all my project manageers automatically. Supplier: OK, so you want a monthly time report of all the actual time worked on each project, that is produced automatically every first of the month, and emailed to any user with Project Manager access to at least one project? Client: No! I want each PM to get the data only for their projects, not everyone else's! Supplier: OK, let me send you a detailed scope of work and a mock-up before we get started on the quote. It's detective work It's not easy to get what the client needs, wants, and asks for. But if you don't do it from the get go, you'll end up spending a lot of time redoing your work.

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 the Gantt, it makes it very easy to organize your project. Also nice is the visuals of task dependencies. If a task in the project needs to be moved, all its dependents will all move with it, which makes it easy to see the impact of changing a date. Visual is better In the end, it all comes do the fact that our eyes are better at understanding something quickly. With abstract concepts (like time), it's hard to have a bird-eye view of the project, unless it's put in visual form.

PITA is for pain in the a**. People who are PITAs really put a dent in any project. How can you detect a PITA? He/She focuses only on the negative aspects of the projects. What's going wrong, what's late, what hasn't been done correctly, etc. However, the PITA is not interested in solving those problems. All the PITA is interested in is to whine about the problem, and possibly blame somebody or something. A PITA also tries to get attention like children do: by throwing tantrums, bullying and manipulating others around him or her. When you habe a PITA in your team, it can be a weight on everybody's shoulders. It can significantly impair the project's progress. How do you deal with the PITAs in your project team? You must remember that PITAs are trying to get energy from you. Their screaming and crises and drama and blaming are all about getting people to feel sorry for them or agree with them or follow them in their blaming mission. As long as you're playing along, you're encouraging this behavior from your PITA. Now, if the PITA is the project manager, it means the whole team is in trouble. It's harder to ignore the project manager PITA and work around him or her. However, it can still be done. If you don't give in to the PITA's behaviors, he or she may realize it's not working and try a different, les painful approach to managing the team. If the PITA is a team member, it's easier to work around this person. A good way to confront the PITA is to ask the question: What should we do about it? Often, PITAs are not interested in solutions. After all, if the problem goes away, what are they going to complain about. Also, asking for a solution changes the mindset of the team, from focusing on the problem to focusing on the solution. It's also a good idea to learn to build resistance to PITA behavior. The PITA is not working specifically against you, but against everyone in their environment. Watch out for PITAs around you Whenever you have an opportunity to change teams or bring someone new in the team, keep and eye out for PITAs. It's easier to avoid having them in your team than getting rid of them once they are in.

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!

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.

ESI International published a report , stating "project management and business analysis software tools met or exceeded expectations for only 10.5 percent of respondents." This means that, according to their survey, nearly 9 out of 10 people are not satisfied with their project management system. That's a lot! Is there no satisfaction to be had from project management software? Is there not a project management tool that can do what the market needs? Wait. What DOES the market need, anyway? This is where things get tricky. No one needs the same thing in a project management system. When I do a demonstration for AceProject, before I even start, I ask two questions: What do you guys do? Tell me about your organization What are you looking for in a project management tool? I have yet to receive two identical answers. Of course, there are basic things that come up: time sheets, email reminders, estimates versus actuals, client access, etc. However, every organization is using a slightly different method for project management, every manager is looking for different metrics to assess his team's performance. That's why no one is completely satisfied with their project management system. If there was a tool that could do everything, it would have so many features it wouldn't be usable. Tools don't make projects successful. People do. At the end of the day (or the project), if your team is not working well or if your client won't ever be happy with what you deliver, having the best project management tool cannot fix that. Likewise, if you have a great team, your project can be successful even if you're using the crappiest project management system.

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: 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. 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. 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. 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. 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. 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. 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." 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. 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." 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.

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.

My washing machine has died on me. It's only when these things failed that we realize how much use we get out of them. I know, I know, it's cliché. Try to tell that to my growing mountain of laundry... Luckily, I had purchased an extended warranty plan, so fixing the thing won't cost me money. So after calling the repair company, waiting two days for a callback, then waiting another day for the technician to show up, I am hoping he will be able to fix my ailing washing machine in one visit. How naive of me. It's now been 2 weeks, 2 visits from technicians, and a couple visits to the laundromat. I still don't have a working washing machine. There's always a new part that needs to be replaced. Nobody will be surprised that I am getting impatient here. I keep wondering why the technician didn't thoroughly inspect my washing machine and made sure he found all the broken parts. The reason is simple: the shorter the service call is, the more service calls the technician can make in a day. The more service call he makes, the more productive he looks. At least on paper. That's the short-sighted way of looking at productivity. In my case, if the tech had spend 45 minutes looking at my washing machine instead of ten, in the end it would have saved a lot of time and at least a couple visits from the technician. Taking the short way is rarely better Because we want to feel that we accomplished something and we want to fix things, we'll stop looking at the first sign or a solvable problem, and fix that. The good feeling of having fixed the problem blinds us to the fact we may have fixed the symptom of the problem, and not the actual cause. In project management, like washing machine repair, it pays to understand the problem before going in a fixing frenzy. Fixing it right the first time pays.

Having patience in today's world is waiting more than 5 minutes for your latte at the coffee shop without throwing a tantrum. Seth Godin's article about patience and success is food for thought. Like anything else in life, projects are an investment in time. It doesn't matter how fast someone wants the project to be completed, things take time and, short of a time machine, time itself cannot be sped up. Not every delay problem can be solved by throwing more people at it. If you need 100 boxes moved from room 1 to room 2, having more people moving the boxes will get the job done faster. However, there are only a few tasks that really gain speed from adding people on the team. Writing the documentation for a product, for example, cannot be sped up by adding more people on the team. If you get several writers working on the same document, all you'll get is a patched-up user's manual that looks not quite put together. The cost in quality is not worth the savings in time. At Websystems, when we work on a new version of AceProject, it's ready when it's ready. We avoid delivery dates for AceProject because we prefer to release a product that works well to releasing a product on a schedule. It's harder to be patient towards the end, when all I want is to show off the new shiny version with all the cool features, but in the end it's worth it, because when I do get to show off the new AceProject, it works.

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. Once you've accepted the failure of the previous project, don't let it slow you down. Let go of that failure and move forward. Reach out. Maybe you need to learn some new skills for project management? Maybe you need to improve how you manage your team, or how you manage expectations, or simply how you manage your time. Training sessions can only help you improve yourself, if only by giving you a confidence boost. Getting a mentor or a life coach can be beneficial too. Get moving. Get your hands on a new project. See it as an opportunity to start fresh. You can apply what you learned in your training or mentoring sessions. Most of all, working on a new project will motivate you. It will change your outlook, from being the one whose project just failed, to being the one whose new project will succeed. Give back. You're not only one who's failed before. When someone else has a failure on their score sheet, don't turn your back on them. You can become their mentor. You can offer them some guidance to move away from the failure and become better at project management. My take on it: it's about looking ahead Recovering from a failure requires that you look ahead of you. You can't move forward when you're always revisiting the past. And if you're constantly thinking of that past failure, other people will see that in you too. The aura of failure is not put on you by the others around them, you're the one keeping it there. Focus on how good you can be.