Wednesday, December 2, 2009

A Reality Check from (our version of) Bob the Builder

I am proud to say that my daughters are not only into princesses, fairies, and everything pink and sparkly. They are also fans of the stereotypically "boyish" characters, like Spongebob Squarepants, Thomas the Tank Engine, and Bob the Builder. I've found that there are some good lessons in project management that can be learned from the Bob the Builder that we all know, and the tweaks that our family has made to his routine.

Here is the description from the website:

Bob the Builder and his machine team are ready to tackle any project. As they hammer out the solutions that lead to a job well done, Bob and the Can-Do Crew demonstrate the power of positive-thinking, problem-solving, teamwork and follow-through. Most importantly, from start to finish, the team always shows that The Fun Is In Getting It Done!

What project manager wouldn't love all of this? I mean, it sounds like the perfect project, doesn't it?! Well, as anyone who's seen one all the way through knows, not all projects go that perfectly.

So, Bob the Builder has this great catchy theme song that my (almost) 3 year old loves to walk around singing, title of the song is "Can We Fix It?". The words repeated throughout the song are "Can we fix it? Yes, we can!" It's inspiring and very cute, I encourage everyone to check out the video. So, we decided to mess with our 3 year old a bit and change the lyrics, but really we just wanted to teach her an important lesson in project management (obviously ;). Our version of the song is:

"Can we fix it? No we can't!", or "Can we fix it? Maybe tomorrow!"

Don't get me wrong, I'm all about being a positive thinker and having a good attitude about getting the work done. But, I also believe in being a realist and have learned lessons the hard way about the importance of being honest about the status and condition of a project. If something is going to be late, make sure people know it or make sure there is a plan to adjust scope so that the critical deliverables can still be completed on time. If something just isn't possible, make sure to raise the flag as soon as possible. Better to get the information out early than stay quiet on it or mask the problems, only to have a more serious blowup at the end.

So, I hope that my daughters learn positive thinking and the power of teamwork from Bob, but I also want to make sure they get the extra lesson in realistic thinking and honesty from their parents!

Wednesday, September 30, 2009

Guest Post: Project Management Battle of the Sexes

Just contributed to LiquidPlanner's "Home on the Range" blog, with a post titled "Project Management Battle of the Sexes".


This past July, the New York Times ran the article, “No Doubts: Women are Better Managers.” It was an interview with Carol Smith, SVP and Chief Brand Officer for the Elle Group, the media company. She explained what she does to be a great manager and why women will always be better managers.

More on the LiquidPlanner blog >


Monday, August 10, 2009

It's painful being a Project Manager....


Have you ever felt alone, completely helpless, struggling with everything around you knowing that you can't do a thing to make it any better?

No, this is not a commercial for a Prozac, it's a story about how I got caught at an incredibly inefficient process at an IKEA one day and almost lost it. I was working on a bunk bed project, had bought a used IKEA bunk bed for my 4 year old and discovered happily at 1am while building it that it was missing alot of critical hardware. So, rather than chase down the seller who had probably already gotten packed up and moved out of the city, I decided to go to the nearest IKEA to get the parts replaced.

I showed up at the returns/spare parts line with the instruction manual for the bed I was trying to build, the pieces of hardware I had left and a list in my head of what I needed. I saw one of those typical scenes in a store, a huge line of people looking really frustrated and just one or two customer service people helping. Then, lots of other IKEA staff were wandering around, attending to other areas that were not as crowded. It's the kindof thing that makes you want to scream...watching people wandering around looking like they have nothing else to do when there clearly are long lines that need to be helped. I thought about Brooks Law for a moment, and decided that in this type of project adding resources might cause a slight delay intially just to get people setup and going, but ultimately will definitely make things go faster.

And wait, there's more!
We all had to pick a number and wait for it to be called, the line moved at a pretty steady (slow) pace but than at a certain point things sped up. The line almost breezed through the last 8 numbers before me and then behold, the two people right before me had a seriously huge cart of stuff to return. Not only was there a lot to return, but there were major complications with their items. It made me think about the idea that software project tasks are either 0% done or 100% done. It's impossible to predict the exact amount of work that will be required to get something done, anyone who's managed programmers before knows that they love to say they are 95% done for the last 90% of the project. You can only get a truly accurate estimate when the task has completed. In the meantime, stick to ranges.

As I sat there waiting and watching the clock tick, I figured I should use the time wisely and made sure I had an exact list of the parts I needed. So, it took 5 minutes and I got my list down. I wish some of the other people around me would have thought of the same thing. I couldn't stand watching the people at the head of the line rifling through their papers, I thought if they had only taken a few minutes to plan before it was time for them to get to the top of the line they would have saved everyone else a lot of time.

So, I'm not saying I'm an expert and that all my projects launch perfectly with the time/budget/scope triangle balanced to a tee. I enjoy learning about how to improve what I do and how to incorporate the right processes that will make my projects more successful. When I spend a lot of my time learning how to make things run more smoothly, it just pains me to see disorganization and chaos in a place where I have no control over things. Yes, I guess I could be one of those people to shout at the customer service reps to move the line along or lecture the others in line to be more organized, but I just don't swing that way.
I suffer in silence, and wait for the moment to pass (well, sometimes at least...)

Wednesday, July 8, 2009

Some Simple Lessons in Project Management, from Edward of Sir Topham Hatt's Railway


We watched a lot of Thomas & Friends over the holiday weekend (yes, with my kids...wow, that joke never gets old). Since I don't watch the show regularly (not kidding here) I was surprised to learn about how many different trains there were. I always heard about 'Thomas the Train" and didn't hear much about his other friends. Anyway, one of the episodes featured Edward, who had to take over Percy's mail route because Percy was getting repaired. Edward didn't want to ask about how Percy delivered the mail, he assumed someone would tell him or he would figure it out.

As he started on the route, he had three deliveries to make. He guessed his way through and got all three deliveries wrong. When he got to the end of the route, he was told that the deliveries were wrong and he had to go back and bring all of the packages to the correct places. At this point he's running out of time, so he rushes through the pickup and drop-off, and ends up losing & breaking packages. By the end of the day he's very frustrated and the other engines are disappointed in him.

So the lessons learned here are pretty simple...

  1. Never assume that you completely understand the task at hand. It might seem simple at first, but once you're in the thick of it, questions might come up that you won't be prepared to answer unless you have a full understanding of the task.
  2. Don't be afraid (or too proud) to ask for help. This doesn't just happen to trains, people will sometimes have pride issues, too. Better to ask what might seem like a stupid question now than look even more foolish later.
  3. Rushing doesn't pay! What you gain in time you lose in quality.

Do you have any Edward trains on your project teams? Better make sure they watch this episode!

Wednesday, June 10, 2009

A Lesson in Risk Identification, from the Very Worried Walrus


Just got a shipment of old school children's books from my in-laws a few weeks ago (yes, we have kids, I don't just read kid's books for fun or blog material). One of the books is "The Very Worried Walrus", by Richard Hefter. This was one of my husband's favorites, but I had never read it before. So, when I read it to my daughters for the first time, it got me thinking about Risk Identification.

Let me tell the story....

Worried Walrus really wants to ride a bike, but is afraid he'll fall off. He has a conversation with "Positive Pig" about why he's worried...

"If I fall off, I'll get hurt. Then I'll have to go to the doctor. And I'll need medicine orbandages....or...stitches! Ohhhh!"

To which Positive Pig replies, "That's silly, bicycle riding is fun and there is no reason to worry."

The Worried Walrus goes on, "An awful lot can go wrong. You have to steer and pedal and balance. You have to look out in front of you and on both sides and make sure nowone is behind you...and not go too fast...and use your brakes."

Reading further, we understand why the Worried Walrus has his title, "...If I get hurt, they'll have to take me to the hospital in an ambulance. I can see it now, there's a traffic jam on Main Street. The ambulance get's stuck..."

And he ends up in the middle of nowhere walking through the rain in a dark night, wet and hungry and looking for anyone who can help him.

I won't give away the rest of the story, you should pick up the book and find out for yourself!

But, I think this is a great example of Risk Identification. This is the process of discovering, defining and documenting risks before they become a problem in a project. The way I see it, the more creative you can be about it, the better. The project team should sit down and brainstorm on all of the possible risks to the project and get them documented. The document should detail the risk, the severity, impact and contingency plan (here's a sample Risk Management Worksheet from the Gantthead site). At regular intervals throughout the project the team should revisit these risks, add new ones and archive anything that is no longer a risk. I recommend reading "Waltzing With Bears: Managing Risk on Software Projects" to find out more about risk management.

The goal of this is not to be worried like the Worried Walrus. Actually the opposite, the more creative thinking you can do in the beginning of the project to identify and then manage the potential risks, the less stress you will have and more sleep you will get at night.

So, I tried to have this same discussion with my 2 and 4 year old after reading the book to them and well...maybe I'll try again in a few more years.

Friday, June 5, 2009

Will the real Project Managers please stand up?

Ok, so I already have that Eminem song in my head and it will be in there for the rest of the day I'm sure. If the least I can do is get that song in your head, than I've accomplished something. But, what this is really about is having an open discussion about all things project management, without the nuisance of spam or other unwanted discussion. I started doing 'Social Media Evangelism' for LiquidPlanner about a month ago and admit I feel like I am constantly struggling with the balance between being an active and valued (atleast I hope, you are all the judge of that) member of the Project Managers on Twitter community and using any available opportunities to express how powerful and amazing the LiquidPlanner project management system is. I am sure this is the same struggle that many people have who are promoting themselves or their products in social media (it's not always about Twitter, there's blogs, LinkedIn, ning sites, Facebook, etc).

Of course, looks like some have already failed. When I was checking out Webworker daily for posts about project management tools, I saw some great posts and then plenty of junk comments. I'm not saying that people shouldn't promote their products, but tell me who you are, and give me some reasons why I might want to use your product. Don't pretend to be a project manager making a recommendation, identify yourself and be open about promoting your product. One of the reasons why I made the post about my relationship with LiquidPlanner was to always have it handy to link back to when I was promoting LiquidPlanner and wanted to identify myself.

I think someone who strikes this balance really well is Charles Seybold from LiquidPlanner (and am I using this opportunity to promote them again? It probably looks like it, but I happened to like what he was doing before I had this whole arrangement with them anyway). His avatar is great, it's got the LiquidPlanner logo in the background and his face in the foreground. He does the same thing in his contributions on Twitter, a mix of product promotion and other interesting stuff. I think more organizat

I've seen many blog posts and articles about how to successfully represent your brand or organization on Twitter and other social media. It's a tricky balance and I don't claim to have found the perfect solution. But at the very least, when you want to talk about your product on project management blogs or via contributions to #PMOT, let us know who you are and why your stuff is so good.

Tuesday, May 19, 2009

A Tale of Two....Web Based Project Management Tools

I think I've found my new purpose in life. Forget doing good in the world, raising healthy and happy children, making a positive impact in my community....I've become obsessed with project management tools. Granted I don't exactly have days, weeks and months of extra time to spend sampling all of them, and there are a LOT of them. But, I like that I've been able to work with a few and research many more.

It all started with Microsoft Project, as it probably does for most people. When I began to learn the ropes of project management I learned how to use MS Project to build my gantt chart, dependencies, durations, assign tasks, etc. It was ok for what I was trying to do with it, but I never really loved it. As time went on and I needed more from a project management tool, MS Project was lacking what I needed. I got frustrated when items would randomly gray out and become uneditable, tasks were held to single point durations, updating one task would shift everything else out of control, and worse yet, nobody else on my team could easily view or work with my project file because they didn't have project installed and weren't comfortable working with it anyway. I needed something simpler, something that cut out all the extra unnecessary stuff that I didn't need when I was managing web projects, and something that was highly collaborative.

In walked LiquidPlanner. I won't go into the details of how I started working with LiquidPlanner since I did that in a previous post, but needless to say it quickly met all of my project management needs and with each new feature release, it only gets better! In the process of getting my workplace to adopt LiquidPlanner, I did research on other project management tools (Daptiv, Fogbugz, WebResource, @task, Wrike, 5pmweb) and consistently found that LiquidPlanner was the most practical and feature rich, giving the most bang for the company's buck.

To the point of the post - my research comparing Basecamp to LiquidPlanner. I've been using LiquidPlanner for over a year now and Basecamp for about 6 months. So when I was asked to work on a detailed comparison of the two systems for LiquidPlanner, I had months of personal experience from my own use to go on. The company I've been working at for the last 6 months is pretty married to Basecamp because of the value it adds as a communication and collaboration tool, but I quickly found that it was lacking as a real project management system. Basecamp has no Gantt chart, and from what I hear they have no interest in adding one...ever. Their goal is to keep the tool 'simple', so anyone can use it. I respect that, but then when I need something that will really help me manage projects, Basecamp isn't my solution.

Basecamp will allow you to create a milestone, give it a date and assign it to a resource. But, there is no way to give the milestone a work duration, dependency or specific start date. The Basecamp milestones also will always exist in one big pile in the project, there is no easy way to group milestones together by phase. This might work for very simple projects, but for anything more complicated with many tasks and milestones, Basecamp will get very messy. Also, because there is no work duration attached to Basecamp milestones, there is absolutely no way to see how your project team us over or under-loaded. It is possible to see all of the milestones assigned to each resource, but no way to really tell how many hours of work each resource has and what deadlines are at risk because of overloaded resources.

LiquidPlanner, on the other hand, took all of the smart and useful features from MS Project (and more) and includes them in its task and scheduling system. You create a task, give it a low and high work estimate, give it a 'promise by' date, a 'don't start until' date, attach dependencies, notes and files with a rich text editing system, put it in a project folder/sub folder and task list, and (of course) assign it to someone. Once you hit "Go", LP will then do all the math for you, figuring out if your resource will be able complete this task given all other work already assigned to him/her and flagging the task if it is at risk of not being completed. Tasks can be easily prioritized for your resources with a slick drag and drop interface (hey Basecamp, ever heard of drag & drop?). LP has an excellent Gantt system, using your tasks that have been estimated in ranges (and it's ok to make single point estimates too, buy why would you want to?!) and plotting out probable finish dates for all tasks, project phases, and of course the entire project.

If you had a chance to read my previous post about why I fell in love with LiquidPlanner in the first place, you'll understand why I feel so strongly about making task estimates in ranges. I wasted hours with MS project trying to find a way to do this, with no luck. And of course Basecamp doesn't have this feature. So far I have not found any other project management tool with this important feature, except for LiquidPlanner.

But what about collaboration? Basecamp has a decent collaboration system, all email communication for a project can be passed through and stored on Basecamp. This can be handy I admit, and this is not something that LiquidPlanner offers at the moment. But, the problem with this is that if the email threads are not managed carefully it's very easy for important details to get lost in the clutter of communication. Basecamp does have a search feature but it's pretty basic and lacks filtering and sorting. LiquidPlanner has many different types of collaboration available. Files and links can be posted, detailed notes created (with a beautiful rich text editor), and Twitter-like commenting. All this is available for each task, on any project sub folder, or on the entire project. This will allow the team to more easily attach the important information to the project, rather than loose things in a flood of Basecamp email.

And there's even more great stuff happening. LiquidPlanner just released it's client portal system, making it even more valuable as a collaborating and showcase tool. I might need to do a part 2 of this comparison, but I think it's pretty clear from this post what tool is my favorite.