16.4 Experience and Training

< Day Day Up >

I will introduce this section with two quick stories. The first involves a fine man I did a project for. At the end of our 1-year association, he and many of his peers had the opportunity to take a very generous termination package, which he did. He asked me to review his resume, because he had decided to be a consultant and was interested in my take on how his background would play out there in the real world. After reviewing his 30-year effort on behalf of his employer, who rewarded him with many promotions, I had to find a nice way to tell him that his resume did not make clear what he could do. Sure, it was replete with names of initiatives and other buzzwords that had great meaning and significance within that corporation, but an outsider would have no clue what his contributions were. Perhaps we should all know about Project Apollo, but who knows what my boss's 3 years on The Diamond Project at XYZ Corporation meant in terms of scope, duties, challenges, and accomplishments?

The next tale occurred a few years later. I was managing a complex and demanding program and in the process of hiring three project managers to implement the plan I had spent months developing. One of the candidates had a very impressive resume that included top-of-the-line project management certification and an MBA. Similar to my former boss, he was testing the consulting waters after taking an early retirement package from another huge company. After scrutinizing this gentleman's resume, however, I could not really tell how much actual project management experience he had, so I asked him to drop in for a chat. In advance of this interview, I felt it unlikely that he had adequate hands-on experience and responsibility managing complex projects to meet my needs. Despite my misgivings, his education and recent employment stature caused me to give him a look. Sadly, the interview confirmed my fears. His project management experience was long on institutional process and short on management participation. He had not been in the trenches, and lacked the level of detailed experience that allows me, for instance, to write a book like this.

The point is this: I tip my hat to all of you who have committed the time and money to become well educated and formally certified in the methodologies that this profession espouses. These methodologies and certifications exist for a reason, but, as stated elsewhere, some of our tasks as complex project managers are not any easier to perform well based on academic accomplishments.

I believe it is relatively easy to evaluate prior experience. Simply ask what the candidate did. If I were to answer this question using my most recent project, my diluted response would look something like this:

Planned and managed weekly project meetings
Oversaw documentation of minutes, engineering, and operational planning
Coordinated data center rack, power, and cabling design and installation processes with consultants, vendors, and users
Oversaw the integration of the various technology designs into the rolled up implementation and operations plans
Developed and managed the migration strategy for users to the new technology
Developed the plan and managed the subsequent relocation of hundreds of servers to multiple sites

If you were interviewing me as a potential project manager, you could drill down into any of these activities to get a feel for:

How many people, servers, or dollars were involved
How complicated this was
Whether I did any scheduling, risk analysis, or design work
What my boss contributed and how much autonomy I had
What my level of involvement was from a technology perspective
What my level of involvement was from a leadership perspective

You should be curious about my contributions, in other words, the value I believe I added to the project through my participation. This last word's significance is sharpened when you reflect on the difference between attending meetings and participating in them. Project managers who participate in their projects, as I have tried to illustrate throughout this book, learn innumerable valuable lessons that help them grow the critical skills. Those who summon enough "chutzpah" to get down into the trenches like this are far more experienced and, thus, capable of plying our trade effectively.

When you do this, you are not writing code, patching network connections, or racking servers. What you are doing is basically making yourself available to team leads while they struggle to get their jobs done. I cannot tell you how many subteam meetings I attend as a mostly silent partner. I am always available to answer project questions or to field issues thrown my way. I am also there to learn and to look for issues that could turn into trouble for me because I am the project manager.

Remember, these people who are the heart and soul of your project are technologists and operations staff. They may be unbelievably talented in their specialties, but they are probably not too adept at project management. As a consequence:

They may wait too long to escalate issues.
They may make poor decisions on resource utilization.
They may not be comfortable getting a disappointing vendor on the phone and making whatever demands are appropriate.
They may shy away from confrontations with beneficiaries or any other stakeholder because of the politics.

If you are not a participant, you will not be aware of these things - at least not until they snowball into major problems if not jeopardy situations. If you are participating, you will recognize these and similar conditions as opportunities for further analysis or escalation that project managers with great skill and a wonderful sense of timing use to the advantage of their project.

16.4.1 Project Management Methodologies

Any top-notch specialized professional is effective because he or she has adequate if not impressive academic credentials, proven successful experience, and a passion for the work. Other than standing on the level of familiarity with project management methodology as implied by this book, I am not necessarily the authority on the right level of certification an individual should possess to be an effective project manager. There is no such thing as too much education, but that is equally true of the other two parameters of prior success and passion as well.

From an interviewing perspective, a discussion of a candidate's familiarity with the proper procedures is important. At the very least, it is important to ask each individual how he or she approaches a project from a process and organizational perspective. There is no correct level of knowledge other than the basics that were covered in this book.

16.4.2 Technical Background

A background with multiple technology experience indicates a general comfort level with technology. Without that comfort level, project managers tend to get hung up on singular technical issues and then lose their perspective and probably control of their projects as well. I once took an assignment because it was a chance to do an ambitious Web site project, something that my network-centric background lacked. The challenges of technology are naturally quite diverse, but it is the willingness to take on any technology that is key.

Being a consultant, quite naturally I peruse the Internet want ads more often than most employees (I hope). I always get annoyed when I see requirements for project managers stating unequivocally that the right candidate must have 15 years of experience using Product X, or building trading floors, for instance. Although this is somewhat understandable, it is, in the end, rather uneducated on the part of the hiring individual. Project management is not about knowing how to deploy Product X or rebuilding Trading Floor Y. Project management is about knowing how to develop and manage a project that will successfully deploy Product X or rebuild Trading Floor Y. If you need expertise in Product X or Trading Floor Y, then go hire experienced analysts, people we once called subject matter experts, in Product X or Trading Floor Y. The expertise of competent project managers is project management, not these specific technologies or product types.

I cannot resist taking one last look at this scenario of requiring previous success with Product X or Trading Floor Y. The reason this is so common is, quite frankly, because good project managers are few and far between. They are a rare commodity - just as it is rare to have a good understanding about what it takes to be a good project manager in the information technology (IT) world. By insisting on demonstrable past success, the hiring manager can check and see if you did a good job with Product X the last time around. In his more honest moments, however, any project management expert will tell you that previous success with Product X is not a fool-proof predictor of equally satisfactory results the next time around. That would be somewhat analogous to expecting the same team to win the base-ball World Series year after year after year.

But I digress. As mentioned in the preface, fully half of the project managers assigned to complex projects that I have known through the years had a nontechnical background. I rationalized this by saying that strong interpersonal management skills are important in our specialized profession, too, so lacking personal technical expertise should not, by definition, exclude that individual from spearheading complex technical projects.

As an interviewer, however, I would expect this individual to have processes, similar to those laid out in Chapter 3, to attack their lack of specific knowledge of the project's technologies, have a terrific track record, and possess excellent skills in the areas covered in this chapter. I would definitely ask them how they handle unfamiliarity with the technology, and business processes that your project will address. If you are not satisfied with their answers, you can always reach for the next resume from the pile in front of you.

16.4.3 Quality Orientation

In my admittedly lengthening career, this was once called process reengineering, then Total Quality Management (TQM), then quality assurance (QA). The more common methodologies in place today include Six Sigma, International Organization for Standardization (ISO), and Capability Maturity Model (CMM). I am neither unlearned nor agnostic about these processes and their fine goals and expect those with whom I work to have an equally high commitment to the disciplined pursuit of quality.

A word of caution is in order, whether the application of any of these methodologies, or one of their cousins, is a project requirement, or discretionary. I am not an expert in any of them, but have observed that they complicate the project from an implementation perspective. I would look for additional resource, longer timeframes, and considerably more tasks to manage if:

Project output must be in compliance with any of the standards described.
Their methods (e.g., Six Sigma) will proscribe your implementation strategies.

These conditions add significant cycles to the project and should be planned for accordingly, despite the fact that adopting high standards and incorporating a process that assures the attainment of these standards is a noble thing.

Experienced complex project managers are aware that:

Perfection is not always possible.
Error and misfortune are part of the landscape.
Quality methods cannot be emphasized to the degree that business and functional requirements are sacrificed or overlooked. A project can sustain just so many deliverables without becoming overloaded and, ultimately, become bogged down by the sheer weight of them all.

The quest for quality from an academic perspective is laudable, but from a "down in the trenches" standpoint is not always possible to the degree that these methodologies demand. Part of the project management experience is treating poor results as a risk and looking for ways to mitigate that, sometimes after the fact. Quality is not simply a matter of following the right processes. Were that true, as I have asked before, what do we need project managers for? I designed two programs in which a major subteam was dedicated to quality. Each team's mission was to apply strict methodologies to all project phases and synchronize handoffs to operations.

We need to understand how to manage poor quality in the same way that we need to ensure that the right processes are in place from the outset to, hopefully, obviate inadequate results. I have found that error reduction is an ongoing affair, not just a certification you can earn for the way a project's deliverables were crafted. The attainment of quality is, to some degree, dictated by the environment, so project managers cannot be unfairly saddled with the burden in a demonstrably dysfunctional environment. Expecting projects with specific, detailed deliverables to significantly uplift the quality of dependent legacy systems and processes is a somewhat unreasonable expectation, when, in fact, it is more likely that the environment will dilute the quality of the new deliverables. This is why so much space is taken up in the early chapters of this book offering details on how to hunt down these opportunities for failure, and proactively circumvent them to the degree that is humanly possible.

I recognize that some of these thoughts are politically incorrect, but, as always, I offer a defense for my posturing. The way I see it, the aggressive introduction of quality methodologies into the project environment have two potential downsides:

Processes like Six Sigma originated in the manufacturing environment, where the principles of identifying and remedying systemic error are a near-perfect fit and certainly long overdue from a perspective of productivity, profitability, consumer satisfaction, and the health and safety of producers and consumers alike. Not too many complex IT project activities fit this model.
The second caveat I would use to temper enthusiasm for this process, at least a little, is that its utilization sometimes strikes me as a proxy for common sense.

Using a technology to implement business goals is far more art than science, and requires as much experience and skill as it does process. To the degree that quality methodologies can enhance success, I fully agree that:

Each component of the project experience should be subjected to the best available quality management tools.
The goal to eliminate error in all phases of the initiative, including the automated processes that result from any complex IT project via such methodologies, are similarly welcome.

One wonders if the quality scrubbing processes take precedence over other management techniques and ignores the human factor, exactly where does the point of diminishing returns reside along the project's critical path? I am most comfortable with the application of these quality methodologies as coaching and modeling tools, not as filters through which all project activities and output must be strained.

Those are my thoughts on the topic. You are equally welcome to your own. In the interview process, each candidate's views on this topic are critical, whether or not their skill with, or certification in, any given methodology is important to you and your organization.

16.4.4 Business Acumen

The selection of this section's title is unfortunate if it implies expertise in finance, marketing, and whatever products or services your corporation is best known for. I use it in the far broader sense. After years of working in the corporate environment, one should have learned how to act, how to think, and how to contribute. I mention this because, sadly, I encounter many people who appear to lack this basic footing that good, competent corporate soldiers are supposed to have. It is a kind of common sense born of reacting to and learning from your environment, so when you earn the chance at your first big IT project, you have some political and interpersonal skills that are far, far better than what little you probably brought to the table when you came into this world from college or the armed forces.

< Day Day Up >