Preface | Complex IT Project Management: 16 Steps to Success

< Day Day Up >

Some 15 years into my IT career, or 5 years ago as of this writing, I awoke one morning with a feeling that I needed to reassess the approach I took to being a technical project manager. By then, I had participated in dozens of projects and played nearly every role while doing so. I had developed and sold projects, provided technical design and implementation expertise, managed many initiatives, and held operational management responsibilities for technologies and processes that sprung from projects I alternately did and did not have a hand in.

I enjoyed a reasonable amount of success, at least enough to be winning assignments in increasingly complicated, expensive, and high-profile initiatives. To put this in perspective, the budgets of my projects went from six to eight figures, that is to say into the multimillion dollar range. Fortunately, along with that came a gratifying increase in my income and standing in the professional community, which itself had transitioned from Tampa to Dallas to New York City. These were the booming 1990s, when money flowed freely, projects were ambitious, and the belief that technology could solve all business problems was often advanced with an evangelical fervor.

Not that everything was a breeze, mind you. As projects increased in size, so did the challenges of dealing with multiple technologies, a much broader stakeholder base, and increasingly testy politics. What led to the decision to take a hard look at my own performance was the burgeoning discomfort I felt at work that my professional life was overly chaotic and difficult to manage. Although it was easy to blame the environment and the challenging individuals who always seem to pop up in it, I knew in my heart that the only thing I could make better was my own behavior. And that, I came to believe, could stand some improvement in its very nature.

Simply put, I decided that I was far too reactive. Perhaps it is equally accurate to say that I was too one-dimensional. I would take a project, get a sense of its mission, and barrel (and occasionally bully) my way toward the finish line. I believed that I was intelligent and aggressive enough to handle problems as they came up. I further believed that I possessed enough will power to steer any initiative back on course, no matter how close to the cliff's edge it got. The nature of reality is such, however, that no individual, not even the corporate CEO, in my opinion, can reasonably expect to be successful with this strategy. The business environment in which IT projects take place is far too complicated and unpredictable for that. Besides, as human beings, we are not always as alert or rational as we would like to believe, and certainly not as clever.

I promise not to turn this into the story of one man's personal journey, but I will share some observations that evolved into the ideas and practices that serve as the book's foundation, not to mention my professional behavior. To paraphrase the Declaration of Independence, which, if you think about it, was the scope statement for the project of creating these United States, I hold the following truths to be self-evident:

All projects have a certain rhythm or flow from beginning to end, almost irrespective of the project's nature. This includes technologies, corporate culture, and the personalities of critical stakeholders.
As a consequence, the project manager's challenge is to understand this process and be prepared with certain strategies or tactics to guide the project toward the most practical and realistic definition of success.
A majority of the challenges to project effectiveness are not only predictable, but are to a large degree avoidable, or can be minimized, with the appropriate and timely application of these strategies and tactics.
The project manager cannot guarantee the success of his or her project because, after all, this is not a perfect world. We can make sure that we understand our jobs, however, and do them to the best of our ability, thereby holding up our end of the bargain.
Although we cannot force stakeholders and the environment to behave as we would like, we can anticipate the likely breakdowns that I, at least, seem to experience over and over again as I progress from one project to the next. Anticipating trouble, and knowing how to react to it, is a very powerful tool that is not as intuitive, or requires as much prescience, as some people think.

As you shall see, I love solving problems. My approach is to break them down into little pieces. Then I examine the surrounding or underlying assumptions that are the likely root causes of that problem, and I attack them methodically, even though patience is not my strong suit. The problem I took on in my own regard, and now present in this book, is how to be a superior project manager particularly well suited for guiding complex information technology (IT) projects from start to finish. I unearthed and examined myriad assumptions about project management that I would wager I shared with most, if not all, project managers. I invite you to look them over, and ask yourself whether it is possible that believing any of them has led you astray, and may in fact prevent that achievement of project management competency.

Those responsible for deriving requirements and the subsequent technical designs will be sensitive to the business drivers that led to scope, and they will remain faithful to scope throughout the project.
Beneficiaries (i.e., those persons targeted to benefit from the project) will be loyal, enthusiastic, supportive, and noninvasive project by-standers.
The project manager will succeed to the degree that he or she has a proven track record and expertise with some, and preferably all, of the project technologies.
Risk analysis is a sidebar to, not a core element of, the planning process.
The project plan is the schedule of events leading up to completion.
Your team leaders will put project needs ahead of their own agendas.
You can expect respect and cooperation simply by possessing a leadership title.
Senior management will move heaven and earth to nurture and protect your project, which they hold in the same regard and view in the same light as you do.

When I examined past projects from a lessons learned perspective (i.e., asking myself what could have been done better and how), I kept circling back to my own expectations about how stakeholders and beneficiaries should have behaved, but did not. The assumptions listed previously capture most, but not all, of these expectations. If you play this expectation game long enough, you eventually get around to asking yourself why you had a particular expectation and whether or not it was realistic.

Perhaps the first time I was disappointed by the disposition of an expectation of this nature, I faulted the individual who failed to meet it. This was not necessarily a derogatory thing. That individual may have been overloaded with tasks, poorly trained, or had troubles at home that clouded his or her performance. After the same expectation and others failed repeatedly over time, however, I started connecting the dots. I recognized that perhaps it was not the case that Jack and Marie failed to meet my expectations. What appeared more likely, on reflection, was that neither of them agreed with me on that expectation. More significant, it dawned on me that my holding these expectations of others in the first place might, in fact, be the real problem.

You may be scratching your head on this one, wondering how the failure of a reasonable expectation could be the project manager's fault. I submit that when you look at it long enough in this manner, it does make sense. If I have a certain expectation, that quite naturally impacts my own behavior. If I think Joe is doing his job, I do not worry about the output of his job (i.e., whether the quality is good, deadlines will be met, and so on). In other words, I take it on faith that an expectation will come to pass, and I have no responsibility for it other than to give it a cursory inspection. On the other hand, if you have come to acknowledge that this expectation game is perhaps naïve, would it not be reasonable to ask:

Why do I think Joe is doing his job?
Do I know what Joe's job is?
Does Joe know what his job is?
Is Joe capable of doing his job?
Is Joe motivated to do his job?
Does Joe have the necessary time and tools to do his job?

I am not saying that if Joe fails, ipso facto it is my fault because I am his project manager. The challenges inherent in managing complex IT projects are more sophisticated and occasionally more sinister than that. By the way, I will not solve this problem of managing Joe in the preface of this book. What I will say is that this sort of thinking pointed me in the direction of the process I eventually concluded would successfully attack the problem of being an excellent manager of complex IT projects. Boiled down to its essence, the process looks like this:

I will understand the environment in which my project must operate because the project will be far more than the sum of its technical deliverables.
I will carefully develop the requirements. These are the conditions the project must create to successfully implement scope.
Technology is a wonderful thing, particularly if it is properly applied in support of these requirements.
Being able to articulate how the project will unfold is a prerequisite to scheduling.
I will identify the most disruptive risks and develop Plan Bs that indemnify against, or minimize, the deleterious consequence of any that come to pass.
Avoiding unnecessary or confusing detail while clearly outlining the critical path is the key to creating a great project schedule.
The right relationships, a great sense of anticipation, and speedy issue resolution skills are the critical success factors for managing the project once it is under way.
Managing project information through a formal documentation process with the attributes of brevity, timeliness, and veracity is important for many reasons.
Understanding and managing the budget involve politics as well as arithmetic and should be approached like any other potential risk event.
Leveraging vendors is not always easy, particularly if their participation in my project involves a key deliverable or represents a significant dependency.
Understanding the operations perspective is the first step of many regarding handoffs of my creation into the IT production world.
Similar to good parenting, project management requires the right blend of flexibility, firmness, and a curtailed ego when dealing with team members.
Objections and scope creep are two of the problematic areas for which one must prepare when dealing with customers and beneficiaries.
Understanding how and when to involve my manager requires savvy and tact and should be based on a realistic appraisal of certain attributes he or she possesses.
The reason why lessons learned are included in traditional project life cycle methodology is to continually remind me of the reflective and adaptive nature of my job.
Effective project managers possess certain attributes against which I can evaluate myself as well as the candidates I interview for project managers on my team.

These are the 16 Steps I follow with the intent of being that outstanding project manager and, coincidentally, represent this book's high-level outline. A chapter is dedicated to each step. I tried to follow the same format for the steps, in which each one is:

Rationalized (i.e., connected to our overall goal)
Illustrated with real experiences to show how to apply each step to best effect
Explained, to show the value in each step and the downside to skipping it

Because the book is organized along the temporal lines of real-world project flow, the important ideas are carried forward and revisited often, as are many of the supporting examples. This mimics the iterative process of complex project management. So much of what we do, we redo. Initially, we seek definition, then clarity, then redefinition and validation when implementation cries out for mid-course corrections to accommodate the shifting realities of the complex project world.

I made one basic assumption about the readership I targeted during the better part of the 3 years it has taken to compile this book - a population, for your information, that I work with every day. I confess to a complete and total ambivalence regarding the value of project managers having considerable technical skills, no matter how current they might be. In my experience, the complex project manager is equally likely to have or lack a strong technical background. In fact, because organizational, communication, and relationship skills are so important in this job, it is not unusual to find that good management type leading a big project.

I also need to define complex projects as initiatives that have many of the following characteristics.

Multiple technical disciplines are called for to deliver requirements.
The budget well exceeds a million dollars.
A half-dozen or more subteams are engaged for design and implementation.
Dozens of timekeepers can charge significant hours to the project.
The project addresses a broad-based, diverse, or highly dispersed beneficiary community.

I would not discourage anyone from reading this book, regardless of prior experience. I have consolidated a huge amount of information into useful strategies or tactics and look forward to learning more each day I start my predawn commutes to New York City. Having said that, I targeted this book, from an experience perspective, at those project managers who, although perhaps rookies in the Big Leagues, have served in the past as team leads or led smaller projects. That profile puts you somewhere near where I indicated I was along the career continuum when I began this narrative. Further, I assumed that you have some Project Management Institute (PMI)-type training or certification, or are degreed in project management. I tip my hat to you on your achievement, which I also mention to benchmark the level of terminology and project life cycle knowledge I believe your education implies.

Probably the most important driver for me as this book's author was observing so many project managers (besides myself) struggle with the job, and the gap between the realities we face and the project management methodologies we have been taught. One of my goals, therefore, was to produce a book that would facilitate a drill down into the practical aspects of implementing best practices in the workplace. I leave it to you, and I welcome your feedback to determine how well this and my other goals were accomplished.

The other kind of reader I targeted is anyone at the sponsor or senior management level who supports large projects within an organization with an interest in understanding the project management process, if for no other reason than to improve the ability to select project managers to handle these complex initiatives. To that end, Chapter 16 is particularly relevant because it highlights the attributes that strong project managers typically possess.

Finally, I must take a moment to offer my gratitude and thanks. Many individuals out there have taught me much, whether they intended to or not. That may sound like a backhanded compliment. Perhaps it is. I definitely wish to single out three people. The first is my wife, Carol, who provides never-ending support and joy. In fact, it was she who suggested I write this book and served as my barometer for lucidity, based on her superior command of the English language and her equally longstanding tenure in the IT world. I also acknowledge my parents, who encouraged me to question everything while simultaneously reaching for the stars.

I thank you for taking a peek at Complex Project Management: 16 Steps to Success. I have made every effort to make it worth your while to keep reading, so let us get to it.

Peter Schulte

< Day Day Up >