What Project Managers Can Learn from Angry Birds

If you haven't already discovered the most clever and addictive mobile game, Angry Birds, I suggest checking it out. The movie really tells the story best, but if you don't have the time to watch it, it's about launching birds at pigs. It's not only a physics-lovers dream; there are also some valuable project management lessons to be learned from the game.

Read more on the LiquidPlanner blog...

Project Schedule Promises: Are We There Yet?

“Just a minute!”

“OK! In a sec...”

“We’ll be done in a bit!”

How many times have you heard yourself say one of those phrases? How many times have they been said to you? If you’re a parent, then you probably find yourself saying them least a few times a day. And you probably learned them from your parents.

The real question is though, how many times were you accurate with that statement? Did you always get to that next task ‘in a sec’, or even in ‘just a minute’? Probably not all of the time. I know I didn’t and I know my kids got frustrated (at least when they were old enough to figure it out).

Now, what if your client or upper management are like your children? You might not say exactly those words, but you might say something like:

“This phase will be finished in a week,” or “Testing will be complete by tomorrow.”

...read more, on the LiquidPlanner blog

Been quiet around here, cause I've been blogging over at LiquidPlanner...

My latest posts on the LiquidPlanner blog -

In Project Estimation, "Guess" is a 4-Letter Word

What's Your Distraction Factor?

Check them out if you'd like!

LiquidPlanner vs. Wrike, the Battle of the Online Project Management Tool Continues

Next in my little battle for the title of the best project management tool, I took a look at Wrike and compared it to LiquidPlanner. If you’ve read any of my posts before you know that the battle is a little uneven, I am clearly biased towards LiquidPlanner but I do try to take a fair look at each tool. I also like to keep this as a friendly forum for discussion, so if anyone out there from Wrike wants to pop in a comment here and clarify anything about my descriptions, feel free.

I will be comparing the following features:

• Task Management / Schedule Building
• Collaboration
• Reporting
• Mobile & Misc

Task Management / Schedule Building

Creating new tasks is pretty quick and simple with Wrike, I specify a title, assignee, start and due date, duration, status, priority, included in, shared with, and description with a rich text edit box. I am allowed to set a recurrence on the task, which is kind-of handy. The duration is a single-point estimate of course. I have yet to find a project management tool that will allow me to have a ranged estimate for a task like LiquidPlanner does. This builds in a level of uncertainty into the schedule which is critical to keep projections realistic, and will keep the project manager from continually going back to revise the schedule when estimates change.


The “priority” field has 3 options - Normal, High and Low. This is a handy feature to be able to flag the task, but it does not make it go any higher in the list of tasks. A personal task list is ordered by due date, which makes sense at a basic level. If tasks need to be re-prioritized then the due dates need to be edited for each task individually, or the end dates adjusted via the timeline. I had fun dragging the little blocks around the timeline but the problem here is that the timeline is only as realistic as I set it to be. The timeline does not take into account the durations of tasks, the resources assigned to them and the other workload or work schedule of those resources, office holidays, etc. There is no way to see if any of the tasks are at risk of being completed by their due date, until they are actually overdue and then they turn red.


With LiquidPlanner, making a task highest priority is done simply by dragging it to the top of the task list. When this happens, the expected completion date for that and all other tasks updates appropriately. The expected completion date takes into account the other tasks assigned to that resource, working schedule of the resource, delay until date, and any other outside dependencies. The date calculated and schedule created shows a much more realistic picture of when things will get done, not just when we hope they will get done. Any items that are risk of not being completed by their promise date will immediately turn red and will remain that way until priorities are shifted or dates revised.


Wrike has a feature called “Flexible Structures”, which allows the manager to build hierarchies of tasks and simultaneously put a sub-project and a task in many projects. Tasks can be sorted in many ways. LiquidPlanner also allows the manager to organize tasks into a folder view and a task list view. So, projects are built and organized in the “Organize” view and then priorities are set and adjusted in the “Task” view.

Collaboration

Wrike has a “Discussions” tab for each task, and a tab where files can be uploaded. LiquidPlanner has additional levels of collaboration for each task, project folder, and root of the project. LiquidPlanner includes:

• Description (plain text edit)
• Discussion (Twitter type comment stream)
• Detailed Notes (rich text edit)
• Links
• Attached documents

This keeps the collaboration rich & organized. Wrike is launching an “Activity Stream” feature with it’s new version, which will show all activity over all projects and also include comments or discussion. This is a nice way to watch everything but I didn’t see a way to sort this stream by project/user/etc.

LiquidPlanner has a client portal system, a great way to collaborate with clients while controlling exactly what they can view & edit. Wrike does allow clients to be invited to the workspace to view projects, but as far as I can tell there is no portal-type system setup with controls over what elements can be viewed, edited, etc.


Reporting

Wrike has a nice sized list of filters available, all prebuilt and accessible from the left column. This is handy, but what I personally find more practical and useful is the prebuilt (and very slick) reports and custom filters that can be setup with LiquidPlanner. LiquidPlanner includes the ability to sort by task owner, project folder, task list and status (active, complete, flagged, work remaining, etc).

LiquidPlanner has a free iphone app, Wrike reports to be working on their app.
Both systems include timesheets.

Summary

Although I found the Wrike interface clean and fairly easy to use, LiquidPlanner still has more of the features that are important to me in the type of project management work that I do, with constantly shifting priorities and tasks that need to need ranged estimates. And with all the talk of project collaboration tools, LiquidPlanner is pretty packed with great (and very organized) ways to collaborate.

What do you think?

Email vs. Stream for Ideal Project Communication

I spotted this interesting post by Dennis Stevenson titled "Why would you abandon e-mail for Streaming tools?", which was a reaction to an article by Stowe Boyd "The Business Case For Streams versus Email". Both are worth a read, and got me thinking about how we communicate and how our messages are received (or not received) by our team. The debate here is stream (public post on shared workspace, ie. twitter/yammer like communication) vs email.

It's funny because like what Stowe Boyd mentions in his piece, this is just the next debate over company communications. In the 70's and 80's there was the debate about email, and in the 90's web-based email. I'm sure there was once a big debate about how and when to best use the fax machine, and then it was the greatest thing ever, and these days I just wish I could burn the thing.

Dennis Stevenson compares email to a hammer:

"pounding everything as if it were a nail. It's a useful tool, but not suited to every situation. Flow or Streams are a different tool, say a pair of pliers. If you've never used a pair of pliers and always used a hammer, you may not have a particularly good understanding of all the things you can do with pliers. This may call for experimentation and some trial/error. That's ok."

I would think that those who prefer to stick to email would say that when you send an email you'll be assured that the recipient will see it and read it. You can select exactly who will receive it. This might not be the case when posting something to the stream.
But that's not necessarily true. That message might never get to where it needs to be because:

• The email could get blocked or stalled by the occasional full mailbox, spam rule, down server
• The recipient could have email rules setup to file away specific messages into folders, this sounds great and very organized but if the filing is happening before the email is being read than it's possible that email might get missed
• The recipient might accidentally delete the message while batch deleting the junk mail from the night before (hasn't everyone had one of those "Who just sent me an email? I just deleted by accident!" experiences, where you send a note out to everyone you can think of asking who just sent you an email?). This is less of a problem these days now that mail can more easily be retrieved from the trash, but it could still happen.
• The recipient might just choose not to read the email from you (in this case there are some other 'personnel' problems that should probably be tackled first).

So for any of these reasons the message is lost, deleted forever or buried in a pile of other messages, never to be read. When it’s something important it’s always good to follow up via some other form of communication (phone, instant message, tap on the shoulder, dart-gun, etc.) but it’s better when the message gets to where it needs to go in the first place. Even when it does get there, it’s not always ideal to have it sitting in one person’s inbox, more on this below.

When a message is posted to the ‘stream’ (via Twitter hashtag, Yammer, or Yammer-style communication tool embedded within the LiquidPlanner online project management system) there are ways to direct the message to a specific person or group of people, and it’s also just out there open for the public. Is the message sitting in someone’s inbox? Well, it can be if there are email alerts setup for messages and in some cases those hesitant to change can even use their email to participate in the discussion on the stream. Unless it’s strictly confidential information (and in this case even email might not be the best option) I think having the message on a shared system, in the stream, is much better solution long term. What it really takes is a cultural shift, having a team that treats the stream like they used to (hopefully) treat their email - keeping the application or browser window open, referring to the stream first when they are looking for something (rather than checking email, wiki, or other notes). Posting information on a shared system means that information will never get lost with one person, or in one person’s email folders. This will help with remote teams, or if someone is unavailable or leaves the organization. Posting to the stream means that critical details are always publicly accessible if an ass needs to be covered at some later point in the project. Although there is a problem that with some tools the messages might not be retrievable after a certain period of time (mentioned in the 2nd comment on the Boyd post). Because of this Twitter might not be the best tool for project communications.

One of the features I like best about the LiquidPlanner online project management tool is that the chatter can be easily organized by project task, sub-folder, or on the root of the project or client. There is no issue of older comments being deleted and the details specific to a task will always be stored where it can be easily found, with that task.

Communication is a critical element of project success, and as the team grows the number of possible communication channels multiplies ( N x ( N-1 ) / 2, where N is the number of stakeholders). I believe that using the stream is the easiest and most efficient way to cover all of those communication channels and ensure that the important details are available anytime and for anyone.

It's All About the Plan, Right?

This brings back somewhat painful memories of a large project post-mortem where the CEO continually asked "Well, was there a project plan?" (and didn't ask anything else). In this specific case, there was a decent project plan, but so many other things (that the CEO chose not to acknowledge) went wrong that the project plan was not able to salvage the project.

Jim Vaughan, in the IT Project Management Blog, also asks (from a much more informed perspective of course) why so many projects with a project plan are failing? His explanation is that too many project managers will open up their slick & sophisticated PM tools and start entering tasks, since the task list is the first thing they will see. This process is a more bottom-up approach (or inside-out, as he says).

His solution to this problem:

...is not the tool but rather the methodology that the PM chooses to use for the development the project plan. The best way that I have found to do this is to gather the technical experts together in a large room with a blank wall. Together, under the leadership of the project manager, using sticky notes, create the WBS from the top down on the blank wall. From there the data can be entered into the tool of choice. This methodology will produce a much more effective plan.

Agreed, that working together with the experts will lead to much more accurate and reliable project plan, but let's not discount the advantage that a powerful project management and collaboration system can give the project leader in setting up and maintaining the plan throughout the project. With web based project management software where all team members can log in and collaborate on each task in the project, the project plan will no longer be something that one person maintains in their own little bubble (like I used to, back in my MS Project days). With a system that allows team members to estimate their tasks in ranges and add new tasks once issues crop up or new challenges arise, the project plan will continuously be relevant.


So, take Jim Vaughan's good advice in building your next project plan, but make sure when you do that you are using a project management tool (albeit somewhat slick) that will allow you to keep your experts engaged and connected throughout the project.

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.

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.

Everything I Needed to Know about Risk Management, I Learned from my Kid's Daycare

Was picking up my kids at their after-school daycare early this evening, when I noticed a sign on their wall. It was titled "Emergency Response" and had a list of awful things that you'd never want to have happen to your kid, and how to handle them. My guess is that there is a state law that if a daycare that wants to maintain certification it needs to have a sign posted publicly that details what the response would be if say, a child were to -

• choke on something
• start vomiting or show flu symptoms
• burn themselves on a stove (especially at an in-home daycare)

Even though I didn't want to think about any of these things happening to my children or anyone else's child at the daycare, I was comforted by seeing that these problems were recognized and addressed with a solution.

Posting this information in a public, central location seemed to me to be the perfect way to handle project risks. At the beginning of a project the team should meet to brainstorm on the 'Perfect Storm' - What are all the possible things that can go wrong and how are we going to handle them? This information should be shared with stakeholders and referenced/updated on a regular basis. The thing with risk management is that nobody wants to think about any of these things actually happening, everyone wants to be an optimist, and it's up to the project manager to be a pessimist and force the team to think of the worst case scenarios. Including this process of thinking through the risks and coming up with solutions should put people at ease, knowing that there is a plan in place to handle anything that comes their way. And even more so, posting the information in a public area will help to remind everyone that yes these risks are out there but we are prepared for them if and when they present themselves.

A Tale of Two PM Tools, the Sequel....

Last spring I wrote up a comparison of Basecamp and LiquidPlanner. I think I'm pretty open on this space about my feelings for LiquidPlanner but I think the comparison was pretty fair nonetheless. I started to realize even then that I'd need to do a followup post since there were so many new features in the LiquidPlanner pipeline. And, to Basecamp's credit, they have also launched new features since then.

In my opinion, the biggest features that LiquidPlanner released since May were the client portals, iPhone app, time-tracking and the treats in the December '09 holiday release.

Client Portals
This was huge! With Client Portals LiquidPlanner now has all of the client collaboration ability that Basecamp has, with more control over what elements are shared and what are kept internal. Because of LiquidPlanner's powerful scheduling engine, the client can see a quick view of how much work is actually left in the project, which can be a more valuable snapshot of things than the list of remaining milestones in the Basecamp schedule.

Clients can also collaborate on tasks with the main workspace users. Clients can see recently completed and upcoming tasks, and various reports (without any additional third party plug-in). There can be an unlimited number of client users on each project, and there is no additional charge for client users. Not only do client portals include Basecamp-style email collaboration, but also Twitter-like commenting and a detailed notes area that is much easier to use than the Basecamp Writeboards.

iPhone app
This was developed in-house (in the LiquidPlanner house that is...) so immediately separates itself from the Basecamp iPhone apps that are all developed by 3rd party vendors. The LiquidPlanner "Mobile Dashboard" is FREE and because it is maintained by the same team that builds the product, you know you're getting the best app possible (and you know who to go to if you find a bug...not that the LP programmers ever make bugs though). The iPhone app provides the following functionality:

• Collaborate with team members and clients
• See prioritized tasks and create new ones
• View rich text comments (images, etc)
• Log time and re-estimate tasks, set promise dates for tasks

Now, I confess I have not tried all of the iPhone apps for Basecamp. I did purchase Outpost at the suggestion of my coworkers but rarely use it because whenever I open it I need to wait anywhere from 15 to 50 mins for all of the projects to sync up. I don't use it often enough to have it sync up daily so I need to suffer whenever I do chose to open to app. Happy to hear reviews of other apps from other Basecamp iPhone app users.

Time-Tracking
LiquidPlanner launched integrated time sheets at the beginning of the summer, and what I LOVE most about their time sheets is that it is directly linked to the tasks in the project. So, gone are the days when a team member needs to sit and scratch their head, wondering what they did all of the week before and how they should log their time. The second best thing I love about LiquidPlanner's time tracking is that they have these handy little timers attached to each task, so you click them on when you start working on something and then let it run as long as you are working on the task. Whenever you finish or move onto something else just stop the timer and your time will be recorded (or you can edit the recorded time, to make sure all of those trips to the candy machine are subtracted from your billable time...). I use LiquidPlanner time tracking for the freelance work that I do and I find it to be incredibly useful when I'm watching actual vs. estimate, reporting hours and building invoices.

I've played around with the Basecamp time tracking system, but have never formally used it with an agency or on my own. I've used a few other time tracking systems and feel like I have an understanding of the critical features. I think the Basecamp time tracking system could be ok for a freelancer, but I think the most significant problem with it is that the description of the task is way too free-form. Yes, the time logged is automatically tied to a Basecamp project, but there is no way to gather more valuable information like what phase of the project, what type of activity, and which deliverables. This information will only be tracked if the team member decides to add all of that detail into the description area, and as we all know most people don't like spending too much time working on their timesheets.

December '09 Release
There's a whole pile of nice presents here, and rather than go through all of them, I'll pick out my favorites. First is the task calendar view, which gracefully plots out your team members tasks on a grid calendar view. And to add even more value to that calendar view, items at risk will be flagged red. Workload analysis is another really great new feature that I find extremely useful. It will show your team's availability, show periods of overload, and steady work. It's a great way to get a bird's eye view of what's going on over various blocks of time.

What's new in Basecamp?
Basecamp released a handful of improvements to it's collaboration & document sharing tools, among them stylized email notifications (which got a mix of praise and backlash), integrated accounts, quick date pickers for milestones, due dates on to-do's, thumbnail image previews, improved file uploads and new file icons, and enhanced private messages. Some nice features here and UI improvements, but nothing monumental in my opinion. I still find major project management tools lacking in Basecamp. Basecamp won't stop me from overloading my team members, building a schedule that's completely unrealistic, and gathering any knowledge about how good or bad my work estimates are.

I'm going to happily stay on the LiquidPlanner team, I still haven't been convinced otherwise.

Keeping the Micro out of Manager

Was talking with someone a few days ago, and surprised to discover that we both took the same career path. He was also a front-end web developer for a number of years, then went into web project management. The only difference was after 2-3 years he dropped project management and went back to doing web programming. I asked him why he stopped and his answer was, "I was tired of getting on people to make sure they got their work done, and dealing with the frustration when they didn't. It was too much like babysitting." I nodded, thinking of my own struggles with team members over the years, trying to keep the micro out of manager. Of course, there are always legitimate reasons why something is not done when we originally think it will be. But this is more about how to make sure people are clear on their priorities and know where to go to find help, without having the Project Manager standing right behind them the whole time watching them do their work. Someone I used to work with suggested the 'walk around with a clipboard' technique, a variation of managing by walking around. But, to me it seemed more like I was getting too much in my team members faces, checking off what they have done and asking what was left to finish a task, etc. I prefer to let my team members report this on their own, and give them the tools to do so.

Then there was also the suggestion of putting a big dashboard on the wall, with a list of task and due dates and assignees. Of course this is very visible and a great way for everyone to see what everyone else is doing, but takes time to manage, and it didn't seem to make sense to me to lose time managing multiple tasks lists in different places. Of course, if I could have a projector that would take the team's task list right out of our web based tool and display it on a wall, now THAT would be awesome.

So, what is the best way to make sure work gets done, without breathing down that team member's back (and I'm sure we can all think of atleast one team member that needs this kind of 'help')?

1. Regular status or 'stand-up' meetings are good, keep them standing so that the meeting is quick and on track, and have each team member report:

• What s/he just finished
• What s/he will be working on next
• If there are any issues holding him/her back

2. A strong web based project management and collaboration system, so that all team members can see the online dashboard that lists all critical deadlines and tasks with their assignees. The collaboration system will keep all details in one place so nothing will get lost in email folders or scribbled notes. Team members should be able to log into their personalized dashboard and see their upcoming tasks with due dates, and also get regular email reminders of their upcoming tasks and due dates.

3. And sure, a little bit of walking around is good. Don't get me wrong, I'm not against checking in one-on-one with team members, just having been micro-managed in the past I'd prefer to avoid creeping over to that dark side.

What have you done to keep your team members on track, especially the ones who need a little extra attention?

Time Tracking: Converting the Masses

I remember way back in 1999, when I was filling out my first time sheets as a web programmer. We filled them out on on excel and sent them to our boss at the end of each week. I didn't really see the full value of tracking time, and jokingly asked my coworkers if I should be recording time that I am in the bathroom, etc. Since then not only have I had an opportunity to use a few different time tracking systems, I've gotten a real appreciation for the whole idea of tracking time and understand how critical it is for an agency and it's clients.

And I've also had an opportunity to work with many people who don't like tracking their time, who feel like it's a waste of energy or forget to do it until weeks or a month has passed, or just don't know how to do it properly. It pains me to see people who just don't get it, and it's even more painful when it comes time to report on a project and the data is either not there or not reliable, then what is an honest project manager to do?

Well, rather then let things get that far, I wanted to talk about some of the anti-time-tracking personalities and what we can do to help them.

The Forgetful One: The person who just can't seem to get it into his routine that time needs to be logged regularly. This person is not necessarily opposed to tracking time, just gets caught up in other things and never remembers to do it. When it comes time to catch up on all the days that time hasn't been tracked, numbers or guessed or fudged and inevitably inaccurate.
How we can help:

• Setup a daily calendar event to help remind him to track time. Send a reminder email each morning asking him if he logged his time from the day before.
  
• Make sure the system is as easy to use and as accessible as possible (I love the LiquidPlanner task timer system, so easy!). Make sure logging to specific tasks is intuitive and can be done quickly and painlessly (better to get more detail on a task than just time logged as "programming").
  
• Put a huge and really annoying alarm clock at his desk, set to go off at 5:30 every day to remind him to log time!

The "Ashamed" One: The person who puts in decent chunks of overtime, but is afraid to log his time for fear that it will look like he is too slow and it takes him too long to finish tasks. He knows what the target budget is, and doesn't want to make the project 'look bad' by adding more of his overtime hours to it.
How we can help:
Oh, how these people put gray hairs on my head...

• Explain to him that he should never be embarrassed or afraid to report time worked on a task. The only way we can ever learn from a project and improve our estimates is to see actual time spent on each task and compare that with the original estimates made.
• Yes, the budget might go over, but this is a fact of life and not only should he not be afraid or feel responsible, he should be comfortable (and proud) to show the rest of the team that he is committed enough to put in the extra time when needed to get the work done.

The Close-Minded One: This is the person who just doesn't see the point in logging time, she thinks it's a huge burden and can not find any benefit in doing it. Who cares how long she spent programming a little feature or sitting in an internal meeting? She's already wasting her time in the meeting, why lose more time recording it in her time sheet? She'll leave her time sheet empty for as long as possible and then just make rough guesses when time comes to fill in the blanks, sometimes many weeks later.
How we can help:

• If you work at a client services agency and bill based on hours worked then explain the direct correlation between the hours she records, and the dollars we will be charging that client (which will then eventually get to her paycheck)
• Show her the reports from the last few projects, and show her actual hours logged vs initial estimates made. If there is a striking difference between any of those totals (which, I'm sure there can be) then maybe she will see the importance of seeing how long things actually took and then using this information to make a better budget next time. If we can justify bigger budgets, than maybe she'll get a bigger bonus next time around!
  
• Losing too much time in unnecessary meetings? The only way we'll be able to figure that out is by looking at people's time sheets and reporting on billable vs non-billable time. Not that all meetings are unnecessary of course, but we all know that some of them can run a little long at times...

What types of personalities have you encountered, and what have you done to show them the light?

Lessons in Communication from "Why Mosquitos Buzz in People's Ears"

I don't remember reading this book as a child, but this was one of my husband's favorites so it came along with a batch of books that his parents saved for him. We've enjoyed reading it to our kids, and I think there are some good lessons here that can be applied to project communication.

To summarize, a mosquito brags to an iguana that he spied a farmer digging yams as big as mosquitoes. The iguana says "I would rather be deaf than listen to such nonsense", and puts sticks in his ears and heads off through the jungle. The friendly python says good morning to the iguana, but after getting no response from the iguana, assumes that he is plotting some mischief against him. The python then looks for the first place he can find to hide, and shoots into a rabbit hole. The rabbit sees the snake and gets frightened, and runs across the clearing. The crow saw the rabbit, and flew into the forest crying an alarm. A monkey hears the crow and leaps through the trees, accidentally killing a baby owl. When the mother owl returns to find one of her babies dead she is so shocked and distressed that she is unable to wake the sun each day with her hooting. The nights grow longer, and when the King Lion calls a meeting to get to the bottom of the situation, the chain of events is traced back to the source of all the trouble — the pesky mosquito. Finding the culprit satisfies the mother owl, who calls the sun back again. But, the mosquito is forever plagued with a guilty conscience, compelling him to forever be a pest.

I'd like to focus less on the mosquito who started it all, and more on the iguana and the pyton, and the other animals afterwards. When the iguana didn't answer the python, the python thought that the iguana was plotting something evil against him. He then went to hide. The rabbit saw the python, she thought something was very wrong (and was scared of the python too) and scurried off. This continues, without anyone stopping to try to find out what was really wrong. Each animal just makes assumptions without asking any questions, and this ultimately leads to the death of a baby owl and prolonged darkness. Now, let's believe the story and accept that animals talk to each other, the python did not try to find out what was really wrong with the iguana, and neither did any other animal afterwards. All went on assumptions without taking time to ask.

In the same way while working with a group on a project, it can be easy to make assumptions without asking more questions. This can easily lead a team member down the wrong path, resulting in wasted time and effort. People should not be afriad to ask questions of others in the group if there is something they do not understand, and the leader should always try to make information as crystal clear as possible. The sooner the misinformation is caught, the less damage that will be done, both in the real jungle...and the jungle that is your project.