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!

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.

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.

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!

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!

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.

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!

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.

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.

Robert, a master jeweler for years holds out his hand and takes the ring, necklace, and earrings. He sighs. He can tell by the weight it’s only gold-plated.  A closer inspection of the small diamond studs in the earrings reveals them to be a very clever fake as well. Sorry sweetheart, your man wasn’t just a cheater, he was a cheap one at that!

PMBoK defines gold plating as providing more features than were originally included in the project’s scope. An example of this is a custom home builder throwing in faux-granite countertops instead of just laminate. Is it a nice little perk? Sure, but you had better believe that home owner is going to hem and haw and bemoan any attempts at getting him to pay for that upgrade. “Where was it in the contract?!” Mr. Ficticious Customer asks the builder, “I’m not paying an extra $2,000 for better counters! If I was going to do that, I’d have put in real granite instead!”

The same applies to pretty much any project. It’s important to keep a tight rein on developers, programmers, and engineers because they are easily excited by the prospect of being innovative and clever. Unfortunately for us managers, our budgets typically don’t even cover the minimum requirements to get the job done.

“It sucks, sure, but that’s why R&D takes place in a separate department,” you remind them. After all, it might only look like a small addition, but that extra time, effort, and budget is best left for quality assurance of the actual deliverables.

If you still feel really strongly about anything that might be considered Gold Plating, submit a PCR and get it approved by the integrated change control board first. Why? Because just like any skilled pimp, your project manager is going to negotiate for more money up front before letting you turn tricks, no matter how much it delights your customer. Sad but true.

“Dude, I just need to make sure that this is gonna be a bangin’ document!”

He was of course referring to the project plan I had been hired to write.

“Nice qualitative criteria you’ve got there.” I knew he was referring to how the thing looked more than how it read, or what went into it.

People love pretty things. That’s why movie celebrities and fashion models get paid so much just to stand around and strike a pose. It’s also why there are such a ridiculous number of Microsoft Project licenses sitting on computers across the US, without nearly enough qualified people to run it. It makes anything you shove into its input tables look pretty darn official. And as they say, “Garbage In, Gospel Out!”

And NO, I am NOT talking about garbage-in/garbage-out. You take one look at that stuff and you know it’s junk. I’m talking about something that looks so good that unless you knew better, you’d never realizes just how seriously Effed up it was.

Ever see a gantt chart with negative float? Oh yes, it’s possible to make a computerized gantt do anything you want without addressing important issues such as fast-tracking, crashing, or resource-leveling. Unless you know project management, chances are you don’t know enough to ask why it looks the way it does, or what the meaning behind the bars are.

So yes, I can give you a bangin’ document. Hell, your secretary could probably even make a prettier document than me, complete with clip art, stock photos, and typography that would make the most die-hard calligrapher pale with envy. But I guarantee she won’t have a clue how to get 5,000 hours of development work split up between five resources and scheduled.

Mostly because if she can, then you’re really screwing her on that hourly rate.

“A $160,000 business education.” Yeah, okay, so I exaggerated a little bit: between merit scholarships and community college classes it was probably only about $50k. Be that as it may…

There’s a classic example for this: complimenting the chef on his utensils when he prepares an exquisite meal. It’s rude, it’s arrogant, and it’s completely dismissive of the knowledge and experience that person brings to the job of preparing a great dish. The same goes for just about any knowledge worker—with an exception being made for the graphic artist who uses Photoshop. They don’t really know anything, they just push buttons on a screen. (Okay, so even I slip up sometimes.)

Everyone probably makes the mistake every now and again of complimenting software and machines in place of the people actually driving them. So, in the spirit of motivation and leadership, I suggest we each make an extra effort to recognize the value added by the people we work with, and not just their tools.

One of the earliest experiments of management science found that the optimum coal shovel held approximately 21.5 pounds. However: that same shovel, and all of the countless hours of research, trial and error that went into designing it, is completely  useless without the worker on the other end of it.

Food for thought. Bon appétit!

Seriously though, I guarantee there will be a time when you are given a complete crap task to do. I mean, so completely pointless and below you that you even feel guilty offloading it on your VA!

Perfect example: a past project I was on required insane amounts of detail on a team timesheet, both for outside consultants and regular employees of the company. First it required two people in the PMO 8 hours collectively to generate individual timesheets for each team member (based on their assigned tasks for that week from the project plan) and email them out. Then It took every one of the project’s 100-something team members about a half-hour each week recording their time to each individual task. Then it took three people in the PMO 24 hours of collective time to enter it all into the system.

All told: 82 hours a week (the equivalent of two full-time resources) spent tracking and recording time. What was this highly detailed level of information for you ask? Re-adjusting the project timeline? Advanced scheduling? Nope! Cost allocation for accounting of the project as a capitalized asset, and it took 3,926 hours a year just for the data entry.

Alright, so this little tale of woe isn’t completely without hope. With enough whining, complaining, and cajoling on the part of the entire staff after yet-another milestone delay, they eventually suspended timesheets for company employees (who already filled out a regular corporate timesheet), and instead only required it of the 30 consultants. And they compromised further, allowing time to be reported to large activity buckets instead of individual tasks.

So, here’s my advice to you: when you run into a crap task, the best way to fight it is to take really detailed records of just how crappy it is. Not just for you, but for everyone in your entire organization. Nobody wants to throw money down the drain, so when the gloves come down and people are ready to duke the whole thing out, you want to make sure your argument has enough UMPH! for a one-hit K.O.!

And that’s how we rock!