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!

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 >

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

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!

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.

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.

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.

The story of my (never ending) love affair with LiquidPlanner

Don't worry, this post is appropriate for children...

It all began about a year and a half ago, when I got slammed by the boss for a web project that was about to enter the development phase and was being projected by the programmers to take about double the amount of time that it was originally estimated. I kept my head up and went back to look more closely at the original estimate and what we knew about scope at that time. Well, we knew very little, practically nothing. And, I remembered that the estimate was made months earlier and my client said to me "just give me a rough ballpark, we'll figure the rest out later". So, that's what I did. Well, I won't get into the details of how that drama continued, but what I will say is that the experience led me to start doing my own research on estimates and how to make them more accurate. I was stunned by the experience, by the idea that I was being held to a number that was calculated before any of us had any idea of what the project was really going to be. It was an estimate, a guess... a really rough guess.

My reading and research just backed up my position even more, that estimates made at the very beginning are subject to a high degree of error (anywhere from .25x lower to 4x higher). I got this and much more great information from a book by Steve McConnell, titled "Software Estimation: Demystifying the Black Art (2006)". I wrote about this idea, and the importance of presenting estimates in ranges on my company's blog. You can find the same post copied here, where I compare the uncertainty of software project tasks with the challenges of herding toddlers around in the morning.

From that point on I was on a crusade to make sure that all estimates my team produced were in ranges. It took a little while to get the programmers into that mode, after the Director of Technology read the same estimation book, he also helped me get the programmers to think of their estimates in terms of best case and worst case. Nobody wants to think that way at first, you always want to think that everything will go smoothly and nothing will be confusing or unclear, but the reality is that things are not always what they seem and we need to allow the extra room to figure things out sometimes.

So, by this point you're probably getting impatient and wondering where the juicy details about the love story with LiquidPlanner starts. It's coming very soon...I promise.

I don't remember the exact order of things, but I know I was pretty frustrated with Microsoft Project. I was a true believer in ranged estimates and I couldn't figure out any good way to get those worked into my MS project schedules. I experimented with new fields and was really unhappy with the lack of flexibility. I wanted to have a tool that showed my schedule in terms of best and worst case so that project stakeholders would have a range to work with and not expect a commitment to an exact date and exact number of hours of work (especially so early on).

Then, that one magical day, I was contacted by Liz Pearce from LiquidPlanner. She had read my blog post about including uncertainty in project estimates and wanted to tell me more about their web based project management tool. It was love at first sight, I was sold pretty quickly just based upon the fact that I could make my task estimates in ranges. Then, as I did more research I saw how LiquidPlanner was going to solve more of my problems. Our office was not using MS Project server so there was no central workspace for project plans, we all worked isolated on our own files and one project manager never knew when the other one needed her resource (yes, all project managers were women at that company at that time...go us!). By having the entire production team on Liquid Planner (for a much lower price than Project Server of course), we could easily see when a resource was overbooked. I also was thrilled to see a project management system that had such great collaboration tools, I was not going to have to rely on saving important emails to folders or logging the information in a shared file, we could all go to LiquidPlanner to see all important discussions and files related to our project. As I researched more about the company, I saw that Steve McConnell was on the advisory board. He is the author of the book I referenced above and many other great software project books that I have read since. One more reason I know LP was for me.

I've been using LiquidPlanner for about a year now, and have never thought of turning back. I recently moved to a new company and have brought LiquidPlanner with me. I've found that the scheduling system has proven an invaluable tool for my resource management challenges in my new workplace. And all this time, I've kept up the relationship with the good people at LiquidPlanner. I like them and believe in their mission so much, that I found myself bragging about their product on project management blogs and twitter posts, LinkedIn and other social media outlets.

After a few months of this, LiquidPlanner and I decided to make it official. I am now a part-time "Social Media Evangelist" (that's the best title I've heard so far, hope I live up to it!) for LiquidPlanner. So....if you see me out there listing off all the advantages to using LiquidPlanner to manage your projects, now you know why. I hope our relationship continues to thrive, and if you haven't checked them out....well, what are you waiting for?!

Making some buzz about blogging for PDUs!

It's still not official yet, but people are talking about it! See my interview on the "Stepping into Project Management" blog. Thanks Soma B!

It all started with a tweet...PDUs for blogs!

Well, it's not official yet. But, the discussion has begun, and what better place than the Project Managers on Twitter (#PMOT) group. This has become my new favorite go-to place for the latest ideas, thoughts, and link sharing of all things project management. The group is growing, tweets becoming more frequent. If you're not sure what this hashtag thing is all about, at least for the project management scene, I recommend checking out this post over at Raven's Brain: Project Management Hash Tags on Twitter.

So, anyway, it all started one day when Vincent Birlouez said this:


And then Kelvin Zhao replied with this:

And that's when I saw the tweet and got in on the conversation. I won't continue to paste the screenshots of how the discussion continued, but it seems that there is a good handful of social media savvy project managers who would like to earn PDUs for their project management related blogs.

And why not? We enjoy what we do, we enjoy reading and learning about what we do and how to do it better, and if we want to invest the time into maintaining a project management related blog, why not get some credit for it?! I have to admit, my own blog posts have slowed down in the last couple months, I've started to contribute to a non project management blog (gasp!), which requires me to post twice a month. I also try to post on my company's blog every so often, so my blogging energy gets diverted somewhat. But anyway, if it's on your mind and you enjoy participating in the discussion of all things project management, only makes sense to get some PDUs out of it.

The PMP handbook describes a PDU as this:

" The professional development units (PDUs) is the measuring unit used to quantify approved learning and professional service activities. Typically, one PDU is earned for every one hour spent in a planned, strcutured learning experience or activity. "

And there are 5 categories under which PDUs can be claimed:

1. Formal Academic Education
2. Professional Activities and Self-directed Learning
3. Courses offered by PMI Registered Education Providers/PMI Components
4. Courses offered by Other Education Providers
5. Volunteer Service to Professional or Community Organizations

So, after some research and twitter discussion, seems like the category that PM blogs fits into is category 2, Professional Activities and Self-directed Learning. Within this category are two areas that seem the most relevant:

2B - Author or coauthor of an article pertaining to project and/or program management published in a non-referreed journal (e.g., PM Network)

2-SDL
- Self directed learning activities are individualized learning events involving personally conducted research or study. Learning may include informal activites such as discussions or coaching sessions with colleagues, coworkers, clients or consultants. It may include articles, books, instructional manuals, videos...etc.

Thanks to some PMOT friends (@andystitt829, @GKonProjMgt, @pm4girls ) who are helping me connect to the right PMI people, the movement to get blog posts to formally qualify for PDUs has begun! The initial response from a Certification Standards Associate at PMI was that while there are no current plans to create a separate category for PM blogs,

"PMPs can report the research done for the blogs under Category 2SDL - Self Directed Learning. Under this category, 15 PDUs can be reported per cycle for any personally conducted self study or research regarding project management. Since blogs often required research on the subject matter, any research that would apply to this categories requirements could be reported."

I doubt that I could use this post to claim PDUs, but the idea has been planted. Looks like there's a way to get PDUs within the current system, and I would just love to see the word 'blog' added to the PMP handbook in that category 2 area. I mean, I'm sure blogs didn't even exist at the time the handbook was written, much less being used by so many of us PMs to share ideas about project management.

So, if/when PDUs for blogs becomes official...how should it work?

Should we submit our blog post to PMI for review and approval? Can we have a peer review system and earn the PDUs that way? Can we earn 1 PDU for each qualifying post, or cap at 15 each year the same way PMI does currently?

If we're going to nudge PMI into the social media world, than shouldn't we also be able to earn PDUs from participating in discussions on Project Management social networking sites like PPMNG, Gantthead, or LinkedIn? And of course, you must not forget Twitter. I have no idea how it would be quantified, but makes perfect sense to me that participating in the PMOT discussion should earn PDUs.

Stay tuned, I'm going to go onto the PMI website and register my 2SDL PDUs for my blog and the reading/research I've done in making my posts. We'll see how it goes, and meantime, it would be great to start the discussion of how we can move PMI into the web 2.o world.

More on project requirements - on Horn Group's Brass Tacks

The importance of gathering, defining and confirming project requirements, and the risks involved with making changes later in the project. Read more about it...here:

"If you don't have time to do it right, when do you have time to do it over?"

Learning Lessons in Requirements, in the Shopping Line...

I was at the Children's Place the other night, grabbing some new footed pajamas for my 2 year old, when I found an interesting parallel between clothes shopping and locking down the requirements in a project. I had just been working on requirements earlier that day, and trying to schedule a meeting with stakeholders to review and sign off on requirements. So, what can I say, I had requirements on my mind.

I knew exactly what I wanted when I got into the store, went right to the pajama rack, found the last remaining size 3T pajamas and went right to the line. Also waiting in line with me, were some stereotypical annoying shoppers. Right in front of me was the couple who had a whole bunch of clothes piled onto their stroller and the wife did more shopping while the husband waited in line. Maybe there's not anything technically wrong with this, but it's annoying and I wish I had the nerve to push myself in front of them. Then, at the register was a guy who was changing his mind last minute and ran back and forth to put stuff back and get something else. Those people are even more annoying! So, fortunately they called in more register workers and the line moved a little faster, but in the time I was waiting my thoughts drifted to requirements gathering and management and the challenges of making changes in the beginning, middle and end of a project.

So, the shoppers are project stakeholders, and the time they spend walking around the store looking for stuff is the discovery process. They are not sure what they want and need time to explore and figure it all out.

Then, when they get in line should be the moment that they identified project requirements and are ready to confirm. For those who need to swap something after they have gotten in line, while sortof annoying...it won't slow things down drastically. I would compare this to making a requirements change while in the design phase. It can complicate things, but probably won't bring the project to a halt (hopefully!).

Next, at the register is development and implementation, and any changes made at this point will definitely slow down the rest of the line, and cause significant delays in our parallel project.
I'm reminded of one of my favorite software development charts, from the good people at Contrux, the cost of defects graph:




This chart illustrates the cost of repairing a defect at the beginning, middle and end of a project. The point here is to find and repair early. So, similarly with requirements, make sure they are clarified and confirmed early and make sure all stakeholders understand exactly what they are getting and the cost involved with making changes later on in the project.

So, if you're a project stakeholder or a project manager and sense anything unclear with requirements, just imagine that long line of angry shoppers behind you, furious that you're slowing everything down for them. Pick the right sizes and colors and make sure you know exactly what you want, otherwise you risk reeking havoc on your project.

The importance of soft (serve) skills...

I debated posting this picture on the interwebs, I mean it's not something I would toss right up on Facebook or anything. I don't consider myself the most photogenic person, but this one is pretty embarrassing. But, I'm going to do it, will make this big sacrifice for my blog. That's how much you mean to me... blog.

Anyway, what's the picture all about anyway? This picture was taken in the summer of 1999 at the overnight camp that I worked at in northern Wisconsin. I was a division leader for the 16 year old group, so I directed a staff of about 10 adults and around 65 16 year olds. The kids put on a play every summer, and the night of the play after everything is over the kids get an ice cream party. Along with this tradition, comes the custom of having an ice cream fight in the dining hall where the ice cream party is held. It's probably the thing the kids look forward to most, they are so wired from the play that the ice cream fight is an excellent way to release some energy. But, of course the camp director and some of the other higher-ups would prefer that this not happen. And, as a member of the staff I should follow the camp directors wishes and make sure this doesn't happen. Well, as you can see by the picture, I didn't. And, this is the one picture from my 6 years working at that camp that I keep in a frame on my dresser and probably look at every morning.

Why is this picture so significant? It reminds me of the importance of moderation in all things, of having structure and holding to the rules when it's critical to do so, but also making sure to have fun and enjoy the moment when it's meant to be enjoyed. I remember thinking about whether I should let the kids have the ice cream fight and how long I should let it go, and then how I should end things and make sure they clean up, etc. I remember times when the fight got shut down immediately and the kids yelled at, and this only made the kids want to get into more trouble, which they did later that night. So, I discreetly got the word out to some of the kids earlier in the day that I was going to let them have their ice cream fight for a little while, and then shut it down when I thought it was the appropriate time. I told them that I wanted them to be responsible about it and be good about cleaning up and not doing anything crazy around the camp that night. I think they appreciate that I trusted them and had respect for what they wanted. So, the evening went pretty well, the fight went for a few minutes (sounds likes short time, but when you have chocolate syrup in your hair, its plenty of time!) and then I stopped it. The kids were great about cleaning up, and the rest of the night was quiet.

I'd like to think that this decision gave me nice brownie points with these kids, and it was important for me to win their respect. In situations I've worked in, it's important for me to feel trusted and respected, so I want to make sure to return that to those who I'm working with. I could never understand why people would use their position as division leader (or project manager) as a way to pull a power trip and talk down to and show little respect to their group. Just seems counterproductive, and then you don't get to have ice cream dripping down your shirt and a room full of very happy 16 year olds.

Funny, through and after college so many people I know went off to do very impressive sounding summer internships, and I spent 6 summers as a leader of kids and adults at an overnight camp in Wisconsin. This was probably the best soft skills training I could have had, and the ice cream incident is just one example of why.

Are we there yet? ... Are we there yet?

I'm brushing my older daughter's hair one night (well, this happens on most nights) and even though I try to be gentle and use that spray in conditioner, she still winces and cries "ouchie" at each stroke. I'm tired and the only response I can give her is "We're almost done!" Same coaching technique I use when I'm clipping my kids toenails, walking with them somewhere in bad weather, or doing any other unpleasant task that I know they just want to be over.

But, I realize that I'm a hypocrite when I say "we're almost done" a few times before we're actually done, or something like "just one more brush" when I know there might be more than one. I mean, I want to keep her spirits up, but I'm also being misleading and not holding up to my side of the bargain by not my promises. She hasn't yet said back to me "but Mommy, you said one more and you're still brushing my hair!"...but she's 4, give her time and I'm sure she'll figure it out.

I worked for many summers at an overnight camp in northern Wisconsin. Campers of mine from the summer of 1996 told me a story of the year before, when their head counselor took them on a 'short hike' one night after a day of fasting (it was a Jewish holiday that required a fast) and repeatedly told them it was going to be just 10 more minutes, until the hike ended 1 hour later. You could imagine the kids weren't thrilled, and I think there might have been some fainting and worse that evening.

So, this reminds me of the problem we face when reporting project status to the client, senior management or any other stakeholders. As the project is heading through system test and approaching launch, it's easiest just to say "the project is almost ready to launch." But, this isn't good enough, this doesn't provide an any helpful measure of time to allow the stakeholders to plan. On the other side of the spectrum though, I have a hard time accepting the report that a project is "87% complete" or some arbitrary number like that. Of course, this number probably comes from looking through all the tasks completed and the ones remaining and doing the math that way. But, we know software, it's impossible to predict with 100% accuracy when something will be complete until it's actually complete. Books and blogs I've read support the idea that nothing is ever 75% complete or 50% complete, it's either finished or 0% done. How many times have you found yourself checking in with programmer's who report a task 95% complete, every week for 3 weeks! It's always 'almost' done, and something else always comes up to delay things once again.

So, I prefer to rely on ranges. In the same way it's best practice to make task estimates in ranges when possible, the remaining time should also be reported as a range. So, rather than say that launch will be on March 1st and then a few days later report that launch will be March 5th, keep the launch date as a range of dates for as long as possible. Of course when the launch needs to be a hard date or stakeholders are pushing for a solid commitment this flexibility won't be available. In an ideal scenario, the project manager can set realistic expectations from the start and keep those final dates in a comfortable range rather than commit to an exact date very early on.

So, I don't see myself saying to my daughter "I will finish brushing your hair after 3 - 10 more strokes", but I'm sure I can find some way to stop leading her on, and should try to soon before she calls me out on it!

So, what exactly DO you do??

I run a youth group a couple weekends a month. It feeds the part of me that worked at overnight camp for 6 years through and after college and still enjoys informal education and just doing good stuff with teenagers. And I'm sure there are some parallels between running a teen youth group and managing projects, but that's not what this post is about.

This past Saturday night I had a program with the kids at our local synagogue, we were painting a mural and making bead bracelets to sell to raise money for charity. While we were breaking for pizza, one of the girls saw me sneak away to check my phone for email/etc. She asked me what my real job was (always a funny thing, because for the longest time the kids didn't think I did anything else besides organize their little programs).

I told her I was a project manager.

She said (with not so much enthusiasm), "Oh, ok. What does a project manager do?"

I said, "Well, I help build web sites and applications. I make sure that people working with me know what they have to do and when it needs to get done. I have to keep things organized."

At which point she said (with still not so much enthusiasm), "oh...ok."

And then I thought later, "Boy, she must think my job is utterly boring!" But then I realized, had someone told me when I was 16 that I was destined to be a project manager, I would have laughed! When I was 16, I wanted to be a concert marimba player, then a professional soccer goalkeeper, then a special effects artist for the movies. Well, I ended up studying mechanical engineering and after a handful of years as a web developer, ultimately became a project manager. After almost four years of working as a project manager I was still not even sure if it was the career I wanted. I decided to go for the PMP, to get some formal training to complement the real life experience I had from managing web projects for a large scale custom content management system. I told myself then that if after my PMP crash course that if I didn't like what I learned then this would be the right time to leave project management and try something else.

Well, the course was good and the content was just the start of a whole new chapter of professional development. I actually really enjoyed topics like risk management, estimation techniques, change control process, work breakdown structure, and more. The course was just a very brief overview, enough to wet your appetite. So, that began my quest to learn more about what it really means to be a project manager. Picked up lots of used books on amazon and surfed the project management blogosphere. It's been a great ride and it still continues.

So, why do I like it so much? It's interesting, it's challenging, it keeps your blood pumping. There's drama with quick and intense decisions, there's "ah-hah" moments when you can figure out something to improve a process and watch your team benefit from it. Where I am working now at Horn Group, I love the opportunity to be able to experiment with new communication methods and try figure out what processes will help improve the groups project work. There's the fun and challenge of working with different personalities and trying to keep people happy, and for that I'm sure the years of being a camp counselor and youth group leader must have been good preparation. Not to say that every single day has the roller coaster ride, but there's always something interesting to do.

So, will the girl from the youth group be inspired by my words and go on to be a project manager? Probably not...I don't remember meeting anyone in college who was actually studying to be a project manager. But, I'm happy I found my way here and enjoy what I do enough to make time outside of work to read & learn more about how to become a better PM. If that's not a satisfying career, I don't know what is!

New post on NYC Moms Blog

Yes, I'm blogging around these days... this one isn't exactly about project management, but touches a bit on the poor management of a process.

It's the therapists that made me crazy...

When my 4-year-old was younger, she would call balloon "a-boon", balloons "buna", and yellow "wellow". All kids do have cute ways of saying things, when they are still figuring out how to put the sounds together. And it's fun, it's fun to listen to them say those cute things and know exactly what they are trying to say, and those are the things we write down or save somewhere in the baby memoirs (more about that in another post)....

Read More....

New Blog post on Brass Tacks - Horn Group Blog

Getting the Word Out, about the After School Art Class and Project Tasks

I’ve been thinking a lot about communication lately, both because I’m a project manager and well…that’s what project managers are supposed to do, and because I’ve had my share of frustration with my older daughter’s preschool and their process of sharing information. It’s funny to me that professionally I try to be completely on top of information and making sure it gets to where it needs to go, but yet I can’t seem to keep anything of importance about my daughter’s school, the schedule, meetings with teachers, etc. anywhere on my radar. A few times already I’ve had to dash out to get her because she had a half day that I didn’t know about, or the after school program was canceled that day. Fortunately I’ve been able to keep straight what days she gets school lunch and what days she gets lunch from home…so I am proud to say I have not let her go hungry yet!

Read more....

A Lesson in Software Specifications, from Amelia Bedelia...

I read kids books a lot...to my kids of course. I've also been on a software/project management book reading kick lately, but more about that in a minute. Tonight I was reading Amelia Bedelia to my 4-year-old and it got me thinking about something else I had just read in Steve McConnell's Rapid Development this week.

So, for those who may not know, the Amelia Bedelia series is about Amelia Bedelia, a house maid for a wealthy family who always gets the instructions wrong because she uses a different meaning of the key words. So, when asked to 'trim the steak' and 'dress the chicken', she procedes to add bows and ribbons to the steak and put the chicken in baby clothes. She always saves herself from being fired by cooking something really great for her employers.

While reading the story (probably for the 60th time since we got it a couple years ago) I thought about how you can never just assume people will understand what you want them to do or what you are trying to describe to them. The more you can get out of your head and on paper the better. Amelia Bedelia is a great example, and another way to think of it is when there are not enough details and too much left up for the next person (let's say a software developer) to design on their own. When given this opportunity, the sky is the limit for how basic or extravagent the feature can be designed.

Steve McConnell gives a great example of this in his book Rapid Development. He discusses the importance of making clear goals, and uses an example of a specification that is silent on the question of whether to provide the user with the abiliy to control polymarker's sizes. The developer is left to answer that question and has any number of paths to take:

"1. Do not provide any control at all.

2. Set up the source code to be modified in one place for the whole set of polymarkers (that is, sizes of all polymarkers are set by a single named constant or preprcessor macro).

3. Set up the source code to be modified in one place, on a polymarker-by-polymarker basis, for a fixed number of polymarkers (that is, size of each polymarker - square, triangle and so on - is set by its own named constant or preprocessor macro). "

all the way up to..

"8. Allow for interactive, end-user modification of a single polymarker-size specification.

9. Allow for interactive, end-user modification of polymarker-size specifications, with one setting per polymarker, or a fixed number of polymarkers.

10. Allow for interactive, end user modification of a polymarker-size specifications, with one setting for polymarkerfor a dynamic number of polymarkers."

And you can just imagine the differences in development and testing time between option 1 and option 10. Unfortunately project teams can't cook killer brownies or lemon merengue pie to make up for overblown budget or to soothe angry clients or end users. So, learn from Amelia Bedelia and make sure that the software specifications include as much detail as possible. And save the great brownies for celebrating a sucessful launch!