Controversial thought of the day: when is it okay to verbally reprimand someone for bad behavior on the job? For some of us, never, we’re all individual contributors and have no real say on the actions of others (except maybe to vocalize “It hurts me when you…“)

For people managers though, there’s eventually a time when someone needs to be called out on their poor performance. If it’s affecting the project, if deliverables are being delayed, if the client is authentically upset; something needs to be said about the <cliché> in the room. So, here’s my advice to keep in mind when choosing how you handle the situation: stomp the toads, but don’t kick the puppies.

The Toad:

The Toad

Experienced, mature enough to know better, and most likely rotten to the core. I’m not talking about ones that are unionized (King Koopa United 100), or that are so close to retirement that they don’t give a damn anymore, because both of these are untouchable for one reason or another (more on that below). They could be narcissistic, mean-spirited, the office jerk who just creeps along waiting to knock someone down a hole. These are the ones you can freely call out when you see them do it. Be tactful but direct, and specify exactly what they did wrong and how it hurt the people in hearing vicinity.

There’s a time and a place where you establish what is unacceptable behavior for everyone on the team. This idea goes back to the quality-of-life crimes talked about in Malcolm Gladwell’s The Tipping Point, where turnstile jumping and graffiti trended into more violent crimes. Same idea. When one person in a group cheats, others cheat because they feel entitled, not that they are necessarily morally predisposed.

The Puppy:

The Puppy

Young, inexperienced, new on the job (or maybe the project), and in its innocence chewed the furniture and peed on the rug. Annoying, but nothing you should get too worked up over. Mainly because you will do more damage to the morale of the entire project than you help by calling this type of person out. These need to be dealt with quietly, in private, and explained to how their behavior is falling short, and advise them on what they can do to improve.

The puppy never meant to hurt anyone, it just doesn’t know any better. A quick chat is usually all it takes to get what you need from this contributor. Because they’re so new, others likely won’t try to emulate their behavior and just chalk it up to inexperience.

The Untouchables:

The Untouchable

Don’t even try it. They have extenuating circumstances that make you have to call in the big guns in order to fix the situation. These include management senior to you, individuals over 40 years old, and unionized workers who you do not manage directly (functional or weak matrix organizational structure). Even if they do report to you directly, union rules typically call for written warnings, and you could still get slapped with a grievance.

If you have an individual like this on your project that’s causing delays, not meeting deadlines, failing to deliver on promises kept, it’s best to shift key tasks away from them to other members of the project and work with your peers to find a way to replace them if possible.

Personally, I find short, impromptu chats with everyone to be the best method of dealing with people issues. It allows them to save face, and gives you an opportunity to find out about deeper issues that might be driving the problem. So again, the above methods aren’t meant to be used when something like that exists; that’s only when you have someone who is intentionally not pulling their own weight to the detriment of others.

Best wishes!

We care deeply about our buckets!

A friend of mine who works as doing software QA told me once that if he charges to the wrong time code he typically has four or more people yell at him. For Developers, I understand just how annoying it is to remember the many different bill codes that we stick on your timesheets. And yes, it’s frustrating to have to spend 20-30 minutes a week recording what you did for who’s project and when.

The flip side of that coin is that we PMs have very, very limited budgets. We’re typically asked to build a 40 story building with only enough funds to cover the first 12 floors. So it shouldn’t come as any surprise that we become quite incensed when someone violates the sanctity of our time buckets at the benefit of someone else.

So look on the bright side: at least our tusks aren’t as sharp as the real walrus’s.

I’m learning yoga. So far, it’s helped to make me more flexible, both mentally and physically. (I can bend in ways I never thought possible, and after going through a workout I no longer have the desire to yell…much.) By in large, that’s considered a “good thing” in business these days. Flexibility, resilience, the ability to bounce back, bending without breaking, are all terrific Post-Millennium-Depression business themes. We survived (some of us), and managed to weather another storm….hurray!

So with this in mind, more and more companies are starting to forgo the regimented, rigid Traditional project management process. It’s documentation heavy and focuses on distinct phases with required deliverables for each.

Agile, like the name implies, is a more nimble method for accomplishing projects. It focuses on producing actual work, with management acting as facilitators for removing obstacles.

Scrum, again a very descriptive name, is a very down and dirty way of following Agile development, with chickens, pigs, and the shortest meetings you’ve ever seen in corporate America.
I’m bringing it up because PM Network (PMI’s magazine for members) had two really terrific articles about getting large companies on board with Agile:

“Philisophical Makeover: Not everyone thinks change is good—which makes assembling an agile dream team that much more difficult.” Sandra Guy, pg. 38-43, May 2010 PM Network

“A closer look: Atlassian, Sydney, Australia: An agile software development team puts its money where its mouth is.” By Carol Hildebrand, pg. 44-47 May 2010 PM Network

The first article describes how it’s best to use Agile on projects where requirements aren’t set, or customers don’t know exactly what they want. It also cautions that because of the very open nature of progress and problems that occur, it’s very difficult to do in highly-political organizations.. The second describes a case of Agile done well, with a team that normally works virtually, who co-located for a week to kickoff their project initiative. Working in the same room from beanbags and laptops, they ground through a mountain of work without the typical distractions associated with working through an electronic medium. (Hello CNN.com, how are you today? *Click*)

I work 100% remotely with teams spread over the globe. I’ve also worked on large SAP implementation projects, where everyone converges on-site for four days a week. I can personally vouch for the benefits of being able to chase someone down for an answer in the physical world, vs. phone calls, emails, and IMs (Pings in corporate-speak.) It really depends on the type of work you’re doing though. For a functional analyst or project manager that has to interface with many different people at any given moment, it’s frustrating to work virtually/remotely. For an independent contributor, such as a developer going off of functional specs or engineering notes, it’s probably bliss to have all those methods of screening people out.
So, what do you absolutely have to know about Agile? It’s completely acceptable to use over traditional project management when one of three criteria is met:

1. The project is less than $250,000.
2. The scope is limited not initially clear.
3. The timeline is less than 1 year.

Any other type of project is too long, has too many moving parts, and too many people to keep happy. Can you use portions of Agile on a long-term project? Sure! But don’t skip important things like kill-gates, earned value analysis, risk mitigation and stakeholder analysis.

I’m a big analogy person, so let’s put it this way: At a large company, on a large project, being a project manager is a bit of a mix between an old-fashioned telephone operator and a rail-yard dispatcher. You make a lot of connections between people who need to talk, and at the same time are trying to move thousands of tons of big clunking objects around a constrained space hoping and praying they don’t collide. An Agile project manager is more like being the driver of a steam roller and keeper of the tin man’s oil-can. You respond to all the squeaks for help, and try to smooth out all the bumps in the road so people can focus on work. They’re both important jobs, but done in massively different ways.

I’ve mentioned my distaste for wireframing in previous posts. It’s not that I can’t do it, it just takes me a while and makes me second-guess every placement I make because I know I lack expertise in User-Interface Design (something that’s currently on my list of self-improvement items.)

So, what difference Balsamiq Mockup do diffferent? Quite a lot actually. It’s counter-intuitive, but using the right tool for the task can sometimes make a world of difference. (Remember my warning: garbage-in / gospel-out still applies, even with low-fidelity wireframes!) Balsamiq is as smart as it comes for making a “dumb document” (which is essentially what a wireframe is!) The idea is you create a shell, devoid of color and graphics that just illustrates what the shape and feel should be. A good deliverable for development methodologies that call for rapid prototyping, and making quick changes early on.

Here’s the example they give of the ficticious “MyTunez”:

How long does it take to put something like that together using BM? About two-shakes of a lambs tail! (Which is greek-geek speak for not long at all.)

BM has features which automatically highlight rows and columns in the pre-made list-shapes you import into your design. Showing or hiding a scrollbar is as easy as checking a box. In a word: awesome.

For $79, you’ll make your investment back in about 1 wireframe. And if you’re like me and don’t know a ton of UI design, don’t fret: you can change it around simply and easily as you learn more.

So for all you non-developers out there who are struggling to communicate, and find it difficult to express yourself visually, go try the free web version. You’ll see exactly why I’m so enthusiastic about this product.

(And, as always, there’s no conflict of interest here: I never put a referral link in a review I write. Anything that benefits me monetarily is marked with the words “Sponsor”, “Ad”, or something similar.)

Good luck! Enjoy!

One of the biggest issues with Basecamp (the simple-to-use, web-based project-management solution sold by 37Signals) is that it doesn’t do Gantt charts. This means resource leveling, scheduling, baselining are all next to impossible. You set due-dates for to-do items and milestones, and sort of hope for the best. So when I saw Tom’s Planner, I had high hopes for something that would allow me to quickly replicate the Poor-Man’s-Gantt I typically make in Excel, but be more informative, visually appealing, and easily sorted. I wasn’t disappointed.

I threw this quick example together in minutes. To quick really, because I missed half the features and began to write up a post about this tool’s shortcomings instead of how well it meets my needs. Is there GI-GO risk using it? Sure, but if it saves me 80% of the tiime I used to spend making timelines then it might just be worthwhile.

It’s easy to select which days of the week to work with (i.e. your business is closed Sunday/Monday as opposed to Saturday/Sunday like some retail stores, or you have a compressed 4-day workweek). That alone makes it work trying in my book. (Not to mention you can share it with your entire organization quickly and easily, helping everyone understand what their priority for any given day on the project.)

For quick concepts, this is a great visualization tool loaded with user-friendly features. I think they’ll be able to deliver a lot of value to organizations that didn’t have the time or application prowess to actually sit down and create an advanced schedule before.

Enjoy!

From time to time, you might find yourself a little bit overwhelmed in your work. Instead of delegating some of that extra work out, most of us tend to try and use every trick in the book to get the job done ourselves, such as the one featured in the short, six-second video below.

That’s why it’s important to remember that a little resource leveling never hurts on a project. Simply asking team members, either during a status meeting or one on one, how they are doing and if they need help can do a world of good midway through the project when things have hit their stride and a routine is starting to form.  The tricky part is when you’re working with independent contractors who are afraid to speak up about their true (lack of) availability, for fear they might lose billable work. Unfortunately, I don’t have a great answer for this. Emphasizing quality of work performed over quantity in terms of contractor compensation is one method, but that only goes so far.

In the end, it’s a matter of being open and honest, and asking for the same in return.

As for myself? I’m vowing to give up my caffeinated body wash and lip balm for a month. Perhaps some soothing green tea will steady the nerves and give me a new, healthy outlook on life. At least until the shakes set in.

If you’re like me with a variety of small projects that you manage simultaneously, you’re not so much a project manager as a portfolio manager. Although I love Basecamp for executing project tasks and communicating with team members, its dashboard just plain sucks for viewing the status of multiple projects at a glance.

Worried I’d have to try and coax one of my programming friends to create one for me, I did a quick search and stumbled on BCViewer.com. Its an excel based project portfolio overview, which reminds me a little bit of the Poor Man’s Gantt technique I learned back in college. It’s simple in that it lists all project milestones based on their due dates, with different colors to display their status.

Try it out, see if you like it. If it’s really successful for you, be sure to drop a note to Paul Irvine, founder and president of pCapacity LLC who developed this handy little tool.

Thanks Paul!

N9T9ZAK2EJDK

I’ve been asked a couple times now to do Wireframing. I know it’s an incredibly valuable skill, and that people who can do it well are 10x more valuable for web development projects than those that can’t. Unfortunately however, I tend to not be so hot at it. I don’t have the years of study in User Interface Design that’s really crucial to the task. Don’t get me wrong: I’m committed to life-long learning. But in the interim however, I’m definitely not the right person for the job.

Reason this comes to mind is during a pinch on a project recently I had to step in and do it. What it made me realize is just how important it is to use the right people for the right jobs and the right tools for the right tasks. A simulation we ran back in college factored this in well: if you tried to stick the electrical engineer in the computer programmer’s job, he’d get the stuff done, but only at 60-percent effectiveness. Same thing for me and wireframing: from a seasoned hand, it’ll be done in half the time with twice the quality. Experience, learning curves, personal skill level all factors in.

So, I’m definitely not complaining. I love the opportunity to learn. But it’s critical to keep in mind the selections we make when assigning tasks on a project. With the right person, things run smoothly, on time, under budget. It’s when we goof that things go awry. And we can’t always rely on the person, who wants to learn, who needs experience, to step up and suggest they aren’t the best person for the job.

Then there’s that trade off that any long-term project manager has to make: mentoring and knowledge transfer vs. timelines and budgets. I’m starting to really appreciate the judgment calls people above me had to make.

We’ve all let loose that exasperated cry at one point or another. Angry to the point of speaking in tongues, and tearing our hear out in large clumps as we hop up and down, frumiating worse than a hot and bothered bandersnatch at a bikini modeling contest. We feel outraged, incensed, and a whole bunch of other words that describe how violated and hurt we are.

There are two key instances where freelancers and experts get in trouble with the people managing them.

1. They were not given clear directions up-front, and had to improvise a way which got them in hot water.
2. They were given explicit, detailed instructions of exactly how a task should be done, and thought they knew a better way to do it, and then did it their way.

One of these will get you an apology and a long heart-to-heart with your manager. The other will give you front-row tickets to watch an already stressed out guy (or girl) have a coronary.

So, keep this in mind, dear expert: if a manager gives you incredibly detailed, but flawed instructions, ask them why. Confront them, and hold them to the task of explaining it to you. I myself don’t always explain every detail of my reasoning, but if asked I have no problem telling you exactly why I told you to do it a certain way.

It could be a client request. It could be past experience on my part that’s guiding me. It could even be the experience of another expert who’s in my personal network, who I asked for guidance, and they gave me those nice directions which you just screwed up in your infinite wisdom. (You never know who your PM knows. That’s rule 1 of project work. Rule 2 is to find out ASAP.)

So, as a final plea to all you highly capable knowledge workers: if you think you’ve been told how to do finish a task in an overly silly way, please just ask for more details before running amok, stepping on toes, and sending your manager reaching for their blood pressure med’s. They’ll thank you.