j e s r u s h . c o m

Most day-to-day project or operational decisions don’t require grand meetings and circumstance, but there are some situations where gatherings should be called to make decisions:

• Whenever group input is likely to significantly improve the quality of the decision.
• Whenever the problem is complex and requires multiple specialists.
• Whenever team members might have difficulty accepting a decision

So how does a project manager or leader facilitate these decision-making sessions? I’ll share my basic framework:

1. Identify the problem. Clearly state the fundamental problem and its context. The key thing here is to avoid framing the problem in terms of choices (predefined choices kill creativity). The WRONG way: “Should we abandon the mapping component entirely or substitute an alternative map module?” The RIGHT way: “The mapping component difficulties have put us ten days behind schedule. We need to determine the best way to move forward.”
2. Generate options. Begin by establishing a moratorium on criticism. All ideas–even the craziest ones–are wanted here. Make the point that all ideas belong to the group, nobody “owns” an idea, and everyone is free to twist and extend ideas suggested by someone else. Try to gather as many ideas as possible (quantity over quality) and be sure to prompt/include anyone who is naturally shy or not participating. Put all ideas up on a whiteboard as they come in.
3. Set evaluation criteria. The team needs some way to sort through the options. If you established an expectations management matrix with the sponsor (which prioritized scope, schedule, or budget) or if you defined a project vision (e.g. “Put a man on the moon by 1975″), then you have your basic criteria there. For example, an alternative which pushed you past 1975 would score poorly.



4. Facilitate a Decision. Provide summaries of progress and keep the group on track. Protect minority opinions and ensure that everyone has a say. Test consensus and re-state your understanding of what is being said (silence does not equal agreement!). Some conflict here is acceptable (even desirable), but if tempers flare or it becomes dysfunctional — then end the meeting and reschedule another one.
5. Follow Through. After the decision has been made, the group should later be called together for a miniature ‘lessons learned.’ Did the decision turn out to be the correct (or best) one? If not, what threw the group off? How can a better decision be made next time?

   The bottom line is that if you want good decisions, you must follow a good decision-making-process!

After using his super PMP study guide some time back, I picked up Andy Crowe’s other book, an obscure little text, ‘Alpha Project Managers,’ published in 2006.

This has to be one of the most under produced books I’ve ever seen.  Crowe essentially self-published on his own Velociteach label.  It shows.  The graphics are third rate and the cover is pretty bad. 

But no matter.  The information inside is fascinating. Crowe surveyed over 3,000 project managers and their co-workers/supervisors in order to identify the “top 2%” of project managers (”alpha project managers”). He tried to identify PMs who were consistently rated as excellent by the people they worked with and their customers. Once he found them, he zeroed in on their work habits and PM techniques.

Some of the interesting findings:

Cornelius Fitchner has put together another great episode over at the project management podcast, this one is an interview with quality expert Stacy Goff.  Goff has some great insights into how and why project quality suffers and what PMs can do about it.

My favorite nugget came when Fitchner asked Goff whether good processes are the key to good quality.  Goff asked Fitchner to imagine a project where the goal was to bake a great cake.  A fantastic cake recipie was located for the endeavor… it was clear, descriptive, straightforward and produced consistently excellent results.  In other words, the process was a very good one.  However when the cake was actually made, the cook had to use a cheap chocolate because it was the only thing locally available.  They had to use a hand mixer (poor aeration) since there was no counter-top unit in the kitchen.  They followed the process word for word, but the end result was of mediocore quality.

I love this example because it illustrates the need for holistic quality management: Even the best process fails when the inputs are off.

I recently slogged through an underrated little number called, ‘Advanced Project Portfolio Management and the PMO: Multiplying ROI at Warp Speed‘ by Kendall & Rollins.  Despite the fact that it reads (and sounds) like a whitepaper, it’s a good book which makes two points incredibly well:

1) Too many organizations try to save money on projects (cost efficiency) when the benefits of completing the project earlier far outweigh the potential cost savings.

You might, for example, be able to complete project X with perfect resource management (all staff are perfectly busy!) in 100 days for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.3 million, but the project would be completed in only 60 days.

What’s that 40 day difference worth? Well, if the project is strategic in nature, it could be worth everything. It could  mean being first to market with a new product or possessing a required capability for an upcoming bid which you don’t even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for a surprise audit. Sometimes the benefits outweigh the cost savings.

2) Project management exists only to better deliver benefits and capabilities. It doesn’t exist for its own sake, it’s not some kind of innately useful, primordial thing. If it isn’t helping deliver benefits and capabilities, then you can send the whole rattling project management caravan off the side of a tall cliff.

This is where so many organizations get themselves into trouble. They hire a bunch of project managers and demand they follow this or that methodology. But why? Is it because — well — this is what everybody else is doing? Or is it because this methodology will deliver 15% more projects with the same resources? Or this methodology will reduce project cycles by 20 days? Is anybody even measuring these things before/after implementing all these processes?

If you’re going to go down the project management road (and you should!), you need to understand why you’re doing it, and how you’re going to measure your success (hint: throughput!).

434 pp. Recommended.

Project managers are usually thought of as analytical types and as people who execute things.  In their analytical moments, they survey a field of options, risks, and opportunities, determining the optimum path through the landscape.  When they execute, they move mountains to get things done.

But there is a third archetype which ought to describe the project manager.  Project managers ought to be creative.  Not creative in the sense of managing their projects (e.g. finding a better way to crash a schedule), but rather creative in the sense of  strategic product and service innovation.  Let me explain.

In today’s cutthroat business world, organizations must constantly improve.  They are in  an endless cycle of cost cutting, value adding, and creating new products. No matter how well your business is doing now, it is just a matter of time until a competitor catches up and duplicates–or even improves on–your success.  Your profits shrink.  As Robert Reich has explained, at the end of the day there are essentially three strategies to stay in the game:

1) You can figure out how to cut your costs and offer your X for less than competitor’s Y.
2) You can figure out how to produce a much better X for the same cost.
3) You can use whatever expertise gained along the way to be first out with entirely new product Z.

What does this have to do with project managers?  Simply put: Everything.  Project managers are in the incredibly unique position of having one foot in their supplying organization, and one foot in the customer’s organization.  They can gather customer needs and match those up to the supplier’s offerings.  But more than that they can  identify unstated customer needs and find innovative solutions which haven’t even been built yet (but which the supplier has the capability to build).

The key of course is creative thinking and relentless focus on the three strategies.  When is the last time you asked yourself and your project team, “How can we cut costs?” “How can we add more value?”  “Is there an opportunity for a new product here?”

COMING SOON:  Part 2 — Tools for Creative Product Innovation

I finally got around to reading another one of Patrick Lencioni’s business “fables”:   The Five Dysfunctions of a Team.  This one involves an elaborate fictional scenario in which a new CEO rescues a splintering senior leadership team.  Presumably, the lessons are just as applicable down the org chart.  The format gives Five Dysfunctions two major advantages over like-minded ‘team building’ texts:  It makes it eminently readable (no dry theory here) and it makes it memorable.  No doubt readers will be able to recall the umm — confrontation — with Mikey for years to come.

After Lencioni has you hook, line, and sinker on the story, he spends the last portion of the book breaking down what happened according to the five dysfunctions, and explaining how to avoid and/or fix these pitfalls.

Dysfunction 1:  Absence of Trust

Dysfuntion 2:  Fear of Conflict

Dysfunction 3:  Lack of Commitment

Dysfunction 4:  Avoidance of Accountability

Dysfunction 5:  Inattention to Results

This is a winner.  Yes it occasionally steps into pop-business-psychology territory, but most of the time it is on point as a basic team building primer.  There is nothing groundbreaking here, but there never is with Lencioni.  He has built a nice little niche gathering assorted insights on some business subject and embedding them into something which is actually readable.  He succeeds once again here and you’ll learn a few tricks in the process.

Recommended.

My wife and I recently went to Italy and spent a lot of time studying the life and work of Michaelangelo. For a legendary genius, his day-to-day life was surprisingly tumultuous. If you thought he quietly tolled away on the world’s greatest art without interruption, you would be in for a big surprise. In fact, the process of decorating the Sistine Chapel was so crazy, that it immediately reminded me of wild and unruly software projects. Which in turn, got me thinking about some of the good (and bad) moves which Michaelangelo–chief engineer–made.

• Estimate? One year. When Pope Julius asked Michaelangelo to decorate the Sistine Chapel, the great genius estimated that it would take him no more than a year to complete the project. When all was finally said and done, four and a half years had transpired. And this was without any beta releases. What happened?
  
  It seems a perfect storm of factors converged to slow the project: There were political fights, there was miswork which had to be re-done, there were structural and weather problems in the chapel, and all variety of other complications. But the factor that struck me most strongly? Michaelangelo made the estimate himself at the beginning of the project before building his team of painter-assistants. At that time, he had not done frescoing in nearly twenty years (his focus had been on sculpture). In other words, he made a wild top-down estimate in an area outside his expertise without consulting the people who would actually be executing the work packages (his team). Sound familiar?

• Minimize your footprint. Renaissance artists had customers just like the rest of us, only they were called patrons. Patrons (be they the Pope or simply a rich businessman) would specify exactly what they wanted in the art which they were paying for… the number of figures… the scene, etc. Nonetheless, the artist would constantly make little, unplanned decisions about how the scene unfolds. Will that person in the crowd be a man or a woman? Young or old? Will they be smiling or frowning? What will they wear? Unfortunately many Renaissance artists (not Michaelangelo) were an egotistic bunch. They would do things like paint themselves side-by-side with the wise men in the nativity scene, or amidst the apostles in the resurrection scene. They look ridiculous, and one can only imagine what their patrons thought.
  
  When building software, you are constantly making the same kind of little, unplanned decisions about how the application will function. Should I display the customer name with their last name first? Should the input box be freetype or should I force selection from a drop-down list? These seemingly inconsequential decisions add up over time into a huge body of collective decisions that are often made with little customer consultation. This is the developer footprint. The bigger it is, the more likely something about it will irritate the customer. Where many renaissance artists had the audacity to paint themselves into scenes side-by-side with the apostles (a big footprint), Michaelangelo rarely painted himself and when he did it was in the most humble of places. In the Last Judgement, Michalangelo painted his face on the dead skin of a skinned martyr (Bartholomew). It was so subtle, that art historians didn’t even notice the portrait for hundreds of years!

• Start in the back. As mentioned earlier, Michaelangelo had not done frescoes for twenty years when he was commissioned to paint the Sistine chapel. With this in mind, he made a key decision: He started painting from the back of the sistine chapel first so that he could improve his technique by the time he got to the front. Indeed, there are obvious differences between the frescoes up front and those in the back. When one enters the chapel from the rear door–the eyes naturally see his best work in the front first.
  
  This reminds me of an agile development trap. With agile, the tendency is to build important, core functionality in the early iterations so that you’ve gotten something worthwhile accomplished if time or money unexpectedly runs out later. This is a wise tendency, however you usually don’t want to do the most important work in the first phase. Critical work should be done when the team is hitting stride, not when they are forming/storming. Michaelangelo nailed this.

[ Note: This is a continuation from Part 1 ]

• Use a braindump. A “braindump” is where you sit down and write key knowledge and formulas onto a sheet of scrap paper. You do this just before beginning an exam, so that the questions don’t twist your memory into a pretzel. A braindump is unbelievably critical on the PMP exam because the test writers love to rearrange simple formulas in complex ways. Remember back in algebra how you could rewrite the same equation ten different ways by moving X around, adding a value to both sides, using fractions, etc? The exam is a lot like that. So your braindump should include (at minimum) all those numerical formulas (earned value, etc) as well as anything that frequently trips you up. At the beginning of the exam, you are offered an optional 15 minute tutorial on the user interface. Take the tutorial (which only requires five minutes) and instead use the extra time to write your “braindump.”

• Do the little things. The exam no longer generates detailed score reports, instead it now shows only a very general area / competency report. But back when it showed actual scores, it was amazing to hear how many people passed the exam by the slimmest of margins. If they had gotten four or five additional questions wrong, they would have failed. Lesson: You need to nail the little things that can give you the slightest edge. Imagine if you failed the exam and wasted $400’s because you got two questions wrong? During the week leading up to the exam, make sure you:

Eat right. Three balanced meals (fruits! vegetables!) a day with an emphasis on brainfoods. Brainfoods are those foods which have been conclusively shown in (real) clinical studies to improve memory and recall. To summarize an ocean of research in one sentence, think protein (e.g. eggs) and omega-3 (e.g. tuna).

Exercise. Every day walk, run, bike, lift weights or do whatever you enjoy. Exercise improves blood flow and increases alertness.

Sleep. It’s really tempting to stay up late for extra study time. Don’t. That time is likely to be some of your least productive and you probably won’t have a chance to make up the slept debt before the exam.

Take off from work. Thinking you can skate by without using any of your vacation? Don’t. Again, imagine if you failed the exam because you were too hard headed to take two days off?

Drive ahead. If possible, visit the test center before test day so there aren’t any surprises. The last thing you need is to get lost, arrive late, or out of sorts.

Bring a snack. In your locker, you can store some caffeine, water, and something to eat just in case you get tired or hungry.

• DO buy the Project Management PrepCast. Remember back in part 1 when I talked about exposing yourself to the PMBOK through many different mediums instead of trying to straight up memorize it? One incredibly easy way to kick start that effort is with Cornelius Fitchner’s project management PrepCast. Basically Fitchner has broken down the PMBOK content into a series of nearly 100 twenty minute audio podcasts. The PrepCast isn’t detailed enough to work as one’s primary study guide, but it’s powerful when you follow up a topic from your (written) study guide by listening to the corresponding topic on the prepcast. It reinforces what you learned and it does so using another part of your brain (audible instead of reading/visual). This was a really effective one-two punch for me and I could study during my daily commute. At only fifty bucks it’s also a good value.

• Set a date. Last but not least, nothing quite motivates you to study as a date set in stone. My recommendation is that once you get approved to take the exam, go ahead and schedule it for 2-3 months out. If you near exam day and you still aren’t ready–you can always reschedule it for later. But most people will dig their heels into the dirt, rise to the occasion, and get it done. Good luck!

There are many facets to hiring technical folks, but one important area is the issue of how they stay on top of the new technologies which are coming out at a frightening pace. I used to ask a standard question: Give me an example from past work experience where you learned or discovered a new technology (new at the time) and used it for the organization’s benefit?

But after asking that question many times, I realized it was too narrow. People “accidentally” get exposed to new technologies all the time through friends, school, etc. Maybe they never sought out new technology and just “stumbled” on something. I needed to tease out the real proactive learners from these casual ones.

After some experimentation, I finally nailed it with an incredibly simple question which has been extremely effective over the past year: Technology is changing all the time. What periodicals do you actively read to stay on top of it?

A good technical person who stays on top of their field should be able to rattle off a number of periodicals or e-newsletters related to their expertise. For example a network engineer might mention Technet. A security expert might say Bugtraq or Mark Minasi’s newsletter. A more senior individual might even throw in some strategy, such as CIO Magazine. If their answer seems canned, you can pry further to validate it: Tell me about something you read in that periodical in the past three months?

But here is the best part: People who don’t stay atop their field absolutely punt this question. They’ve got nothing. One candidate told me that he reads the documentation which comes with the software used at his company. Another mentioned a four year old SQL book which she had read a year ago. Many others are surprisingly honest and simply tell you, “I don’t have time to read anything like that.”

This question is a deal-breaker for me. I count on my technical people for innovation, and their capacity for such is drastically reduced when they aren’t following the industry. This has quickly become one of my all time favorite interview questions.

PS–This reminds me of a great management practice: Assign technical periodicals to individuals on your staff, formally give them an hour or two every Friday to read them, and then have them present short “book reports” to the whole team on interesting findings. Most geeks love learning new stuff and get excited about new technology. This is an easy way to keep your team both happy and on the cutting edge.

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.

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…

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…