New Blog Site

Last April I announced that I was moving this blog over to Typepad. I did that, but various technical issues precluded me from taking that site live, and then I got overly busy with work and family so I put it on the back-burner.

What I decided to do is to maintain only one blog on my viewpoints on project management and IT, so you can find the latest and greatest here:

http://enterprisearchitect.typepad.com

I'll keep this blog up on the net indefinitely for reference and posterity, but all of my writings from here forward will go to Typepad.

Thanks and hope to see you!

MOVING OVER TO TYPEPAD SOON

I'm in the process of moving my PM blog over to Typepad from here, as I did with my enterprise architecture blog last month. More details to follow!

A Key Question To Ask Project Sponsors & Major Business Stakeholders

Regular readers of my blog know that I teach project management courses at the University of Wisconsin-Milwaukee. I kind of fell into lecturing as a sideline some years back and enjoy it very much because not only do I enjoy teaching "real world" topics to adult professionals, I learn as much from them as I give, even in introductory courses such as the one I completed yesterday.

Here's an example of an 'a-ha' moment I had with my students at the beginning of the course Monday morning. For the first hour or so, we talk about and define projects, project managers, and project management in the context of going forward with the methodology that we teach in the program. I also spend a fair amount of time explaining the relationship between project managers and various project constituancies such as project sponsors and major stakeholders.

After this we have an exercise where the students (in groups) take 20 minutes and brainstorm what they as PMs must have from sponsors & stakeholders, and what would be nice to have, but not critical to project success. Each group puts their findings on an easel and I debrief each group to conclude the exercise.

A group of three very intelligent students came up with a question to ask sponsors and stakeholders as a 'must-have' that, while I've heard it before in other contexts, never equated with requirements gathering/analysis and project planning:

"Please tell me what 'done' looks like to you with respect to this project."

What an awesomely succinct and powerful question! It gets right to the heart of the matters at hand in this project phase and the answer(s) you get are critical with respect to what you do and say next.

Scenario 1 is a focused, bullet-like list of objectives with little ambiguity. This is the best possible answer you'll ever receive from sponsors because you can proceed right into developing the project plan with clear-cut objectives. Unfortunately, this scenario is very rare in practice.

Scenario 2 is a list of objectives with a fair amount of unknowns and ambiguity. You have more work to do with these folks fleshing out enough for you to work with in starting the planning.

Scenario 3 is a very broad, currently unfocused vision of an outcome that needs much more work to go from half-baked to something you can work with. Much more thought and work is required to get the vision into a state that leads to the project planning process, and you help and support the sponsor getting to that point.

Always ask this question of your sponsors and major stakeholders up front, and never in a condecending or abrupt manner, but more one of support and empathy if elements of the project aren't completely formed yet. A powerful question asked like this up-front and the answers you receive will spare you, the project, and your organiation much time, angst, and money in the long run.

HOUSEKEEPING AND OTHER ITEMS OF INTEREST

I will update this entry as needed for items of general interest and information. Last updated March 15, 2006.

See The Man...:)

My upcoming schedule of public appearances:

May 4-5, 2006: Project Management Foundations course at the University of Wisconsin-Milwaukee. 2-day PM fundementals course with yours truly. More information and registration here.

May 8-9,2006: Multiple Project Management course at the University of Wisconsin-Milwaukee. 2 days of advanced training in managing multiple projects, including prioritization schemes, software, and metrics tracing and reporting. More information and registration here.

Enterprise Architecture Blog

In addition to project management, I as an enterprise, system, and data architect to government and the Fortune 1000. About 1/2 of my practice is EA, and the rest is PM. I started an enterprise architecture blog and you can access it here.

Copyright and Use of Materials

All material posted on this site is Copyright (c) 2006 by Robert J. McIlree. All Rights Reserved Worldwide. Permission to quote or use this material in any form or medium is automatically granted provided that proper attribution is made in the quoting material. Also, if you quote or use my commentary in other materials, I would appreciate knowing about it and/or a copy or access to the material. An email sent to robert.mcilree@rjmtech.com is sufficient, and thanks!

Problem Children and What to Do About It

A fellow project manager came to me recently with a dilemma I've seen a few times before: his superstar software developer has an attitude and ego to match his prodigious skills. As such, this individual is causing chaos on this PM's project team with the behaviors listed below:

• Routinely dismisses and belittles ideas advanced by other team members, particularly in meetings. More than a few of these episodes degenerated into personal attacks on other project team members.
  
• Has productivity swings that range from super-human delivery of working software to days on end with nothing substantial delivered.
• Feels that formal development and project processes and standards do not generally apply to him, as it interferes with his 'creativity' and 'sense of urgency' in delivering his project work.
  

The project manager who informed me of this dillemma unfortunately rationalized keeping this individual on the team because he is a superb developer and the PM 'cannot afford' to lose an individual with such talents.

I told him that this person is severely dysfunctional regardless of his contributions or the potential for them, and that he had, as I saw it, three possible avenues of resolution:

1. Confront the individual, with line management, about the behaviors and inform him that they will cease immediately, 'or else...'.
2. Move the individual's work out of the project task mainstream and give him assignments that he can work on as an individual contributor. This leaves the remainder of the team to execute the majority of the project tasks.
3. Remove the individual from the project completely, and perhaps terminate his employment (although that's not in this particular PM's scope to do so).

Team members like this, regardless of their brilliance and accomplishments, hurt your project team (and thus your projects) more severely that most PMs realize. Why? Because the disruption and angst that they routinely cause brings down the morale and productivity of the rest of your team. The magnitude of the disruptor's contributions is usually not enough to counteract the lack of productivity of the other team members, even though they are less talented, experienced, or gifted.

This is a situation that most project managers can never afford to maintain, even short-term. What usually happens in cases where the behaviors are tolerated is that the affected projects' executions and outcomes swing back-and-forth between great execution and unmitigated failure - usually failure to deliver or very late as opposed to project plans. Not to mention the very toxic work environment situations of this type routinely create.

You cannot afford to have this happen to you, and if it does, you must take action immediately. Don't wait until it festers and infects the rest of your team, just don't tolerate unprofessional behavior at any time and don't be afraid to remove or re-assign (or get rid of) people like this. What you're potentially losing will retrospectively look trivial compared to the low morale (and possible mutiny) of the rest of your team members.


Project Management

The Interaction Between IT Architects and Project Managers

I also maintain a blog on enterprise architecture and IT topics, and a debate within the architect blogosphere has ensused about the tension and interactions between architects and project managers. I posted my initial commentary on that topic and you can view it here.

How 'Percent-Complete' Is That Task Again?

Students in my project management classes get treated to a mini-rant about the percent-complete method of measuring when a task or set of them are completed or not. So I thought I'd share it with the blogosphere. Simply put, this is a poor technique to measure task completion, and always has been.

Why? For starters, its too ambiguous. How many times have you sat in project status meetings and heard claims that some front-burner, critical task is '90% complete' and stays there for months? Or that the last 10% of some task takes much longer to complete than was originally scheduled? Happens all the time, and I plead guilty in my software developer past to doing the same thing.

This technique suffers from a number of problems beyond ambiguity: the 'system' it creates is easily gamed by project staff; the neophytes on your team usually don't have the experience and judgement to make reliable estimates in this fashion; and if you're using earned value analysis or other PMO-style metrics to track project progress, you can't come up with metrics that have much value or believability.

The ambigutiy is maddening at times. Can you put 80% of a software application into go-live production? Does 95% of a new product development have any immediate economic value to the business? Of course not, so why are we using this measurement?

Here's another way to look at this issue: tasks fall into two categories, with no gray area between them - they are complete, or they are not. No middle ground. No percentages. No promises that the remaining 6% will be completed by next Wednesday. This technique scares the hell out of people because it is a binary measurement of truth-in-project-status, and such accountability may be too harsh in the politics of a lot of organizations.

But the technique is very, very effective. If you decide not to use this in your daily/weekly project management scheme with your teams, I strongly suggest that you do it anyway for your own enlightenment on where things really stand with your projects.

Some caveats on using this technique are in order. First, the tasks need to be broken down into time-manageable chunks, such as a few days or, at most, a couple of weeks, without giving the appearance of micro-mangement to the project teams. This is particularly true in knowledge-intensive work like engineering, programming, research & development, etc. If you let tasks go on too long, you may be in for a number of rude surprises where task deadlines are coming up and you find out last minute that they won't be complete, with the corresponding risk and damage to the project schedule.

Then, you should make it perfectly clear to your team what the basis of task completion is. No hidden agendas, no unfair comparisions. If you explicitly state up front what the measures of task completeness and success are, you'll encounter little pushback from teams, other than the ones who know how to hide behind percent-complete random guesses.

As I mentioned before, if the above is politically unpalatable in your organization, you can make this assessment from your current project data by marking all tasks between 0 and 99% complete as 'not done' and those at 100% as 'done,' and see where you really stand. Believe me, you will probably find a number of issues to take action on when you make this type of assessment.

Accountibility and truth - such wonderful concepts.

What Cell Phone Cameras Are Really Good For

Wondering what that camera phone is good for other than taking some goofy photos of the kids and spouse or getting it confiscated at the health club? Behold the following:


Yeah, that's right: they are really good at taking pictures of whiteboards. Which saves you oodles of time not copying it down on paper. Even better, with most camera phones you can e-mail the photo to your account as an attachment, then use it in a document or convert it to some other format like Word, Powerpoint, or MS Project. I've saved e-mailed whiteboard photos do my hard drive as JPG files, then slapped them unedited into a Word document with text and sent them off as e-mail to other groups. Very simple and effective.

A caveat: if your cell camera has low resolution, be prepared to edit the e-mailed file to get the words to show correctly - usually increasing the size of the images works fine if you've taken the pictures properly. Once you get your e-mailed photo, saving it as a JPG or GIF file helps in using the image in other documentation.

I knew these camera phones would eventually be good for doing something other than chatting...:)

The WORST Type of Project Manager

In addition to working as a project manager and teaching the subject at UW-Milwaukee, I also work in IT as an enterprise and data architect. For the non-IT types reading this, enterprise architects deal with the specific relationships between business strategy and processes and how those are realized with information technologies.

I usually have no problems working in teams in a non-PM role as I love IT architecture as much as I do project management. Also, I never offer PMs managing the teams I'm on project management advice unless they ask me for it (they often do ask, but some don't). Finally, I don't overly critique PMs to the team or management unless: a) asked; or b) things are so bad that I have to rant and vent in the hope of getting to a positive outcome for the project and the project team.

OK, my motives might not be entirely altruistic. After all, I am running a business, and projects are revenue, and good, completed projects are good, long-term referals, so yes, I get something out of this too.

Anyway, I recently had the misfortune to run into a pretty poor project manager who has one key strength - excellent political skills. On the poor side, the guy can't do scheduling and come up with accurate milestone dates to save his butt. His method of scheduling primarily comes down to this: 1) Here's the totally aggressive and unrealistic date I promised the sponsor, but didn't let you in on until just now; and 2) match all of your work to this date, regardless of any other committments (business & personal) that you have.

Then, of course, as the dates get routinely blown by the project team, he distances himself more and more from the project until its clear that it has no project manager, or one steps up into the breech to either complete the work or shut the project down as gracefully as possible. We were in the middle of blowing some significant milestones on a project I was doing with him when he entered my office all bent out of shape and declared "WHAT shall WE DO about THESE DATES??"

After I motioned to him to take a seat - I leaned over, got about a foot from his face, and said very evenly but making no mistake about my intent: "You are the project manager, and its time that you started acting like one. You are the first one to take credit when things go well, and are nowhere to be found when they don't. This is YOUR PROJECT. If you want me to take over PM, then let's go see [the CIO] and make arrangements. I'll also make sure to inform him of WHY we're suggesting this change. If you think that you can lay all of the problems on this project with the project team, I strongly suggest that you think again because believe me, the outcome will not be in your favor."

He looked at me like I shot his dog. That's what narcissistic types do, I guess. It's all about him and things just can't survive without him. We'll see.

We ended up completing that project and delivering on its major milestone 6 months later than planned, and looking back, that 6 month slip was the realistic date. Narcissistic PM went on to head an even larger, more expensive project (in part due to his excellent political and BS skills) but his bad habits caught up with him. He was the cause for a huge revolt on his project team within 9 months, and severe slippage in cost and schedule on the project. He was summarily canned as PM and likewise from the company a few months later in a downsizing cutback.

Wonder if he learned anything from these experiences, or if it will always be our fault he didn't succeed.

I've Seen This Movie Before and Know the Ending

Once again, a client is heading for a project train wreck. A project that was back-burner for many months now is front and center because of significant regulatory issues (i.e. fines) that will crop up in July if this project is not implemented, or fails to deliver.

Projects based on regulatory or government-mandated edicts are strange ducks. You can't over- or under-prioritize them with respect to other projects because, for the most part, you have to do them to become or remain compliant, and stay in business. In short, they just happen, and when they hit an organization, it usually has the force of an anvil dropped off the 50th floor.

Not so this time. The issues and impact were known months ago, but management incorrectly gambled that they'd get a waiver (they've had several already), and you know, with budgets tight and all, it just didn't register on the priority scale.

Well, they bet wrong. Again. This situation is compounded by the fact that two major projects have significant (read: affects their revenue) milestones coming up in the next 60 days, and critical resources from those projects are being siphoned off to deal with the 'new' regulatory project. The PMs involved feel like transplant surgeons who have installed 3 livers into an alcoholic that keeps right on drinking. Now the patient needs a fourth liver - and will most likely keep right on partying. It gets old, fast.

Call it hindsight, but the time to have started worrying about the regulatory issues was last summer or spring, when they were known. It's too late to address these issues with 6 months to go, and it's pre-ordained that the organization will undergo significant pain because even if the regulatory project succeeds on-time, the two other revenue-based projects will not (as originally projected) because of resource shifts and adding resources will have little effect on current schedules and will drive up costs regardless.

Unfortunately, there are no PM scenarios or methodology to counteract bad managerial judgments. The PMs will 'take one for the team' for the 4th or 5th time, and it would not surprise me in the least if some of these fine folks (and key players on their teams) vote with their feet in a few months and begin drawing paychecks somewhere else.

Where they will most certainly be more appreciated than they are now.

RECOMMENDED READING

A continuously updated list and short review of books, periodicals, web-based resources, and other materials I have found useful in the context of PM. I'm a bookstore hound, whether its Powell's here in Portland (what a great place!), airport bookstores, B&N/Borders, or Amazon.com.

A search for "project management" today on Amazon yields 176,041 titles, and the majority are obscure, dated, or just plain crap. More mainstream, general business titles on management are also useful depending on your needs and tastes.

GENERAL BUSINESS & MANAGEMENT TITLES

It's All Politics - Winning in a World Where Hard Work and Talent Aren't Enough, Kathleen Kelley Reardon, Currency Doubleday, 2005. The title snagged me in an airport bookstore browsing before a long flight back to Portland. Reardon's premise that one's talent and hard work is not enough, you have to be politcally savvy in the workplace to succeed and she shows you what to say, how to say it, and to whom and when. PMs should take note that being politcally-savvy at work doesn't mean being devious, nasty, or unethical. But there's a game being played every day in the workplace, and refusing to play doesn't mean that the games aren't being played on you, to your detriement. Highly recommended.

All Marketers Are Liars, Seth Godin, Portfolio, 2005. A master marketer talks a lot about, well, marketing...but he does it in the context where you can insert just about anything as a replacement for marketing, such as project management and resume'. The essence of its message boils down to how well we tell stories to customers and stakeholders, and what they believe based upon their view of the world. Must reading for insights on how to deal with sponsors and stakeholders effectively.
PROJECT MANAGEMENT-SPECIFIC TITLES

Update soon

OTHER RESOURCES

Update soon

OFFSHORING LABOR COSTS

I've had more than one client make serious and costly errors regarding labor costs on projects (or major portions) that were offshored, primarily to India. This post isn't a slam on offshoring or Indian or Chinese or Eastern European labor. It's more a post about how labor costs should be treated in project regardless of where the labor originates from or where the services are performed.

The big problem? Only focusing on what the labor costs and not how much of it is used. More than one client goes crazy about $10-15 per hour labor costs in an offshore situation (compared to $30-45 per here in the US), signs up, then gets a bill for about 2-to-3-times the hours it would have taken to have the work performed locally. Some deal, eh?

These clients forgot or ignored that all labor costs are, at a minimum, two-dimensional: Labor Rate X Hours of Work Performed. As such, it doesn't make a whole lot of sense to engage cheap labor that requires many more hours to perform tasks than more expensive labor that may be geographically closer. The additional management costs involved when engaging offshored resources is not accounted for here, but should be.

Offshored labor resources have a definite place on projects, but engaging them solely on the basis of per-hour costs is a mistake; the entire labor cost projection has to be made to get the real costs to projects.

GLOSSARY - Updated December 26, 2005

This post is a continuously updated list of definitions, TLAs, and other jargon I use in my writings.

JDI - "Just Do It" - refers to line managers, project sponsors, or major stakeholders who ignore, deliberately or otherwise, the constraints imposed on projects by time, project scope, and available resources. A JDI typically ignores constraints when requesting scope changes to projects, or believes a project can be executed within a certain timeframe or at a specific cost arbitrarily without analysis or other thought processes before proceeding. Successful project managers either educate JDIs on project management (to the extent possible) or avoid working with or for them because unchecked JDIs have shown to be primary drivers of project failures.

PMBOK - Project Management Body of Knowledge published by the Project Management Institute. The definitive manual for process-based (or "traditional") project management. If one desires a PMP certification from PMI, they need to know this work verbetim.

PM - Project Management or Project Manager, depending on context

PMI - Project Management Institute. The professional organization for project management and project managers. Further information here.

PMP - Project Management Professional. A certification conferred by the Project Management Institute obtained by a combination of experience, continuing education, and the passing of an examination.

REP - Registered Education Provider. An academic insitution or for-profit training firm that is authorized by PMI to offer PM courses that count as continuing education credit for PMP certification or to maintain the certification.

TLA - Three Letter Acronym

TWO-DIMENSIONAL COSTING - Knowing (or coming to the realization) that some project costs are multi-dimensional, such as labor (hours X hourly rate). Only treating these costs as single-dimension is usually an error that leaves one over-budget during project execution.

UNFUNDED MANDATE - Projects (and work on such projects) that are not officially recognized, much less formally funded by an organization. Actually, this definition is a misnomer because if one performs work on projects that are 'unfunded,' you theoretically should not be paid. Since nobody works for free in most cases, the unfunded mandate is, in reality, funded - secretly from the budgets of projects recognized and formally budgeted by an organization.

VACATION

I'm taking the Christmas holidays off to be with family & friends, so I won't be updating again until after December 26th. I wish all of you and your loved ones a safe and happy holiday season!

Bob McIlree

New System Integration Blog

I started a new blog focusing on system integration from the perspective of the intersections between project management, enterprise architecture, and business process/analysis/strategy. Check it out (it started today) and let me kow what you think!

Have a wonderful and safe holiday season!

PROJECT PLANS: A Plan to Plan, or Execute?

I've reviewed hundreds of project plans in my career. About 20% of them were well thought-out and assembled. The rest range from middling to truly awful. The reasons why a good percentage were truly awful are legion, but the middling ones are salvagable and share an attribute that, when fixed, propels the plan into the top-tier of usable, complete project documentation.

The difference? Excellent project plans are those that project teams can execute projects from. The rest can be simply categorized as "plans centered around more planning," which are generally useless to executing project teams.

The key to indentifying project documents like this is to examine the language and phrases used througout. Good plans concentrate on operations and execution, not strategy. Strategizing should come before, not during or after execution, so the plan must be explicit it how the project will accomplished as opposed to why it will be done.

For example, if continung statements of need are present, such as "...we need a comprehensive claims processing workflow definition..." or "...it is necessary to get the Business Operations Board to decide which network platform to buy," you're not receiving an operational plan or guidence to execute, you're simply getting strategizing or at worst, wishful thinking.

The project plan is the wrong place to do things like this. It must come well before a project ever gets close to the end of the planning process and into execution. If it doesn't, your project is behind the eight-ball before it even gets out of the gate.

If you're having trouble getting the plan into an operational form executable by the project team, it best to start by answering these questions:

1. Do we know what we're supposed to accomplish?
2. If we know the answer to (1), how are we going to accomplish it?

Excellent plans focus almost exclusively on how, and why or what the project addressed should have been answered well before the plan was put together.

KATRINA - Some Lessons for Project Managers

Before I begin, allow me to extend my sympathies and share my grief to all who lost loved ones and livlihoods in the wake of Hurricane Katrina and its aftermath. If you haven't already, please consider making a donation to the Red Cross and Salvation Army. Further donor information at http://www.redcross.org and http://www.salvationarmyusa.org.

Katrina, or more specifically, the effects of her destruction of New Orleans and the Gulf Coast and the response to them, have the elements of a project as defined by the PMBOK: a beginning, an end, and an outcome. The coordinated governmental response to her wrath and havoc, or lack of it, and the failure to execute those plans properly and in a timely fashion, led to many deaths. Some PM-related examples:

'In Arkansas, state officials were first told to expect 300 evacuees. Nobody came. Then the state was told to prepare 4,000 meals for a fleet of buses. No buses arrived. Suddenly, in the wee hours of Sunday, more than 9,000 refugees showed up at a National Guard post. “It rained people on us,” said Gov. Mike Huckabee, a Republican.'

'In West Virginia, Gov. Joe Manchin dispatched several planes to the South to ferry refugees to his state. Most of the aircraft sat empty until he ordered them back home in frustration. “The waste that goes on because of a lack of coordination ... ,” he said. Too angry to finish that sentence, Manchin spit out a new one: “To bring five planes back empty is a crying shame.” '

'In New Mexico, Gov. Bill Richardson said he authorized National Guard troops to leave for New Orleans early last week, but paperwork delayed their departure for days. '

- All quotes from "Governors Appalled, Galvanized by Response" MSNBC.com, September 7, 2005.

I don't know about you or other PMs, but after-the-fact disasters such as this make me wince because these scenarios didn't have to play out the way that they did. In fact, I've done a lot of wincing watching the news over the last two weeks. As is stands at the moment, the bungling and inept responses to Katrina is not a politcal problem. It is not a Democrat or Republican problem, nor is it a liberal or conservative problem.

It is a governmental problem. A big one. A gravely serious one that caused thousands of needless deaths and untold suffering.

Government at all levels failed these folks. Miserably. Ineptly. The primary culprits? I can think of three strong possibilities that will become clearer as time passes and the truth (or what passes for it) comes out at myriad hearings and commission testimonials:

1. Turf-battles between governmental units, most likely along the lines of geography and level of government (local, state, and federal).
2. Bad execution process (bureaucratic, process-heavy, delayed for whatever reason).
3. Lack of strong leadership in government (not politicians, but bureaucrats and appointees)

If we learned anything from the horrors of 9/11, it was that a strong, coordinated response (as shown by New York City's fire and police departments) and leadership (as practiced by then-mayor Rudolph Guliani and President Bush), go a long way in resolving the effects of these disasters and bouying the nation in preparing for the next disaster or terrorist strike.

That didn't happen here. Not even close.

America, the great superpower, stumbled badly trying to rescue its own people from a horrific disaster on its own soil. There will be other Katrinas. How will we respond? How will we evacuate those who cannot leave? How will we rescue the injured and infirm? How will we feed and house these people until they can return (if they can return)?

The really sad part of this is, Homeland Security, FEMA, and the States have gloriously detailed plans - on paper. You would expect nothing less given their respective charters, laws, and the taxes we pay for the people who produce these plans and the material and resources to execute them. The underlying issue is that we could not, as a collective and united people, execute those plans successfully.

'A more visceral indictment came from closer to the calamity. Aaron Broussard, president of Jefferson Parish near New Orleans, said the bureaucracy "has murdered people in the greater New Orleans area." "Take whatever idiot they have at the top of whatever agency and give me a better idiot," he told CBS. "Give me a caring idiot. Give me a sensitive idiot. Just don't give me the same idiot." '
- "FEMA Director Bears Brunt of Katrina Anger," MSNBC.com, September 7, 2005

Lots to think about for project managers here. Disasters and tragic events always give us much food for thought.

NEGOTIATION

In addition to PM training of all types, I highly recommend that PMs either get training in negotiation techniques or self-educate themselves on the topic via books, audio CDs, etc. There are too many choices in this category to list, but I'll take a whack at a few of my favorites in my Recommended Reading section later this week.

Negotiation skills and political savvy are key characteristics of successful project managers - and that doesn't mean successful PMs are untrustworthy snakes or would haggle their mothers away for a contract concession from a vendor. What it means is that good-to-great PMs are totally aware when negative negotiation and political games are being played and know how to mount an effective counter to them.

One thing that always makes me chuckle when thinking about my own training in negotiation tactics were some of my fellow students who decried some of the techniques we were being taught - so boorish, so unethical, so...slimy.... The instructor, a wise old sage, remarked, "You need to know about these techniques because I don't expect you to use them, but I do expect you to recognize when they are being used on you and to give the proper counter-response."

Like I said, a wise old sage.

THE SKINNY ON PROJECT MANAGEMENT TRAINING CLASSES - PART I

Before I comment on PM training, here's a disclaimer: I'm an instructor in the PM program at the University of Wisconsin-Milwaukee, and have been for almost 4 years now. So I have a definite bias on the need for training and how good our program is (the best!! :)), but I also have biases on what types of training PMs should consider getting, and how to go about getting it frm the myriad providers and types of course delivery out there.

Do PMs need formal training? Yes, they do. Just like in any other profession and discipline. Not only do PMs require training, they also need it on a continuing basis, just like other professionals. Sure, you can self-educate yourself by reading PM books and periodicals, but nothing beats a formal learning experience for receiving and synthesizing useful information of value to you on the job. If you have, or are about to acquire a PMP certification, you need continuing education credits to get the cert, and more each year to maintain it.

My discussion that follows centers around continuing education PM courses and programs - that is, these courses do not confer academic credit that leads to an undergraduate or graduate school degree.

There are a number of ways to slice-and-dice the need for formal PM training:

• As mentioned above, you have or are going to get a PMP certification and need to rack up hours in the classroom to qualify.
• You are a complete newbie to project management, or wish to enter the field from some other discipline or profession.
  
• You are a working PM and wish to enhance your skills; perhaps learn new techniques to introduce at work.
• You are a manager and wish to introduce PM into your organization, or must understand how an existing PM discipline works in your firm.

Once the need has been established, there are a number of choices:

1. Self-study programs - print or web-based
   
2. University-based and for-profit PM programs, some of which lead to a PM certificate on completion of a specified number of courses
3. "Onesy-twosy" PM courses offered by local colleges, for-profit training firms, PMI chapters, and others.

Self-study programs are basically teach-yourself with some off-site assistance (if web-based) programs that rely on your initiative to complete. This is OK if you're an experienced PM and the topic is advanced or arcane and you are satisfied with largely self-educating yourself on the topics covered. If you're a newbie or inexperienced, this route is not recommended because of the lack of rigor and formality found in the classroom. If you're not sure about PM as a professional pursuit, reading general-scope PM books is fine to get started, but if you're going to do PM on the job and/or are serious about entering the field, you get much better instructional benefit being in a classroom with similar people from other organizations - you will learn more, not only about PM, but about other people's attitudes, companies, challenges, and successes that is completely missed staring at a computer screen or a manual. One good thing about self-study is that, in most cases, its relatively cheap compared to formal training.

Many universities and for-profit training companies offer complete PM programs to the public on a continuing education basis. Most are REPs - Registered Education Providers with PMI that confer continuing education credit for those pursuing or maintaining the PMP certification. Some offer a certificate at the end of specified curriculum of courses - and please realize that a PM "certificate" or "Masters Certificate" is not an academic degree or PMP certification. It simply means that you attended and completed a specified number of PM and business-related courses, and for a Masters certificate, took and passed an exam after each course. These courses range from 2-4 days and the costs run anywhere from $300-400 to over $1000 each, depending on length and content. If your employer is paying the tuition, this is not usually an issue, but I realize that it definitely is for the unemployed folks out there or the ones who don't receive an employer subsidy of the costs.

The 'onesy-twosy" PM courses, usually offered by for-profit training companies and small community colleges, are usually introductions to PM that are offered alongside other courses, say in information technology and general business topics. They are relatively inexpensive, short duration overviews that are fine if you just want to sample the topic in a formal setting. These offerings become problematic if you need PMP credits or a formal PM training program, and should generally be avoided of that's your situation.

In Part II, I'll talk about these training vehicles in more detail, and what to look for and expect when deciding to sign up, pay for, and attend these programs.

RESOURCES

I've never liked referring to people as 'resources,' as the term is a bit too impersonal and cold for my taste. However, in the PM community, the term fits rather well.

In today's drive-thru, multi-task, do-everything-now business environment, a project manager's acquisition and retention of project team members is a critical skill and is vital to project success. Why? Because a PM who doesn't pay attention to these matters is going to wind up empty at the 'resource pool' and isn't going to deliver on-time or close to it.

Within organizations, competition for available talent is fierce and if you don't play that game well, you lose. Not only is competition for talent a major issue, but retention of that talent on your projects can be problematic because there is always demand for the skills of the folks on your teams, and I've seen plenty of savvy, political PMs poach the time (directly or not) of other projects' members to advance their projects and agendas. In my PM classes, a challenge often identified by students often is the lack of available or allocated resources and/or having team members continually re-assigned to whatever crisis-of-the-moment is hitting their organization.

This issue has a whole bevy of problems and solutions, so I offer a few insights now and will return to this often.

• Make certain that you have asked for adequate staff in the project plan, schedule and budget. Your plans shouldn't be grandiose or overly padded with tons of staff, but other than the normal allowances taken for project scheduling (productivity, time off, etc.), you should have some room in the schedule and staffing for work that may come up that has nothing to do with your project, but you may need to account for later. Trying to shave a few bucks off of the budget by subtracting resources can come back to haunt you later when those resources suddenly disappear into someone else's black-hole.
• Beware of the multiple-project-allocation trap when utilizing people with project responsibilities on a number of different projects. If you need to utilize a scarce and heavily-in-demand resource, you will eventually find those resources reallocated to some other task or project - without your input and usually after-the-fact. Stay on top of what these folks are working on at all times as your project executes. If your work isn't getting the allocation that it needs, take action with that person or his/her management as soon as you can. If you cannot get a committment for that person to return to your project tasks immediately, get a committment for when that can happen, adjust your project pln accordingly, and start looking for a replacement if that can be reasonably accomplished.
  
• Watch out for "resource hoarding." To combat having resources taken away or otherwise becoming unavailable to them, some PMs utilize what I call "resource hoarding" - scheduling resources as unavailable when, in fact, the resources have little or nothing to do on that PMs project at any particular point in time. PMs do this so they can control availability of critical resources to their projects, but takes away the resource for others. This is largely a political issue, and if its played in your company, I advise that you understand how that game is played. Even if you don't plan to play, you will eventually, because its being played on you and your projects, often to your project's detriment.
• Direct management flip-flops. In situations where you don't managerially control the project team members, their direct management will often reassign their charges to other work - notify you after the fact. That's bogus, and call the line manager on it when it happens. I was co-managing a project couple of years ago and the direct manager of a key team member told us at 5:30 PM one night that yes, her direct report would be "100% dedicated" to our project for the 4 weeks we needed him. By 8:30 AM the next morning, she had reallocated her employee to another project that wouldn't deliver anything for a year, but made her look good to her management. We called her on it later that afternoon in a meeting with our project's sponsors and major stakeholders, and while we wound up not getting her employee in the end, we were able to bring in a person from the outside to assume the work even though a hiring freeze had been imposed.
  

Like I mentioned earlier, I'll update this thread continually because starving projects of resources occurs frequently and is a key contributor to project failures.

HALF-BAKED PROJECT MANAGEMENT

A constant refrain I hear when with clients or in my PM classes at UW-Milwaukee is "...that project management methodology sounds great, but can we only do this and this and this instead of the whole thing?"

Of course they can, and often do. But the Laws of Unintended Consequences come into play as well. Well-defined and honed methodologies work best if they are completely implemented and executed without stinting on portions that seem irrelevent, expensive, take too much time, ad nauseum. When "pick-and-choose" comes into play on PM methodologies, oftentimes the outcome is worse than had no methodology been followed in the first place. This applies to agile methods as well as process-oriented methods. In fact, agile methods are more tightly coupled with each other than process-oriented ones, so skipping processes has potentially a greater negative impact on project outcomes.

OK, I'm aware that some of the skeptics out there eschew methodologies as mostly cooked up by consultants hungry to make a lot of bucks hawking their wares. However, the fact remains that mainstream PM methodologies are tested and viable means to deliver projects within cost and time parameters. That has been proven over many years on millions of successful projects.

Another valid consideration is that PM done "by the book" has up-front costs, which gives managers and small organizations heartburn when cash and time go out the door up-front and the return on that investment is sometime later when the project is delivered. The point here is that the project will cost more (or become a sunk cost if it fails to deliver) if a project plan isn't developed and isn't executed properly.

Finally, these processes are resource-driven. That is, a PM who may be contributing in some other way to projects (as an engineer, programmer, scientist, etc.) now must pay attention to project management and let go of specific tasks within projects. Some kind of balance must be struck as the transition from the operational/tactical roles the PM played on projects to straight project management - with the eventual goal being that the PM is 100% dedicated to project management at some point.

So, let's say you are facing these constraints and need to make some choices about what can and cannot be accomplished using a PM methodology. Here's a list of "must-have's" in the traditional, process-oriented methodology and why you need it:

1. Project Charter or Statement of Work (SOW) signed off by project sponsor and major stakeholdlers - this is mandatory because if you have no initial scope or boundaries drawn about what the project outcome should be, you have no basis going forward to plan anything formally.

2. Work Breakdown Structure - Following from the charter, if you have no list of tasks needed to accomplish the work, how do you measure progress during the project and/or know that you are delivering what is required? You cannot generate a realistic schedule or budget without a WBS, although many PMs try (and fail miserably).

3. Schedule and Budget - Follows from the charter and WBS. The amount of detail and iterations required to generate a detailed schedule or budget can be compressed to save time or money, as long as each fairly represents the project situation.

4. Risk Management Plan - A basic risk plan with corrective actions if risk events are triggered is mandatory and can save your project. As an organizations perfects its PM processes and techniques, the risk plan can (and should) get more sophisticated.

The above documents are the basic, fundemental work products of a project plan. For other project plan deliverables in a PM methodology, you may find it useful to apply the following rules of thumb:

• Does the document or work product deliver value to your sponsor/stakeholders and you as a PM? For the former, it must convey useful and timely project information; for you, it must help you track progress and execute the project. If it can't or won't, don't do it.
• Can you generate this project plan element easily or with modest effort? Some portions of plans and reports, particularly detailed progress reporting using earned-value analysis, require a lot of data to be accurate. Collecting and processing this data requires time and money. If you have niether, then basic tracking from status reports and updates to the project plan should suffice.
• Is this project plan element a one-time only exercise or something you will do on all projects? Obviously, greater PM value is obtained the more time a plan element is used within projects. Certain projects require one-time-only plan elements (see point 2 above) but you will obtain better value for your efforts the more times you generate and use specific project plan elements.

Finally, a few suggestions to help ease the transition and hone your PM methodology if you're starting from zero:

• Use commercially available project management software. Sounds obvious, but $500 for a copy of Microsoft Project is cheap compared to the alternatives. And yes, I've seen more than a few people balk at this so that's why I'm mentioning it.
  
• Copy, develop, and use templates for standard PM documentation. The good news here is that there are templates available free for just about any PM document you can think of. If you put "project management templates" into Google you will not have enough years of your life left to look at everything that comes back from that search. Hone the search in to what specific element you are looking for to narrow the choices. Once you have downloaded what you need, don't be shy about modifying templates to suit your needs - just be consistent going forward about using them on your projects.

PMP - Worth the Trouble?

The PM community is very familiar with the Project Management Professional (PMP) certification offered by the Project Management Institute (PMI). Like other certification programs, the PMP confers on the holders an aura of competence in project management by way of documented professional experience, continuing education requirements, and the passing of a graded examination. All of these goals, on the surface, are worthy. However, once one digs deeper, the whole concept of certification is problematic.

Certification programs abound in lots of categories, particularly within information technology disciplines and allied fields, such as PM. For reasons I will expand upon below, I generally have a dim view of certifications, particularly with employers who use them as a 'gate' or checkpoint when evaluating candidates for employment.

Before I continue, I don't hold certifications in any field. I just have college diplomas, some continuing education, a lot of self-education via books/audio, and years of hard-won practical experience on-the-job as both an employee and consultant. These have proven far more valuable to me than any certification bestowed by some organizational 'authority' that is not an employer or an accredited university.

Certification programs (including the PMP certification) suffer from the following problems:

1. They are not licenses to practice the profession, such as those for law or medicine. However, they are often indirectly treated that way.
2. As the number of certifications increases, the number of incompetent and/or inexperienced people being 'certified' also increases.
3. Certifications lose a lot of lustre when it becomes possible to obtain a certifcation simply by going to a commercial 'boot camp' to cram for the certification exam, getting a few continuing education credits, and refactoring one's 'work experience' to meet the professional experience requirements.

Let's take these points in turn:

Certifications are not professional licenses

I'm not going to get into the argument that project managers should be licensed by an authority recognized by governments - that's a separate issue. What I am concerned about is the perception of certifications as a standard or a license that proves competency in the subject area. Worse, these perceptions are owned by hiring managers and human resources staff who screen PM applicants not for experience as a primary factor for futher review, but the fact that the applicant is 'certified.'

The fact is that any certification scheme in almost any field can be gamed, and the PMP certification is not immune to this. Licensed professionals face the termination of their license to practice by the appropriate licensing board if they are found incompetent or committed malfeasance in the performance of their duties. No such avenue exists for PMPs., and with good reason, since its not a license.

So why treat it as such?

Incompetent and Inexperienced People Get Certified

There are bad and poorly-performing doctors and lawyers, and as with any profession, the same hold true in project management. I personally know of three project managers who have been dismal failures in the course of their PM endeavors (not bad people, mind you, but not good or even average PMs) who hold PMP certifications. I have interviewed more than a few certification holders for clients who couldn't tell me what a work breakdown structure is or how to simply determine budget and schedule variances.

Then we have the inexperienced folk who, upon reading how PM is such a burgeoning field with high renumeration for their efforts, refactor their work experience as 'project management' when they actually were project team members or, at best, team leads reporting to a project manager. They get their bosses to sign off on the application form and presto - a newly-certified PMP emerges if they pass the certification exam.

Yeah, I'm aware that PMI "audits" the PMP program to verify credentials stated in applications. That's nice - has anybody had their certification revoked for falsifying their application? Right, I didn't think so.

Its Too Easy To Get Certified

A key indicator that a certification is peaking in popularity is the increase in the number of "boot camps" and other study aids to help one pass the certification exam (which, I'm told, is fairly difficult). Some of these programs claim to have you ready to take the exam within a week or two after attending their program. When coupled with misrepresentation of experience scenarios I just mentioned, it's not surprising that we get "certified" project managers that have never actually managed a project!

The PMP situation reminds me of the Novell NetWare certifications of the 80's and early 90's. Novell Netware was the dominant PC network operating system at the time, and the CNE designation (for Certified Netware Engineer) was a hot commodity to land a job. Of course, the boot camp industry answered the call and cranked out thousands of "certified" Netware engineers over a period of time, with the boot camps lasting all of one week and the primary objective to teach attendees how to pass the exam, and not actually run a real network.

At more than one client, newly minted CNEs were hired with little experience in actually operating a Netware installation, but hey, they have the cert, so they're OK right? That is, until the network they're administering shuts down and the new CNE has no idea how to troubleshoot the problem and get the network back on the air. Why? Because the problems they encountered and the steps to correct the problems weren't on the certification exam!

PMPs with little or no experience are going to find life very difficult when they run into problems (and they will, trust me) that they have no idea how to approach, must less solve.


Should You Get A PMP Certification?

If you are an experienced PM, the certification couldn't hurt. I'm ranting about this today because the cert has been held up as some absolute measure of PM competency by employers, and the only thing that truly proves competency in our profession is actually managing projects and successfully delivering on outcomes on-time and on-budget. Nothing else matters.

PANIC AND POLITICS

Since I've been dealing with project mangement problems with clients and reading a lot about project failures lately, I decided to write a few things about another major risk facing projects - office/organizational politics and the ensuing panic on the part of the project manager and project team.

Office politics, like change, is inevitable and must be dealt with properly and in a timely fashion. Folks we work with who proclaim "I don't do office politics" or similar utterances do so at their own peril and are deluding themselves that their strategy will keep them employed and professionally viable. Those I've known in my career who have done that have generally been ignored, not promoted, or worse, among the first victims of staff cutbacks. It's not possible (or advisable) to "keep your head down" all of the time at work and expect to advance or have any real effect on the outcome of your work. This is particularly true of project managers. As I tell my students in PM courses: "If you want to sit in your cube all day staring at a screen, don't like attending meetings, can't or won't communicate well, or play the political game at work, project management is not the job for you!"

Of course, how one specifically plays office politics has effects on project outcomes, but I'll leave that for another article. My point here is that politics played the wrong way can drive an emotion that can kill projects: panic. The effects of panic behavior, both short- and long-term, can be devastating to projects and those involved with them.

The main effects of panic on a project involves what I'll simply call "corner cutting." PMs and project teams in panic mode usually thrash about looking for any possible way to compress time and tasks to fit the situation that caused the panic attack. Perhaps the project wasn't well-managed to begin with, and its near time to deliver and we find that we're not in any sort of position to do so. Or a massive scope change changes the project deliverables drastically with little time for the team to assimilate the changes. Or a 'Just Do It" (JDI) sponsor or major stakeholder is demanding change without compensating for time, budget, or resource impacts.

Panic situations have dramatic effects on outcomes for projects managed in with traditional, process-oriented methodologies, but projects managed with extreme or agile methods are not immune either. In my experience, what normally happens when panic sets in is as a part of the "corner cutting," the project management methodology involved is either cast aside (throwing out the baby as well as the bathwater) or so significantly altered, truncated, or abused that the project has little hope of succeeding regardless of what the follow-on decisions or tasks are. The essence of this is a shift from a disciplined, focused approach to a flying-by-seat-of-your-pants / managing-in-the-moment strategy that increases the risk of failure.

There is another insidious and sad side-effect of allowing panic to dictate within a project: it trashes organizational project management methodology and the benefits of it. Why? Because if a project is allowed to operate in panic mode for any length of time (particularly at the end of the execution phase), the organization is sending a very clear signal about project management in that its OK to use PM techniques until the situation gets desperate, then anything goes. PM has little chance of long-term success in such cases because people such as Crisis Junkies seize the opportunity to avoid disciplined techniques and can lurch their work forward in the moment without planning or much in the way of accountibility. Worse, some CJs are very adept at artificially creating a project crisis (or more often, crises) that they can overreact to repeatedly to keep that "high" they crave in the work environment.

The next time things on a project "hit the fan" and you're tempted to correct course by making split-second decisions that have a half-life of ten minutes before you're making the next one to replace the ones you've already made, stop, take a deep breath, and pull out your risk management plan. Map the crisis to the plan, and take the remedial actions specified while modifying the project plan accordingly.

You do have a risk management plan for your projects, don't you?

CRISIS JUNKIES (a.k.a. HEROES)

A Business Week article online (http://www.businessweek.com/careers/content/feb2005/ca20050224_1390_ca010.html) about 'crisis junkies' - people that only function well when there is a real or perceived crisis - caught my eye as project management is rife with such individuals. In some organizations where the business processes move only my lurching frm crisis to crisis, people of this mindset are necessary. However, in most cases, the crisis junkie (CJ) actually does more harm than good to an organization - particularly to projects.

There are numerous problems with people like this and particularly with organizations that tolerate the behaviors. First, project management is discipline that is process-driven, which flies in the face of heroes and CJs because they manage in the moment as crises appear. Since they feed off of unstructured, improvised responses to events, any form of process or authority that doesn't help them meet their objectives is cast aside. Worse, it is very difficult to measure, much less control, responses like this from a PM or even general management perspective.

The next problem deals with sustainability - even CJs get fatigued, and usually their project teams fare much worse over time. We only have so much energy and adrenalin in our bodies and when a continuing crisis-mode loses its luster, project productivity falls as the crisis drags on or is replaced by a fresh set of 'critical' demands to be fulfilled on an urgent basis.

Now lets move on to results - CJs can (and usually do) deliver results in response to the current crisis, but with a caveat - the underlying issues and root causes are almost never addressed and corrected. In the mind of a CJ, there's never any time for that, and in retrospect it takes away the major catalyst for acting in crisis-mode. All project management methodologies are designed to have some form of predictibility built-in for outcomes, and crisis-mode managing is exactly opposite of that.

Finally, PM methodologies address accountability as a key feature of their processes. CJs generally don't have a problem with accountability, as long as they are accountable only for quick results and 'saving the day' as often as possible on high-profile problems and issues. This behavior is narcassistic and only serves the CJ, not the project and definitely not the organization.

Projects managed in continual crisis-mode have very high rates of failure to deliver, and at best, cost the organization dearly in terms of money and team/employee relations. If you operate in this mode frequently or your organization tolerates this behavior routinely, its time to take a long hard look at the way projects (and probably operations) are managed in the organization.

GETTING SERIOUS

I set this blog up about a year ago and promptly got so busy with client work and other writing that I forgot about it. Well, let's see how I do on the seriousness scale going forward...:)

Welcome to my Project Management blog! My name is Bob McIlree, and I work as an IT enterprise & data architect and project manager. I'm based in Portland, Oregon. I also teach project and project portfolio management courses at the University of Wisconsin-Milwaukee (www.uwm.edu).

If you are (or have been) a student of mine, some of this material is going to be familiar to you. If you and I have never met or worked together, I hope tht I can provide you with some valuable insights on the discipline of project management, particularly as it applies to IT. For you non-ITers out there, fear not - I will be providing you with insight and information that applies to your situations also.

Your comments and other feedback on my posts are always welcome. You can contact me at robert.mcilree@rjmtech.com anytime and I actively encourage you to do so.

With that...on with the show!