Escolar Documentos
Profissional Documentos
Cultura Documentos
ASSIGNMENT
Course Code : MS - 52
Course Title : Project Management
Assignment Code : MS-52/SEM - I /2011
Coverage : All Blocks
Note: Answer all the questions and send them to the Coordinator of the Study Centre you are attached with.
Q1. What are the phases of a Project Development Cycle? Give the salient tasks under each phase.
Q2. What are the traditional methods of financial evaluation of the projects? Give a comparative analysis of these methods.
Q3. Discuss the usefulness of matrix organization in project management. Also explain the recent trend in organization design.
Q4. Elaborate the concept of Earned Value of the Budget in PERT/COST System.
Q1. What are the phases of a Project Development Cycle? Give the salient tasks under
each phase.
Projects are the way that most new work gets delivered. All projects have certain characteristics in common.
1 They all have a beginning and an end.
2 All projects are unique. They may be similar to prior projects but they are unique in terms of timeframes, resources, business
environment, etc.
3 Projects result in the creation of one or more deliverables.
4 Projects have assigned resources - either full-time, part-time or both.
All organizations have projects. Projects can be managed using a common set of project management processes. In fact, a similar set of
project management processes can be utilized regardless of the type of project. For instance, all projects should be defined and planned and
all projects should have processes to manage scope, risk, quality, status, etc.
Some people are confused on the difference between project management and the project lifecycle. It takes both types of work to complete a
project successfully. The general difference is that project management is used to define, plan, control, monitor and close the project. The
work associated with actually building the project deliverables is accomplished through work that is referred to as the “lifecycle”. Project
management is used to build the schedule, but the vast majority of the work in the schedule is the lifecycle work associated with building the
project deliverables.
Projects can be managed using a common set of project management processes. In fact, a similar set of project management processes can
be utilized regardless of the type of project. All projects should be defined and planned and all projects should manage scope, risk, quality,
status, etc. One of the valuable things about having a common project management methodology in your organization is that the same
processes can be used on all projects.
The thing that makes a project unique is the deliverables that each project builds. For example, building a bridge is a different type of project
that building an IT solution, or building a new consumer product. The lifecycle describes the activities used to build the deliverables and is
generally unique for each project.
Even though all projects are unique, there are still common lifecycle models that can be used to build deliverables in similar ways. An
example of a lifecycle models is the generic “waterfall”. In a waterfall project you start off understanding the requirement of the solution,
designing a solution, building and testing a solution and then implementing the solution. Each of these major areas of focus is called a phase
(Analysis Phase, Design Phase, Construct Phase, etc.) The classic waterfall approach is the lifecycle model you would probably end up with if
you knew nothing about methodology and just had to build a project schedule from scratch.
=========================================================
What could be easier? Even if you have a small project you still go through these basic steps, although some of them may be a mental
exercise. If you have a forty-hour enhancement project, for instance, it may seem that you can jump right in with construction. But are you
really? It is more likely that you are receiving some type of service request that describes the work required (analysis and requirements),
which you take and mentally map into the work to be performed (design). You then make the enhancement changes required, test them and
implement them (construct, test, implement). The classic waterfall approach is the life cycle model you would probably end up with if you
knew nothing about methodology and just had to build a project schedule from scratch.
There are other life cycle models other than classic waterfall. Although the waterfall model can be applied to all projects, other life cycle
models might be more efficient and effective based on the characteristics of the project. For instance, if you are installing a software package,
you can utilize a specific life cycle model for package implementation that is light on the design and construct phases. Likewise, if you are
conducting a research and development (R&D) project, you can use a specific R&D life cycle model that takes into account that the work
might be thrown away when you are done. Other important life cycle models can be used to accelerate projects with certain characteristics.
IT online development projects, for instance, may be able to utilize iterative development and Agile techniques.
The important point is that a common, scalable project management process can be used effectively on all your projects. The specific,
detailed work to build your deliverables is referred to as the “life cycle”.
The Project DEVELOPMENT Cycle [ PDC ] refers to a logical sequence of activities to accomplish the project’s goals or objectives. Regardless
of scope or complexity, any project goes through a series of stages during its life. There is first an Initiation or Birth phase, in which the
outputs and critical success factors are defined, followed by a Planning phase, characterized by breaking down the project into smaller
parts/tasks, an Execution phase, in which the project plan is executed, and lastly a Closure or Exit phase, that marks the completion of the
project. Project activities must be grouped into phases because by doing so, the project manager and the core team can efficiently plan and
organize resources for each activity, and also objectively measure achievement of goals and justify their decisions to move ahead, correct, or
terminate. It is of great importance to organize project phases into industry-specific project cycles. Why? Not only because each industry
sector involves specific requirements, tasks, and procedures when it comes to projects, but also because different industry sectors have
different needs for life cycle management methodology. And paying close attention to such details is the difference between doing things well
and excelling as project managers.
Diverse project management tools and methodologies prevail in the different PDC phases. Let’s take a closer look at what’s important in
each one of these stages:
1) Initiation
In this first stage, the scope of the project is defined along with the approach to be taken to deliver the desired outputs. The project manager
is appointed and in turn, he selects the team members based on their skills and experience. The most common tools or methodologies used in
the initiation stage are Project Charter, Business Plan, Project Framework (or Overview), Business Case Justification, and Milestones Reviews.
*developing a business case.
*undertake a feasibility study
*establish the project charter
*appoint a project team
*set up a project office
*performance phase review.
-------------------------------------------------
2) Planning
The second phase should include a detailed identification and assignment of each task until the end of the project. It should also include a risk
analysis and a definition of a criteria for the successful completion of each deliverable. The governance process is defined, stake holders
identified and reporting frequency and channels agreed. The most common tools or methodologies used in the planning stage are Business
Plan and Milestones Reviews.
*build deliverables.
*monitor and controls.
*perform time management
*perform cost management
*perform quality management
*perform change management
*perform risk management
*perform issues management
*perform procurement management
*perform acceptance management
*perform communications management
-------------------------------------------------------------
4) Closure
In this last stage, the project manager must ensure that the project is brought to its proper completion. The closure phase is characterized by
a written formal project review report containing the following components: a formal acceptance of the final product by the client, Weighted
Critical Measurements (matching the initial requirements specified by the client with the final delivered product), rewarding the team, a list of
lessons learned, releasing project resources, and a formal project closure notification to higher management. No special tool or methodology
is needed during the closure phase.
==============================================
PDC Models: How They Differ and When to Use Them
PDC lifecycle models are not interchangeable. To deliver a quality system, it's critical to know the risks facing your project and to use a
model that reduces those risks. The following describes standard project lifecycle models, and reviews their strengths and weaknesses. These
standard models can be adapted to fit the industry issues, corporate culture, time constraints and team vulnerabilities which comprise your
environment.
What model do you use? Or, more appropriately, what model should you be using? Here's a summary to help you decide.
============================================
Pure Waterfall
This is the classical system development model. It consists of discontinuous phases:
Concept
Requirements
Architectural design
Detailed design
Coding and development
Testing and implementation
STRENGTHS
1 Minimizes planning overhead since it can be done up front.
2 Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff.
WEAKNESSES
1 Inflexible
2 Only the final phase produces a non-documentation deliverable.
3 Backing up to address mistakes is difficult.
-----------------------------------------------------------------------------
Pure Waterfall Summary
The pure waterfall performs well for products with clearly understood requirements or when working with well understood technical tools,
architectures and infrastructures. It's weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified
models may be more effective
==================================================
Spiral
The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks.
After major risks have been addressed, the spiral model terminates as a waterfall model. Spiral iterations involve six steps:
Determine objectives, alternatives and constraints.
Identify and resolve risks.
Evaluate alternatives.
Develop the deliverables for that iteration and verify that they are correct.
Plan the next iteration.
Commit to an approach for the next iteration.
STRENGTHS
1 Early iterations of the project are the cheapest, enabling the highest risks to be addressed at the lowest total cost. This ensures that as
costs increase, risks decrease.
2 Each iteration of the spiral can be tailored to suit the needs of the project.
WEAKNESSES
It is complicated and requires attentive and knowledgeable management to pull it off.
-----------------------------------------------------------------------------
Spiral Summary
For projects with risky elements, it's beneficial to run a series of risk-reduction iterations which can be followed by a waterfall or other non-
risk-based lifecycle
===========================================
Modified Waterfall
The modified waterfall uses the same phases as the pure waterfall, but is not done on a discontinuous basis. This enables the phases to
overlap when needed. The pure waterfall can also split into subprojects at an appropriate phase (such as after the architectural design or
detailed design).
STRENGTHS
1 More flexibility than the pure waterfall model.
2 If there is personnel continuity between the phases, documentation can be substantially reduced.
3 Inplementation of easy areas do not need to wait for the hard ones.
WEAKNESSES
1 Milestones are more ambiguous than for the pure waterfall.
2 Activities performed in parallel are subject to miscommunication and mistaken assumptions.
3 Unforseen interdependencies can create problems.
------------------------------------------------------------------------------------------------
Modified Waterfall Summary
Risk reduction spirals can be added to the top of the waterfall to reduce risks prior to the waterfall phases. The waterfall can be further
modified using options such as prototyping, JADs or CRC sessions or other methods of requirements gathering done in overlapping phases
=====================================
Evolutionary Prototyping
Evolutionary prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each
iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration.
STRENGTHS
1 Customers can see steady progress.
2 This is useful when requirements are changing rapidly, when the customer is reluctant to commit to a set of requirements, or when no one
fully understands the application area.
WEAKNESSES
1 It is impossible to know at the outset of the project how long it will take.
2 There is no way to know the number of iterations that will be required
-----------------------------------------------------------------------
Evolutionary Prototyping Summary
The manager must be vigilant to ensure it does not become an excuse to do code-and-fix development
===========================
Code-and-Fix
If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely produces useful results. It is very dangerous as
there is no way to assess progress, quality or risk.
STRENGTHS
1 No time spent on "overhead" like planning, documentation, quality assurance, standards enforcement or other non-coding activities.
2 Requires little experience
WEAKNESSES
1 Dangerous.
2 No means of assessing quality or identifying risks.
3 Fundamental flaws in approach do not show up quickly, often requiring work to be thrown out
-------------------------------------------------------------------------------------------------------------
Code-and-Fix Summary
Code-and-fix is only appropriate for small throwaway projects like proof-of-concept, short-lived demos or throwaway prototypes
=============================
Staged Delivery
Although the early phases cover the deliverables of the pure waterfall, the design is broken into deliverables stages for detailed design,
coding, testing and deployment.
STRENGTHS
*Can put useful functionality into the hands of customers earlier than if the product were delivered at the end of the project
WEAKNESSES
*Doesn't work well without careful planning at both management and technical levels.
--------------------------------------------------------------------------------------------
Staged Delivery Summary
For staged delivery, management must ensure that stages are meaningful to the customer. The technical team must account for all
dependencies between different components of the system
===============================
Evolutionary Delivery
Evolutionary delivery straddles evolutionary prototyping and staged delivery.
STRENGTHS
*Enables customers to refine interface while the architectural structure is as planned.
WEAKNESSES
*Doesn't work well without careful planning at both management and technical levels
--------------------------------------------------------------------------------
Evolutionary Delivery Summary
For evolutionary delivery, the initial emphasis should be on the core components of the system. This should consist of lower level functions
which are unlikely to be changed by customer feedback
==========================
Design-to-Schedule
Like staged delivery, design-to-schedule is a staged release model. However, the number of stages to be accomplished are not known at the
outset of the project.
STRENGTHS
1 Produces date-driven functionality, ensuring there is a product at the critical date.
2 Covers for highly suspect estimates.
WEAKNESSES
*Won't be able to predict the full range of functionality
--------------------------------------------------------------------------------
Design-to-Schedule Summary
In design-to-schedule delivery, it is critical to prioritize features and plan stages so that the early stages contain the highest-priority features.
Leave the lower priority features for later
=========================================
Design-to-Tools
When using a design-to-tools approach, the capability goes into a product only if it is directly supported by existing software tools. If it isn't
supported, it gets left out. Besides architectural and functional packages, these tools can be code and class libraries, code generators, rapid-
development languages and any other software tools that dramatically reduce implementation time.
STRENGTHS
*When time is a constraint, may be able to implement more total functionality than possible when building everything "from scratch".
WEAKNESSES
1 You lose a lot of control over the product.
2 You may become "locked in" to a vendor. If it is for long-term functionality, vendor lock-in can become a weak link.
3 May not be able to implement all features desired or in the manner desired.
--------------------------------------------------------------------------------
Design-to-Tools Summary
Consider the tradeoffs of time-to-market versus lock-in and functionality compromises. This may be an appropriate approach for a high-risk
element of the overall project or architecture
==================================
Off-the-Shelf
Following requirements definition, analysis must be done to compare the package to the business, functional and architectural requirements.
STRENGTHS
*Available immediately and usually at far lesser cost
WEAKNESSES
*Will rarely satisfy all system requirements.
----------------------------------------------------------------------------------
Off-the-Shelf Summary
It is critical to know how the desired features compare with the packaged set and if the package can be customized
##############################################
Q2. What are the traditional methods of financial evaluation of the projects? Give a
comparative analysis of these methods.
Various project evaluation and analysis techniques namely
-Payback Method,
-Accounting rate of return,
-Internal rate of return,
-Net present Value, and
-Profitability Index
METHODS OF RANKING
1.PAYBACK METHOD
The payback period is the number of years required to return the original investment from the net cash flows (net operating income after
taxes plus depreciation).
Example
Assume the firm is considering two projects; project A and project B, each requires an investment of $100 millions. The cost of capital is
10%. Below is the summary of expected net cash flows in millions.
Net flow summary
year 1...............project a.............project b
50-----------------10
year 2................40-----------------20
year 3................30-----------------30
year 4................10-----------------40
year 5................1-------------------50
year 6................1-------------------60
ARR is also known as accrual accounting rate of return unadjusted rate of return model and the book value model.
Its compilations is related with
- Conventional accounting models of calculating income and required investment
- Shows the effect of an investment on project’s financial statement.
EXAMPLE
Assume the company invested in the consturction of machine,
whose investment cost is $607,500 useful life is 4 years. estimated
disposal value is zero, and expected annual cash inflow from the
operation is $200,000.
Annual depreciation would be = original investment/ useful life
=$607,500 / 4 = $ 151,875.
ARR = 200,000- 151875/ 607500= 7.92 %
NPV = SUM of F /[ 1+ k]
Ft= net cash flow at time t.
k=cost of capital
Io= initial cash flow
Some value of R will cause the sum of the discounted receipts to the equal the initial cost of the project, making the equation equal to zero,
and that value R will be the project’s internal rate of return.
IRR--Advantages/Disadvantages
1) Advantages
• Considers all cash flows
• Considers time value of money
• Comparable with hurdle rate
2) Disadvantages
• Does not show dollar improvement in value of firm if project is accepted
• IRR can be affected by the scale (size) of the project, i.e., Io
• Possible existence of multiple IRRs
Relationship Between IRR and the NPV Profile
1) When the IRR = the firm's hurdle rate, NPV = 0
2) When the IRR < the firm's hurdle rate, NPV < 0
3) When the IRR > the firm's hurdle rate, NPV > 0
Note: Ranking conflicts are unusual but can occur. These conflicts are relevant only when there are multiple acceptable mutually exclusive
projects
3. Profitability index
It is sometimes called Benefit Cost Ratio or present value index. It is calculated by taking the present value of cash inflows divided by the
present value of cash outflows. The decision criteria is to accept project with a Profitability Index (PI) greater than one.
This ratio gives the return in the present terms per unit invested. Using this criterion, projects will be ranked from the one with highest PI
down to one with the lowest, and then project would be selected in the order of ranking up to the point where the budget is exhausted.
This criterion is simple but suffers from two basic limitations.
It cannot be used to except in cases where there is only a single constraint. In case where the capital is rationed in more that one period or
where the capital is not the only constraint, the criteria will not provide the best solution.
It looks projects individually and does not take into account the overall portfolio where correlation of projects’ returns is important
##########################################
Q3. Discuss the usefulness of matrix organization in project management. Also explain
the recent trend in organization design.
THE POPULAR ORGANIZATIONS IN PROJECT MANAGEMENT
Functional structure
Employees within the functional divisions of an organization tend to perform a specialized set of tasks, for instance the engineering
department would be staffed only with engineers. This leads to operational efficiencies within that group. However it could also lead to a lack
of communication between the functional groups within an organization, making the organization slow and inflexible.
As a whole, a functional organization is best suited as a producer of standardized goods and services at large volume and low cost.
Coordination and specialization of tasks are centralized in a functional structure, which makes producing a limited amount of products or
services efficient and predictable. Moreover, efficiencies can further be realized as functional organizations integrate their activities vertically
so that products are sold and distributed quickly and at low cost . For instance, a small business could start making the components it
requires for production of its products instead of procuring it from an external organization.But not only beneficial for organization but also for
employees faiths.
Divisional structure
Also called a "product structure", the divisional structure groups each organizational function into a divisions. Each division within a divisional
structure contains all the necessary resources and functions within it. Divisions can be categorized from different points of view. There can be
made a distinction on geograpical basis or on product/service basis .
Matrix structure
The matrix structure groups employees by both function and product. This structure can combine the best of both separate structures. A
matrix organization frequently uses teams of employees to accomplish work, in order to take advantage of the strengths, as well as make up
for the weaknesses, of functional and decentralized forms. An example would be a company that produces two products, "product a" and
"product b". Using the matrix structure, this company would organize functions within the company as follows: "product a" sales department,
"product a" customer service department, "product a" accounting, "product b" sales department, "product b" customer service department,
"product b" accounting department. Matrix structure is amongst the purest of organizational structures, a simple lattice emulating order and
regularity demonstrated in nature.
• Weak/Functional Matrix: A project manager with only limited authority is assigned to oversee the cross- functional aspects of the project .
The functional managers maintain control over their resources and project areas.
• Balanced/Functional Matrix: A project manager is assigned to oversee the project. Power is shared equally between the project manager
and the functional managers. It brings the best aspects of functional and projectized organizations. However, this is the most difficult system
to maintain as the sharing power is delicate proposition.
• Strong/Project Matrix: A project manager is primarily responsible for the project. Functional managers provide technical expertise and
assign resources as needed.
Among these matrixes, there is no best format; implementation success always depends on organization's purpose and function.
HORIZONTAL ORGANIZATION
Horizontal organizations consist of teams which are organized around business processes and which are responsible for the results they
generate. By flattening portions of the organization and holding the team members accountable for results, it asserts that decisions will be
made more quickly and more consistently with business objectives. This tool seeks to reduce problems with cross-functional coordination by
ensuring that the team members have the necessary skills to have end-to-end accountability for the process.
Approach
• The following steps are critical to creating a horizontal organization:
• Organize teams around the most critical business processes.
• Give team members ownership of the process and assign a clear process leader.
• Cross-train team members for the range of skills needed for their process.
• Tie performance measures directly to customer requirements for the process, and reward individuals for individual and team contributions.
• Create career development paths consistent with developing team consistent with developing team skills.
• Redefine managers' roles to focus on enabling teams to perform through training, coaching, sharing, information, and setting strategic
direction.
Benefits
Horizontal organizations are often used to structure processes which requires extensive cross-functional coordination. This tool increases the
responsiveness and productivity of an organization. Additionally, horizontal organizations can be used to balance local and global needs within
a multinational corporation by creating a network linking the disparate operations.
[these types of organization structure are still very popular with the
''brick and mortar '' type of manufacturing / marketing cos.
these organization are visible and can be seen in types like
-product divisions
-business divisions
-geographical divisions
-functional divisions
etc etc
==========================================###
virtual organization
A virtual organization or company is one whose members are geographically apart, usually working by computer EMAIL and GROUPWARE
while appearing to others to be a single, unified organization with a real physical location.
But there is more to virtual organizations then simply replacing the location where people work.
What makes a virtual organization different?
It removes many barriers - especially that of time and location.
It emphasizes concentrating on new services and products, especially those with intensive information and knowledge characteristics, rather
than concentrating on cost savings made possible by removing the barriers.
It goes beyond outsourcing and strategic alliances and is more flexible in:
• that it has continuously changing partners,
• the arrangements are loose and goal oriented,
• emphasizes the use of knowledge to create new products and services,
• its processes can change quickly by agreement of the partners.
What are the steps to a virtual organization?
Often the steps here go through:
• outsourcing mainly to reduce costs where there is some experience in working at a distance, but three is one dominant party and high
certainty of what everyone must do.
• forming strategic alliances to share the work and gain experience in developing and sharing common goals. Here there is no dominant
party although the parties are fixed. and
• then becoming virtual organizations to achieve flexibility. Now the partners themselves can quickly change, with greater emphasis on the
use of knowledge to create new and innovative products.
Why virtual?
What are the reasons for organizations becoming virtual. These include:
• Globalization, with growing trends to include global customers,
• Ability to quickly pool expert resources,
• Creation of communities of excellence,
• Rapidly changing needs,
• Increasingly specialized products and services,
• Increasing required to use specialized knowledge
[these types of organization structure are becoming very popular with the
''SERVICE '' type of cos.
these organization are visible and can be seen in types like
-insurance
-financial
-consulting
-professional services
etc etc
=========================================================###
Matrix structure
Different structures can be combined together. When one has two parallel
organizational structures this is called a matrix structure. The idea is to combine the
advantages of two structures, but this has the obvious disadvantage of being harder to
coordinate and introducing more potential conflict.
In the past most large companies were centralized – that is, involved structures in
which decisions were taken at the centre or upper levels of organization. Just as there
has been a move to flatter organizations, so there has been a move to decentralized
ones.
**MATRIX STRUCTURE
Reinforces & broadens technical excellence
Facilitates efficient use of resources
Balances conflicting objectives of the organization
Increases power conflicts
Increases confusion & stress for 2-boss employees
Impedes decision making
###############################################################
Q4. Elaborate the concept of Earned Value of the Budget in PERT/COST System.
Earned Value Management
Earned Value Management (EVM) is a systematic project management process used to indicate variances in projects in an objective manner,
based on the evaluation of the work performed compared to the work planned. When properly applied to a project, EVM provides and early
warning indication of project performance issues.
EVM uses principles of Earned Value (EV), which is a project management tool used to measure project performance. EV is essentially an
approach for project managers to monitor the project plan, actual work, and work completed to verify if the project is performing as
expected.
In simple terms EV compares the actual project performance to the planned performance with respect to budget and schedule at any point in
time during the project.
Why Use Earned Value?
Earned Value can be a valuable project management tool, but the utility of it must be understood for it to be used correctly. EV indentifies
the variances in a project and informs a project manager on what is occurring in a project, but does not identify the "source" or "cause" for
the variance, nor does it address the required action necessary for the "correction" of the variance.
Earned Value provides an objective assessment of project performance and once introduced can provided a common understanding and
perspective among project mangers regarding the metrics of project performance.
The other major benefit to using EV is the ability to evaluate the performance of a project at any point during the project's life cycle, not just
at the completion of a project. How many times have you come to the end of a project and learned that the project performance did not
meet expectations? By the end of the project it is too late to take any corrective action. Earned Value allows project managers to evaluate
and monitor their project through out the project life cycle, which will allow for better project control.
Key Components to Earned Value
There are three key components to EV that are used when evaluating projects for EVM.
• Project Budget - The budget has two values that are used for EV, which are;
o Budgeted Cost of Work Schedule (BCWS) - BCWS is the baseline cost up to the current date.
o Actual Cost of Work Performed (ACWP) - ACWP are the actual cost required to complete all or some portion of the tasks to the current
date.
o Project Schedule - The project schedule has two values that are used for EV, which are;
♣ Scheduled Time for Work Performed (STWP)
♣ Actual Time of Work Performed (ATWP)
o Value of Work Performed - This is the value earned (reported percent complete) by the work performed and is referred to as the Budgeted
Cost of Work Performed (BCWP).
Earned Value Graph
The final outcome of an EV analysis is a three line graph showing cost over time for a project, which helps visualizes the key values used in
EV. The three lines indicated are the BCWS, ACWP, and BCWP as described above. From reading the graph you can determine project
variances .
Looking at the data date the project is behind where it should be as indicated by the variance between BCWP and BCWS, and the project is
over budget as indicated by the variance between the ACWP and BCWS.
Performance:
- Unexpected technical problems arise.
- Insufficient resources are available when needed.
- Insurmountable technical difficulties are present.
- Quality or reliability problems occur.
- Client requires changes in system specifications.
- Inter functional complications arise.
- Technological breakthroughs affect the project.
Cost:
- Technical difficulties require more resources.
- The scope of the work increases.
- Initial bids or estimates were too low.
- Reporting was poor or untimely.
- Budgeting was inadequate.
- Corrective control was not exercised in time.
- Input price changes occurred.
Time:
- Technical difficulties took longer than planned to solve.
- Initial time estimates were optimistic.
- Task sequencing was incorrect.
- Required inputs of material, personnel, or equipment were unavailable when needed.
- Necessary preceding tasks were incomplete.
- Customer-generated change orders required rework.
- Governmental regulations were altered.
And these are only a few of the relatively “mechanistic” problems that project control can occur. Actually, there are no purely mechanistic
problems on projects. All problems have a human element, too. For example, humans, by action or inaction, set in
motion a chain of events that leads to a failure to budget adequately, creates a quality problem, leads the project down to a technically
difficult path, or fails to note a change in government regulations. If, by chance, some of these or other things happen (as a result of
human action or not), humans are affected by them. Frustration, pleasure, determination, hopelessness, anger and may other emotions arise
during the course of a project. They affect the work of the individuals who feel them – for better or worse. It is over this welter of
confusion, emotion, fallibility, and general cussedness that the PM tries to exert control.
All of these problems, always combinations of the human and mechanistic, call for intervention and control by the project manager. There are
infinite “slips” especially in projects where the technology or deliverables are new and unfamiliar, and project
managers, like most managers, find control is a difficult function to perform. There are several reasons why this is so. One of the main
reasons is that project managers, again like
most managers, do not discover problems. In systems as complex as projects, the task of defining the problems is formidable, and thus
knowing what to control is not a simple task.
Another reason control is difficult is because, in spite of an almost universal need to blame some person for any trouble, it is often almost
impossible to know if a problem resulted from human error or from the random application of Murphy’s Law.
Project managers also find it tough to exercise control because the project team, even on large projects, is an “in-group”. It is “we” while
outsiders are “they”. It is usually hard to criticize friends, to subject them to control. Further, many project managers see
control as an ad-hoc process. Each need to exercise control is seen as a unique event, rather than as one instance of an ongoing and
recurring process.
-that projects are drifting out of control if the achievement of milestones is threatened.
Because control of projects is such a mixture of feeling and fact of human and mechanism, of causation and random chance, we must
approach the subject in an extremely orderly way.
This why we start by examining the general purposes of control. Then we consider the basic structure of the process of control. We do this by
describing control theory in the form of a cybernetic control loop. While most projects offer little opportunity for the actual application of
automatic feedback loops, the system provides us with a comprehensive
but reasonably simple illustration of all the elements necessary to control any system.
The process of controlling a project (or any system) is far more complex than simply waiting for something to go wrong and the, if possible,
fixing it. We must decide at what
points in the project we will try to exert control, what is to be controlled, how it will be measured, how much deviation from plan will be
tolerated before we act, what kinds of interventions should be used, and how to spot and correct potential deviations before they occur. In
order to keep these and other such issues sorted out, it is helpful to begin a consideration of control with a brief exposition on the theory of
control,
No matter what our purpose in controlling a project, there are three basic types of control mechanisms we can use: cybernetic control,
go/no-go control and post-control.
Cybernetic control
Cybernetic or steering control is by far the most common type of control system. The key feature of cybernetic control is its automatic
operation.
- a system is operating with inputs being subjected to a process that transforms them into outputs. It is this system that we wish to control.
In order to do so, we must monitor the system output.
This function is performed by sensors that measure one or more aspects of the output, presumably those aspects one wishes to control.
Measurements taken by a sensor are transmitted to the comparator, which compares them with a set of predetermined standards.
The difference between actual and standard is sent to the decision maker, which determines whether or not the difference is of sufficient size
to deserve correction. If the difference is
large enough to warrant action, a signal is sent to the effectors, which acts on the process or on the inputs to produce outputs that conform
more closely to the standard.
A cybernetic control system that acts to reduce deviations from standard is called a negative feedback loop. If the system output moves away
from the standard in one direction, the control mechanism acts to move it in the opposite direction. The speed or force with
which the control operates is, in general, proportional to the size of the deviation from the standard. The precise way in which the deviation is
corrected depends on the nature of the
operating system and the design of the controller.
Cybernetic controls come in three varieties, or orders, differing in the sophistication with which standards are set.
a simple, first order control system, a goal seeking device. The standard is set and there is no provision made for altering it except by
intervention from the outside. The common thermostat is a time-worn example of a first- order controller. One sets the standard temperature
and the heating and air-conditioning systems operate to maintain it.
Relatively few elements of a project (as opposed to the elements of a system that operates more or less continuously) are subject to
automatic control. An examination of the details of an action plan will reveal which of the project’s tasks are largely mechanistic and
represent continuous types of systems. If such systems exist, and if they operate across a sufficient time period to justify the initial expense
of creating an automatic control, then a
cybernetic controller is useful.
Given the decisions about what to control, the information requirements of a cybernetic controller are easy to describe, if not to meet.
First, the PM must decide precisely what characteristics of an output (interim output or final output) are to be controlled.
Second, standards must be set for each characteristic.
Fourth, these measurements must be transformed into a signal that can be compared to a standard signal.
Fifth, the difference between the two is sent to the decision maker, which detects it, if it is sufficiently large, and
If the control system is designed to allow the effectors to take one or more of several actions, an additional piece of information is needed.
Knowledge of cybernetic control is important because all control systems are merely variants, extensions or non-automatic modifications of
such controls. Because most projects have relatively few mechanistic elements that can be subjected to classic cybernetic controls,
this concept of control is best applied to tracking the system and automatically notifying the project manager when things threaten to get out
of control.