Project management

Ch Muhammad Irfan +92-345-4426176 Facebook.com/chmuhammedirfan skype: ch.irfan786
Ch Muhammad Irfan +92-345-4426176
PROJECT
MANAGEMENT
FUNDAMENTAL
MBA ACCOUNTING &
FINANCE
2ND
QUARTERQuestion:

What is Project? What are the constraint of a project/
parameters of the project?
Answer:
Definition:-
A project is a sequence of unique, complex, and connected activities that have one goal or purpose and that
must be completed by a specific time, within budget, and according to specification.
Following are the constraint of a project:
 Scope:
Scope is a statement that defines the boundaries of the project. It tells not only what will be
done but also what will not be done. In the engineering profession, it is generally called a statement of work.
 Quality:
It is the agreed quality of the project outcomes everything from the requirements and design documents to
the project products or services e.g., a new computer system, a bridge, or whatever is being produced.
Quality is not a part of the project management triangle, but it is the ultimate objective of every delivery.
Hence, the project management triangle represents implies quality.
 Time
This refers to the actual time required to produce a deliverable. Which in this case, would be the end result of
the project? Naturally, the amount of time required to produce the deliverable will be directly related to the
amount of requirements that are part of the end result (scope) along with the amount of resources allocated
to the project (cost).
 Cost
This is the estimation of the amount of money that will be required to complete the project. Cost itself
encompasses various things, such as: resources, labor rates for contractors, risk estimates, bills of materials,
et cetera. All aspects of the project that have a monetary component are made part of the overall cost
structure.
 Resources:
Resources are assets such as people, equipment, physical facilities, or inventory that have limited
availabilities, can be scheduled, or can be leased from an outside party.

Topic:
Managing the Creeps
Answer:
 Scope Creep:
Scope creep refers to the change in a project's scope after the project work
has started. Typically, the scope expands by the addition of new features to an already approved feature list.”
 Poor implementation of change
control.
 Incomplete gathering of
requirements before project
execution begins.
 Insufficient involvement of critical
stakeholders (including customer)
 Lack of support from executive
sponsor and enforcement power in
project manager
 Scope Creep is one of the main
reasons why projects fail.
 A variety of reasons can be
responsible for scope creep.
 Scope verification is key.
 Hope Creep:
Yes hope creep is different from scope creep. In short, hope creep is lying about
the status of the project/task until you're caught. For project managers, hope creep happens when the
project manager starts lying about the status of the project (which is behind schedule and over-budget) to
the stakeholders and the client, while hoping that he will be able to get the project on track before anyone
discovers the truth. Since hope creep involves lying to important people either inside or outside the
company, the project manager will always be in panic mode because he knows that he'll most likely be fired
when the truth comes out, and it usually does.
Effort Creep:
Effort creep is when one of your team members makes a huge effort on a task that is nearly
done, but cannot finish it. For example, a task is 80% done in one week, and the team member is working on
the remaining 20% for several weeks, with no end in sight. This is very common in software projects, and the
perfect remedy for effort creep is to assign the remainder of the task to someone else who has more
experience in the particular area of the task.
 Feature Creep:
Closely related to scope creep is feature creep. Feature creep results when
team members randomly add features and functions to the deliverable that they think the client would want
to have.
Topic:
Work Break down Structure (WBS) and its uses.
Answer:
Definition:

A complex project is made manageable by first breaking it down into individual components in a hierarchical
structure, known as the work breakdown structure, or the WBS. Such a structure defines tasks that can be
completed independently of other tasks, facilitating resource allocation, assignment of responsibilities, and
measurement and control of the project.
The work breakdown structure can be illustrated in a block diagram:
 Terminology for Different Levels:
Each organization uses its own terminology for classifying WBS components according to their level in the
hierarchy. For example, some organizations refer to different levels as tasks, sub-tasks, and work packages, as
shown in the above outline. Others use the terms phases, entries, and activities.
 Organization by Deliverables or Phases:
The WBS may be organized around deliverables or phases of the project life cycle. Higher levels in the
structure generally are performed by groups. The lowest level in the hierarchy often comprises activities
performed by individuals, though a WBS that emphasizes deliverables does not necessarily specify activities.
 Level of Detail:
The breaking down of a project into its component parts facilitates resource allocation and the assignment of
individual responsibilities. Care should be taken to use a proper level of detail when creating the WBS. On the
one extreme, a very high level of detail is likely to result in micro-management. On the other extreme, the
tasks may become too large to manage effectively. Defining tasks so that their duration is between several
days and a few months works well for most projects.
 WBS's Role in Project Planning
The work breakdown structure is the foundation of project planning. It is developed before dependencies are
identified and activity durations are estimated. The WBS can be used to identify the tasks in the CPM and
PERT project planning models.
Topic: What Is POS.? Also describes its purpose:
Answer:

 Pos:
The POS defines the scope and the business rationale of the project. It is intended to
communicate to all project personnel and stakeholders exactly what will be implemented and why. Not just
why it is needed, but why it needs to be implemented in this way.
 Purpose of the POS
The following are the purpose of POS:
 Problem or opportunity
 Project goal
 Project objectives
 Success criteria
 Assumptions, risks, and obstacles
 Problem or Opportunity:
The first part of the POS is a statement of the problem or
opportunity that the project addresses. This statement is fact—it does not need to be defined or defended.
Everyone in the organization will accept it as true. This is critical because it provides a basis for the rest of the
document. The POS may not have the benefit of the project manager’s being present to explain what is
written or to defend the reason for proposing the project to management. A problem or opportunity
statement that is known and accepted by the organization is the foundation on which to build a rationale for
the project. It also sets the priority with which management will view what follows. If you are addressing a
high priority area or high-business-value area, your idea will get more attention and senior management will
read on.
 Establishing the Project Goal:
The second section of the POS states the goal of the project—what you intend to
do to address the problem or opportunity. The purpose of the goal statement is to get senior management to
value your idea enough to read on. In other words, they should think enough of the idea to conclude that it
warrants further attention and consideration. Others may propose the same issue. Because yours will not be
the only proposal that’s submitted, you want it to stand out among the crowd.
A project has one goal. The goal gives purpose and direction to the project. At a very high level, it defines the
final deliverable or outcome of the project in clear terms so that everyone understands what is to be
accomplished. The goal statement will be used as a continual point of reference for any questions that arise
regarding the project’s scope or purpose. The goal statement must not contain any language or terminology
that might not be understandable to anyone having occasion to read your POS. In other words, no “techie
talk” is allowed. It is written in the language of the business so that anyone who reads it will understand it
without further explanation from the proposer. Under all circumstances, avoid jargon.
 Defining the Project Objectives
The third section of the POS describes the project objectives. Think of objective
statements as a more detailed version of the goal statement. The purpose of objective statements is to clarify
the exact boundaries of the goal statement and define the boundaries or the scope of your project. In fact,
the objective statements you write for a specific goal statement are nothing more than decomposition of the
goal statement into a set of necessary and sufficient objective statements. High-level requirements are often

used as project objectives. I have done that with good results. That is, every objective must be accomplished
in order to reach the goal, and no objective is extra.
 Identifying Success Criteria
The fourth section of the POS answers the question, “Why do we want to do this
project?” It is the measurable business value that will result from successfully completing this project. It sells
the project to senior management and it is a standard that can be used to compare projects to one another.
No matter how you define success criteria, they all reduce to one of the following three types.
 Increasing Revenue
 Avoiding Cost
 Improving Services
 Listing Assumptions, Risks, and Obstacles
The fifth section of the POS identifies any factors that can affect the outcome of the
project and that you want to bring to the attention of senior management. These factors can affect
deliverables, the realization of the success criteria, the ability of the project team to complete the project as
planned, and any other environmental or organizational conditions that are relevant to the project. You want
to record anything that can go wrong.
Topic: Project Management Life Cycle and New Product Management Life Cycle:
Project Management Life Cycle:
Any project, from building a new office to launching a marketing campaign, requires thoughtful and
directed project management.
Followings are the phases of PML:
 Initiation
Initiation refers to choosing the goal. What is actually happening? Are you building a new
office? Launching a new product? Make sure your goal is clearly worded and very concrete – this will serve as
the backbone to your whole project. Once you’ve clearly defined the goal, you will want to define the scope
of the project. Look at it from afar to figure out how wide it extends. If you’re building an office, do you need
to find and purchase land, or are you just renovating an older space. This is the point where you will want to
assign a project manager to take control of the project and be responsible for its success
 Planning
Planning the project is possibly the most important phase in project management. The
project manager should write project plans that outline what is being done and what items and actions are
needed to do it. These plans will be used throughout the project to more clearly define a plan and make sure
it is being executed properly. They can include such steps as:
1. Estimating resources and time
2. Identify the order of tasks
3. Execution schedule
4. Risk Analysis
5. Communication Systems
 Execution and Control
Once you’ve got your plan completed, you can begin executing and controlling your
project. You will inevitably have to modify your plan along the way and your project manager should have

good project controls to make sure the whole operation is monitored and reacted to appropriately. This can
also be tracked with efficient status reports and communication systems.
 Wrap-up / Closing out project:
After a project has been completed, the last step is the final wrap-up. A complete summary
should be written of every step of the project along with changes made to the original outline of the work as
well as any alterations to budgets and the overall lessons learned from the project. This will be very helpful to
you and your company in completing future projects.
New Product Development:
Developing a new product involves a number of stages which typically center on the following key areas:
 The Idea:
Every product has to start with an idea. In some cases, this might be fairly simple, basing the new product on
something similar that already exists. In other cases, it may be something revolutionary and unique, which
may mean the idea generation part of the process is much more involved. In fact, many of the leading
manufacturers will have whole departments that focus solely on the task of coming up with ‘the next big
thing’.
 Research:
An organization may have plenty of ideas for a new product, but once it has selected the best of them, the
next step is to start researching the market. This enables them to see if there’s likely to be a demand for this
type of product, and also what specific features need to be developed in order to best meet the needs of this
potential market.
 Development:
The next stage is the development of the product. Prototypes may be modified through various design and
manufacturing stages in order to come up with a finished product that consumers will want to buy.
 Testing:
Before most products are launched and the manufacturer spends a large amount of money on production
and promotion, most companies will test their new product with a small group of actual consumers. This
helps to make sure that they have a viable product that will be profitable, and that there are no changes that
need to be made before it’s launched.
 Analysis:
Looking at the feedback from consumer testing enables the manufacturer to make any necessary changes to
the product, and also decide how they are going to launch it to the market. With information from real
consumers, they will be able to make a number of strategic decisions that will be crucial to the product’s
success, including what price to sell at and how the product will be marketed.
 Introduction:

Finally, when a product has made it all the way through the new product development stage, the only thing
left to do is introduce it to the market. Once this is done, good product life cycle management will ensure the
manufacturer makes the most of all their effort and investment.
Topic: Define Risk and also explain Risk Management Process with sufficient
detail?
 Risk:
A situation involving exposure to danger.
Risk management process can be defined by the following details:
 Risk identification
 Risk assessment
 Risk mitigation
 Risk monitoring
 Risk Identification
In order to establish a risk management program for the project, the project manager and project team must
go through several processes. The first is risk identification, and it generally occurs as part of project planning
activities. In this part of the process, the entire planning team is brought together to discuss and identify the
risks that are specific to the current project. Risk has following categories:
 Technical Risks
 Project Management Risks
 Organizational Risks
 External Risks
 Risk Assessment
When the team puts together the risk identification list, nothing should be ruled out at first. Let the team
brainstorm risk without being judgmental. Some risks are so small that you will eventually ignore them. For
instance, the risk that a meteor will destroy the building in which you work is miniscule. If you’re worrying
about things like this, you won’t be much of a project manager. You need to manage the risks that might
actually occur.
There are two major factors in assessing risk.
 Static Risk
 Dynamic Risk

 Risk Mitigation
The next step in risk management is to plan, as much as possible, the responses that will be used if the
identified risks occur. For instance, you may want to include a clause in your hardware contract with the
vendor that if the servers don’t get to you by a certain date, then the vendor will pay a penalty. This penalty
gives the vendor an incentive to analyze and mitigate the risks involved in late delivery of key equipment. For
all the risks listed in the risk identification that you choose to act upon, you should have some type of action
in mind. It’s not enough to simply list the risks; you need to plan to do something about the risk events should
they occur. It has following steps:
 Accept
 Avoid
 Contingency
 Mitigate
 Transfer
 Risk Monitoring
Once you’ve identified the risk, assessed the probability and impact of the risks, and planned what to do if
the risk event occurs, you need to monitor and control the project risks. The process of writing down the
risks, assessing them, and posting them in the Team War Room makes everyone on the project team aware
of their existence and is a good place to start. Start by creating a risk log. This document lists all risks that you
want to manage, identifies who is supposed to manage the risk, and specifies what should be done to
manage the risk event. A risk log is a simple template that can be created in a text document or spreadsheet
package. A risk log is a simple template that you can create in Microsoft
Word. A typical risk log contains the following five fields:
 ID number
 Risk description
 Risk owner
 Action to be taken
 Outcome
Topic: Write a note on the Scope of Triangle?
Scope Triangle
Scope Triangle’ or the ‘Quality Triangle’ this shows the trade-offs inherent in any project.
The triangle illustrates the relationship between three primary forces in a project. Time is the available time
to deliver the project, cost represents the amount of money or resources available and quality represents the
“fit-topurpose” that the project must achieve to be a success.
In reality the normal situation is that one of these factors is fixed and the other two will vary in inverse
proportion to each other. For example “Time” is often fixed in a project and the “Quality” of the end project
will depend on the “Cost” or resources available. Similarly if you are working to a fixed level of “Quality” then
the “Cost” of the project will largely be dependent upon the “Time” available (if you have longer you can do it
with fewer people).
A phenomenon known in project management circles as “scope creep” can be linked to the triangle too.
Scope creep is the almost unstoppable tendency a project has to accumulate new functionality. Some scope

creep is inevitable since early on, your project will probably be poorly defined and will need to evolve. A large
amount of scope creep however can be disastrous.
When the scope starts to creep new functionality must be added to cover the increased scope. This is
represented by the quality arm of the triangle, representing the ability of the ‘product’ to fulfill users’
requirements. More requirements fulfilled = a better quality product.
In this situation you have three and only three options:
 Add time – delay the project to give you more time to add the functionality
 Add cost – recruit, hire or acquire more people to do the extra work
 Cut quality – trade off some non-essential requirements for the new requirements
If the art of management lies in making decisions, then the art of project management lies in making
decisions quickly! When faced with such a dilemma you should not hesitate to take one of the three options
listed above. Delaying raises the risk of your project failing.
What is project and its characteristics:
Definition:-
A project is a sequence of unique, complex, and connected activities that have one goal or purpose and that
must be completed by a specific time, within budget, and according to specification.
Key Characteristics
As follows from the given definition, any project can be characterized by these characteristics:
 Temporary
This key characteristic means that every project has a finite start and a finite end. The start is the time when
the project is initiated and its concept is developed. The end is reached when all objectives of the project
have been met (or unmet if it’s obvious that the project cannot be completed – then it’s terminated).
 Unique Deliverable(s)
Any project aims to produce some deliverable(s) which can be a product, service, or some another result.
Deliverables should address a problem or need analyzed before project start.
 Progressive Elaboration
With the progress of a project, continuous investigation and improvement become available, and all this
allows producing more accurate and comprehensive plans. This key characteristic means that the successive
iterations of planning processes result in developing more effective solutions to progress and develop
projects.
In addition to the listed characteristics, a conventional project is:
 Purposeful as it has a rational and measurable purchase
 Logical as it has a certain life-cycle
 Structured as it has interdependencies between its tasks and activities

 Conflict as it tries to solve a problem that creates some kind of conflict
 Limited by available resources
 Risk as it involves an element of risk
Topic: Delphi Technique:
The Delphi Technique is a method used to estimate the likelihood and outcome of future events. A group of
experts exchange views, and each individually gives estimates and assumptions to a facilitator who reviews
the data and issues a summary report. OR
A process of exploring… assessing… and evaluating
Following are the steps of Delphi Technique:
The aim is to clarify and expand on issues, identify areas of agreement or disagreement and begin to find
consensus.
 Define the problem:
Identify the problem that you want to work on, writing it down in a clear way that is easy to
understand. This can be in various forms, form a questionnaire to a broad and open question.
You can work on one problem and you can work on several problems at once. The constraint is usually the
bandwidth and expertise of the people in the Delphi group.
 Give everyone the problem:
Recruit people to the Delphi group. This includes anyone who has been selected to contribute
thinking on this project. There is often a meeting needed for Delphi work, making it ideal for virtual teams.
Delphi thinking can be done with a small group and it can be done with hundreds of people. Around 20
people is fairly common size
Send the problem or problems to everyone who is in the group and ask them respond. You will have to
handle a lot of feedback, so asking for short bullet-points will make things much easier to deal with than
rambling text.
 Collate the responses:
Take the responses that people send back to you and collate these into a single anonyms list of
sets of list. Make this as easy as possible for the people to read when you send it back out again, but be
aware of casing inappropriate bias. For example you may group responses into appropriate headings, but
with the caution that this might presuppose particular thinking.
On the other hand, if you are seeking creative ideas you may deliberately mix up the answers.
 Give everyone the collation:
Send the collation back out to everyone with the request to score each item on a given scale.
You may also allow them to add further items as appropriate. Remember to include the original problem at
the top of the page, along with instructions on what to do. You can also make responding easier by putting
the items in a table with space for the score.
 Repeat as necessary:

The process may now be repeated as many times as is deemed appropriate. If you are seeking
consensus and there was a wide range of responses, then this may require several iterations. In particular at
least a second round to see how others have scored can be very useful.
NOT NECESSARY below mentioned adv and limitations
Advantages of Delphi Technique:
 Opportunities for large number of people
to participate
 Focus is on “ideas” rather than
“individuals”
 Anonymity for participants which make
contributions of ideas a safe activity
 Opportunities for participants to reconsider
their opinions
 Allows for identification of priorities.
Limitations of Delphi Technique:
 Large amount of time to conduct several
rounds
 The complexity of data analysis;
 The difficulty of maintaining participant
enthusiasm throughout process
 The problem of keeping statements value
free and clearly defined
 Self reporting data is subject to
respondent’s biases and memories
Topic: Explain the purpose and contents of project
1. Background
This is a brief description of the situation that led to the project proposal. It often states the business
conditions, opportunities, and any problems giving rise to the project. It sets the stage for later sections and
puts the project in the context of the business.
2. Objective
This is another short section that gives a very general statement of what you hope to accomplish through this
project. Use the language of the business, not the technical language of your department. The objective
should be clearly stated so that there is no doubt as to what is to be done.
3. Overview of the Approach to Be Taken
For those who might not be interested in the details of how you are going to reach your objective, this
section provides a high-level outline of your approach.
Some mention of the PMLC model to be used would be good here. Again, avoid jargon whenever possible
4. Detailed Statement of the Work
Here is where you provide a high-level summary of what will be done, when it will be done, who will do it,
how much time will be required, and what criteria will be used to measure completeness. This is the roadmap
of all the project work. Gantt charts are useful for such presentations.
5. Time and Cost Summary

This usually works best if presented as a single high-level table. Often the data will have been stated over
several pages, and it is brought together here for easy review and comment by the client.
6. Appendices/ Annexure
Anticipate questions your client might have, and include answers here. Remember that this is detail beyond
the basic description of the project work. Supporting information is generally found here.
7. Putting It All Together
The work of planning the project is now complete. You have written and submitted a detailed project
proposal based on the project plan. To the best of your ability, you’ve provided a time line, budget, and
resource requirements list.
Topic: How would you manage a change in project?
To deliver a project successfully, project managers need to overcome the obstacle of changing objectives.
Working out how to handle changes in advance will make the process easier on IT teams and business users.
Change control or change management for IT projects is different to managing operational IT change. It’s the
process of managing unplanned but desired influences on the project. It is important because any change
will:
 Need to be analyzed for its impact on the project objectives and scope
 Modify your existing plans
 Need to be recorded properly for a complete audit trail
Since change is inevitable, it’s best to be prepared. Here are five steps to consider when that "change
request" turns up on your desk.
 A request to make a change to the project is received
You want the person suggesting the change to be as specific as possible and to put their request in writing. If
they have any supporting materials, such as quotes for additional IT equipment or estimates from developers
that might help the analysis, ask for those too.
 Update the change log
The change log in its simplest form is a document where changes and activities to assess changes are written
down. Make a note of this latest request.
 Assess the priority of the change request
Give the "change request" a priority. Is it critical, important or nice to have? This provides a sense of urgency
for planning the impact analysis. Be guided by the person who raised the request but use your own common
sense. Have clearly defined categories so one person’s "urgent" is not equivalent to someone else’s "nice to
have".
 Assess the change
As a team, look at the change request. It is helpful to assess all changes against the same criteria. The
purpose of the assessment is to decide whether to approve or reject the change. You should also consider the
impact of the change if it is not done. Sometimes not doing something, such as applying a software patch, can
have more of an impact than doing something.

 Decide the course of action: approve or reject the change request
Take the decision, and communicate the outcome to the relevant stakeholders and those affected by the
change. Update the change log with the outcome and rationale behind it. If the change is approved, amend
all the appropriate project documents.
Finally, once you have completed all the steps of a change management process, you will need to delegate
the tasks to the right IT resource to get the change made. This could be to developers, testers, architects or
anyone else who is impacted by the work. It’s best to explain the rationale for the change at the same time
instead of just dishing out the tasks. People tend to work more effectively if they know why they are doing
something, so take the time to set the new work in context and explain the benefits of the change on the IT
solution overall.
Topic: Project Close-Out Phase
Project closeout is critical, yet for one reason or another, it's an area that's often left loose at the ends - with
the potential for disastrous consequences.
Professionals who closeout properly create significant benefits for themselves, their organization and for
others - better success prospects for future projects, increased employee motivation, better customer
relations, improved attractiveness to repeat and new business and so on...
A good closeout process includes:
Verify Scope:
- Review all test data against the approved
specification
- Identify & resolve any discrepancies
- Validate all supporting documents
- Verify all deliverables are available
- Assess customer satisfaction
Closeout Contracts
- Ensure that all open issues are resolved with the customer
- Return or destroy all customer's proprietary documents at the customer's direction
- Help the customer conduct an audit of completed scope
- When the customer is happy, receive final payment
Closeout Administration
- Return all personnel loaned to project
- Complete personnel performance evaluations
Conduct a Lessons Learned Review
- Conduct a survey
- Hold the lessons learned meeting
Build a Project History File
- Document planned & actual schedule duration
and include data on past similar completed
projects
- Document planned & actual labor costs and
include past data
- Document all approved changes to PM plan
- Document all meetings minutes
- Document all problems
- Document subcontractor performance records
- Document customer satisfaction records
- Document project reviews

Create the Final Project report
- Describe the overall success of the project
- Describe organization on the project
- Describe recommended changes for other similar
projects
- Describe techniques used to get results
- Describe project strengths & weaknesses
- Describe project team recommendations
Celebrate Success
- Involve everyone on the project
- Gather outside the working environment
- Recognize outstanding performers
- Express appreciation to all project participants
Topic: Compare and contrast TPM and CCPM approaches to the project
management:
Definition of TPM:
Project Management is a method and set of techniques based on the accepted principles of management
used for planning estimating and controlling work activities to reach as desired end result on time, within
budget and according to specifications.
Definition of CCPM:
The critical Chain is defined as the longest duration path through the project considering the task
dependencies and resource constraints. The planning, scheduling and maintenance of critical chain
throughout the course of the project. Moreover by giving priority to the critical chain, the Project Manager
identifies scheduled Tasks around the most constrained resources and completes the Project in less time as
compared to TPM Approach.
Contrast of Two approaches TPM and CCPM
1. Both Approaches are identical to the point, where Project Network is drawn and critical path is
identified.
2. Thereafter CCPM Manager develops critical chain Plan.
3. CCPM is more scientific and make use of Mathematical statistics to reduce special cause variations,
which reduces the time duration of Project.
CONCLUSION: We have discussed both approaches, that is TPM and CCPM. In order to decide which
approach makes more sense for a given project, it depends upon the nature of the Project. In case the time
duration of the Project is more essential, we would like to have CCPM Approach otherwise we can adopt TPM
approach.
Topic: Post Implementation audit:
POST IMPLEMENTATION AUDIT
The post implementation Audit is an evaluation of the Project Goal and activities achievement as measured
against the project plan, budget, time, deadlines, and quality of deliverables, specifications and client
satisfaction.
Six questions to be answered during post implementation audit

1. Was the project goal achieved?
The project was justified based on a goal to be achieved. That goal either was or wasn’t achieved, and the
reasons for this must be provided in the audit.
2. Was the project work done on time, within budget, and according to specifications?
Here you are concerned with whether the specification was met within the budgeted time and cost
constraints.
3. Was the client satisfied with project results?
It is possible that the answers to the first two questions are yes, but the answer to this question is no. How
can that happen? Simple: the Conditions of Satisfaction (COS) changed, but no one was aware that they had.
The project manager did not check with the client to see whether the needs had changed, or the client did
not inform the project manager that such changes had occurred.
4. Was the business value realized?
The success criteria were the basis on which the business case for the project was built and were the primary
reason why the project was approved.
5. What lessons were learned about your project management methodology?
Companies that have or are developing a project management methodology will want to use completed
projects to assess how well the methodology is working. Different parts of the methodology may work well
for certain types of projects or in certain situations, and these should be noted in the audit.
6. What worked? What did not?
The answers to these questions are helpful hints and suggestions for future project managers and teams. The
experiences of past project teams are real “diamonds in the rough”—you will want to pass them on to future
teams.
What do you understand by conditions of satisfaction in a Project? How are these
developed? Show Diagrammatically?
Answer:
Definition of Conditions of Satisfaction (COS):
These are the conditions on which the client and the Project Manager agree as a result of their Negotiations
about a particular project.
Development of COS:
The client makes a request for a project to the project Manager. At this point both parties define exactly what
the request is and what kind of response is appropriate. The deliverable from the conversation is COS.
This process is explained with the help of
following diagram.

The deliverable from the COS is a one-page document (with attachments) called the Project Overview
Statement (POS). The POS is a template that is used to clearly state what is to be done. It is signed by the
requestor and the provider as a record of their COS session. When the POS is approved by senior
management, the Scoping Phase is complete and the project moves to the Planning phase.

Project management

More Related Content

Similar to Project management

More from Ch Irfan

Recently uploaded

Project management