Managing Projects Well

Stephen Bender

• Publisher: Routledge
• Year: 2009
• ISBN:
  9781136382390
• Edition: 1
• Topic: Negocios y empresa
• Subtopic: Negocios en general

Few people realise how many projects people actually manage. Or how many of the theoretical approaches to Project Management do not meet the test of the real world.This intensive look at Project Management teaches people what they need to know to lead, or be a member of, a project team. Most Project Management texts deal predominantly with technical areas, leaving readers ill-prepared for the real world. Managing Projects Well looks closely at the behavioural aspects of project management and project team participation.
Managing Projects Well shows: What happens when your boss decides the project's schedule and budget, and you have to work backwards to make things fit
How to communicate and present effectively within and beyond the team
How to cope when you do all the work, and have to manage multiple projects and non-project time as well
How to organise people for success, and develop ideal methods for team member motivation
How to change your own bad habits quickly
What to do when things go wrong More traditional areas of project management, such as planning, organising, leading, and controlling a project, are also covered.Stephen Bender has many years experience managing projects, both small and large. He specialises in teaching professional, technical and clerical staff the techniques of workflow management and project management.

section

1

About projects
and quality

1 A new view of concepts

As I mentioned in the Preface, I was woefully unprepared for the real world of projects. My formal training was excellent: it covered almost 5% of what I needed to know! In my ‘trial by fire’ I learned the other 95%—the hard way. It is this view that I share in this work.

The success of projects depends on many things:

• understanding what a project is and what it isn't;

• knowing clearly the shared vision and tasks for project managers, project leaders, team leaders, and project team members;

• knowing excellent project management techniques; but you must also know what constitutes an excellent product of the project;

• closing the gap between what you say and what you do. To ‘walk the talk,’ you must first get your own affairs in order by managing time and stress, and using planning models;

• working well with others: one-on-one, meetings, facilitation, motivating, problem solving, status reporting, handling criticism or conflict, and delegating;

• being flexible and creative, and

• getting the requirements right.

Finally, you need to have a model to deploy these principles progressively, rather than overdoing it and then quitting.

Well, this seems like quite a bit. In fact, item by item, each of the things discussed in this work are things that you already know something about. Hopefully (except for certain specialised techniques) you will not learn one new thing about projects that you do not already know in some other context. Our purpose is to organise what you already know and put it into a plan of action. This work is not simply a compendium of human resources training materials, it is that subset of knowledge and techniques specifically involved in projects. Once again, if I had this information organised for me on my initial journey, life would have been much simpler. Therefore, let us take a look at the main concepts.

WHAT IS A PROJECT, ANYWAY?

A project is an organised effort to a specific, typically one-time, goal. We will be looking at projects not only in business but also personally, including home life, raising a family—even self-improvement.

It is important to understand what a project is and what it is not.

There are many things that go on in a company, or even in a household, that one does not consider to be projects, for example:

• ongoing operational work, or day-to-day repetitive actions. The structure of the work is known, typically via a series of procedures. While the content may differ, the actions to carry out the content are the same, such as running routine errands, making a meal, or seeking family entertainment;

• customer service actions, once designed, are not projects so long as the work is routine; and

• manufacturing assembly line operations on the shop floor, where the work does not change, even though different cars, machines, or parts are produced.

A project, by contrast, has a specific beginning and an end. In many important ways, no two projects are the same:

• a project has a specific goal. Once the goal is achieved, the project is over;

• a project is finite—it has a specific time period and an end point;

• a project is usually fairly complex and has many details;

• projects are generally one homogeneous unit. Even though large projects often have many phases, components, or sub-components (sub-projects), they form one unit overall; and

• in contrast to repetitive, day-to-day ongoing operations, projects tend to be one of a kind and non-repetitive.

Illustrations of projects include:

• software development activities. While there may be a uniform development methodology, the work might not be repetitive or operational. This is because the nature of the product being developed is different each time. However, the mass reproduction of user manuals or packaging of products such as diskettes or compact disks are not considered to be projects;

• the development of a new or unique machine tool in a job shop operation. Each machine tool is different, and when it is done, it is done;

• the development of a painting by an artist. The development and painting is a project; the mass production of multiple lithographs of the painting is not;

• the design of procedures used in day-to-day customer service operations by bank tellers, help desk attendants or operators, but not the day-to-day operations themselves. While the tasks in the procedure are repetitive, the initial design of the methods is not;

• a research and development activity, even if it leads to an idea rather than a finished product. The nature of the research is different each time, and it results in a specific outcome;

• planning a family vacation to a new or unusual destination—it is neither routine nor repetitive;

• gaining and using a new skill, or completing on-the-job training;

• undertaking new personal growth and introspection with a specific improvement goal in mind; and

• undertaking a major home improvement activity.

A final example: a custom home builder undertakes a project each time they build a new home. Although they may have constructed many homes, each home and each set of circumstances is different.

Products and processes

As we can see from the comparisons, any time you construct a new type of ‘product’ you are running a project. For the purpose of understanding this, we need to define what is meant by ‘product’.

A product is the output of a process. It is not necessarily physical, or even tangible. If a process is an activity, or work, or an action, then a product is the result of such an action. As such, a product can, of course, be a physical thing that is constructed (a home, a piece of software, a machine tool). Because it is the output of a process, a product can also be a customer service action, a meeting, or even a thought—anything that is the result of an activity.

What defines a project is not the product. It is, instead, the fact that the product is unique and non-repetitive.

Some time ago, the content of this book was conveyed in workshop form to a large scientific research and development organisation. One of the participants questioned whether or not their work was a project. ‘After all’, he said, ‘we don't actually make anything’. What he meant was, his work and that of his team, after research, resulted in a single idea—an idea for the consumer product that could be built using the technology embodied in the research. This idea is actually a product, because it is the result of a process (thinking and research). The fact that it is not tangible does not matter. Because of the nature of the research, the work done and the resultant idea is unique, non-repetitive, has an end point, and is expressed as one homogeneous unit. Therefore it is a project.

Project cascading and size

Many times, the output of one project (the product) is the input to another (part of the other's process). For example:

• the research and development activity results in an idea, and this is one project;

• the idea is then used to build a prototype of a new customer product. This activity is a project also;

• the prototype is used to design the operations for the method of mass production on the manufacturing shop floor. The setup of the assembly line, for the first time, and the ‘working out of any bugs’ in the manufacturing operation, is also a project;

• the continued mass production of the customer product is not considered to be a project; and

• any subsequent quality assessment or focus group activity to validate that the product meets the needs of the market and customers is a project.

If projects are all different, how can it be possible to have any kind of a method to make their construction more efficient, effective, and of higher quality? Because although what ‘goes through’ a project activity is different, the techniques, activities and problems associated with vastly different projects can be very much the same. In the same way that a software development project can be governed by a phased methodology that remains the same, so too can projects be governed.

This ‘same kind of things’ approach applies not only to the technical aspects of project management, but also to the human side: staying ‘sane’, managing stress levels, managing your time, leading your people, and being a quality participant in the process as a team member.

Projects can be ‘phased’; that is, broken down to a series of sequential steps. They can also have concurrent sub-elements or modules. These pieces can be very small projects in themselves. For example, many job-shop operations, such as software projects, require sequential developmental phases (requirements, design, construction, testing, and implementation). Also, many complex projects need to be broken down into smaller pieces just to make them manageable. The planning of an extensive family vacation might have concurrent pieces done by different family members: selecting the vacation spot, meeting the needs of all family members, planning travel arrangements, booking reservations, completing office work and cross training others for your absence, allocating savings to finance the trip and expenses during the trip, and so forth.

On the other hand, projects can be very large. For example, I met the person responsible for laying all of the fibre optic cable in the ground, in the whole world, for a long distance communications company. This person had hundreds of project managers working for him. In a sense, his ‘project’ was to coordinate the projects managed by his team members.

Now that we have an idea of what constitutes a project, let's take a look at the players…

A DIFFERENT VIEW OF LEADERS, MANAGERS,
AND EMPLOYEES

Many discussions on projects fail to take into account:

• the actual roles of the project manager;

• the difference between management and leadership;

• additional responsibilities of the project manager; and

• the significant role of the project team members.

The role of the project manager

The project manager, in traditional project management tutorials, is the one who plans, organises, and controls the project. Perhaps it should be stated that the project manager plans, organises, leads and controls a project. If assigned this role, you must accomplish your goals through the efforts of others.

The ‘planning’ piece occurs initially, before the project is actually underway by the team members, and may have to be repeated during the project, especially if there are changes along the way.

The ‘organising’ piece involves allocating equipment, resources, people, money, suppliers, and anything else that is necessary to run the project, based on the plan. This frequently involves coordination with others.

The ‘control’ piece essentially means the comparison of the plan with the actual progress, and making any necessary ‘mid-course’ corrections. This is an often overlooked area of most projects. In quality terms, the planning piece is ‘prevention’ based; that is, it guides the project in the proper direction, and prevents subsequent failures if properly done. The control piece is ‘correction’ based; that is, it identifies variations of the project with the plan, and re-plans based on actual circumstances. Technically, it is true that prevention is more powerful, and better than, correction, if a choice had to be made.

Yet in the real world, it is almost necessary to be better at project controls than project planning, if you were forced to make a choice. Seldom do projects go exactly as planned. The very fact that a project includes elements that have not been done before (by definition) means that there is a certain element of unpredictability, no matter what planning is done.

Many people erroneously plan projects in great detail, omitting contingencies, and then fail to control them. When they notice that the project has gone awry, they simply abandon the plan and ‘shoot from the hip’. The result is an ad-hoc approach to project management with resultant cost overruns, missed dates, and poor quality projects.

While I cannot advocate lack of planning, a person who plans but does not control is in worse shape than a person who controls without planning. In the latter case, at least the project is continuously re-oriented to the real-world facts and events of the day. Obviously, both planning and control are nece...

Table of contents

• Front Cover
• Half Title
• Title Page
• Copyright
• Preface
• Contents
• Acknowledgements
• SECTION 1 About projects and quality
• SECTION 2 Getting your own house in order
• SECTION 3 Getting other’s houses in order
• SECTION 4 What they don’t teach you in project management school
• Epilogue What do I do on Monday?
• Index