PROJECT MANAGEMENT FOR EXECUTIVES

iUniverse, Inc.

Contents

Introduction: Read Me First:..........................................ixSection 1: Perspectives...............................................1Chapter 1: Basic Principles...........................................1Chapter 2: Contrasting Perspectives...................................6Chapter 3: Projects as an entity......................................18Chapter 4: Characteristics of Successful Projects.....................22Section 2: The Look of Success........................................27Chapter 5: What a Successful Project Looks Like.......................27Chapter 6: Key Success Factors........................................33Chapter 7: Create Your Success Framework..............................45Chapter 8: Slogans and Handles........................................51Section 3: Facilitating Success.......................................57Chapter 9: Soft Skills Rule...........................................57Chapter 10: Knowledge Area Topics.....................................66Chapter 11: Managing by Metrics.......................................79Chapter 12: Methodologies.............................................90Closing Comments......................................................95Appendices............................................................97HELPFUL TOOLS.........................................................97Index.................................................................101

Chapter One

These basic principles are sprinkled throughout the book, but I feel they are so important that I wanted to present them right up front. This also makes finding and reviewing them quite easy. So, here you are.

Adding value / Delivering value

Project management was not ordained by God or fashioned from the big bang via subatomic particles. Project management is a completely contrived human endeavor that is intended to add or deliver value. This deserves emphasis because I know that project management has in many industries been a key buzzword for the past couple of decades. Some implement project management rigidly as in "This is THE only way to run projects." In other organizations project management has become ubiquitous; considered like part of the furniture. "Oh, just pull that convenient risk assessment unit over here while we talk about work." "No, no! Don't grab that change management unit. It has squeaky springs, is uncomfortable and people get wrankled over the decisions it forces us to make."

Project management as a completely contrived human endeavor has evolved and is intended to add value by completing work. No one way exists to implement it. In fact, if you can deliver value without it – Great! If your organization has difficulty delivering value, or meeting timelines, or fixing a lot of defects after delivery, etc. then project management implemented well can help.

As an executive you are in an ideal position to actively contribute to adding and delivering value.

Providing what is needed to add value

I like to emphasize that the component parts of project management are included because they work! As a completely contrived human endeavor, change management is included because it works, even if people get wrankled over the decisions it forces us to make.

Adding value requires certain ingredients and processes. As an executive, you are either willing to provide what is needed to add value or not. You really can't expect to add value through work that requires 5 FTE by providing only 1.5 FTE. I see companies and teams ensure adding value by emphasizing foundational processes like building agreement of the project scope, of defining work packages, of interactions and the need for detailed test plans or verification steps.

As an executive, you are in an ideal position to provide what is needed to add value.

Defining work

Defining work is a basic principle because this ensures everyone understands the work in the same way, i.e. the goals, objectives – everything about it. I present examples of agreement and of disconnects throughout the book because this is so important. I've seen the consequences of this in the form of success and conversely in the form of - as colleagues label it - "swirl".

Don't assume everyone understands things the same way, or even your way. Sometimes you may even need several weeks of a planned and coordinated campaign to explain what is intended, to show how it is valuable and build relationships so that others want to be spokespersons for your campaign.

As an executive you need to ensure the work is defined.

Prioritization

Everything really is a matter of prioritization. Delaying projects because you don't have the capital to invest is a legitimate prioritization. Building labs to conduct research and development is a prioritization over other uses for that money. Deciding to use formal, structured processes to control work, i.e. project management, is a prioritization decision. Providing only 1.5 FTE needed to complete the work requiring 5 FTE is a prioritization. You get the point.

As an executive you need to make prioritization decisions that support delivering value.

Time Exchange to Plan versus Fix

The concept of a time exchange to plan versus fix is one of the most important basic principles I have encountered in every work environment and every industry. This is the embodiment of the adage "never enough time to do things right, but always enough time to do them over again."

The time exchange is the "thought prior to action"; the "ounce of prevention versus the pound of cure." The more time spent up front figuring out how to do the work, how to prevent problems, how to sequence work steps, how to get others to be on your side, the less time is needed to fix problems later.

I developed the explanation of a time exchange after several situations where people said "we don't have time to wait and figure all this out", but they ultimately spent more time pausing the work to figure out what to do next than if they had taken an extra two weeks up front to figure it out. I began to present: "Think of this up front work as a time exchange in which you reduce swirl or time throughout the project by spending as much time as needed planning before you begin the work.

As an executive support the time and effort to figure things out up front, as a time exchange to prevent more time needed to fix problems later.

Planning is real work that provides control

As I just alluded, planning provides a level of prevention and a level of control. However, in many organizations planning seems to be considered not real work. "Why are they spending so much time in meetings, drawing diagrams and writing papers? When are they going to begin the work?"

Well, planning is real work. It is fundamental work that facilitates subsequent work.

Even organizations that spend time planning can have a tendency to plan only up to their psychological comfort level; sometimes not completing inevitable steps. I do like to emphasize that experienced project managers don't need to know a particular subject matter to realize that planning may not be complete or that risks may be inherent. This type of inquiry, discussion, and documentation is real work that both subject matter experts and those experienced in managing work need to do.

As an executive you need to actively support the basic principle that planning is real work.

Managing potential problems, changes and risks

Even the best planning can't anticipate all situations, but it can develop processes to handle situations. This is the basic principle. Throughout the book I present examples of how processes can lead to effective resolutions, even for situations not known earlier.

If your organization does not use processes to handle these type of situations, don't sweat! Project management includes these. Why? Because they work. In fact, a real and practical value of project management are the use of best practices for handling problematic situations like something changing or a potential risk actually happening.

As an executive you need to emphasize and insist that processes be developed and used to manage problems, changes and risks.

Letting the Doers Do! Projects as an Entity.

This basic principle is that projects are worked by dedicated teams whose mission is to complete the scope of work. Once the project is defined, planned, funded, etc. and have what is needed to be successful, the team needs to be supported but not interfered. I like to say that the project is now an "entity" that includes scope, processes, people, funding, etc. As such, let the doers do! One colleague refers to this as "self-directed teams." And I think this is a fairly accurate description. After all, they have everything needed to be successful or, if they don't at least they have processes to manage the things they do need.

Unfortunately, projects are often asked to add pieces of work, to do more with fewer people or money; to shorten testing, etc. These are all examples of change and some changes, like shortening testing, also introduce risks.

As an executive you need to support the project entity by providing what it needs to be successful and let the doers do.

Chapter Two

Whether your company is large or small, most of the work is probably organized as projects intended to enhance value or provide new value. Yet projects in many industries either don't complete or complete beyond the established time frame and cost much more than budgeted. This reduces the value the project represents.

Project management truly is all about the work. It is about completing work to add value to your organization. All of your company's processes, metrics, roles, controls, best practices, etc. are focused on one thing: completing work to add value to your organization. Theory and best practices around project management are the result of practical experiences - both good and bad. So with this type of foundation for projects, why should projects not complete and add the needed value to your organization? This book addresses some key reasons. For now, two reasons are:

1. Your understanding of how projects actually operate and

2. Your active involvement with projects.

Now you might ask: "While knowing project management intricacies would be an asset for helping me understand projects, are not project details the responsibility of a project manager? Why should I learn project management?" Excellent point! As an executive, you don't need to know project management intricacies. In fact, they can seem a bit mystifying; like Merlin the magician reciting Latin from his gigantic book of incantations and potions. Rather you need to be able to recognize aspects of projects, such as when someone is changing what the project is supposed to deliver so you can ask questions like: "why is this change happening?" "Who is pushing this or authorizing it?" Similarly, when reading or hearing a project status report you can recognize issues that indicate effective use of time, steps to ensure quality or, recognize a definite risk and be able to ask the team for the steps to mitigate it.

Demystifying Project Management

A key feature of this book is demystifying project management for you. Here is an example of how project management need not be a mystery. Notice the three times recognize is used in the preceding paragraph. Executives without a sufficient "inside out" perspective may not even recognize factors or situations that help or hurt projects. Just being able to recognize such factors will be another tool in your arsenal to add value for your organization.

I'll begin the demystifying process by presenting what I have seen as two somewhat different perspectives of projects by executives and project teams. Often an executive's view of projects is what I call from the "outside looking in." You sponsor work, it gets assigned, you want to monitor status and see results. Conversely, project details are from the "inside looking out" by the people doing the work.

Executives tend to be protective of factors like delivery dates and costs, i.e. when you want work completed and how much it costs. Project teams tend to be protective of their mission – the work they are assigned to accomplish and whether they have the time, people and other resources, and budget. These two perspectives can create substantial disconnects. I want to help you – as an executive - have that project "inside-out" perspective in order to remove this disconnect.

As an executive you probably focus on

• The organizational need for the work or deliverables. • Value to be gained.

• Practical realities of how much time, cost and people you can afford to devote to the work.

In contrast, a project team perspective is that they have been given an assignment – a mission to complete. In order to complete that mission, they need to

• Analyze and plan sufficiently.

• Estimate the time, cost and people needed to do the work.

• Determine dependencies and risks that can hurt the work.

• Have a management champion, like you, to protect their ability to complete the work.

Often, these two perspectives create the need to reach a sweet spot or consensus of what can be delivered for what the organization is willing to provide. At this point, I need to point out that project planning and analysis represent reality – what the subject matter experts have determined is needed to complete the mission. Not understanding this is part of disconnects due to different perspectives.

Here is a graphic illustrating the two perspectives and getting to the "Sweet Spot".

Everything reduces to Prioritization Perspective

Ultimately what projects need to be successful and what your organization provides to the project can be considered a matter of prioritization or importance. How important is the value you want compared to the investment needed to deliver the value?

Based on my experience project teams understand this quite well. In fact as I mentioned, the analysis and planning by projects is specifically to reflect reality then move to reaching the "sweet spot" by showing what can be delivered for what is provided. You may be able to get 70%, 80%, 90% or 100%. I can't assess how well you and other executives in your organization understand this. I simply want to present this as perspective for how to understand projects and view them from the "inside out" so you can get the most value for your organization.

Here is another chart highlighting the underlying issue of prioritization compared to the perspective of executives and projects. Note that these are some things that can happen, not an exhaustive list.

Have you experienced other similar issues that are a matter of prioritization? As an active exercise, take some paper and list situations then reflect on whether these are matters of prioritization?

As another example, one company I worked for readily accepted new work from its sales force with delivery dates that did not consider the company's capacity to complete the work. Evaluating which project was more important, staff vacation schedules, internal support work, etc. was not done. These would just have to work themselves out. The clear message from executives was, the sale/contract is the priority.

Project Flow Perspective

I've heard many people say that project management practices sound good in theory but do not work well in practice. Controls and processes just create paralysis by analysis, too much bureaucracy, etc. I've heard statements like:

"We need to complete work quickly, be agile – you know. We really don't have time to follow project management."

Well, there are two sides to this coin:

• Heads: Don't work carefully enough and costs may continue and may increase well after delivery; whether you deliver a road, software or widget.

• Tails: Add too many processes and your company will spend more time defining and documenting than building the road, software or widget.

I ask people to consider the time spent in planning as a time exchange in which time to fix problems at the end of a project is exchanged to earlier in the project to figure out how to prevent problems. In fact, measurements can be gathered to determine the value of catching a potential problem early rather than fix problems after delivery. This topic is covered in detail in my book "Creating a Project Management Work Environment."

NASA faces risks that may justify the extraordinary time defining processes and documentation. Most other organizations do not face risks of NASA's magnitude. The answer is to have the proper balance for your organization. I also must say that I've seen project management rigor used quite effectively to add value and avoid both paralysis by analysis and the long tail of rework to fix defects. Said another way, project management is a facilitator rather than an inhibitor. This book will help you make project management a facilitator for adding value.

(Continues...)

Excerpted from PROJECT MANAGEMENT FOR EXECUTIVESby STEVE HOUSEWORTH Copyright © 2011 by Steve Houseworth, PhD, PMP. Excerpted by permission of iUniverse, Inc.. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.