Task 1

1.1
1.1.1 Interdiction to the project
1.1.2 Feasibility study
1.2
Project management principles
1.3 Risk management
1.4 Terminating project
1.5 Cost benefit analysis
Task2
2.1 Matrix organization
2.2 Human resources for a project
2.3 Role and responsibility
2.4 Monitoring and controlling for a project
Task 3
3.1 Gannt chart
3.2 Measuring project performance
3.3 Cost control of a project
3.4 Project change control procedures

1
Introduction to the project

A Project is a temporary endeavor undertaken to create a unique product or service. Projects

normally involve several people performing main customer for the project is often interested in
the effective use of resources to complete the project in an efficient and timely manner. The
following attributes help define a project further.

A project has a unique purpose. Every project should have a well-defined objective. For example
Anne Roberts, the chief project officer in the opening case, might sponsor an information
technology collaboration project to develop a list and initial analysis of potential information
technology projects that might improve operations for the company. The unique purpose of this
project would be creating a collaborative report with ideas from people throughout the company.
The results would provide the basic for further discussions and projects.

A project has a definite beginning and definite end. In the information technology collaboration
project, Anne might from a team of people to immediately work on the project. And then expect
a report and an executive presentation of the results in one month.
A project requires resources, often from various areas. Resources include people, hardware,
software, or other assets. Many projects cross departmental or other boundaries to achieve their
unique purpose. For the information technology collaboration project , people from information
technology , marketing , sales , distribution and other areas of the company would need to work
together to develop ideas.

A project involves uncertainly. Because every project is unique, it is sometimes difficult to

clearly define the project’s objectives, estimate how long it will take to complete, or how must it
cost.

2
Feasibility study

A feasibility studies main goal is to assess the economic viability of the proposed business. The
feasibility study needs to answer the question: “Does the idea make economic sense?” The study
should provide a thorough analysis of the business opportunity, including a look at all the
possible roadblocks that may stand in the way of the cooperative’s success. The outcome of the
feasibility study will indicate whether or not to proceed with the proposed venture. If the results
of the feasibility study are positive, then the cooperative can proceed to develop a business Scope
Management.

Feasibility study for management conference

A management conference feasibility study is a controlled process for identifying challenges and
opportunities, determining objectives, defining successful outcomes and assessing a range of
costs and benefits of an event concept. It is a preliminary study undertaken before the real work
of an event/festival starts, to ascertain the potential of the events success.

Developing a successful inaugural event can be a risky investment and taking the event concept
from an initial idea through to the operational stage is often a complex and time-consuming
effort. Red Horizon Events consulting expertise in feasibilities studies provides decision makers,
within your organization, with the opportunity to make better, more informed decisions on new
event concepts.

Interdiction-By organizing this management conference we target more students for IDM
Management students. Our aim promotes the IDM and shows its value and strength for after
advanced level students. We gave more valuable knowledge for them by this managing
conference.

3
• Draft Budget

Budget needs to reflect on a number of costs. If you are not able to have exact figures for
some of this, estimate - you can always correct this once you have confirmed figures and
can change this for the final budget.

• Venue

Most places can send you pricing by email -this is helpful in preliminary draft budget
planning they may offer discounts on room hire or accommodation. Check when you
need to confirm. ü Sponsorship Need to look at whether we can get sponsorship for the
event? And if so, in what form will it be e.g. money (donation towards costs), full cost or
half cost of the event.

• Events Activity List

The Events Activity List is good tool to use when organizing a function – as each point is
raised and completed, it can be ticked off. This means nothing is forgotten and it is also a
double check from the timeline document. Also if you are away for any reason, someone
else can easily see at what stage you are up to with the event organization.
• Budget
Catering Get quotes from different venues – look at cost and what they are offering. Is
the food what you want? Can you change any menu supplied? Need to look at these sorts
of things. You may have people with special dietary needs – these people need to be
catered for, but they should be telling you this before the event (not on the day).

• Photographer
If you need one for the event book them well ahead of the event, as they are hard to get. I
would suggest 3-4 months before and again ring 2-3 people and get quotes. Once booked

4
 put all contact details on sheet for ease of access by anyone else who
may have to contact them..

1.2
project management principles

• Objectives
Goals for a project at must be stated in terms of deliverable items. To so state a project
objective forces the definition of a clear, comprehensible, measurable and tangible objective.
Often deliverable items resulting from a project are documents. In constructing a residence,
is the deliverable items.
It is use full to start planning by discussing the IDM management conference goals. They
may be formulated by the project’s sponsor and be found in a preliminary. Conference
mandate but there is always a need to elaborate on them and define them more precisely main
goals.

5
• Scope

The scope is the most important element to understand about any project. All planning and
allocation of resources are anchored to this understanding.
Defining the project scope sets the stage for developing a management conference plan.
Project scope is a definition of the end result or mission of your project-a product or service
for your student. The primary purpose is to define as clearly as possible the deliverable(s) for
the end user and to focus project plans. As fundamental and essential as scope definition
appears, it is frequently overlooked by project leaders of well-managed, large corporations.

Research clearly shows that a poorly defined scope or mission is the most frequently
mentioned barrier to project success.

• Resources

Resources are assets, such a people, equipment, physical facilities, or inventory, that have
limited availabilities, can be scheduled, or can be leased from an outside party. Some are
fixed; other are variable only in the long term. In any case, they are central to the scheduling
of project activities and the orderly completion of the project.

• Deliverable

The result of completing the work that makes up the activity is the production of a
deliverable. The deliverable is a visible sign that the activity is complete. This sign could be
an approving manager’s signature, a physical product or document. The authorization to
proceed to the next activity, or some other sign of complete
The expected out puts over the life of the project. For example, deliverables in the early
design phase of a project might be a list of speculations. In the second phase deliverables
could be software coding and a technical manual. The next phase could be to test prototypes.
The final phase could be final tests and approved software.

6
• Time
The customer specifies a timeframe or deadline date within which the project much be
completed. To a certain extent, cost and time are inversely related to one another. The time a
project takes to be completed can be reduced, but cost increases as a result.
Time is an interesting resource. It can’t be inventoried whether we use it or not. The
objective for the project manager is to use the future time allotted to the project in the most
effective and productive ways possible. Future time (time that has not yet occurred) can be a
resource to be traded within a project or across projects. Once a project has begun, the prime
resource available to the project manager to keep the project on schedule or get it back on
schedule is time. A project manager realizes this and protects the future time resource
jealously.

The question of whether the conference is on schedule. Whether the activity will be
completed on time, is also important. The plan shows when the activity should be completed.
It is important to discuss whether this unique to the current situation, or if it was a general
way of doing scheduling.

The question of whether the project is on schedule. If whether the activity will be completed
on time, is also important. The plan shows when the activity should be completed. It is
important to discuss whether this is unique to the current situation, or if it was a general way
of doing scheduling.

7
Objectives More than 1000 students to take the management

Scope 17-20 Age groups

Deliverables Briefly explain about the management studies and give the knowledge
to students

Accountability Surely students get some information in management

Constrains More than 200 students selected in HNDM

Assumptions Number of students

Resources Giving lecture about studies

Giving certificate

8
1.3 Definition of Risk Management

Project Risk Management is the systematic process of identifying, analyzing, and responding to
project risk. It includes maximizing the probability and consequences of positive events and
minimizing the probability and consequences of adverse events to project objectives.

Project Risk is an uncertain event or condition that, if occurs, has a positive or a negative effect
on a project objective.

What is a Project risk?

Project Risk management is a central part of any organization’s strategic management. It is the
process whereby organizations methodically address the risks attaching to their activities with
the goal of achieving sustained benefit within each activity and across the portfolio of all
activities.

The focus of good risk management is the identification and treatment of these risks. Project
Risk management should be a continuous and developing process which runs throughout the
organization’s strategy and the implementation of that strategy.
It should address methodically all the risks surrounding the organization’s activities past, present
and in particular, future.

Any of organization, when that developed a Project strategic plan that can face and our Tec Need
– IDM management conference will face following risk management but, this risk management
can occur two key ways such as External and Internal factors. They can be categorized further
into types of risk such as strategic, financial, operational, etc.

9
Tec Need – IDM management conference can face some significant problems. In this situation,
to avoid these risks that we are following risk management process steps. That contains in order
rule and regulations and by using that processes, how that we can overcome above problem
which mentioned. These are steps of risk management.

• Time

In this case delay is examined. Denotation of the classes is linked to the objective and the
definition of the risk analysis. When the situation involves a conference result that is completed
later than planned, then a value is assigned to the classes that different from the one used where a
later completion of a partial result is being examined.
For example: if the total time required for a managing conference is 6hours, then a risk with the
consequence of a 1 hour delay is very undesirable.

• Money

The consequences for the aspect of money is expressed in a unit currency factors involves may
include additional costs as well as. The budget available for the risk analysis must he
determined, as well as what the expenditure included in the budget has to yield.

• Quality

When it comes to the aspect of quality, it is a bit more difficult to assign a criterion for
expressing the consequences of the risk. In the case, the degree to which a risk is capable of
doing harm to the specified quality requirement is used as a standard

The level of detail of the risk analysis plays an important role in quality required of it.

10
The required quality characteristics of risk management are agreed upon
beforehand. The quality is determined by
• What is to be done?
• How it will be done
• By whom it will be done

• Retaining Risk

In some cases a conscious decision is made to accept the risk of an event occurring. Some are so
large it is not feasible to consider transferring or reducing the event. The project owner assumes
the risk because the chance of such an event occurring is slim. In other cases risks identified in
the budget reserve can simply be absorbed if they materialize. The risk is retained by developing
a contingency plan to implement if the risk materializes. In a few cases a risk event can be
ignored and a cost overrun accepted should the risk event occur.
The more effort given to risk response before the project begins, the better the chances are for
minimizing project surprises. Knowing that the response to a risk event will be retained,
transferred, or shared greatly reduces stress and uncertainly when the risk event occurs. Again,
control is possible with this structured approach.

• Technical Risks

Technical risks are problematic; they can often be the kind that causes the project to be
shutdown. What if the system or process does not work? Contingency or backup plans are made
for those possibilities that are foreseen. For example, Carrier Transcicold was involved in
developing a new Phoenix refrigeration unit for truck-trailer applications. This new unit was to
use rounded panels made of bonded metals, which at the time was new technology for
Transicold. Furthermore, one of its competitors had tried unsuccessfully to incorporate similar
bonded metals in their products. The project team was eager to make the new technology work,
but it wasn’t until the very end of the project that they were able to get the new adhesives to bond
adequately to complete the project. Throughout the project, the team maintained a welded-panel

11
fabrication approach just in case they were unsuccessful. If this contingency
approach had been needed, it would have increased production costs, but the project still would
have been completed on time.

In addition to backup strategies, project managers need to develop methods to quickly assess
whether technical uncertainties can be resolved. The use of sophisticated CAD programs has
greatly helped resolve design problems.. They suggest that one should first identify the high-risk
technical areas, then build models or design experiments to resolve the risk as quickly as
possible. By isolating and testing the key technical questions early on in a project, project
feasibility can be quickly determined and necessary adjustments made such as reworking the
process or in some cases closing down the project. Usually the owner and project manager make
decisions concerning technical risks.
Schedule Risks

Managing scheduling risk usually requires trade-off decisions. It is ironic that practicing
managers actually increase schedule risk by some of their decisions. Three of those situations are
examined on.

When some managers see network slack, they case to worry about completing their activity on
time-why worry if there are 10 days of slack! Unfortunately, that slack may be needed by
another activity on the path that now must start later and leave little or no Slack available
because the path slacks has already been used up. Managing slack can be an excellent method for
reducing schedule risk. Remember, use of slack moves more activities nearer their late start, and
thus the risk of project delay is increased.

• Imposed Duration Dates

12
Our experience suggests that about 80 percent of all projects have imposed
duration dates. Usually this means someone (with authority) has determined that the project or
milestone(s) can or must be
Completed by a specific date. Examples might be completing a road by January 1 or developing
a video game for the Christmas market. The specified project duration is frequently a top-down
decision that does not include bottom-up planning and often understates the normal time required
to complete the project. If this case, meeting the required, specified project duration will result in
activities being performed more rapidly than the normal, low-cost method. This hurried approach
increases cost and the chance of activities being late and reduces flexibility in the total
scheduling system. There are times when completing a project by imposed durations, both risks
of being late and greater costs are increased. The question is,” Is this simply poor planning, or is
there a real necessity to manage project by imposed durations?”

• Compression of Project Schedules

Sometimes before or midway through the project, the need to shorten the project duration arises.
Shortening project duration is accomplished by shortening (compressing) one or more activities
on the critical path. Shortening an activity/work package duration increases direct cost. In
addition, compressing the critical path decreases total slack on other paths, and more paths
become critical or near critical. The more critical activities or near-critical activities there are, the

Higher the risk of delaying project completion. Some contingency plans can avoid costly
procedures. For example, schedules can be altered by working activities in parallel or using start-
to-start lag relationships. Also, using the best people for high-risk tasks can relieve or lessen the
chance of some risk events occurring. Techniques for managing this situation are discussed in
chapter

• Cost Risks

13
Given some of the reported cost overruns, cost risks are significant and carry
heavy consequences. Most cost risks are created in schedule and technical estimate errors and
omissions. In addition, some management decisions actually increase cost risks. A few selected
cost risks found in practice are discussed here.

• Time/Cost Dependency Link

There is a dependency link between time and cost and technical problems and cost. For example,
if the activity “develop process prototype” requires 50 percent more time than the original
estimate, it can be expected that costs will also increase. Thus, time and cost do not occur
independently. Neglecting to consider this interactive dependency can result in significant cost
risk errors.

1.4 Terminating project

Termination of a project is inevitable, but how it is terminated and when may have a profound
and long lasting impact on the organization and its employees. The success of future projects
may depend on not only the success of past ones, but also on how unsuccessful projects were
treated by the organization and its stakeholders. Firms have the option of initiating a variety of
entrepreneurial projects with varying degrees of risk. If an organization chooses to accept.

14
Greater risks, it should avoid penalizing members of projects that turn out to
be unsuccessful. If team members believe they will be penalized for participating in unsuccessful
projects, they will be less willing to terminate failed projects and may become risk adverse.

This research contains information about the project life cycle and the importance of continually
monitoring a project to determine if it is meeting the objectives established at the outset. We
have identified and categorized external and internal factors that influence the success or failure
of projects. The relative importance of each factor varies by organization and project type.

Organizing a project's termination process is especially important when it has failed, because of
the lasting impact on future projects as well as the organization's image. Including project team
members in the termination process will increase their loyalty and commitment, not only to the
organization but also to the success of future projects. At the end of a project a post-audit report
will be prepared that summarizes the project and provides recommendations for similar projects
in the future. Lastly, as a project is closed down or completed it is important that senior
management recognize the contributions of the project team.

1.4 Cost benefit analysis

These analyses are always difficult to do because you need to include intangible benefits in the
benefits in the decision situation. Things such as improved customer satisfaction cannot be easily
quantified. You could argue that improved customer satisfaction reduces customer turnover,
which in turn increases revenues, but how do you put a number on that? In many cases, senior
management will take these inferences into account, but they still want to see hard-dollar

15
comparisons. Opt for the direct and measurable benefits to compare against
the cost of doing the conference and the cost of operating the new process. If the benefits
outweigh the costs over the expected life of the conference deliverables, senior management may
be willing to support the conference.

Activity Financial benefit Non financial benefit

Budget Can reduce the cost.

Can estimate the necessary
capital

Pricing Can gain money to do the

conference.

Costing Can gain money to do the

conference.

Invitation design Can find a accurate time.

Brand image will go up.

Event promotion Can get more money from HND
students
communication Can get more money from
management conference
Arrangement of technical item Can reduce the cost for
technical item
Getting sponsor Get gain some money for
conference
Can get more students for
HNDM
IDM brand awareness
Good image for IDM
IDM image will go up

16
Task 2
Organizing Projects within a Matrix Arrangement

Matrix management is a hybrid organizational form in which a horizontal project management

structure is “overlaid” on the normal functional hierarchy. In a matrix system, there are usually
two chains of command, one along functional lines and the other along project lines. Instead of
delegating segments of a project to different units or creating an autonomous team, project
participants report simultaneously to both functional and project managers.

Companies apply this matrix arrangement in a variety of different ways. Some organizations set
up temporary matrix systems to deal with specific projects, while “matrix” may be a permanent
fixture in other organizations. Let us first look at its general application and then proceed to a
more detailed discussion of finer points.

The matrix structure is designed to optimally utilize resources by having individuals work on
multiple projects as well as being capable of performing normal functional duties. At the same
time, the matrix approach attempts to achieve greater integration by creating and legitimizing the
authority of a project manager. In theory, the matrix approach provides a dual focus between
functional/technical expertise and project requirements that is missing in either the project team
or functional approach to project management. This focus can most easily be to seen in the
relative input of functional managers and project managers over key project decisions

17
In principle every major project decision and action must be negotiated. The
project manager is responsible for integrating functional input and overseeing the completion of
the project. Functional managers are responsible for overseeing the functional contribution to the
project.

Different Matrix Forms

In practice there are really different kinds of matrix systems, depending on the relative authority
of the project and functional managers. Functional, light weight or weak matrix is titles given to
matrices in which the balance of authority strongly favors the functional managers. Balanced or
middleweight matrix is used to describe the traditional matrix arrangement. Project,
heavyweight, or strong matrix is used to describe a matrix in which the balance of authority is
strongly on the side of the project manager.

The relative different in power between functional managers and project managers is reflected
along a number of related dimensions. One such dimension is level of reporting relationship. A
project manager who reports directly to the CEO has more clout than a marketing manager who
reports to director of marketing. Location of project activities is another subtle but important
factor. A project manager wields considerably more influence over project participants if they
work in his office than if they perform their project-related activities in their functional officers.
Likewise, the percentage of full-time staff assigned to the project contributes to relative
influence. Full-time status implies transfer of obligations from functional activities to the project.

One other factor is who is responsible for conducting performance appraisals and compensation
decisions. In a weak matrix, the project manager is not likely to have any direct input into the
evaluation of participants who worked on the project. This would be the sole responsibility of the

18
functional manager. Conversely, in a strong matrix, the project manager’s
evaluation would carry more weight than the functional manager’s. in a balanced matrix either
input from both managers is sought, or the project manager makes recommendations to the
functional manager, who is responsible for the formal evaluation of individual employees. Often
companies will brag that they use a strong, project-oriented matrix only to find upon closer
examination that the project managers have very little say over the evaluation and compensation
of personnel.

Ultimately, whether the matrix is weak or strong, a functional or project matrix is determined by
the extent to which the project manger has direct authority over participants. Authority may be
determined informally by the persuasive powers of managers involved and the perceived
importance of the project or formally by the prescribed powers of the project manager. Here is a
thumbnail sketch of the three kinds of matrices:

• Weak matrix

This form is very similar to a functional approach with the exception that there is a formally
designated project manager responsible for coordinating project activities. Functional managers
are responsible for managing their segment of the project. The project manager basically acts as
a staff assistant who draws the schedules and checklists, collects information on status of work,
and facilities project completion. The project manager has indirect authority to expedite and
monitor the project. Functional managers call most of the shots and decide who does what and
when the work is completed.

• Balanced matrix

19
This is the classic matrix in which the project manager is responsible for
defining what needs to be accomplished while the functional managers are concerned with how it
will be accomplished. More specifically, the project manager establishes the overall plan for
completing the project, integrates the contribution of the different disciplines, sets schedules, and
monitors progress. The functional managers are responsible for assigning personnel and
executing their segment of the project according to the standards and schedules set by the project
manager. The merger of “what and how” requires both parties to work closely together and
jointly approve technical and operational decisions.

• Strong matrix

This form attempts to create the “feel” of a project team within a matrix environment. The
project manager controls most aspects to the project, including scope trade-offs and assignment
of functional personnel. The project manager controls when and what specialists do and has final
say on major project decisions. The functional manager has title over her people and is consulted
on a need basis. In some situations a functional manager’s department may serve as a
“subcontractor” for the project, in which case they have more control over specialized work. For
example, the development of a new series of laptop computers may require a team of experts
from different disciplines working on the basic design and performance requirements within a
project matrix arrangement. Once the specifications have been determined, final design and
production of certain components (i.e., power source) may be assigned to respective functional
groups to complete.

20
Matrix management both in general and its specific forms has unique
strengths and weakness. The advantages and disadvantages of matrix organizations in general are
noted below, while only briefly highlighting specifics concerning different forms:

A matrix organization structure introduces, or at least recognizes, the real life complexity of our
business environment. Geography, function, technology, business unit and technology (among
others) are important, so why not recognize this reality in our matrix organizations structure.
However, a matrix organization structure also introduces a higher level of internal complexity
and some additional people management challenges, so there must be significant advantages to a
matrix organization structure that outweigh the matrix people management challenges.
Matrix organization structures were introduced in the airspace industry in the 50s to cope with
complex projects. Since then many thousands of organizations, often prompted by the large

strategy consultancies, have adopted the matrix organization structure to help deal with internal
and external complexity.

At its simplest the matrix organization structure just reflects this external complexity in the
internal structure. Companies realize that geography is important but so is function, and so is
customer grouping, product and technology. Instead of choosing a dominant organizing principle
we choose to reflect all of these important strands in our structure, we have solid lines to product
group and function, dotted lines to geography etc…

In a sense then, a matrix organization structure is recognition that we cannot choose which of
these is more important, so we need a structure that allows them to be balanced and prioritized
on a daily basis.

What this means is that, when we choose a matrix organization structure, we are deliberately
trading some clarity in return for more flexibility.

21
The matrix organization structure itself, solves nothing, it is how people work
together in the matrix organization that makes it succeed or fail - and often this is the neglected
bit.
At a more detailed level the advantages that most organizations seek through using a matrix
organization structure include

• Improved ability to access resources across the old functional and geographic silos
• Better coordination on shared technologies across the organization
• Faster decentralized decisions
• Improved access to a diverse range of skills and perspectives
• Improved global or regional projects
• Increased communication and coordination across the business
• Reflects the needs of global or regional customers

As we can see, most of these are about improving the way people work together and breaking
down traditional barriers to cooperation. The idea of the matrix organization structure is to
enable faster response and adaptation to a complex world. The matrix structure can deliver this,
provided people have the skills to make the matrix work.

In our experience working with clients most of them do not communicate the benefits of their
matrix organization structure clearly enough, all people see are the challenges and not the
benefits that make a matrix structure worthwhile.
Efficient

Resources can be shared across multiple projects as well as within functional divisions.
Individuals can divide their energy across multiple projects on an as-needed basis. This reduces
duplication required in a project zed structure.
Strong project focus

22
A stronger project focus is provided by having a formally designated project
manager who is responsible for coordinating and integrating contributions of different units. This
helps sustain a holistic approach to problem solving that is often missing in the functional
organization.

• Flexible
Matrix arrangements provide for flexible utilization of resources and expertise within the firm. In
some cases functional units may provide individuals who are managed by the project manager.
In other cases the contributions are monitored by the functional manager.

The strengths of the matrix structure are considerable. Unfortunately, so are the potential
weaknesses. This is due in large part to the fact that a matrix structure is more complicated and
the creation of multiple bosses represents a radical departure from the traditional hierarchical
authority system.

Furthermore, one does not install a matrix structure overnight. Experts argue that it takes 3-5
years for a matrix system to fully mature. So many of the problems described below represent
growing pains.

• Dysfunctional Conflict

The matrix approach is predicated on tension between functional managers and project managers
who bring critical expertise and perspectives to the conference. Such tension is viewed as a
necessary mechanism for achieving an appropriate balance between complex technical issues
and unique project requirements. While the intent is noble, the effect is sometimes analogists
opening Pandora’s Box. Legitimate conflict can spill over to a more personal level, resulting
from conflicting agendas and accountabilities. Worthy discussions can degenerate into heated
arguments that engender animosity among the managers involved.

23
 • Stressful

Matrix management violates the management principle of unity of command. Project participants
have at least two bosses-their functional head and one more project managers. Working in a
matrix environment can be extremely stressful. Imagine what it would be like to work in an
environment in which you are being told to do three conflicting things by three different
managers

MD

Project Project The The The end

manager sponsor member supplier user

Project
A

Project
B

24
2.2

• Project manager
• Sponsor of project
• The member
• Functional experts and adviser
• The supplier
• The line manager
• The end user

25
2.3 Role and responsibility
A steering committee is the project manager’s superior. It may also be called the management
group. The steering committee plays a central role in a project. Its main responsibilities are to
initiate and purpose the project and approve the principle responsibilities chart. It should
determine the use of resources and ensure that the project responsibility chart and the principle
responsibility chart are observed.

You could ask whether there is a need for a steering committee. If those in positions of
responsibility are clearly delineated on the responsibility chart, and the role of the base
organization is clearly described, is a steering committee still necessary? In many cases it is. But
in some cases we can manage without.

A significant issue for the project approach is that the project is dependent on resources from the
base organization. Even if it is absolutely clear which resources should be provide by it, in
practice this is not always so easy to achieve. It can then be beneficial to have a steering
committee, which should be a group of line managers, to ensure that the relationship between the
base organization and the project functions as it should. This line manager colleagues can see to
it that every one sticks to the agreements made, and can among themselves find solutions for
problems which arise from time to time with access to resources. It may be easier for a group of
line managers to tackle these problems than a project manager to take them up with each line
manager in turn.

What we have just said also shows who should be included in the steering committee, the line
managers who are involved in the project. It is not normal practice, for instance, that elected
employee representative have a place in the steering committee.

26
If the conference only involves the staff of one line manager, then it is natural
that this line manager be the ‘steering committee’. The responsibility chart shows that this
manager is assigned all the operational tasks belonging to a steering committee.

Usually a project involves areas of responsibility and personnel belonging to several line
managers. If the managers involved meet frequently as a manager group, it is best that this
group, in addition to its other duties, also functions as a steering committee for the project. Part
of the time of the management group’s meeting should then be used as a steering committee
meeting.

We see reason to established a new forum unless absolutely necessary. It simplifies

administration, and it is clear that people who are working together in order matters functions
better as a group.

Some organizations have decided that their management board should function as a steering
committee for all projects involving more than one sector. The board then makes time for
steering committee tasks each time they assemble.

Some companies have so much experience using the conference approach that it is regarded as
hardly necessary to establish a steering committee function. Relevant tasks will then be divided
among those involved according to their areas of responsibility and described on the
responsibility charts.

We present two situations where a steering committee is essential. They are when
The project approach is unknown in the base organization
The project crosses organizational limits or involves several companies.
If the organization does not have any experience with project work it is particularly important to
give prestige and support to the projects and the project manager. This can be achieved to a
greater extent by establishing a steering committee than distributing its tasks to a series of
individuals. Since the steering committee consists of some or all line managers, it will be
perceived as a forum with authority, and its pronouncements will be listened to.

27
If the line management is not used to working with conference, it is difficult in many cases to
ensure that it will accept its responsibility for the conference. When matters are discussed in a
steering committee with several line managers, it is easier to get individual line managers to
realize their responsibilities. Line managers are more aware of their responsibilities. The same
matters can, of course, be expressed on the responsibility charts, but the dialogue between the
participants in a steering committee ensures that the commitments are more deeply felt.
In a company lacking project experience, training and motivation are important. It is particularly
important that knowledge and expertise come in at the top level. In such a situation a steering
committee can be used deliberately to provide training on conference work. When central people
in the base organization belong to a steering committee, it can be used to give conference
members skills and shared attitudes.
Good work on the part of the steering committee can be measured by a better project culture in
the organization.

• Project managers

New project managers who have not experienced the development of a project, as well as
seasoned project managers, will benefit from the techniques described.
Most project managers are traditionally taught to develop a detailed management conference of
all the activities needed to complete the conference. This approach is not always appropriate in a
world where rapid changes in technology can significantly change the details of a plan. In most
cases only an outline plan is required of the main conference activities, followed by the
traditional detail of the first stage activities. Understanding this critical point can save many
hours of needless effort in initially recording all the activities involved, only to have to change
them a few weeks later.
Sponsors of project
One of the biggest problems for sponsors of projects is to visualize the whole picture when it
comes to commissioning a management conference. Understanding all the different elements
necessary to successfully implement a conference is a challenging task, and recognizing the need
for these elements will give them head start.

28
Have the objectives been agreed with the team? How often will feed back on
progress be given? Have all the appropriate departments been involved from the start? Should
internal or external people resources be used?

• The team

For a management work shop to succeed the team should recognize the need for the conference.
What it means and what their contribution does for the workshop. The term needs to understand
the key stages of conference. Individuals mark up a term and recognizing the efforts of the
workshop, leading and motivating the term is vital to the success of the workshop.
Functional experts and advisers
Functional experts such as member of a Human Resource department, finance or marketing
department often participate in projects because they are the recipients of a system or process, or
their areas provide the rules for developing systems or processes. But such people cannot act in
isolation. Participating fully at the beginning as well as during the life of a project is a critical for
it to succeed. Understanding the role of other participants as well as their own role contributes to
eventual success. A project that progresses without regular checks, or feedback, from such
functional experts during development often results in failure.

• The supplier

Although suppliers or contractors involved in a project should balance all three conference
dimensions, they often focus on the budget and schedule first and then on the quality of the
deliverables. They will first consider how much income they would receive from the conference
and how much of their time is demanded by the schedule.

• The line manager

The line manager is not directly involved in the conference, but provides from his or her team the
functional experts as a resource. The manager’s concern is to find out when this resource will

29
return to his or her own term, so the manager’s interest in the conference
primarily to do with the schedule.

• students or end users

The students often look at the time dimension first. When will they receive the conference
deliverables? After they receive the outputs of the conference, they hen consider the quality.

30
Main stages and activities of any projects

• Define
• Plan
• Team building, leading and motivation
• Control
• Communications
• Review

• Define

Defining the client requirements is the first stage in a IDM conference This is a fundamental
process that requires a significant amount of time and effort to clarify. The main aim of this stage
is to
Define the conference objectives in a document called the terms of the reference.
Start to build a good relationship with the sponsor.

• Plan

About 15 per cent of all the time spent on a project should be dedicated to the planning stage.
Quite often, a newly appointed project manager will have a number of objections towards
spending any significant time on planning a workshop. The most common complaint is that
planning requires a lot of work and this takes time-time that can be spent on completing tasks
required by the conference.

31
Another complaint is that planning is not viewed as being productive by many people involved
in a workshop. It is not action it is not producing anything. Planning is a pretty chart that gets
pinned on a wall at the beginning of a project and never gets updated again. It will change within
a few days of starting a conference, so why create a plan in the first place.

A final complaint that is often heard is that the original plan is fixed and cannot be changed, as
the Sponsor has agreed to it. The conference manager will feel committed to the original plan
will believe that changes cannot be accommodated. The concept of change during the life of a
project in this case is not understood. Change will inevitably happen and a process must be put in
place to capture, assess and action requests for change.

All these objections to preparing and working with a plan are overcome when a project manager
consider the following.

A plan is a map that allows us to reach the conference objectives.

Getting the term to participate in preparing a plan allows the project manager to secure buy in to
the project by the term. The term will feel that it is their plan as they contributed to preparing it.
As a minimum, the plan contains detailed information on what needs to be done, by whom and
by when. Without this information, the term ill not know what to do and when to do it by.
No corrective action can be taken during a project unless there is something to refer to. This
reference point, baseline, is the plan.
Above all, a plan is a tool or business device that allows the objectives of a conference, as
defined in the TOR, to be achieved. It is a living document that can be changed during the life of
the IDM conference
• Creating a work breakdown structure
• Creating the term structure and individual responsibilities
• Estimating effort and duration for each tasks
• Preparing the schedule
• Allocating resources to tasks
• Determining the budget

32
 • Risk analysis and contingency

Each of these elements will now be discussed in detail, using the case study to show us how to
prepare the necessary documentation to complete our plan.

Determining the budget

At this stage of the planning process each of these costs is an estimate and the estimates will
change as the work on the conference begins. The process of estimating these costs is to provide
a structured framework for estimating the total projects costs. These are presented to the sponsor
so that he or she may raise the necessary budget, or make appropriate changes to the scope and
deliverables, to reduce the conference costs.

• Controlling

Controlling is the adjustment of the work when needed so the overall time and money
commitments are maintained or at least optimized. Thus controlling means taking the appropriate
action in the light of the information gained from monitoring. The whole purpose of scheduling
and monitoring is to permit intelligent control.

Scheduling and monitoring by themselves are not control. Control must be deliberately
exercised. The engineer must, with help if necessary, decide what action must be taken to keep
the project on schedule. Once the controlling action has been decided on it must be implemented.

The most common error in project control is not acting soon enough. Action is delayed either
because of poor monitoring or more often because of unwillingness to face the facts. The
solution to a problem is assumed to be just around the corner or will yield on completion of the
next test. The true facts cannot work against a conference, but erroneous assumptions can. When
it

33
Becomes reasonably clear that a certain line of investigation or approach is not going to work,
stop it. Redirect the effort in a more fruitful direction. Delay wastes time and money.
It is often a mistaken assumption that delays or difficulties can be overcome by working harder.
Engineers should always be working hard. This will rarely solve the problem. Delays can only be
overcome by adding extra time or extra resources. Expert help can be sought, tests can be run
concurrently, overtime can be put in, or the approach can be changed to one that is more likely to
yield result. Control is exercised by a definite, specific action.

One of the major blocks to effective control is a common error in the engineer's view of the
conference. When engineers are given a task they tend to identify with it, and feel that its success
is their success. The more effort they put into it the stronger they feel that way. This is good
because it means commitment. Unfortunately, they often begin to see their solution or approach
as the only correct one. Controlling actions threaten this image and engineers often resent and
resists them. Engineers must learn to identify with success of the whole conference. The
controlling actions are for the good of the whole project. Individual success comes from being
identified with successful IDM conference.

It is during this stage of a project that the majority of work is carried out by the team to meet the
objectives. The project manager has to constantly keep the team focused on the deliverables and
ensure that progress is tracked and reported on.

• Maintaining control on a project has two very different aspects

• Progress control
• Environmental control

Process control refers to the physical processes put in place to control the conference. These
include activities such as recording time sheets for tracking progress, preparing progress reports,
managing change requests, holding reviews, and replanning meetings. Process control needs to
be enforced, and the rules for team discipline need to be clearly defined and understood.

34
Environmental control is about creating a working condition that makes the team feel that they
own the project, understand the level of environment there have in making decisions, and a
feeling of responsibility for delivering the conference objectives,

Project Control is a formal process in project management. In most respects, there is not a lot of
room for creativity in the Control Phase of project management.’

• Areas of Control

Impact of Project Control: Project Control has a direct correlation to conference progress and
stake-holder's expectations. In the other subsections of the Control Phase, the basic concepts of
control related to scope, change, schedule, cost, risk, and contract administration will be
reviewed.
Configuration Management: The configuration management system is a subsystem of the overall
project management information system.

• Scope Control

Scope Control is a straightforward concept. The intent of implementing a Scope Control process
is to identify and manage all elements that may increase or decrease the conference scope
beyond the required or defined need of the original approved Project Scope Statement.

• Risk Control

Risk control involves executing the Risk Management Plan in order to respond to risk events
over the course of the conference.

35
Quality Control:

Quality control involves monitoring specific project results to determine if they comply with
relevant quality standards and identifying ways to eliminate causes of unsatisfactory results.
• Cost Control:

Conference may fail to control cost, or go over budget, for many reasons. Often it is not a single
problem but a series of small problems that combined permit cost control to be sacrificed and
prevent the project from being completed successfully.

• Contract Administration Control:

Quite simply, contract administration control is the process of ensuring that the vendor's or
section within the organization’s performance meets contractual requirements.

• Monitoring

No matter how good the schedules are, if they are not used for monitoring they serve very little
purpose other than recording expectations. Monitoring does not require holding to the schedule
rigidly. Circumstances change and as the project develops new information becomes available
that may require a change in plans. The schedules serve as a yardstick against which to measure
progress, to show where and how plans must change. The schedule is a tool to keep attention on
the final objective and goal. Monitoring means; the progress of the project must be continuously
measured against the established schedule.

The conference progress must be continually monitored with respect to the schedule. The
engineer uses the schedule to see where he stands and to ensure that commitments are met as
planned. If they cannot be met, then those whose work depends on them can be forewarned.
Resources can be diverted, reallocated, and the schedule revised so the overall project
commitment is achieved.

36
The checking of progress against schedules is never interesting and the temptation is to avoid it.
Therefore, it should be a mandatory routine. The most useful way to do monitoring is to combine
it with the regular project technical reviews. Thus once technical progress is reviewed and
established, the project's status is checked against the schedule. Most projects do not always run
smoothly, unexpected difficulties do occur. Monitoring is the only way that resources can be
reallocated effectively and judiciously.

37
3.2
It's happened to nearly every project manager sometime in their career. They're given the
requirement to provide detailed performance reporting on a project and end up spending most of
their time entering hours worked into work packages in conference and estimating percent
complete on these packages - on a daily basis. Whether the requirement for that level of
reporting was real or perceived, the project manager finds that he's unable to manage the day to
day activities of his project because he's too busy trying to measure the project's performance.
When a successful IDM invests time, money, and other resources in a management conference,
its primary concern is always what it is getting in return for its investment. It is the responsibility
of the Project Manager to ensure these projects stay on schedule and within their approved
budget. Performance measurement provides the Project Manager with visibility to make sure he
is operating within the approved time and cost constraints and that the plan is performing
according to planned performance. It also alerts management if a project begins to run over
budget or behind schedule so actions can quickly be taken to get it back on track.
As the Project Management Office (PMO) manager it is your responsibility to ensure that project
performance is being captured and reported. It is also your responsibility to ensure that the level
of reporting is achievable and doesn't unnecessarily overburden or distract the project managers.
Next, you should determine what earned value metrics you want to track and present to
management. Although you can easily calculate most all earned value metrics you don't
necessarily need to track all these values and you definitely don't want to present them all to
management. Management just needs a quick view of the project's performance using only some
of these values and would be overwhelmed if they had a complete list. For most projects I track
the Schedule Variance (SV), Cost Variance (CV), Schedule Performance Index (SPI) and Cost
Performance Index (CPI). These four values provide a reliable measurement of the project's
performance.

Schedule Variance (SV)

If SV is zero, then the project is perfectly on schedule. If SV is greater than zero, the project is
earning more value than planned thus it's ahead of schedule. If SV is less than zero, the project is
earning less value than planned thus it's behind schedule.

38
Cost Variance (CV)
If CV is zero, then the project is perfectly on budget. If CV is greater than zero, the project is
earning more value than planned thus it's under budget. If CV is less than zero, the project is
earning less value than planned thus it's over budget.

Schedule Performance Index (SPI)

If SPI is one, then the project is perfectly on schedule. If SPI is less than 1 then it's behind
schedule. If SPI is greater than one then it's ahead of schedule. A well performing project should
have its SPI as close to one as possible.

Cost Performance Index (CPI)

If CPI is one, then the project is perfectly on budget. If CPI is less than 1 then it's over budget. If
CPI is greater than one then it's under budget. A well performing project should have its SPI as
close to one as possible.

Measuring project performance is an important part of project and program management. It

allows the PMO and project manager to identify cost and schedule problems early and take steps
for remediation quickly. It starts with setting the standards for the size of work packages,
applying credit for work performed, and which earned value metrics to track, which should be
included in the Cost Management Plan. Measuring performance provides the organization with a
clear picture of the health of its projects and can instill confidence in the project teams.
Additionally, these performance measures can help the PMO establish continuous improvement
initiatives in areas where projects commonly perform at lower levels. The usefulness of
measuring performance is evident and as long as organizations do not become overwhelmed with
them, these measures will remain important contributors to organizational success.

39
3.3
The IDM organize the work shop on the subject of control in the cost of organizing a conference.
Work shop was organized we estimated the cost of entertainment and other relevant matters. Our
special effort was to curtail the unnecessary expenses normally incurred. When such work shop
is organized. The participants in the work shop short great interest in learning may useful things
relevant to the careful management of the cost.

During the execution of a project, procedures for project control and record keeping become
indispensable tools to managers and other participants in the construction process. These tools
serve the dual purpose of recording the financial transactions that occur as well as giving
managers an indication of the progress and problems associated with a conference. The problems
of project control are aptly summed up in an old definition of a project as "any collection of
vaguely related activities that are ninety percent complete, over budget and late”

The limited objective of project control deserves emphasis. Project control procedures are
primarily intended to identify deviations from the project plan rather than to suggest possible
areas for cost savings. This characteristic reflects the advanced stage at which project control
becomes important. The time at which major cost savings can be achieved is during planning and
design for the conference. During the actual construction, changes are likely to delay the project
and lead to inordinate cost increases. As a result, the focus of project control is on fulfilling the
original design plans or indicating deviations from these plans, rather than on searching for
significant improvements and cost savings. It is only when a rescue operation is required that
major changes will normally occurring in the construction plan.

Finally, the issues associated with integration of information will require some discussion.
Project management activities and functional concerns are intimately linked, yet the techniques
used in many instances do not facilitate comprehensive or integrated consideration of project
activities. For example, schedule information and cost accounts are usually kept separately. As a
result, project managers themselves must synthesize a comprehensive view from the different

40
reports on the project plus their own field observations. In particular,
managers are often forced to infer the cost impacts of schedule changes, rather than being
provided with aids for this process. Communication or integration of various types of
information can serve a number of useful purposes, although it does require special attention in
the establishment of project control procedures.

Hall arrangement
Spoke the authority concern to arrange the hall at the lesser cost.

The advertisement
The advertisement was necessary to inform the people of the conference. But we took maximum
care to see that only reasonable amount of money was spend the advertisement.

3.4

Change control process is used for identifying and maintaining changes to baselines of a
conference. Change Control Procedure is a process of creating a formal method for identifying,
documenting, evaluating, and communicating all changes to conference. The major roles and
responsibilities involved in change control process are Project Manager who is responsible for
creating a change-sensitive environment from the beginning of the project by educating project
participants about need of change control.

Project team members provide estimate of effort needed to evaluate change request. Evaluates
change request to determine potential alternatives for implementing changes, recommend
alternatives, and estimate the effort to implement. Project board reviews and approves change
request referred from the Project Manager.

The Change Request Form is a formal document where the requester describes the changes that
need to be applied to the system. The form records the required change as well as recommended
changes and estimated costs of making the change. The Change Request Log provides a register
of all requested changes to the project. The Project Manager monitors the status of Change

41
Request and takes action as necessary to ensure sufficient progress towards
acceptance/rejection.

42