My Mind, My Heart, My File

Preface: Successful Project Management
Although managing projects has been going on for thousands of years, the practice has only recently been recognized as a discipline in its own right. Suddenly master’s-level degree programs are springing up at schools throughout the world, and certificate programs are being offered as well. Not only that, but some organizations have begun to ask their contractors to provide only project managers who have been certified as professionals by the Project Management Institute, the professional society for practitioners. In today’s fast-paced world, organizations that practice sound project management methods have a competitive advantage over those who fly by the seat of the pants. Why? Because competition is rapidly becoming time-based as well as cost-based. That is, if you can get a product or service to market faster than anyone else, you have an edge on your competition. Further, if you can control the costs of your work better than others, you can sell your products or services at lower margins; “sloppy” management requires that goods be sold at higher margins in order to make sure the business is profitable.
What if you aren’t dealing in products or services? The same principle applies. If you are nonprofit or a government agency, you face competition from others who might be able to do your work more efficiently (and at lower cost). In short, we must all learn to work smarter, not harder, in order to survive into the twenty-first century. Managing projects better is one way to achieve that result.
This book gives you a fast-track approach to managing your own projects. You will learn the essential steps in setting up project plans, scheduling your work, and monitoring progress/exercising control to achieve desired project results.
The approach outlined in this book is based on what is considered best practice by experts in the field. If you
follow the methods presented here, you will increase the probability that you can meet critical performance, cost, and schedule targets. Admittedly, there is a lot more to project management than can be presented in this short book, but if you learn the essence of the tools, you can go on from there to increase your skill.

See detail : Fundamentals of Project Management

Problems and Solutions

SOME PEOPLE LIKE TO HIDE FROM PROBLEMS. THEY CALL THEM ISSUES OR concerns. I like to be more straightforward. A problem is a problem. And when I recognize that, I put it on a schedule to fix it. As soon as I do that, the problem becomes a project.

A good project manager is like a doctor—we diagnose problems before jumping in to fix them.We will learn:

_ To understand the different parts of a problem

_ Several tools to investigate and define problems

_ How to turn a problem into a project

_ How to make sure your solution works

What Is a Problem?

If I have an old car sitting in my garage and it doesn’t run, then the fact that it doesn’t run is not a problem. But if I own only one car and it doesn’t run, then that’s a problem. A problem is something that gets in the way of what we want to do. If we have something we need to use and it’s broken, that’s a problem. If something is blocking the path to where we want to go, that’s a problem. So, the time to define our problems is after we’ve defined our dreams and opportunities.  Now, we’re going to define the problems that get in our way and turn them into projects.

Right and Wrong Questions

There are a bunch of wrong ways to approach problems and they’re all about blame. Blame asks questions about the past, but only to point fingers. “Who did this?” “Who made this mess?” Those kinds of questions don’t get us anywhere. Instead of asking, “Who?” if something isn’t working, ask, “What?” and then ask, “Why?” “What happened?” “What’s wrong?” “Why did this happen?” Those are useful questions.

Another way to avoid blame is to focus on the present and the future. Once we understand what happened, we shift from the past to the future and ask, “What can we do to fix this?” Then “Who?” can be the right question: “Who is the best person to fix this problem?” And he or she might just be the person who made the mistake.

The Parts of a Problem

A problem has some or all of these five parts:

_ a crisis

_ a symptom

_ a consequence

_ a cause

_ a root cause

If there is a crisis, we take care of that first. Then we look at the symptom. We separate the symptom from the consequences of the problem and we evaluate the consequences. If the consequences are costly enough, then we decide the problem is worth fixing. Otherwise, we choose the least expensive solution—

live with it! If we decide to fix the problem, we look at the cause and the root cause. Understanding those will help us develop the best solution. Let’s take a closer look at each of these ideas:

_What makes a situation a problem? A situation is a problem only if it gets in the way of doing what we want to do. Some people can make big problems out of situations of no real consequence, making mountains out of molehills. Business problems basically come in two forms: barriers to ongoing business and barriers to realizing new opportunities.

_ A crisis requires urgent attention. Sometimes, part of a problem requires immediate action: if we don’t do something, things will get worse. We take care of a crisis so we can buy time to fix the problem. All crises are problems, but not all problems include a crisis.

_ The symptom tells us about the problem. The symptom is something we can see or smell or measure that tells us that there is a problem. Where there’s smoke (symptom), there’s fire (cause). Doing something about the smoke does nothing at all. We have to look deeper than the symptom to find the cause. Then we can make a real difference.

_ The consequence of a problem is the unwanted results if we do nothing. When we describe a problem, the consequence is the possible future of the problem. If we solve the problem, we won’t have that unwanted consequence.

_ The cause is the center of the problem. The most basic project is to define the cause of a problem and change that cause so that the problem stops happening. Sometimes there’s more than one cause that we may have to fix.

_ The root cause is the cause of the cause. Sometimes, we solve one problem after another, yet the problems keep coming back. It’s just like pulling up dandelions: if we don’t remove the whole root, dandelions will keep coming up. If we can find and dig out the root cause, then the problem will never happen again.

_ A permanent preventive solution puts an end to a root cause. If we remove all the dandelion roots from our garden, then the dandelions never grow back. If we remove all the root causes of our problems from the way we work, then our problems don’t come back. When we encounter a problem, our first question should be “Is there a crisis?” If so, then take care of the crisis. If not, then examine the problem before you try to solve it. If there’s no crisis, we’ve got some time to understand the problem and come up with a really good solution. When we can describe a problem’s symptoms, consequences, and causes, we can say that we understand the problem.

Source : Project management for small business made easy / by Sid Kemp.

An introduction to the concept of quality

This chapter introduces the idea of quality, which in a sense is an odd idea because it raises the question of whether quality should be a distinct area within project management, rather than quality pervading all areas of it. The chapter begins by answering this question in terms of general management, and then proceeds to set an approach to quality management for projects. Just like the other chapters in this book that cover the knowledge areas in project management or the process groups, this chapter follows the PMBOK approach to project quality management. The PMBOK approach is consistent with the world’s main quality management practices, including:

·         ISO 9000 series.

·         Iskikawa.

·         Deming.

·         Juran.

·         Crosby.

·         Six Sigma.

·         Failure Mode and Effect Analysis.

·         Voice of the Customer.

·         Cost of Quality (COQ).

·         Continuous Improvement (CI).

·         Total Quality Management (TQM)

For a summary of the key features of four of these, see Table 8.1. The PMBOK approach is also consistent with the approaches to quality espoused by:

·         Def Stan 05-97

·         Review, Learn and Improve (RLI).

·         Lean Quality.

·         House of quality.

·         Quality Value Added (QVA).

·         Zero Defects (ZD).

·         Baldridge.

·         John Boyd/OODA loop.

PMBOK adopts unmodified the ISO definitions for key quality management terms (in recognition of which we use ‘ISO says’ boxes in this chapter where appropriate, rather than the ‘PMI says’ boxes). It is not surprising that the list of compatible approaches to quality management is so long, and we have named only a few, because they are all trying to do the same thing. They are worth listing because sometimes as a project manager you may encounter a low-level executive with nominal responsibility for projects or for quality who will try to argue that the approach to quality management that you want to take on your project is incompatible with some mandated standard. One cannot be too sceptical of this type of claim – if you encounter this problem, ask to see the evidence and insist on seeing the details of the argument. The authors’ experience of quality management, after a slightly sceptical start, is that there is a great amount in the ISO 9000, PMBOK and other approaches to quality management that can add real value to projects and their project managers, if used intelligently.

Quality is an odd thing to manage. Surely the whole point of management is to do a quality job? As someone once said, if a thing is worth doing, it is worth doing well. And real-life pressures and incentives mean that Oscar Wilde’s rejoinder, that if a thing is worth doing then it must also be worth doing badly, is not a factor in management. The question is why have a separate angle on management, including project management, just for quality? Should it not be part of everything we do in management, in business, in government? Let us dispose of a completely uninteresting answer to this question quickly, and then give the real and more substantial answers. The uninteresting answer is that we have a separate field of quality management in project management, or in management generally, because there are standards such as ISO 9000 which we want to comply with. This tick-box answer is not a proper answer to the question.

The question is important because if we are to have quality management as a separate part of project management then there will be a substantial cost, if only in your time as a project manager. That cost must be justified if a project manager is to be asked to spend time on quality management, and the PMBOK and other approaches to project management do ask that. There are two kinds of answer to the question, both of which are different sides of the same coin, so to speak. One answer starts with human nature, the other with the problems of complexity. The reader may be concerned that we have not yet defined what quality is. Let us proceed in answering the question using whatever intuitive notion we have of what quality means, and later we will come to a formal definition.

Most people, especially in business, are perfectionists. They naturally want to do a high quality job, other things being equal. It is difficult to maintain one’s motivation, sense of purpose and pride in one’s work if one deliberately tries to do a bad job. There are, however, a number of reasons why even the most able and energetic person may produce a high quality piece of work. And think – who decides what quality is? In project management, as in all business, it is the customer, the organization or person or team for whom the project is being done, not the team or person doing the work, who decides what is to count as a good job, that is, what counts as quality. Some of the reasons why good people working hard to the best of their ability may not produce quality work are as follows:

·         The customer’s requirements were not understood.

·         The customer’s requirements were understood but were not possible to achieve.

·         The customer’s requirements changed.

·         All other requirements were met but at much greater cost than was necessary (i.e. the implicit cost requirement was not met).

·         The people doing the work lacked the techniques, experience or skills to do the work well.

·         The work was done in a way that did not last (i.e. the implicit requirement for persistence was not met).

·         The final result met quality expectations, but the way it was done upset or disappointed people.

·         Everything worked out with respect to quality, but the people doing the project were physically or mentally injured in the process.

All of these possible causes of quality failures are consistent with people trying to do a good job, and the last one, perhaps in extreme cases killing oneself through the sheer effort to do a good job, arises precisely from trying too hard to do a good job. Is that a quality failure? Yes, the quality of life of the project team is ruined, and as we shall see the scope of quality management includes more than just the quality of the final deliverable.

Having started from a consideration of human nature, we can see from some of the bullet points above how the problem of complexity also affects quality. When a project is complex, for example it has many stakeholders and a deliverable with many features, it may not be clear what constitutes quality. An excessive focus on satisfying one dimension of quality, say ease of use, may compromise another aspect, say flexibility of use. Quality management is a tool which helps to manage this trade-off.

We finish this introduction by considering why quality should be treated as a separate angle on management, including project management. Let us answer this from the point of view of management generally, as the answer translates readily into project management terms. Management (and project management too) is a unified whole. Financial management is part of management, as is managing people and legal and regulatory management, in the following way. A manager cannot make decisions of strategic importance, or decisions about the general direction and management of an organization, exclusively on the basis of financial factors, while ignoring human factors and legal or regulatory issues. All the different aspects of management need to be considered, certainly at senior management levels and usually at middle management levels, and also in project management. By dividing up the large and difficult subject of management into distinct subject areas – people, finance, leadership, legal and regulatory, marketing and sales, and so on – we are able to make a better job of it. Quality is simply one of the areas within management.

Having set the scene for quality and introduced the notion, let us move to a formal definition of quality within the specific context of project management.

Source : The Definitive Guide to Project Management: The fast track to getting the job done on time and on budget, By by Sebastian Nokes; Sean Kelly

PROJECT MANAGEMENT

Just as events throughout history have required management and leadership, many have required what has become known as project management. A project is a temporary undertaking to produce a unique output subject to limitations such as time, people, and other resources. Projects have occurred all through recorded history. Construction projects have included the pyramids of Egypt, the great cathedrals of Europe, and the temple at Machupicchu. Research and development projects included the creation of metals during the Bronze Age and the development of war implements during many ages. Projects were conducted to wage war and to build civilizations. These examples all qualify as projects since they were temporary endeavors that created unique outputs subject to limitations. It is highly unlikely that the people performing these projects shared lessons about what worked since they were generally separated by distance, time, and war. Because there was no open sharing, however, project management did not exist as a formal discipline.

The resulting lack of professionalism in early project management can be highlighted by asking questions about the success of these projects: Was the output produced efficiently and effectively? Were any of the limitations exceeded? Were the “customers” satisfied? What did the stakeholders think of the project? While we may never know the answers to these questions, we can guess on some of them. Some of these projects required the efforts of thousands of people (often slaves). Some required large amounts of time—more than a century in some cases. Many of the project participants (especially slaves) were probably far from satisfied with the work demands placed on them. The outputs of some of the projects were probably successful, but the outputs of others certainly were not.

Management principles that had developed previously applied generally to ongoing operations. Projects are different in that, once their objective is achieved, they are (or should be) disbanded. The temporary nature of projects created different kinds of management challenges that were increasingly not being met using traditional management principles alone.

By the middle of the twentieth century, many began to believe that there must be a better way to achieve the desired results of projects. With the advent of World War II, the demands of war required that projects be completed very rapidly. Shortages of people and materials required the careful use of resources. In 1957, the Soviet Union successfully launched a satellite, Sputnik. This event signaled the need for a wide range of new developments that are collectively known as the Space Race. The desire for a successful moon landing translated into a very large project with specific goal and time limitations. The need for project management became crystal clear.

In 1969 the Project Management Institute (PMI®) was organized to allow project managers to share experiences. The premise behind PMI® is that projects share certain similarities regardless of size, complexity, or industry, and that the skills needed to manage projects are fundamentally different from those needed to manage ongoing work processes.

In the 1970s, much effort was spent developing cost and schedule controls and automated project management software. In 1987 PMI® published the first edition of A Guide to the Project Management Body of Knowledge (PMBOK®). The PMBOK® continued to develop and broaden with increased emphasis on topics such as risk, quality, human resources, and communications. The most recent addition to the PMBOK® is project integration—tying together all the project areas into a unified, workable plan.

In the 1990s, project management increased its focus on communications, team building, leadership development, and motivation. The specific areas in which the project management discipline increased its focus during the 1990s include:

• Stakeholder identification and management

• Project team member competency and commitment

• Interpersonal/behavioral aspects

• Communications and communications planning

• Performance measurement to specifications/objectives

• Integration of core and ad hoc team personnel

• Project management as a career path.

Definition of Project Management

So what is this thing called project management? Understanding it requires the definition of a project. According to PMI®, “A project is a temporary endeavor undertaken to create a unique product or service”.^[11] This brief definition suggests several notions. First, because the output is a unique product or service, project personnel must develop a thorough understanding of what that output is, along with the limitations and risks that will be encountered in trying to achieve it. Second, because a project is temporary it must be handled differently from an ongoing operation. In particular, the project lifecycle must be understood. Finally, both the temporary nature and the unique output of a project create the need for alternative forms of organization and for unique project skills and tools.

“Project management is the application of skills, tools, and techniques to project activities to meet project requirements”.^[12] This requires project managers to understand the project objectives, limitations, lifecycle, and roles of the participants. It also suggests that project managers should possess a variety of essential skills.

Every project has an objective, that is, a reason for performing the project. This objective can be implementing a new computer system, constructing a building, merging two companies, or developing a new product. Each objective has two considerations: scope (the features that are included) and quality (how the output performs).

Every project also has one or more limitations on how well and how quickly the objectives can be achieved. These limitations frequently include budget, resources, time, and technology. The limitations create risks that the objectives may not be met; these risks need to be identified.

Project Lifecycle

Unlike ongoing operations that continue indefinitely, projects are temporary and have lifecycles. A project lifecycle can be used to guide a project team through all the necessary work. Some industries have their own, highly detailed project lifecycle models. However, a simple four-stage model (shown in Figure 1-6) can be used to explain the concept.

Figure 1-6: Project Lifecycle Model

The first stage, initiating, starts with identifying a potential project. Initiating activities include establishing the need for the project, understanding the project scope, approximating the time and cost required, and securing approval to plan the project in detail.

Once approval is granted, the project enters the planning stage. Many additional details are planned, some team members are added, and approval to perform the project work is granted.

The third stage, executing, is when most of the project work is accomplished. The project team is at its maximum size. Activities are directed, monitored, and controlled. This stage ends when the project customer accepts the project output.

The final stage—closing—occurs when workers and other resources are reassigned; the project is evaluated and administratively closed.

Several distinct roles are required for projects. A project manager is responsible for ensuring that the objectives are accomplished. This requires facilitating the project team, dealing with problems, making decisions (often concerning tradeoffs between the project objectives and limitations), and communicating with all other parties. A sponsor (usually an executive) guides the project manager and helps behind the scenes with overcoming obstacles. The project team determines the details of how the work must proceed, performs the work, and reports progress. Stakeholders are those who have an interest in the project. The primary stakeholder is the customer of the output, but many other parties also have interests in a project. For example, neighbors at a construction site may have concerns about noise, dust, and traffic.

A project manager must possess a variety of skills to achieve the project objectives. According to Kloppenborg and Mantel (2001), these skills can be grouped generally into six categories: planning, budgeting, scheduling, resourcing, monitoring, and controlling.^[13] While managers of ongoing operations also need to perform tasks related to each of these six categories, the methods by which these must be performed on projects are different because of the temporary nature and the unique output that define projects. Many project-specific, specialized skills in these areas have been developed over time.

^[11]Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 2000 edition (Newtown Square, PA: Project Management Institute, 2000), p. 4.

^[12]Ibid., p. 6.

^[13]Timothy J. Kloppenborg and Samuel J. Mantel, Jr. “Project Management”, The Concise International Encyclopedia of Business and Management, 2nd ed. (London: Thompson Press, 2001), p. 5438.

Source :  Project Leadership By Timothy J. Kloppenborg , Arthur Shriberg , Jayashree Venkatraman

The Project Management System
The project management system consists of seven components, as shown in Figure 1.4. If any one of these is defective, then the management of projects will suffer.

The Human System
The human system is placed at the bottom of the pyramid because it forms the foundation for everything else. A project manager must deal with all the “people issues.” These include communication, team building, conflict management and resolution, motivation, and, yes, that “dirty word” politics! The list covers only a handful of the issues that must be handled.
Dealing with people is a major function that a project manager must perform. This is partly because project managers have a lot of responsibility and (usually) very little authority (or none at all). That is almost a given in project management. So the only way to get anything done is through using people skills. These include persuasion, influence, negotiating, and sometimes just plain begging.
I can almost hear the groaning now from the techies. As a former engineer, I know that the human element is not typically one of our strong suits. In fact, some techies complain bitterly that they hate the people problems they have to deal with. To them, I suggest that they rethink their careers. They don’t want to be project managers. Or any other kind for that matter. You are not likely to be good at something you hate, and in my view, life is too short to spend doing something you hate. Also, you can’t get around it.
So if you hate dealing with people, have a heart-to-heart talk with your boss and state up-front that you don’t want to be a project manager. You would rather be a techie for the rest of your life. If that doesn’t work, change jobs! I’m serious. But then it’s your life, and your career, and you have to make your own choices.
If you are one of those individuals who don’t actually hate dealing with people, but feel that you need to improve your skills, then hang in there. Everything listed in the box in Figure 1.4 can be learned—even leadership.

Culture
Related to people issues is culture. Every organization has a culture, which is the sum total of values, beliefs, attitudes, behaviors, and traditions. In fact, one way you can tell when people are talking about culture is that they say, “We don’t do it that way around here.” Broadly speaking, there is nothing right or wrong, good or bad about cultures. But when people from different cultures interact, it often results in misunderstanding, conflict, and downright fighting. Perhaps a few examples will help. My wife and I have hosted exchange students from several different countries, for 10 months at a time,
partly because we are interested in cultures. Our first guest was a Japanese student named Yukiko. When she arrived, I asked her how to say things in Japanese. “Well, yes is hai, and no is e-a,” she said, “but we don’t like to say no very much.” At the time, I didn’t fully appreciate what she was telling me. Later I learned that the Japanese consider saying no directly to be fairly rude. For instance, I was in a Japanese restaurant one evening when a fellow customer ordered a beer by name. The waitress, who was Japanese, said, “Maybe we don’t have that kind. Maybe you’d prefer a different kind.” Now she knew very well that she did not have the beer he asked for, but she could not say so directly. She had to soften it a bit.
The “roundabout no” is very mystifying to Americans, who are used to being direct. So we sometimes get into trouble with Japanese business deals. “I thought we agreed on this,” says the American negotiator, after finding an apparent violation of what she thought was agreed to. “Oh, we agreed on this,” says her Japanese colleague. Such misunderstandings can be a serious source of conflict. My favorite experience with culture shock occurred in Malaysia. After I completed a day of teaching at Petronas, the oil company, a company driver pulled up in a van to take me to the airport. I started to get into the back seat, which is common in the United States. He looked back at me and said, “Sir, you’re kind of fat. You’d be more comfortable up here in the front.” It was all I could do to keep from laughing. Fortunately, I had done my homework and I knew that tomany people from Asian cultures being fat is not a stigma, as it is in our American “twiggy” society. It is actually a sign of affluence, because over several thousand years, only the wealthy could afford a diet that would allow them to be fat. What I found funny was to imagine my driver taking a job with a U.S. limo company and doing to some unwary person what he did to me. The person complains and the driver gets fired for insulting the customer. He is totally bewildered. “What happened?” he says, “I was only trying to be helpful.” Which he was.

Organization
Every organization must define the authority, accountability, and responsibility conferred on each member of that organization. As I mentioned previously, project managers always have a lot of responsibility and little authority. It has almost always been that way, and probably will continue.

However, there are two kinds of authority. One is to tell people what to do and expect them to do it. That one a project manager will never have. And it doesn’t matter very much in the first place. Ask any CEO of any company, “You have a lot of authority, don’t you?” The reply will be yes. Then ask, “Does your authority guarantee that people do what you want done?” The response turns to no. Then what does persuade people to do what a CEO wants? Every CEO I have asked has said, “In the end analysis, people have to want to do it, and my job is to get them to want to do it.” I call that influence.
If a CEO has to use influence to get things done, you and I can hope to do no better. That’s why you need those people skills listed at the bottom of the pyramid. The second kind of authority is decision-making authority. This one I consider a major problem for many project managers, especially when it comes to decisions to spend money. Some project managers can spend no more than $100 without approvals. Yet they have project budgets of hundreds of thousands of dollars. They are being given mixed messages by their companies. The first message tells them, “We trust you, because we’ve put you in charge of a project that will spend a lot of our money.” The second message, however, is, “If you want to spend any of it, you have to get it approved first.” To me, this message says, “We don’t trust you.” Now when two messages differ, the negative one takes priority over the positive one. In other words, these managers are being told that the company doesn’t trust them. If you follow my process for managing projects, you will find that the implementation plan must be approved, and this plan will include a budget for the project. After that, so long as the project manager is spending in accordance with the already approved plan, why should any more approvals be needed? Doing so is a total waste of everyone’s time.

Methods
Methods are the “tools of the trade.” For project managers, the only issue that usually comes up here is scheduling software. I fully understand the need for some standardization in organizations, because information systems (IS) departments can support only so many software programs. However, one size does not always fit all—in clothing or in software—and insisting that everyone use a low-end package will cause major problems for managers of very large construction projects. Alternatively, insisting that everyone use a high-end package because a few people manage large projects is to provide everyone with a sledgehammer when only a mallet is needed. One solution to this problem, adopted by a few companies, is to have one person do all scheduling for a group of project managers. That way the scheduler can become intimately familiar with the high-end package, and all that the project managers have to know is its capability. The approach works very well and saves a lot of money. Furthermore, it frees project managers from the drudgery of long hours at a computer trying to massage a schedule, and it allows them to concentrate on the important things that they should be doing, such as dealing with political issues.

Control
For the moment, we will skip to the top of the pyramid and then backtrack. When you get right down to it, the reason for managing is always to maintain control. You are expected to control the application of scarce resources to achieve desired objectives. The question is, how is this done?

con • trol: Control is exercised by comparing where you are to where you are supposed to be, then taking corrective action when discrepancies are found. The answer is partly provided by the definition of control.

Control is exercised by comparing where you are to where you are supposed to be, and taking corrective action when discrepancies are found. It is clear that this is a feedback systems definition of control, as opposed to a power or authority definition. This means that the two boxes under “control” in Figure 1.4 play a vital role in allowing a project manager to exercise control over a project.

Planning
It is the plan that tells you where you are supposed to be in the first place. Without a plan, you have no idea if you are doing okay or not. Thus, if you have no plan, you have no control. I consider this to be one of the most important principles of project management, because it clearly explains why planning is not an option—it is a necessity.

PRINCIPLE: If you have no plan, you can not have control—by definition!

Information
If you don’t know where you are, you certainly can’t exercise control. This is a problem for most organizations. They have excellent information systems for inventory control, order tracking, and so on, but no system for tracking projects. The reason is simple—they didn’t know they needed one. For the time being, you will most likely have to track each project manually. That isn’t too big a problem for most project managers.
You will also need to estimate how long a task will take. Organizations don’t have history databases. If you want to estimate how long a task will take, your best starting point is data on how long it took previously. All too often, this information exists only in the memories of individuals, and these are notoriously faulty.

Source : The Project Manager’s Desk Reference A Comprehensive Guide to Project Planning, Scheduling, Evaluation, and System by James P. Lewis

Overview of Project Management
Barry Benator

If one word could describe the essence of project management it is responsibility. The project manager (PM) is responsible for all that happens on a project. This doesn’t mean the project manager should or could do everything associated with the project; it does mean the PM owns ultimate responsibility for the project, regardless of who is on the project team and regardless of the obstacles encountered along the way to successful completion. In other words, the buck stops with the project manager. If that sounds like an awesome responsibility, then you have grasped the concept of what it means to be a project manager. For many people, it’s an exciting challenge. Because, in addition to the large responsibilities of project management, there are numerous rewards
for successful project managers. This book will help you meet those responsibilities and attain the rewards of becoming a successful project manager.

REWARDS OF PROJECT MANAGEMENT
There are a number of rewards associated with being a successful project manager. Listed below are a just few of them.

• The satisfaction of pulling together a diverse group of people from different organizations and creating a high performing project team that accomplishes the project’s mission.
•The reward of helping these people perform their responsibilitiesand achieving success for themselves and the project.
•The reward of increased profits and enhanced cash flow to your company
•The reward of a satisfied and appreciative customer.
•The reward of repeat business from that customer.
•The reward of new business from other customers based on positive recommendations from your satisfied customer.
• The reward of enhanced career opportunities for you and your project team.

Good project managers are one of the few job functions which continue to be in demand by companies in almost every business sector. Good project managers have a bright future ahead of them. This book will help you achieve that brighter future.

THE PROJECT MANAGER’S RESPONSIBILITY
The technical knowledge and skills required to be a successful
engineering or construction project manager are wide-ranging, but the good news is you don’t need to be an expert in all of them. In fact, you don’t need to be an expert in any of them; you do, however, need to have engineering or construction experience. However, as important as this technical experience is, even more important is the will and commitment to take on the overall responsibility for your projects. The fact that you are reading this book is a strong signal of your commitment to learn and practice good leadership and management skills, which will help you fulfill your project management responsibilities and succeed as project manager.
A typical engineering or construction project will have many of the following disciplines associated with it:
• Electrical • Financial/accounting
• Mechanical • Purchasing
• Process • Legal/contractual
• Structural • Insurance/risk management
• Architectural • Purchasing
• Civil • Drafting/Computer
•
Cost estimating Aided Design
The project manager’s responsibility is to manage the financial, technical and schedule requirements of the project in such a manner as to bring the project in on-time, within budget and with a technical quality that meets or exceeds the contractual performance specifications.

Source : Project management and leadership skills for engineering and construction projects by Barry Benator, Albert Thumann.

Project management can be a profession, a job, a role, or an activity. Some companies have project managers whose job is to oversee entire 200-person projects. Others use the title for line-level junior managers, each responsible for a small area of a large project. Depending on how an organization is structured, what its culture is, and what the goals of the project are, project management can be an informal role (”it’s done by whomever, whenever necessary”) or highly defined (”Vincent, Claude, and Raphael are full-time project managers”).

In this book, I’ll primarily use the phrase project manager, or PM, to refer to whoever is involved in project leadership and management activity. By project management activity I mean leading the team in figuring out what the project is (planning, scheduling, and requirements gathering), shepherding the project through design and development work (communication, decision making, and mid-game strategy), and driving the project through to completion (leadership, crisis management, and end-game strategy).

If this sort of work is structured less formally in your world, just translate project manager or PM to mean “person doing project management tasks, even though it’s not her primary job” or “person thinking about the project at large.” I’ve encountered many different ways for these activities to be distributed across teams, and the advice in this book is largely indifferent to them. This book is less about job titles and formalizations and more about how to get things done and make things happen. But to keep my writing as simple as possible, I’ll rely on the phrase project manager, or PM.

Sometimes the absence of a dedicated project manager works fine. Programmers and their bosses maintain schedules and engineering plans (if any), and a business analyst or marketing person does the planning or requirements work. Anything else that might qualify as project management simply gets distributed across the team. Perhaps people on the team have been hired for their interest beyond writing code. They might not mind early planning, user interface design, or business strategy. There can be significant optimizations in working this way. As long as everyone is willing to pay the tax of responsibility for keeping things together, and distributing the burden that a dedicated project manager would carry for the team, there’s one less employee that the team needs. Efficiency and simplicity are good things.

But other times, the absence of a project manager creates dysfunction. Without a person whose primary job is to shepherd the overall effort, individual biases and interests can derail the directions of the team. Strong adversarial factions may develop around engineering and business roles, slowing progress and frustrating everyone involved. Consider that in hospital emergency rooms, one doctor takes the lead in deciding the course of action for a patient. This expedites many decisions and gives clarity to the roles that everyone on the trauma team is expected to play. Without that kind of clear authority for project management-type issues, development teams can run into trouble. If there is no clear owner for leading bug triage, or no one is dedicated to tracking the schedule and flagging problems, those tasks might lag dangerously behind individual, programming-centric activities.

While I think many of the best programmers understand enough about project management to do it themselves, they also recognize the unique value of a good, dedicated person playing the role of manager.

Source : The Art of Project Management by Scott Berkun