j e s r u s h . c o m

There is a brillant podcast over at Cornelius Fitchner’s aptly titled ‘Project Management Podcast’ about the challenges of working with virtual project teams (i.e. when team members are scattered all over the world). In addition to all the usual difficulties in managing a project team, virtual teams add an additional layer of communication complication and other relational problems. But this week’s guest–Adrienne Keane of Cisco–has some incredibly good advice for handling these issues. She has organized them into six success factors:

• Foster effective communications
• Focus on building relationships and trust
• Establish team identity & key processes
• Conduct effective virtual meetings
• Recognize & reward team members
• Enable collaboration & communication with technology

This is not pop-management nonsense, Keane has some really good ideas on implementing those factors.  Listen to the full podcast for all the details.

David Christiansen has a great post over at techdarkside entitled, “What IT Should Learn from GoDaddy.com“. In it, he argues that IT departments should offer pre-spec’d, preconfigured, “cafeteria style” offerings to their internal organization. A la:

• Standalone High-Speed-Production-Server: $16,000
• Standalone Medium-Speed-Production-Server: $11,000
• Virtual Medium-Speed-Development-Server: $6000
• Storage Space: $5000/TB

The idea is that your infrastructure team would go out and spec out these configurations for typical applications, add some overhead (say 15%) to cover cabinet space, UPS, etc., and then offer them to all departments for whatever applications they want to run.

Christiansen argues that departments will be more likely to use these configurations (rather than going through the trouble of spec’ing something custom) because they are readily available buffet style, like a cafeteria.

What I love about this approach is that it clearly places the onus for paying for the gear on the originating department (so the gear doesn’t somehow come out of IT’s budget!) and that it increases visibility into the inner costs and workings of the IT hairball. This is a great way to take your users to the next level in understanding their infrastructure needs.

Recently I sat for and passed the project management professional (PMP) exam on my first shot. Given that 40% of test takers fail, this was nothing to shake a stick at.

I got a lot of advice from people on how to pass the exam. Having been through the whole experience, I think some of that advice was actually flawed. There is a whole sea of people out there who are thinking about, studying for, or restudying for (after failing) the exam. So I wanted to share a few tips which worked well for me.

• Don’t memorize the ITTOs. Everyone kept telling me to memorize all of the ITTO’s (inputs, tools, techniques, and outputs). So about three months beforehand I dutifully starting making flashcards with the process on one side and all of the ITTOs on the other. About two weeks later, I decided this was ridiculous. Who can memorize 400 items? This was horrible advice–ignore it (and see next tip).

• Focus on EXPOSURE instead of memorization. The exam is multiple choice, so you don’t need to be able to completely reproduce the ITTOs on a blank sheet of paper from memory, you just need to be able recognize them by name and associate them with a process. The key to doing that is repeated exposure from multiple angles. Use multiple books, multiple techniques, and multiple mediums (audible, read the PMBOK glossary, play a match game, write them, type them, draw them, speak them). Basically just activate as many different parts of your brain in learning them as possible.

• Don’t buy Rita Mulcahy’s PMP Exam Prep Book. Everyone and their dog told me to buy this book. I did and it’s good. Huh? Then why would I say don’t buy it? Because it does everything well and nothing great. The layout is pretty good, the instruction is pretty good, and the practice questions are pretty good. If you work *really* hard, you can pass the exam with just this book! But why work harder than you have to when two other books are better? See the next two tips.

• DO Buy Andy Crowe’s How to Pass the PMP Exam on your First Try. This is probably the best organized study guide for any exam that I’ve ever read (SATs, GREs, MCSE, etc.). Within minutes of cracking the cover, your head is completely wrapped around the enormous task at hand. Crowe is the king of context, priority, and focus. Every section without fail asks the same questions over again: What is it? How important is this on the exam? When is it used? Reading this first saved me so much time which I would have wasted studying material of minimal importance. Unfortunately, the weakness of this book is that the teaching instruction is not especially good (for example the section on critical chain is a disaster), but Crowe is so darn good at putting the entire PMBOK into perspective, that I consider this indispensable for the exam.

• DO buy O’Reillys Head First PMP. This book is the polar opposite of Crowe’s book. The crazy format (”the latest in cognitive research!”) makes it seem utterly, completely unorganized. I constantly found myself wondering, where am I? What process is this? Am I dead? But its saving grace is the teaching instruction, which is insanely, magically, alarmingly good. These guys could teach a small child earned value. So if you pair this book with Crowe’s in a tag-team approach, then you get two books which do two things really, really well. Crowe gets your head around the exam and gives you laser-like focus on whats important. Head First teaches you everything you don’t know. Together, they’re better than Rita.

Continue to Lessons Learned Part 2…

A story: I was once a team member on a project to move an office from one location to another. Even though there wasn’t enough equipment and people to fill all of the available office space in the new location, the project manager insisted on taking advantage of management’s good will and the available resources to build out the unused space.

Several months after the move, employees began complaining about high noise levels. It was determined that the cubicles were too noisy because the ceiling was highly reflective, the cubicle walls were short, and the cubicles were too close together. All of the cubicles office wide—including all of the unused build out—had to be replaced with taller walls and moved farther apart. Fixing the unused build out added about 35% additional cost to the change.

This was a classic case of “overbuilding,” the tendency to buck rolling wave planning and build things now which aren’t needed until much later. You see this all the time in IT Infrastructure projects. A small business learns that a bigger competitor has a high-availability SAN. Because that little business might someday have hundreds or thousands of customers and because they want to “keep up” and look “big,” they spend big money on their own SAN.

Next thing you know, a tiny IT staff has to manage a super-complex system in which they are using 10% of the functionality. Three years later, when better, simpler, faster technology rolls out, they’re stuck with the existing system.

How do you avoid the overbuild mess? By taking the building-block-approach to infrastructure design. A topic for another post…

Cornelius Fitchner has an interesting story over at the always excellent project management podcast about his discovery of David Allen’s infamous book Getting Things Done: The Art of Stress-Free Productivity. Allen has basically turned a simple idea into a cult following. It works like this: Instead of filling your todo list with major tasks and projects, focus instead on defining the next step. So for example, instead of listing:

• Go to dentist.

You might break that down into “next steps”:

Go to Dentist

• NEXT STEP: Obtain access to my PPO website through HR.
• NEXT STEP: Use the online directory to lookup a local dentist.
• NEXT STEP: Book appointment and add to calendar.
• NEXT STEP: Alert boss: I’ll be out half-day

Does this sound trivial? It did to me the first time I heard it. But I kept hearing people talk about GTD, and ended up finally breaking down and trying it one day. Just as Cornelius described in his podcast, I was shocked by how effective it is. There is a strange psychological boost that comes from concretely defining your next step, it makes you more likely to actually do it.

And thanks to Backpack, the process of managing these steps (and my todo list) is infinitely easier. But that’s a story for another post…

In Steve McConnell’s classic, ‘Rapid Development,’ he talks about the benefits of versioned software development.

The basic idea is almost a kind of psychological trick: Instead of promising one version with five features, you promise five versions with one new additional feature in each. Either way, the customer expects they’ll end up with the same thing. But by doing this, you force the customer to ruthlessly prioritize the most important features into the early versions. Guess what happens next?

By the time you’re into version two or three, the customer realizes that what they planned for versions four and five is all wrong. They need something different. So plans can be adjusted and the new revised requirements can be met. Now imagine that we had originally built the entire application (all five features) in one version. At this point, the code for the original features four and five would have to be thrown out, and the new revised features would have to be built.

The benefits of versioned development are obvious. But after watching this process unfold a couple of times now, I’ll go a step further: Not only does versioned development bring the utility of rolling wave planning to bear on software and reduce wasted effort, it reduces work entirely. What do I mean? I mean that I’ve seen customers end the project early because they realized that the functionality in version one, two, or three meets their needs entirely. They certainly don’t need the features originally planned for versions four and five, but nor do they need a different set of features.

And as everyone knows, project size has a linear relationship to risk. If you can reduce the size of your project with the psychology of versioned development, then you can reduce your project risk. Your project is more likely to be successful. Beautiful…