Thursday, April 29, 2010

LiquidPlanner vs. Clarizen, a comparison of two Project Management Tools

Since I've been serving proudly as the LiquidPlanner Social Media Evangelist for almost a year now, I wanted to take some more time to evaluate other online project management tools and get a better understanding of what the competition is like in the space. This post will not be another comparison of Basecamp, I think I've made it pretty clear that Basecamp shouldn't even really be called a project management tool, but merely a decent collaboration system, lacking in critical project management features & functionality.

Clarizen was next on my list, so I spent some time checking it out. The interface is fairly clean and loading time is decent, but my first real impression was how much it looked like a web based version of MS Project. Personally, that scares me, but it might be a draw for others.

Both tools have task & resource management, time tracking, collaboration, gantt view, reporting, and a way to include clients in project collaboration. Clarizen also has a fairly full suite of Budget Management tools which LiquidPlanner does not yet have.

What I spent the most time evaluating was task scheduling and management, since I think these are the most powerful features of LiquidPlanner and I'm always curious to see how other systems handle them.

To setup a task in Clarizen, you need to have a start and end (due) date, duration and work. The first thing I noticed is a default task in the system that is 40 hrs of work, assigned to one person, and set to last 5 working days. I changed the work to 60 hrs and the other values didn't change, and there was also no flag that the task was at risk of not being met. In LiquidPlanner, to setup a similar task I would give it a "delay until" date, promise date, high/low work estimate and put it in the proper priority order. From here, LiquidPlanner will calculate expected finish date, based on the hours per week that the resource works, any other tasks in the workload, and of course the amount of hours the task is expected to take. If I take a 40 hour task and make it into a 60 hour task on LiquidPlanner, the expected finish date would automatically get pushed back to the following week. Tasks can be due on a certain date, but I can't force them to finish on that date without moving up the 'delay until' date and/or re-prioritizing tasks. And, I really like that feature of LiquidPlanner, because it communicates the reality of the schedule, that you can't always force something to be done by a certain date (unless you want to sacrifice quality, quantity, other work, your team member's sanity, I could go on...).

Next, I wanted to reprioritize the tasks assigned to one of my team members. I found on Clarizen that it took a lot of clicks to get to the list of tasks for one specific user, then once I was there I was not able to easily shift (drag & drop) tasks around like I am able to do with LiquidPlanner. Now, this feature is very important to me because where I work there are constantly shifting priorities so I need to be able to easily move the tasks around to ensure that the critical items get finished on time. Clarizen does allow tasks to be reordered on a team member's list, but it takes a couple more steps than the drag & drop.

In Clarizen the tasks can be given the designation 'at risk' but it looks like this must be done completely manually and not automatically if the resource assigned to that task is overloaded with work. With LiquidPlanner, tasks are automatically marked 'at risk' by the system if the promise date is after the expected finish date. The task can also manually be marked at risk or assigned any other relevant alert.

Something interesting about Clarizen was the ability to assign multiple properties to a task, such
as Project Phase, Pending (Customer approval, feedback, testing, etc) and Type (Define, Design, General, Integration, etc.). What I didn't see was a way to customize the items in these drop-down lists, so the user is tied to these specific properties.

I've heard many seasoned project managers say (and even some programmers guiltily admit) that a task is always going to be reported as 90% complete, until it's finally finished. There are many who adhere to the idea that tasks are either 0% or 100% complete, and never anything in the middle. Percent complete is just an inaccurate way to report progress on a task. Rather, report hours worked and estimate (high/low is ideal, of course) of hours to complete. So, I admit, I had to chuckle when I saw that Clarizen was using a percent complete field with each task, and allowed me to arbitrarily update the value without recording any time worked or time remaining. LiquidPlanner stays away from the percent complete model, the only percentages you will see attached to a task is the calculated probability of a task being completed by a specific date. So, you can report to your execs that task A has a 10% chance of being finished by next Friday, a 50% chance of being finished by the following Wednesday, etc. In my opinion (and many other project managers) much more useful information than having the task owner report something like their task is "65% complete."

I mentioned at the beginning of this post that both tools have reporting features. If you look at the reports page on the Clarizen system and compare to the reports in LiquidPlanner, you might be blown away at the sheer number of reports available on Clarizen. What will become obvious after taking a closer look at LiquidPlanner is that many of these same reports are available, with even more customization, by using the drop-down lists in the "Plan" view to filter to the exact view that you're looking for. These custom views can be saved and easily accessed later. The prepackaged reports that LiquidPlanner does have are pretty slick, and Clarizen doesn't have the proper data to generate reports like that. To Clarizen's credit though, there are financial reports available in that system that are not yet in LiquidPlanner, but once LiquidPlanner launches additional financial tools this will not be an issue.

The bottom line here is that it's all about what your needs are as a project manager and what type of organization you're working in. If you're looking for a tool that closely resembles a web based version of MS Project with added collaboration tools, then Clarizen might be a good fit. If you'd prefer something that removes a lot of the rigid structure of MS Project and includes only the most useful features (plus a robust scheduling engine, collaboration, etc), than LiquidPlanner would be an ideal solution for you.

Monday, April 19, 2010

No More Fear of Failure...

(This was originally posted on Horn Group's Brass Tacks)

Last week I went to the first FAILfaire NYC, organized by MobileActive.org. I was first turned on to the event when I saw a tweet about it from another project manager that I’m connected with through the “Project Managers on Twitter” (#PMOT) group. Now, failure is nothing new to project managers, any quick skim through the #PMOT feed on a given day will show blog posts about “10 top ways to fail at an IT project”, or “5 ways to fail as a project manager”. Talking about common mistakes and lessons learned from them is something project managers try to do on a regular basis. But, I have never seen an event where people will submit their project failure stories in order to be able to stand in front of a large group of people and talk about how they screwed up. What an amazing idea!

Too often people are afraid to talk about their mistakes, both professional and personal. The problem here is that when we don't talk about them, we don't learn from them, we forget how they happened and then of course we go back and repeat them. This can be a dangerous and expensive habit when it comes to software and interactive projects. And, as we all learned from the presentations at FAILfaire, just as bad with "Information Technology for Development" projects.

What were the lessons learned from the projects presented at FAILfaire? Here's the main ones that I took from the event:

  1. A great idea and great branding will not necessarily lead to a great project. Plenty of time needs to be spent planning out all steps of the project from initiation to final execution, trying to brainstorm all possible bumps along the road and how they will be handled.
  2. Pay attention to early warning signs. The example from the project presented was where family members warned "not to give up your day job" and there was no funding offered from friends/family or charitable organizations. Regardless, the project forged on as planned.
  3. The people are just as critical as the technology and process. You might have an amazing idea but without a team of qualified people that is 100% motivated about the project, the challenges could be too much to bear.
  4. Make sure to do enough market research. In this specific case presented, plenty of time and resources were spent designing and producing an LED lamp that was already more cheaply made and available in the local area.
  5. Especially when dealing with developing nations, make sure to think through the technology challenges as fully as possible. The level of technology use and infrastructure is nowhere near what we are lucky enough to have here in the U.S.
  6. Make sure you have complete buy-in from your audience. If you need a crowd of people (and in one of the cases presented, children) willing to participate make sure they have incentive and no significant barriers to participation.



I think the best idea that came from the event is the extendability of it. The organizers mentioned more than once that the logo was free to reuse and they would love to see more FAILfaires sprout up in other cities and with other industries. And if done well like it was last week in New York, I think this could be a huge success. The keys to a successful FAILfaire are:

  1. Make sure the environment is comfortable and conducive to open conversation (at the NYC event the alcohol was flowing, while the sunset came in all around the stunning penthouse location).
  2. Fingers should not be pointed at any time during the event. This is not a time to lay blame, but learn from mistakes that anyone can make.
  3. Set clear ground rules early about what is on and off the record, especially when participants are coming from different organizations and industries. In the age of live tweet streams and blogging (this post is even on the late end), try to ensure that any sensitive information is either left out entirely or clearly declared off the record.

I already have a couple of ideas for how I'd like to see FAILfaire spread, and I hope the 60+ people in attendance that night also help start more events in their own circles, helping to bring out the failures from under the rug so that we can all learn from them.