j e s r u s h . c o m

What follows are some of my thoughts on IT Project Management from my experiences working on software development, IT infrastructure, and system implementation projects…

The other day I witnessed a major misstep when a vendor serving my own employer recommended a solution to us which was incompatible with one of our key business constraints.  Fortunately we caught the problem, and the proposal was scraped.

But not everyone is so lucky.  Insane sums are spent on rework for systems which were built with bad or missing information.  As someone who builds and implements these systems myself, I can’t say that there is a foolproof method for uncovering every constraint, assumption, requirement, and interface which might affect the solution I propose.

But I can say that there is a process of due diligence which must be systematically followed to try and fully understand the target business.  I decided to sketch a brief list of things which the project manager, business analyst, and technical lead should look at when building and implementing a solution:

•  Corporate objectives.  The suits might be leery of sharing the three or five year plan with a vendor team, but the more information you can get about the organization’s strengths, weaknesses, opportunities and threats — the better!  Is the organization growing, innovating, changing, and/or trying to cut costs?  If so, how are they accomplishing these things?
• Competitors.  Who competes with this organization?  What does market share look like and how have these competitors designed their systems?  How can they be outdone?
• The Industry.  Checkout the trade journals, attend a conference, and join any industry organizations.  You need to become a kind of insider who can help lead the customer to a solution which they never even considered.
• Org Charts 2.0.  You need to take the plain old org chart and dress it up with some key details for each department or entity: mission, function, and current initiatives.
• Infrastructure Charts.  How do the existing systems communicate with each other?
• Location Models.  Geographically, where does everything sit?  And what laws, cultures, and locale-specific variables change from one location to the next?
• Business Events.  What events drive the business? Do they come from customers, partners, suppliers, regulators?  Who springs into action when these things occur? Do they occur on a regular schedule?
• Process Models.  Workflows and interactions.

While so many customers (and providers) want to dive directly into the requirements gathering phase, there are huge benefits to first researching these domains.  It can mean the difference between a well conceived proposal and an expensive disaster. But more than that, it can lay the foundation for a customer-provider relationship which goes beyond this project.

Imagine if you (as a provider) noticed a trend in your customer’s industry which led you to design a solution for a problem which your customer didn’t even realize they had!

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 Lessons Learned (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.

Sramana Mitra recently wrote one of the most ridiculous articles I’ve read in a long time over in Forbes magazine. In it, she claims that India’s outsourced IT Services industry faces a “coming death” as Indian wages rise and IT service firms in areas like Eastern Europe or “Oklahoma” become more appealing. Huh?

Meanwhile, back on planet earth, Indian technology firms are finally expanding beyond software development and taking aim at US-based infrastructure management services with the promise of lower-cost, remote administration. When you consider that 70-75% of infrastructure management can be done remotely (CIO Magazine, March 2008), this market is a potential goldmine for Indian firms.

Over the next five years, these Indian companies will turn infrastructure management into a kind of commodity. Just as an organization pays their electric bill every month, they will dutifully dispatch a check to India to keep their network running.

And these services will not be moving to Eastern Europe, which has neither the people, capital, nor experience to compete with India on any meaningful level at this point. All that outsourced software experience gives India an insurmountable head start.

This is bad news for US based infrastructure management firms and system/network administrators, but good news for IT Project Managers who will be tapped to manage these transitions and their inherit risks. Expect security and disaster recovery issues to be at the forefront.

I was on construx’s website the other day (Construx does software development best practices, construx’s website the other day (Construx does software development best practices, seminars, consulting, etc.) and stumbled on a real nugget: Their career progression ladder for software project managers. For the life of me, I can’t re-find the page (perhaps it was pulled?), but fortunately I had saved the info to google notebook.

The ladder describes three “levels” of career progression and each level has three components: experiences (such as estimating a project), reading material, and training (mostly Construx seminars–which sound really good).

Given how much I love reading, it was (surprise!) the reading lists which really interested me:

Level 10

• Code Complete, Steve McConnell
• Rapid Development, Steve McConnell
• Software Project Survival Guide, Steve McConnell
• UML Distilled, Martin Fowler et all
• Mastering the Requirements Process, Robertson and Robertson
• Software Requirements, Karl Wiegers
• “Manager’s Handbook for Software Development”, NASA Goddard Space Flight Center

Level 11

• Principles of Software Engineering Management, Tom Gilb
• Mythical Man-Month, Fred Brooks
• Peopleware, Tom DeMarco and Tim Lister
• Measures for Excellence, Lawrence Putnam and Ware Myers
• The Art of Software Testing, Glenford Myers
• “Software Measurement Guidebook”, NASA Goddard Space Flight Center

Level 12

• Programming Pearls 2nd Ed, Jon Bentley
• Applying UML & Patterns 2nd Ed, Craig Larman
• Conceptual Blockbusting, James Adams
• Software Creativity, Robert Class
• Quality is Free, Philip Crosby
• The Deming Management Model, Mary Walton
• Managing the Software Process, Watts Humphrey
• Writing Effective Use Cases, Cockburn
• Exploring Requirements: Quality before Design, Gause and Weinberg
• Requirements Engineering, A Good Practice Guide, Sommerville and Sawyer

This is a killer list. The only thing missing is more coverage of risk management (!). But that omission aside, I’ve tackled about half of these and can attest to their value. Good stuff!

It’s been said that 70-90% of project management is communication. So I was very interested when Patty Azzarello turned me on to a little book about communicating ideas called, ‘Made to Stick,’ by Chip and Dan Heath. The interest was justified.

This is one of the five best business books I’ve ever read. The Heath brothers take you on a wild romp through urban legends, advertising, and the mind’s jungle to tease out why some ideas “stick” with you and others don’t. Why is it that we remember the bathtub-ice-kidney-heist after hearing it one time, but can’t name the auto manufacturer in that TV commercial we’ve seen four times?

Because, Chip and Dan argue, the kidney heist is simple, unexpected, concrete, and emotional… They spend about 200 pages exploring these and other aspects of “sticky” messages while tying in some some remarkable research from academia.

Most importantly, they step you through the process of making your own messages more sticky. If this sounds like a marketing book, don’t be fooled: You will quickly find yourself applying this concepts to all kinds of communications… with your team… with your superiors… with everyone.

I was stunned by how dramatically ‘Made to Stick‘ “stuck” with me and actually improved by ability to communicate. Insanely recommended.

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…