Next Generation Project Management Systems - A Quality Approach .

Next Generation Project management systems –A Quality
Approach
Introduction
Implementing Quality Management Systems using Project management techniques to projects: A
systems approach to Planning, Scheduling and Controlling – Innovative approach..
Executives have realized that Project management and productivity are related to each other, both
trying to make effective and efficient utilization of existing resources. This project work is
developed to provide hands on approach to learning the necessary tools and techniques by which
activities can be integrated throughout the organizational size, project complexity, or type of
industry.
The purpose of this research is to contribute to a better understanding of project management
practice by investigating the use of project management tools and techniques and the levels of
support provided by organizations for their use. The study examines both general levels of use
and variations among project types and contexts. Many aspects of project management practice
are common to most projects in most contexts, while others vary significantly among different
types of projects and among projects in different contexts. The purpose of this paper is to present
empirical results that show both the common elements and the significant variations. The paper is
based on a survey of many experienced project management practitioners. The use of tools and
techniques is seen here as an indicator of the realities of practice. The study found some aspects
of practice to be common across all types of projects and all contexts, but on this background of
similar patterns of practice, several statistically significant differences have also been identified.
The primary focus of this paper work is on these variations in practice.
Aims and objectives:

Building a Next-Generation Program Management and Portfolio
Management
“Instead of defining roles and making sure team members are following project
management processes and procedures to , next generation project managers need to
focus on improving collaboration and removing obstacles and distractions so that project
members can get their work done on time and on budget.”
1
Approach
While the Project/Program Management Office (PMO) continues to be a growing
trend in recent years, the reality of the turbulent business environment is posing new
challenges for implementing and sustaining PMO‟s. The pressure to deliver value and
reduce overhead has created a need to find innovative approaches to enhance the
PMO to the next level. Whether you are building a PMO to support and enhance
project management capabilities, or as a governance structure, or to focus on strategic
aspects of Portfolio Management, you may encounter implementation challenges and
mixed results. While the PMO can offer tremendous benefits and have strategic
impact, the challenge is in the focus of the PMO and the way it is implemented. How
can you find innovative ways to build and sustain a PMO that can address the
challenges and critical success factors to overcome the barriers? What is the role of
the PMO in delivering business strategies? How does it fit with Program and
Portfolio Management? What organizational structures, functions, processes and
practices will ensure success? How can you sell and demonstrate PMO value and
Return on Investment (ROI)?
Need for study

The purpose of this research is to contribute to a better understanding of project management
practice by investigating the use of project management tools and techniques and the levels of
support provided by organizations for their use. The study examines both general levels of use
and variations among project types and contexts. Many aspects of project management practice
are common to most projects in most contexts, while others vary significantly among different
types of projects and among projects in different contexts. The purpose of this paper is to present
empirical results that show both the common elements and the significant variations. The paper is
based on a survey of many project management practitioners. The use of tools and techniques is
seen here as an indicator of the realities of practice. The study found some aspects of practice to
be common across all types of projects and all contexts, but on this background of similar
patterns of practice, several statistically significant differences have also been identified. The
primary focus of this paper is on these variations in practice.
The Project Management approach requires departure from the traditional business organizational
form which is basically vertical and which emphasizes a strong superior-subordinate relationship.
2
Approach
Understanding Project Management:

In order to understand Project Management, one must begin with definition of project .A project
can be considered to be any series of activities and task that:
 Have specific objective to be completed within certain Specification.
 Have defined start and end dates.
 Have funding limits.( if applicable )
 Consume resources ( i.e. Money, People ,Equipment )
Project management involves Project Planning and Project monitoring and includes such items
as.
 Project Planning
 Definitions of work requirements.
 Definition of quantity of work.
 Definition of resources needed.
Project Monitoring
 Tracking progress.
 Comparing actual to predicted.
 Analyzing Impacts
 Making adjustments.
Successful management can then be defined as having achieved the project objectives:
 Within time
 Within Cost
 At the desired performance /Technology level.
 While utilizing the assigned resources effectively and efficiently.
The potential benefits from Project Management are:
 Identification of function responsibilities to ensure that all activities are accounted for
regardless of personnel turnover
 Minimizing the need for continuous reporting
 Identification of time limits for scheduling
 Identification of a Methodology for tradeoff analysis.
3
Approach
 Measurement of accomplishment against plans.
 Early identification of problems so that corrective action may follow
 Improved estimating capability for future planning
 Knowing when objectives cannot be met or will be exceeded.
Unfortunately, the benefits cannot be achieved without overcoming obstacles such as:
 Project Complexity
 Customers Special Requirements
 Organizational Restructuring
 Project risks
 Changes in Technology
 Forward Planning and Pricing
Project management can mean different things to different people .Quite often, people
misunderstand the concept because they have ongoing projects within their company and feel that
they are using Project management to control these activities .In such a case, the following might
be considered as appropriate definition.
 Project management is the art of creating the illusion that any outcome is the result of a
series of predetermined, deliberate acts when, infact, it was dumb luck.
 Project management is designed to make better use of existing resources by getting work
to flow horizontally as well as vertically within the company .This approach does not
really destroy the vertical , bureaucratic flow of work will be accomplished more
smoothly throughout the organization. The vertical flow is still the responsibility of Line
Managers.
The Figure Shows how many companies are structured .There are always “Class or prestige “
gaps between various levels of management .There are also functional gaps between working
units of the organization .If we superimpose the management gaps on top of the functional gaps
,we find that the companies are made up of small operational islands that refuse to communicate
with one another for the fear that giving up information may strengthen their opponents .The
project managers responsibility is to get these islands to communicate cross-functional toward
common goals and objectives .
4
Approach
 Project management is planning ,organizing ,directing and controlling of company

resources for a relatively short term objective that has been established to complete
specific goals and objectives .Furthermore ,Project Management utilizes functional
personnel ( the vertical hierarchy ) assigned to specific project ( the horizontal hierarchy )
.
Research methodology
Project Plans
Firstly, one needs to make sure we are all on the same page when it comes to what a plan is.
Many people (and a distressing number of project managers, too) think only of a Gantt chart
when they think of a project plan. You may recognize it as what you get from Microsoft Project.
This is better called a project schedule, in that it shows when we expect the various sections of
the project to happen. We will see this later.
What we want to have in our project plan is:
5
Approach
1. Aim of project
2. Outputs
3. Quality criteria
4. Resources
5. Management structure
6. Milestones
7. Tolerances
8. Dependencies
9. Risks
10. Schedule
Let's have a look at these in turn, and see why they are needed, and what we want to achieve with
each of them.
Aim of Project
What do we want to produce? The aim of the project is a mixture of the reasons for doing the
project and the benefits that are expected from it. This section of the plan can be either fulfilled
by linking to the main business case, or by restating it in language for the expected audience. For
example, your business case may have been written for high level approval in your organization.
You may want to now put it in terms the project executive expects.
Outputs
Given the aim of the project, what do we actually need to produce to get there? What will your
completed project be made up of? These need to be clearly defined. For example, your project's
aim may be to upgrade the IT infrastructure in an organization. Your final output would be a
completed computer network, a new computer on every desk, and all appropriate software
installed and ready to go.
Quality Criteria
Now we have the outputs, we need to understand what quality they need to be of. In the example
above, we have an output of a completed computer network. However, we need to know that the
network can actually cope with the amount of traffic going over it.
6
Approach
This means we need the completed output to be of a certain quality, and we need to define what
that quality is. These targets tell you what success is, what completion of the project is. They need
to be SMART:
 Specific: Clearly defined and precise.
 Measurable: e.g. not "new computers," but "computers with 2Gb of memory," etc.
 Attainable: Don't ask for the impossible.
 Relevant: Is the criterion actually related to the aim of the project?
 Time-based: Enough time to achieve this. There is no point expecting a year's worth of
work in one week!
It is important you take some time with the stakeholders in your project to produce this list. The
final customer of the project will naturally be very involved, but don't forget your business head -
don't promise everything without considering the costs. Your project executive, and a
representative of those who will be doing the work, will have major inputs into this also.
Finally, you will also need to decide who has the final say over the quality of the outputs.
Hopefully your work on defining the quality criteria will mean there are no arguments over the
quality (i.e. no qualitative judgments, only quantitative) but you need to make sure you schedule
in time and people to do the evaluation work.
Resources
We have now set down what outputs we need to produce, and what quality they need to be at.
This means we are now in a position to look at the resources we will need to achieve this.
Resources include staff time, particular knowledge or skill sets, money (e.g. buying equipment),
and time (some tasks can't be increased by throwing more people at the problem, e.g. delivery
times, setting time for concrete, etc.).
Management Structure
How are we going to manage the work? You need to describe the general approach to the project
here. Who will be the decision makers for the various different streams of work? For example,
you may be doing a significant procurement - who makes the decision about what company to
buy from?
How will we share progress on the project? Who will we share it to? For example, you may
decide to have regular project team meetings - who needs to attend? What level of information
7
Approach
will you be sharing? Who else needs to be kept informed, at what level of detail, and how often?
For example, you may want to keep the project executive updated at an overview level of detail
on a weekly basis, while you keep other managers appraised at a higher level of detail.
You will also need to spell out the relationship of yourself to the project executive, in terms of the
monitoring of progress. Equally, you need to put down how you will be monitoring progress of
the allocated tasks.
There is no one right answer for how this should be done, and indeed it will vary with every
project. Make sure you think about the size and complexity of the project, and also the
organisation's ethos and current management style.
Milestones
Here you need to think about how you will break up the project. Unless it is very small, you don't
want to have the entire project as one lump of work, with the only check on progress at the very
end. Instead, it makes sense to break the project up into discrete chunks, where related tasks can
be lumped together, with a sensible milestone at the end of them. For example, in the technology
refresh in the example above, you may want to break the project down into something like:
1. Requirements Gathering
2. Tender Writing
3. Tendering Process
4. Contract Negotiation
5. Deployment
6. Testing
It makes sense to have a defined milestone, so you know when each section is completed. There
is also another benefit of breaking the project into chunks, which I'll come back to.
Tolerances
You will have already looked at the resources you need. Now we need to set how far you, or the
project executive, can let the project stray from these targets before needing to sound the alarm.
For example, you could set a tolerance in terms of finance of +/- 5%, and a tolerance in terms of
time of +/- 10%. Equally, you may want to look at tolerances of quality - i.e. how far from the
quality criteria are you willing to accept?
8
Approach
It is remarkably unlikely that a project will not deviate from its resource or quality targets. Setting
tolerances allows you to be able to manage the project without continually seeking guidance from
the project executive as to whether you should carry on. This is not to say that you should be
happy with these deviations, and you should try to avoid them, and monitor them closely. That
way you can build your understanding of the project for the future.
Dependencies
This is where you look at what needs to happen before something else. For example, in our
example above, you need to complete the requirements gathering before you can finish the tender
documentation. You need to start thinking about the dependencies so you, and the project team,
can understand the impact of changes in any part of the project.
These dependencies should include both those internal to the project (i.e. those under your
control), and those external to it (i.e. those outside of your control). For example, you may need
an accurate figure for the number of staff in the organisation. This needs to come from your HR
department, and would be an external dependency.
Risks
Simply, what could go wrong? What could happen that would damage your ability to deliver the
project? Are there things you can do to avoid them, or minimise them ?
Scheduling
This is the Gantt chart-style information that many people envisage when a project plan is
mentioned. In this, you need to put down what you expect to happen when. It will include your
dependencies, milestones, and probably resources. At this point, it will be a relatively high
overview of the whole project.
One needs to understand that you cannot make a perfect schedule. , what you need to do here is
achieve the possible.
The schedule needs to include the overview, with the project broken down into sensible chunks.
This is the other advantage of breaking the project into chunks we mentioned above. By having
the project broken up in this way, you will be able to start planning the first section in quite some
detail, extending out for a few weeks. But from then on, it will start to be based more and more
on blind guesswork and faith. Do not try to be artificially precise - keep it vague, use rough
figures.
9
Approach
As you come to the end of each chunk of the project, you will be able to plan the next one. You
can use the information and experience you have just gained from the previous section, and thus
you will be able to be more confident.
Make sure you explain this to your project stakeholders! Often your project executive may look at
a schedule, and imagine everything is laid out and known. You must get this idea out of their
head straight away! Explain that the early part is firmer than the rest, and make sure they expect
changes as the project moves on.
The planner will crave certainty, and absolute dates for the project, from the very beginning. You
must resist the pressure to name a specific date, and explain why. While there may be a
temptation to give an answer, One needs instead be realistic about what is and isn't possible in
terms of scheduling. Anything else can only lead to trouble for you, the project, and ultimately
the planner will further down the line.
The Purpose of WBS:

A deliverable oriented hierarchical decomposition of the work to be executed by a project
team to accomplish the project objectives to create the required “deliverables “.
What purpose does WBS serve to our project and our project team. There are three reasons to
use a WBS in your projects .The first is that it helps more accurately and specifically define
and organize the scope of the total project .The most common way this is done by using a
hierarchical tree structure .Each level of this structure breaks the project deliverables or
objectives down to more measurable chunks .
Second reason for using WBS in your projects is to help with assigning responsibilities,
resource allocation, monitoring the project and controlling the project .The WBS makes the
deliverables more precise and concrete so that the project team knows exactly what has to be
accomplished within each deliverable .This also allows for better estimating of cost, risk and
time because you can work from smaller task. back upto the level of entire project . Thirdly,
It allows you to double check all the deliverables specifics with the stake holder and make
sure there is nothing missing or overlapping.
10
Approach
1. Process: After creating WBS to help our project efficiency & effectiveness .there are
several inputs you will need to get you off on high foot.
 The project Scope statement.
 The project Scope management.
 Organizational process assets
 Approve change requests (PMBOK guide)
Ones team needs to create WBS along with these inputs yo will use certain tools as well :
 Work break down templates.
 Decomposition (PMBOK)
Using tools you will create the following outputs
 Work breakdown Structure.
 WBS dictionary
 Project Scope Statement (Updates on Primavera tool )
 Project Scope management Plan (updates)
 Requested changes-PMBOK (guide)
The first step to creating your WBS is to get all your team, and possibly key stakeholders,
together in one room. Although your team is not listed as an input or tool in the above
sections, they are probably your most vital asset to this process. Although your team
possesses all the expertise, experience, and creative thinking that will be needed to get down
to the specifics of each deliverable. Next, we have to get the first two levels setup. The first
level is the project title, and the second level is made up of all the deliverables for the project.
At this stage it is important to function under the 100% Rule. This rule basically states that
the WBS (specifically the first two levels) includes 100% of all the work defined in the
project scope statement and management plan. Also, it must capture 100% of all the
deliverables for the project including internal, external, and interim. In reality the WBS
usually only captures between 90-95%, and 100% is our goal.
Once we have got the first two levels set, it is time to launch into our decomposition.
Decomposition is the act of breaking down deliverables in to successively smaller chunks of
11
Approach
work to be completed in order to achieve a level of work that can be both realistically
managed by the project manager and completed within a given time frame by one or more
team members. This level of breakdown and detail is called the work package. Work
packages are the lowest level of the WBS and are pieces of work that are specifically
assigned to one person or one team of people to be completed. This is also the level at which
the project manager has to monitor all project work. Now the million dollar question is how
specific and small does a chunk of work need to be to still be considered a work package?
Well PMBOK does not seem to give a definitive answer on that. Most project managers
concur that this varies by project, but can usually be measured using the 8/80 Rule. The 8/80
Rule says that no work package should be less than 8 hours or greater than 80 hours. Notice
we said that the work package is the lowest level of the WBS. Activities and tasks are not
included in the WBS. They will be planned from the work packages once they are assigned.
Occasionally, you will run into a project that is a "first of its kind," but that is not usually the
case. Most of the time, you, your team, or your organization has done a project like this one
in the past. That means that there should be a WBS from the previous project that you can use
as a template. This will save you a lot time and effort. Even if you have not done a project
like this one before, most Project Management Offices (PMOs) have basic WBS templates
that can get you started. Another great technique to make your life easier is the Post-It Note
Technique. , it actually works very well. In this technique you simply write each deliverable
on a post-it note and stick them at the top of a wall. Then you and your team start to break
down each deliverable into components and write each component on its own post-it note.
This way, as you place them on the wall and start to create your tree structure, everyone can
easily see what has been accomplished and where you are headed. Also this technique allows
for easy movement of components around within the WBS.
You can use your newly created WBS to look for missing or overlapping pieces of each
deliverable. This will help eliminate change requests and double work down the road. Once
that is completed, put your WBS on paper and log it into your project.
Many projects will also find it necessary to create a WBS Dictionary to accompany their
WBS. The WBS Dictionary is simply a document that describes each component in the WBS.
This helps clarify any specifics later on when team members completing the work or
stakeholders viewing the deliverables have questions. Also, when creating the WBS for very
large, lengthy, or complex projects, all the deliverables' specifics might not be known up
front and, therefore, it is difficult to create a full WBS. In cases such as these many people
12
Approach
use what is called Rolling Wave Planning. This is when you plan down to the level of detail
currently known and go back to plan deeper once more information is acquired. Usually
rolling wave planning needs to stay as least 2-3 months ahead of the actual work being done,
but of course this varies slightly by industry.
Pitfalls: Five commonly occurring Pitfalls
1. Level of Work Package Detail
When deciding how specific and detailed to make your work packages, you must be careful
to not get too detailed. This will lead to the project manager to have to micromanage the
project and eventually slow down project progress. On the other hand, work packages whose
details are too broad or large become impossible for the project manager to manage as a
whole.
2. Deliverables Not Activities or Tasks
The WBS should contain a list of broken down deliverables. In other words, what the
customer/stakeholder will get when the project is complete. It is NOT a list of specific
activities and tasks used to accomplish the deliverables. How the work is completed (tasks
and activities) can vary and change throughout the project, but deliverables cannot without a
change request, so you do not want to list activities and tasks in the WBS.
3. WBS is not a Plan or Schedule
The WBS cannot be used as a replacement for the project plan or schedule. A WBS is not
required to be created in any type of order or sequence. It is simply a visual breakdown of
deliverables.
4. WBS Updates Require Change Control
The WBS is a formal project document, and any changes to it require the use of the project
change control process. Any changes to the WBS change the deliverables and, therefore, the
scope of the project. This is an important point to help control scope creep .
5. WBS is not an Organisational Hierarchy
The WBS and Organisational Hierarchy chart are never the same thing. Although often
similar in appearance, these two documents are very different. The Organisational Hierarchy
shows things like chain of command and lines of communication, but the WBS is restricted
simply to a project and shows only the deliverables and scope of that project.
13
Approach
The WBS is an extremely valuable tool to the project management methodology. It can make
or break a project. It sets the foundation for the rest of the project planning. A solid WBS
helps ensure proper project baselines, estimating, resource use, scheduling, risk analysis, and
procurement
Gantt charts and PERT charts are useful tools for visualizing and communicating information
about projects, but they have a number of limitations. In addition, the ease with which they
can be created using software applications makes them open to misuse and misinterpretation .
Project Breakdown
Part of the problem is that there isn't a clear understanding of how to break the project down
in the first place, and using Gantt chart software to do this isn't necessarily the best way of
going about it.
A common method of breaking a project down is using a Work Breakdown Structure (WBS).
This concentrates on analyzing the scope of the project according to its outcomes or
deliverables. This method of breakdown does not necessarily imply any dependencies (logic)
or sequence, hence neither the Gantt chart nor the PERT chart are suitable tools for carrying
out this analysis.
Project Management Methodologies such as PRINCE2 also seek to analyze the project in
terms of deliverables, "Products," although there is more of a sequence involved in the
definition of the stages: in particular, there is a process of sign-off for each stage, sometimes
called "Gateways", before the project is allowed to move on to the next.
Using the Charts

Having defined the breakdown, you should have a list of tasks which need to be completed in
order to produce the desired outcomes. These tasks will have dependencies and durations and
hence can be scheduled. Now's the time for the PERT or network chart software to be used.
You can concentrate on the logic of the task relationships: the software should do the
scheduling for you, including calculating the critical path.
Once the logic has been defined and the schedule has been calculated, the result can be
displayed on the Gantt chart. It's often best not to show the dependencies (links) on this chart,
especially if there are a large number of tasks and complex dependencies between them. It's
also helpful if you can produce separate Gantt Charts for different WBS levels or
14
Approach
stages/products, as they will have fewer tasks in them. Summary Gantt charts showing higher
levels in the WBS may also be useful.
Updating Progress
Charts should be seen as snapshots of the current project situation: they should be dynamic
and change as circumstances change, particularly as work is carried out on the tasks.
I've seen a number of cases where the project manager creates a beautiful Gantt chart
showing the project being completed on time, with nice neat task relationships, sends it out to
all the people involved - and then they sit back and leave it at that. When asked how the
project is going, they say "fine" because the chart looks fine. What they fail to do is update it
with what's actually happening and re-schedule it according to real progress.
If some tasks are taking longer than expected, are they going to continue at the same pace and
if so, what impact will this have on the rest of the plan? Remaining effort needs to be
estimated and the project rescheduled.
What will be the effect if some tasks are ahead of schedule? The impact on resources will not
be apparent from just looking at the charts: other tools are needed, such as resource
histograms, to identify peaks and troughs in resource utilisation.
Building SMART goals.

Once you have planned your project, turn your attention to developing several goals that will
enable you to be successful. Goals should be SMART - specific, measurable, agreed upon,
realistic and time-based.
A goal might be to hold a weekly project meeting with the key members of your team or to
organize and run a continuous test programme throughout the project.
The acronym SMART has a number of slightly different variations, which can be used to
provide a more comprehensive definition for goal setting:
S - Specific, significant, stretching
M - Measurable, meaningful, motivational
A - agreed upon, attainable, achievable, acceptable, action-oriented
R - realistic, relevant, reasonable, rewarding, results-oriented
15
Approach
T - time-based, timely, tangible, trackable
This provides a broader definition that will help you to be successful in both your business
and personal life.
When you next run a project take a moment to consider whether your goals are SMART
goals.
SMART Goals
Specific
Well defined
Clear to anyone that has a basic knowledge of the project
Measurable
Know if the goal is obtainable and how far away completion is
Know when it has been achieved
Agreed Upon
 Agreement with all the stakeholders what the goals should be
Realistic
Within the availability of resources, knowledge and time
Time Based
Enough time to achieve the goal
Not too much time, which can affect project performance
16
Approach
Literature review
A Project Management Primer – Basic principles- Scope triangle
Cost
Time
Quality
Quality
Called the “Scope triangle” or the “Quality triangle“this shows the tradeoffs inherent in any
project.
The triangle illustrates the relationship between three primary forces in project .Time is the
available time to deliver the project. Cost represents the amount of money or resources
available. Quality represents the fit-to–purpose that the project must achieve to be success.
The normal situation is that that one of the factor is fixed and the other two will vary inverse
proportion to each other .For e.g. Time is often fixed and Quality of the end product will
depend on the cost or resource available .Similarly if you are working on a fixed quality then
cost of the product will depend on the time available (if you have longer you can d it with
fewer people).
The astute person will be wondering what will happen when two of the things are fixed. This
will happen when costs are fixed and project has a delivery date to deliver, an all to set of
familiar set of circumstances.
17
Approach
Then if the scope starts to creep you are left with only one choice cut on functionality.
Cutting functionality may seem to be extreme measure, but an experienced Project manager
will happily cut away functionality as if like peeling a potato.As long as the
Core requirements remain, everything will be fine.
A really experienced project manager might even pad his project while his superfluous
functionality that can be sacrificed when the crunch comes.
A phenomenon known as “scope creep “can be linked to the triangle too, Scope creep is
almost unstoppable tendency to accumulate a new functionality .Some scope creep is
inevitable since, early on , your projects will be poorly defined and will need to evolve .A
large amount of scope creep can be disastrous .
When a 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 =a better quality products.
In this situation you have, three questions
 Add time – delay the project to give you an add the functionality.
 Add cost – recruit ,hire or acquire more people to do the extra work.
 Cut Quality – to trade off some non essentials requirements
If the art of management lies in making decisions, then the art of Project Management lies in
quick decision making.
The Context of Project Failure
There are a number of increasingly popular project management methodologies aimed at

standardizing project management approaches, reducing project risk, and guarding against project
failure. The three main accreditations - all of which have spawned subsidiary industries in
training, certification, and consultancy, are as follows:
PRINCE2 (Projects In Controlled Environments)
MSP (Managing Successful Programmes) both MSP and PRINCE2 originating from the
Office of Government Commerce in the UK
18
Approach
The Project Management Professional (PMP) certification administered by the Project
Management Institute in the US
To put project failure in context; Gartner, the world's most listened to analyst firm estimate
that 66% of large scale projects fail to achieve their stated business objectives, are delivered
late, or are substantially over budget.
The Standish Group, which exists solely to track IT successes and failures, defines project
failure as projects abandoned midstream, and estimates failure rate at 15 percent, but that
"challenged" projects (defined as projects with cost overruns, time overruns, and projects not
supportable as delivered) represent 51% of all IT projects.
Looking at these figures in the post PRINCE2 / MSP / PMP world, you might be forgiven for
asking yourself, "why then is project success so elusive?"
The Standish Group believes that the most important factors in a project's success or failure
are, in order of importance:
 The degree of user involvement
 Executive management support
 An experienced project manager
There are probably few who would disagree with the points above, which all deal with the
question, "how are we going to manage this project through its active life?"
Poorly defined deliverables and scope, lack of organizational buy-in, poor resource allocation
and control of risk, poor project management, components that are not fit for purpose, and so
on - any and all of these can cause project failure.
But what about the failing projects that should never have seen the light of day?
First Things First

.
The second of Stephen Covey's famed 7 Habits of Highly Effective People is "begin with the
end in mind," which is an excellent guiding principle for project management approval as it is
for life: if you don't define what you want to achieve, it's very unlikely that you'll do so. In
consultant-speak, this is usually couched in the question, "what does success look like?"
A broad aim is fine to start with:
19
Approach
We want to provide world-class services to our clients
We want to reduce the number of outages affecting our systems
We want to take a higher proportion of payments online
We want to increase customer satisfaction
But these need to be much more tightly defined in terms of why, what, how, when, and who,
in order to establish the capability of the organisation to deliver them, the impact on the
business and probable pain level involved in change management, the likely cost
implications, and a best guess at the timescales involved.
This becomes a project charter, or project brief, or in PRINCE2 terms, the Project Initiation
Document (PID), which can then be realistically and robustly challenged by the potential
stakeholders, refined and re-issued, so that everyone knows where they're going, how they're
getting there, when they're supposed to arrive, and what the organisation will look like when
the project ends.
1. Speaking to many of my project management colleagues, and reading the industry press,
it's clear that most projects do not start with this level of definition, and poor project
definition stems from what I believe is the main cause of project failure from the
approval stage onwards.
An insufficient level of accountability and responsibility at an appropriately senior level for

the success of a project, through its lifecycle.
Take a moment to think through the project failures you've known, and ask the following
questions:
 Who was responsible for the success of the project?
 Were there any consequences for the failure of the project?
If the answers are in any way vague, it would suggest that the senior members of the
organisation in question need to look seriously at the way in which projects are
commissioned.
Senior people are busy people, and tend to focus attention where attention is required. If there
are no consequences for project failure, of non-attendance at Project Boards, or lack of
preparation for them, or if Project Board members are insufficiently senior or influential, the
20
Approach
Board doesn't function. If there is no customer driving a project, or at least heavily engaged
with it, the chances are that it will fail.
The Road Map

There is always too much pressure on organisations to take on too many projects, and senior
managers as well as project staff, are always spread too thin: managing competing interests
and resources is invariably a delicate balancing act.
With this in mind, the following approach will help to ensure that a project starts off on the
right foot, whatever befalls it later on:
2. Sit down with the organisation's project customers and hammer out an agreement on
project prioritization, based on business requirement, business risk, available resources,
and so on
3. Publish the list of projects and their priorities and go through another iteration of the
exercise if necessary so that everyone can feel that they've had their say
4. Close the projects on the bottom half of the list - if they're already low priority, you're
saving time and trouble stopping them at this stage
5. From the projects within the context of the current organisation. Cut the projects that
don't - you can always revisit them later that remain, identify those that have strong
customer (in every sense) commitment, clearly identifiable purpose, and those that can be
achieved
6. Agree senior owners for the projects still in the game, making it clear that they will be
closely identified with the project(s) they own, will be required to drive the project
forward, and will lose credibility if it fails. If a senior owner (seniority being relative to
the ambition of the project) cannot be found for a project, cut it
7. You should be left with a handful of projects left that are important to the organisation,
with senior commitment, sufficient resources (freed from the projects that aren't going
ahead) and have a high chance of success
8. There may be little appetite in your organisation for the effort that such a rigorous
approach implies, but if you look at how much project failure has cost the organisation
over the years, it's much less effort than struggling to undertake every project, then going
before the Chief Exec to explain why you haven't delivered.
21
Approach
Define the Scope and Objectives
9. Firstly, understand the project objectives. To make a company profile? Or to make a

small business plan .Deciding the real objectives will help you plan the project.
10. Scope defines the boundary of the project. Is the organisation of transport to take staff to
the blood bank within scope? Or, should staff make their own way there? Deciding what's
in or out of scope will determine the amount of work which needs performing.
11. Understand who the stakeholders are, what they expect to be delivered and enlist their
support. Once you've defined the scope and objectives, get the stakeholders to review and
agree to them.
Define the Deliverables

You must define what will be delivered by the project. If your project is an advertising
campaign for a new chocolate bar, then one deliverable might be the artwork for an
advertisement. So, decide what tangible things will be delivered and document them in
enough detail to enable someone else to produce them correctly and effectively.
Key stakeholders must review the definition of deliverables and must agree they accurately
reflect what must be delivered.
Project Planning
Planning requires that the project manager decides which people, resources and budget are
required to complete the project.
You must define what activities are required to produce the deliverables using techniques
such as Work Breakdown Structures. You must estimate the time and effort required for each
activity, dependencies between activities and decide a realistic schedule to complete them.
Involve the project team in estimating how long activities will take. Set milestones which
indicate critical dates during the project. Write this into the project plan. Get the key
stakeholders to review and agree to the plan.
22
Approach
Communication
1. Project plans are useless unless they've been communicated effectively to the project
team. Every team member needs to know their responsibilities. I once worked on a
project where the project manager sat in his office surrounded by huge paper schedules.
The problem was, nobody on his team knew what the tasks and milestones were because
he hadn't shared the plan with them. The project hit all kinds of problems with people
doing activities which they deemed important rather than doing the activities assigned by
the project manager.
Tracking and Reporting Project Progress

Once your project is underway you must monitor and compare the actual progress with the
planned progress. You will need progress reports from project team members. You should
record variations between the actual and planned cost, schedule and scope. You should report
variations to your manager and key stakeholders and take corrective actions if variations get
too large.
You can adjust the plan in many ways to get the project back on track but you will always
end up juggling cost, scope and schedule. If the project manager changes one of these, then
one or both of the other elements will inevitably need changing. It is juggling these three
elements - known as the project triangle - that typically causes a project manager the most
headaches!
Change Management
Stakeholders often change their mind about what must be delivered. Sometimes the business
environment changes after the project starts, so assumptions made at the beginning of the
project may no longer be valid. This often means the scope or deliverables of the project need
changing. If a project manager accepted all changes into the project, the project would
inevitably go over budget, be late and might never be completed.
By managing changes, the project manager can make decisions about whether or not to
incorporate the changes immediately or in the future, or to reject them. This increases the
chances of project success because the project manager controls how the changes are
incorporated can allocate resources accordingly and can plan when and how the changes are
made. Not managing changes effectively is often a reason why projects fail.
23
Approach
Risk Management
2. Risks are events which can adversely affect the successful outcome of the project. I've
worked to avoid the risk, or, if the risk cannot be avoided, to mitigate the risk to lessen its
impact if it occurs. This is known as risk management.
You don't manage all risks because there could be too many and not all risks have the
same impact. So, identify all risks, estimate the likelihood of each risk occurring (1 = not
likely, 2 = maybe likely, 3 = very likely). Estimate its impact on the project (1 - low, 2 -
medium, 3 - high), then multiply the two numbers together to give the risk factor. High risk
factors indicate the severest risks. Manage the ten with the highest risk factors. Constantly
review risks and lookout for new ones since they have a habit of occurring at any moment.on
projects where risks have included: staff lacking the technical skills to perform the work,
hardware not being delivered on time, the control room at risk of flooding and many others.
Risks will vary for each project but the main risks to a project must be identified as soon as
possible. Plans must be made
Not managing risks effectively is a common reason why projects fail.
Summary
Following these best practices cannot guarantee a successful project but they will provide a
better chance of success. Disregarding these best practices will almost certainly lead to
project failure.
The benefits of risk management in projects are huge. You can gain a lot of money if you
deal with uncertain project events in a proactive manner. The result will be that you minimise
the impact of project threats and seize the opportunities that occur. This allows you to deliver
your project on time, on budget and with the quality results your project sponsor demands.
Also your team members will be much happier if they do not enter a "fire fighting" mode
needed to repair the failures that could have been prevented.
Rule 1: Make Risk Management Part of Your Project

The first rule is essential to the success of project risk management. If you don't truly embed
risk management in your project, you can not reap the full benefits of this approach. You can
24
Approach
encounter a number of faulty approaches in companies. Some projects use no approach
whatsoever to risk management. They are either ignorant, running their first project or they
are somehow confident that no risks will occur in their project (which of course will happen).
Some people blindly trust the project manager, especially if he (usually it is a man) looks like
a battered army veteran who has been in the trenches for the last two decades. Professional
companies make risk management part of their day to day operations and include it in project
meetings and the training of staff.
Rule 2: Identify Risks Early in Your Project

The first step in project risk management is to identify the risks that are present in your
project. This requires an open mind set that focuses on future scenarios that may occur. Two
main sources exist to identify risks, people and paper. People are your team members that
each bring along their personal experiences and expertise. Other people to talk to are experts
outside your project that have a track record with the type of project or work you are facing.
They can reveal some booby traps you will encounter or some golden opportunities that may
not have crossed your mind. Interviews and team sessions (risk brainstorming) are the
common methods to discover the risks people know. Paper is a different story. Projects tend
to generate a significant number of (electronic) documents that contain project risks.
They may not always have that name, but someone who reads carefully (between the
lines) will find them. The project plan, business case and resource planning are good starters.
Another categories are old project plans.
Are you able to identify all project risks before they occur? Probably not. However if you
combine a number of different identification methods, you are likely to find the large
majority. If you deal with them properly, you have enough time left for the unexpected risks
that take place.
Rule 3: Communicate About Risks

Failed projects show that project managers in such projects were frequently unaware of the
big hammer that was about to hit them. The frightening finding was that frequently someone
of the project organization actually did see that hammer, but didn't inform the project
manager of its existence. If you don't want this to happen in your project, you better pay
attention to risk communication.
A good approach is to consistently include risk communication in the tasks you carry out. If
you have a team meeting, make project risks part of the default agenda (and not the final item
25
Approach
on the list!). This shows risks are important to the project manager and gives team members a
"natural moment" to discuss them and report new ones.
Another important line of communication is that of the project manager and project sponsor
or principal. Focus your communication efforts on the big risks here and make sure you don't
surprise the boss or the customer. Also take care that the sponsor makes decisions on the top
risks, because usually some of them exceed the mandate of the project manager.
Rule 4: Consider Both Threats and Opportunities
3. Project risks have a negative connotation: they are the "bad guys" that can harm
your project. However modern risk approaches also focus on positive risks, the
project opportunities. These are the uncertain events that beneficial to your project
and organization. These "good guys" make your project faster, better and more
profitable.
4. Unfortunately, lots of project teams struggle to cross the finish line, being
overloaded with work that needs to be done quickly. This creates project
dynamics where only negative risks matter (if the team considers any risks at all).
Make sure you create some time to deal with the opportunities in your project,
even if it is only half an hour. Chances are that you see a couple of opportunities
with a high pay-off that don't require a big investment in time or resources.
Rule 5: Clarify Ownership Issues

Some project managers think they are done once they have created a list with risks. However
this is only a starting point. The next step is to make clear who is responsible for what risk!
Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign
a risk owner for each risk that you have found. The risk owner is the person in your team that
has the responsibility to optimize this risk for the project. The effects are really positive. At
first people usually feel uncomfortable that they are actually responsible for certain risks, but
as time passes they will act and carry out tasks to decrease threats and enhance opportunities.
Ownership also exists on another level. If a project threat occurs, someone has to pay the bill.
This sounds logical, but it is an issue you have to address before a risk occurs. Especially if
different business units, departments and suppliers are involved in your project, it becomes
important who bears the consequences and has to empty his wallet. An important side effect
of clarifying the ownership of risk effects, is that line managers start to pay attention to a
26
Approach
project, especially when a lot of money is at stake. The ownership issue is equally important
with project opportunities. Fights over (unexpected) revenues can become a long-term
pastime of management.
Rule 6: Prioritise Risks

Some risks have a higher impact than others. Therefore, you better spend your time on the
risks that can cause the biggest losses and gains. Check if you have any showstoppers in your
project that could derail your project. If so, these are your number 1 priority. The other risks
can be prioritized on gut feeling or, more objectively, on a set of criteria. The criteria most
project teams use is to consider the effects of a risk and the likelihood that it will occur.
Whatever prioritization measure you use, use it consistently and focus on the big risks.
Rule 7: Analyze Risks

Understanding the nature of a risk is a precondition for a good response. Therefore take some
time to have a closer look at individual risks and don't jump to conclusions without knowing
what a risk is about.
Risk analysis occurs at different levels. If you want to understand a risk at an individual level
it is most fruitful to think about the effects that it has and the causes that can make it happen.
Looking at the effects, you can describe what effects take place immediately after a risk
occurs and what effects happen as a result of the primary effects or because time elapses. A
more detailed analysis may show the order of magnitude effect in a certain effect category
like costs, lead time or product quality. Another angle to look at risks, is to focus on the
events that precede a risk occurrence, the risk causes. List the different causes and the
circumstances that decrease or increase the likelihood.
Another level of risk analysis is investigate the entire project. Each project manager needs to
answer the usual questions about the total budget needed or the date the project will finish. If
you take risks into account, you can do a simulation to show your project sponsor how likely
it is that you finish on a given date or within a certain time frame. A similar exercise can be
done for project costs.
The information you gather in a risk analysis will provide valuable insights in your project
and the necessary input to find effective responses to optimize the risks.
27
Approach
Rule 8: Plan and Implement Risk Responses
Implementing a risk response is the activity that actually adds value to your project. You
prevent a threat occurring or minimise negative effects. Execution is key here. The other rules
have helped you to map, prioritise and understand risks. This will help you to make a sound
risk response plan that focuses on the big wins.
If you deal with threats you basically have three options, risk avoidance, risk minimization
and risk acceptance. Avoiding risks means you organise your project in such a way that you
don't encounter a risk anymore. This could mean changing supplier or adopting a different
technology or, if you deal with a fatal risk, terminating a project. Spending more money on a
doomed project is a bad investment.
The biggest category of responses are the ones to minimise risks. You can try to prevent a
risk occurring by influencing the causes or decreasing the negative effects that could result. If
you have carried out properly risk analysis you will have plenty of opportunities to influence
it. A final response is to accept a risk. This is a good choice if the effects on the project are
minimal or the possibilities to influence it prove to be very difficult, time consuming or
relatively expensive. Just make sure that it is a conscious choice to accept a certain risk.
Responses for risk opportunities are the reverse of the ones for threats. They will focus on
seeking risks, maximizing them or ignoring them (if opportunities prove to be too small).
Rule 9: Register Project Risks

This rule is about bookkeeping. Maintaining a risk log enables you to view progress and
make sure that you won't forget a risk or two. It is also a perfect communication tool that
informs your team members and stakeholders.
A good risk log contains risks descriptions, clarifies ownership issues and enables you to
carry our some basic analyses with regard to causes and effects. Most project managers aren't
really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off,
especially if the number of risks is large. Some project managers don't want to record risks,
because they feel this makes it easier to blame them in case things go wrong. However the
reverse is true. If you record project risks and the effective responses you have implemented,
you create a track record that no one can deny. Even if a risk happens that derails the project.
Doing projects is taking risks.
28
Approach
Rule 10: Track Risks and Associated Tasks
The risk register you have created , will help you to track risks and their associated tasks.
Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that
daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks
or to generate, select and implement responses.
Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which
risks are more likely to happen? Has the relative importance of risks changed? Answering
this questions will help to pay attention to the risks that matter most for your project value.
The 10 golden risk rules above give you guidelines on how to implement risk management
successfully in your project. However, keep in mind that you can always improve. Therefore
rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your
risk management efforts and continuously implement improvements to make it even better.
Success with your project!
The Risky Business of Project Management

Undertaking any project, whether in-house or in partnership with a professional services firm,
entails risk. Project risk is defined as any area of concern that could prevent a project from
achieving all of its benefits. Project risk requires careful management and involves
identification, assessment, and mitigation.
It is important at the beginning of any project to go through the risk identification process.
Not all project risks are obvious. When identifying risks, look for areas in the project that are
based on:
1. Insufficient or unreliable data
2. Insufficient preparation
3. Inadequate resources
4. Lack of control
Some areas to pay close attention to are:
 Requirements identification
 Involvement of project sponsorship
29
Approach
 Level of project management experience
 Third-party involvement
 Political/cultural environment
 Change control procedures and management
 Complexity of the technology
Risk identification is only the first step. Risks need to be assessed to quantify and prioritise
them according to their impact on the project. Keep in mind significant professional judgment
is required during the assessment process to quantify the magnitude of potential negative
impact and to develop risk control measures. The assessment process should determine the
(1) likelihood of the risk occurring, (2) range of outcomes, (3) estimated timing of the risk,
and (4) the frequency with which it will occur. It should also determine the warning signs of
the risk that will forecast that the occurrence of the risk is imminent. The prioritised risks
provide the basis for establishing Project Success Factors (PSFs). Specific action plans are
developed to address each PSF. For example, assume that required key policy changes are a
high risk. An action plan must be developed to:
 Focus on thorough and frequent communications
 Implement a steering committee structure
 Obtain strong support for the project team from executive management
 Stress the benefits of the project
 Identify training needs early
Once risks have been identified and assessed, mitigation plans should be developed. The
plans document what the response will be when a risk event occurs. Keep in mind a
mitigation plan might be to do nothing to mitigate the risk. The need is to accept that a risk
exists and be prepared to deal with the consequences when and if it happens. This type of
action plan typically applies to low priority/minimal project impact risks. A mitigation plan
should outline plan B for the project area impacted by the risk. Knowing what plan B is prior
to having to execute it will greatly reduce the probability of increasing the negative impact of
the risk event or causing other unknown risks to occur.
30
Approach
An effective risk project management process means choosing and implementing risk-control
strategies that work. Identifying, assessing, and developing mitigation plans are not one-time
events. These processes need to occur throughout the life of the project. As the project
progresses and project risk changes occur, documentation resulting from the identification,
assessment, and mitigation planning processes need to be updated. The risk management
process must be continuous.
Requirements Management
A critical part of any project is the requirements management. If you are unsure about what is
going to be delivered how will you know when you get there?
What is User Requirements Capture?

User Requirements Capture is a research exercise that is undertaken early in a project lifecycle to
establish and qualify the scope of the project. The aim of the research is to understand the product
from a user's perspective, and to establish users' common needs and expectations. The user
requirements capture is useful for projects that have a lack of focus or to validate the existing
project scope. The research provides an independent user perspective when a project has been
created purely to fulfil a business need. The requirements capture findings are then used to
balance the business goals with the user needs to ensure the project is a success .
Reduce Project Risk in the Requirements Process

Gathering and managing requirements are important challenges in project management.
Projects succeed or fail due to poor requirements at any time throughout the project lifecycle.
The continuously evolving baseline of requirements needs to be managed effectively. The
project manager needs to assess and understand the uniqueness of the requirements gathering
process for his/her individual project.
The Elements of a Good Feasibility Study

In its simplest form, a Feasibility Study represents a definition of a problem or opportunity to
be studied, an analysis of the current mode of operation, a definition of requirements, an
evaluation of alternatives, and an agreed upon course of action. As such, the activities for
preparing a Feasibility Study are generic in nature and can be applied to any type of project,
be it for systems and software development, making an acquisition, or any other project.
31
Approach
Project Requirement Needs For Success: Important Considerations
A company with poor requirements practices is just asking for over-budget costs and regular
failure, according to a new report by IAG Consulting. The report, entitled Business Analysis
Benchmark, examined 110 enterprise technology projects at 100 companies to determine just
how important project requirements really are.
Requirement Gathering
Requirement gathering is an essential part of any project and project management. Understanding
fully what a project will deliver is critical to its success. This may sound like common sense but
surprisingly it's an area that is often given far too little attention.
Unified Modeling Language (UML)

A key element of any project is understanding the customer requirements. This is where the
Unified Modeling Language (UML) can help.
Reaping the Benefits of Good User Requirements with the Unified Modeling
Language (UML)
A critical part of any software development project is the requirements gathering. If you are
unclear about what is going to be delivered, how will you know when you get there? Good
user requirements lead to better estimates, improved customer satisfaction, reduced cost and a
shorter duration.
Project Management: Tips for Helping You Adopt A Process

The Rational Unified Process, Enterprise Unified Process, Agile Development
Methodologies, Unified Modeling Languages. They come in many names, complexities and
sizes but following one will help ensure success on your next project. This is not a detailed
overview of a formal process. Instead it provides an overview of the most critical components
common to each, as well as some tips on successfully deploying them.
Use Case Diagrams: A PM's View

Recently, I attended a class on managing requirements with Use Cases. It was aimed at
training business analysts and programmers to use Unified Modeling Language (UML) to
understand and communicate business requirements. As a project manager I found it both
enlightening and encouraging.
32
Approach
Project Scheduling and Resource Levelling
We all know that in the real world we, as project managers, are given the finish date of the
project before they even have a chance to plan for it. This is a good reason why we need to
get better at scheduling our projects and leveling our finite resources.
Sure, there are tools that allow us to automate the process, but a tool is as good as the
knowledge of those who use it. All in all, project managers have a tool and a method by
which we create our project schedules. But, we all suffer from common mistakes such as
having the wrong dependencies, excessive constraints, and inadequate level of detail in the
WBS, estimates too granular or nonexistent, over allocated resources, etc. Ring a bell?
The tool that is most widely used is MS Project (MSP) & Primavera (Mostly Construction
projects in Middle East countries & USA)
Develop the WBS

Most organizations have a hierarchical structure to break down the work. Typically, it looks like
this: Stage, Phase, Task/Deliverable/Milestone. This is a way to organize and define the total
scope of the project by decomposing the work to be done into tasks that the project team can
execute and create the required deliverables. The tasks, deliverables or milestones are
components that can be scheduled, cost estimated, monitored and controlled.
USE OF PLANNING TOOL PRIMAVERA 6.0

GANTT CHART
To completely close
the lower layout and
view only the data in
the top layout, click
the Show/Hide
Bottom Layout
button.
33
Approach
Click the Layout

Options bar to
display a menu of
the options
available for the
Activities
window.
In this sample layout, the top part of the window shows activity data in a
Gantt Chart, and the lower part of the window displays the Activity Detail
To hide or show more
of the information in
each pane, drag the
horizontal split bar
between the two
layouts.
Customizing Displays
Most windows and dialog boxes include a Display ot Layout Options bar
at the top of the screen that contains commands that enable you to
customize the current display. Click this bar to display a menu of the
commands available for that window or dialog box. You can also access
many of these commands from the view menu.
34
Approach
Sample Layouts
The sample database included with the module provides standard layouts that you can use with
your own projects.
To open a sample layout, first open one of the projects from the sample database or your own
database in the activities window, then choose view, layout open.
In this sample layout, you can view your project data based on the project‟s work breakdown
structure (WBS)
In this sample layout,

you can view your
project data based on the
project‟s work
breakdown structure
(WBS)
35
Approach
Establish Dependencies
Dependencies are defined so that the work is executed in the proper order. Understand the
following task dependency types before you use them; incorrect dependencies will impact the
finish date of your schedule and create unnecessary constraints:
1. Mandatory (hard logic) - Inherent in the nature of the work being done. They often
involve physical limitations i.e. a test case must be defined before testing.
2. Discretionary (soft/preferred/preferential logic) - Based on experience, desire or

preferences i.e. the team decides that they will create the user manual after the first round
of testing, although it is not necessary.
3. External - Based on needs or desires of a party outside the project i.e. the server must be
purchased before configuring.
A network diagram is used to show dependencies in a graphical form. MSP generates a network
diagram automatically.
Work is the number of labour units (usually expressed in hours, days or weeks) required to
complete a scheduled task. Estimation is equivalent to success. Duration is the total number of
work periods (usually expressed as days or weeks) required to complete a scheduled task. When
estimating, keep in mind the different task types:
1. Fixed units (MSP default) - Allows the schedule to calculate the finish date ASAP based
on resource availability.
2. Fixed duration - Used when the priority is to preserve duration. To complete work, assign
resources as needed to satisfy the finish date, remember my comment about "knowing"
the finish date before we even plan?
3. Fixed work - Some project management systems that sit on top of MSP don't support this
type because of the effort driven nature of it and the unpredictable results it may create.
So, I have chosen to get used to not using it at all.
36
Approach
This is how task types work:
Task Revise Duration Revise Work Revise Units

Type
Fixed Work is recalculated, and Duration is recalculated, Duration is recalculated,
Units units are fixed. and units are fixed. and work is fixed.
Fixed Work is recalculated, and Units is recalculated, and Work is recalculated,

Duration duration is fixed. duration is fixed. and units are fixed.
Task constraint is the next item we need to look at when estimating. You must avoid using
moderate and inflexible types. Wrong constraints increase the project risk and extend the finish
date:
1. As late as possible (flexible; default) - For projects scheduled from the finish date.
Schedules the latest possible start and finish dates for the task.
2. As soon as possible (flexible; default) - For projects scheduled from the start date.
Schedules the earliest possible start and finish dates for the task.
3. Finish no earlier than (moderate; avoid) - For projects scheduled from the start date.
Indicates the earliest possible date that the task can be completed, and the task cannot
finish any time before the specified date.
4. Finish no later than (moderate; avoid) - For projects scheduled from the finish date.
Indicates the latest possible date that the task can be completed, and the task can be
finished on or before the specified date.
5. Start no earlier than (moderate; avoid) - For projects scheduled from the start date.
Indicates the earliest possible date that the task can begin, and the task cannot start any
time before the specified date.
6. Start no later than (moderate; avoid) - For projects scheduled from the finish date.
Indicates the latest possible date that the task can begin, and the task can start on or
before the specified date.
7. Must finish on (inflexible; avoid) - Indicates the exact date on which the task must finish.
Other scheduling parameters such as task dependencies lead or lag time, and resource
levelling become secondary to this requirement.
37
Approach
8. Must start on (inflexible; avoid) - Indicates the exact date on which the task must begin.
Other scheduling parameters such as task dependencies, lead or lag time, and resource
levelling become secondary to this requirement.
Assign Resources
Resources (typically human) are assigned to tasks, deliverables and milestones that need to be
executed. At the beginning of the project, when named resources are not known yet, roles are
assigned that can later be replaced with names i.e. the role of Analyst is assigned to a task during
project scheduling and is later replaced with John Doe when he is the analyst assigned to the task.
Level Resources
Helps in utilising resources consistently throughout the project. Ensures resources are not over
allocated. Helps the project manager avoid delays caused by bad allocations. Helps the project
manager identify and take advantage of unused times by analysing task dependencies. MSP can
automatically level resources based on resource calendar, task types, dependencies, and
constraints, however, I have yet to find a project manager that has felt comfortable with the way
MSP does it. I level resources manually via the Resource Usage view, but if you insist in using
the automatic feature of MSP, save a copy first. If you find resource conflicts (over or under
allocations) you could:
1. Delay certain tasks.
2. Assign a different resource.
3. Change task dependencies.
4. Remove tasks.
5. Add tasks (instead of using the MSP's split task functionality, which is not supported by
some project management systems i.e. Clarity).
Determine the Critical Path

Helps the project manager identify tasks that must be carefully monitored. The critical path is the
longest duration path through a network diagram and it is the shortest path to complete the
project. Knowing the project's critical path should be the goal of the scheduling process. MSP
calculates the critical path automatically and through the Gantt chart it shows what tasks are in it.
One thing to keep in mind is that as tasks are completed ahead or behind schedule the critical path
38
Approach
changes. Another is that there can be more than one critical path but this increases risk. If the
critical path takes your project's finish date way too far there are a couple of techniques that
project managers can use to compress the schedule:
1. Fast tracking - Perform critical path tasks in parallel that were originally planned
sequentially. It usually increases risk and often results in rework.
2. Crashing - Assign additional resources to critical path tasks while maintaining scope.
Almost always results in increased costs.
As project managers, we forget a very important intangible: resource calendars affect project
scheduling. Public holidays or time off in a resource's calendar makes those days non-workdays
and therefore, MSP skips them altogether.
Earned Value management (EVM) is the measurement, monitoring and control of project
progress in terms of cost, time and scope against an agreed fully integrated baseline plan. It is a
proven process that provides strong benefits for the control of projects .It facilitates the
integration of project scope, time, and cost objectives and the establishment of baseline plan
which performance can be measured during the execution of the project..
EVM has the unique ability to combine measurement of work performance (completion of
planned work ) ,Schedule performance (behind or ahead of schedule),and cost performance
(below or above budget) within a single integrated methodology .Furthermore it provides a sound
basis for early problem identification ,corrective actions ,and management re-planning as required
.The use of EVM improves delivery of projects.
Basic concepts of EVM are:
 All project steps “earn“ value as work is completed
 The earned value (EV) can then be compared to actual costs and planned costs to
determine project performance and predict future performance trends.
 Physical progress is measured in dollars, so schedule performance and cost performance

can be analyzed in the same terms.
39
Approach
Scheduling
Project scheduling is the art of planning dates for starting and completing activities and
milestones.
Critical Chain Project Management reduces project Lead time

In spite of the fact that project task durations are often conservatively estimated to begin with, the
presence of certain behaviours can cause them to increase. Critical Chain Project Management
and project scheduling eliminates these behaviours and reduces project lead times. Four
behaviours make project durations longer than necessary.
Useful Techniques to fine-Tune Your Project Schedule

One of the most common problems that project managers weep about is "unrealistic timelines," a
common consequence of clients having set their expectations too high even before the project
starts. Ironically, there are occurrences in the duration of a project when a staff is sitting idly,
waiting for a colleague to finish so he can start his own task. In this situation, does the project
manager shout foul and blame other people? Chances are, as a project manager, he needs to give
the project schedule a second look.
Project Scheduling And Resource Levelling

We all know that in the real world we, as project managers, are given the finish date of the project
before we even have a chance to plan for it. This is a good enough reason why we need to get
better at scheduling our projects and levelling our finite resources.
Comparing Current and Baseline Schedules
After a project is updated, a target comparison makes it easy to see variances between the current
and baseline dates.
40
Approach
Critical Path Mapping

The activity network diagram is a method of displaying the timelines of all the various sub-tasks
that are involved in any project. By doing this, the total task duration and the earliest and latest
start and finish times for each task are also calculated and displayed. In addition to showing
which sub-tasks are critical to on-time task completion, the activity network diagram can help
determine where extra effort to speed a sub-task will have the greatest payoff to overall speed.
Why Over 90 Percent of All Projects Finish Late

Several tools exist for managing projects, and have been available for decades. Yet most projects
fail and over 90 percent of them are delivered late. Find the answers below .
Project Management: Time Estimates and Planning

Accurate time estimation is a skill essential for good project management. Often people
underestimate the amount of time needed to implement projects. This is true particularly when the
project manager is not familiar with the task to be carried out. This article covers the basics to
think of when planning projects.
41
Approach
Estimating by Percentages
An experienced Planner have been occasionally asked what percentage of time in a project
should typically be devoted to a specific phase of work, for example a Phase 1 Feasibility Study,
Phase 2 Systems Design, etc. Basically, the reason the person wants to know this is to use it as a
means for estimating the remainder of the project. For example, if I were to say Phase 1
represents 10% of the overall project, they would simply multiply the amount of time spent in
Phase 1 by ten. This is an unreliable approach for estimating, which is why I usually balk at
giving out such figures.
Managing the Project Time

Project managers know, or should know, the iron triangle of project management sometimes
called the triple constraints of project management because all projects are constrained by these
three elements: time, cost, and scope. Every bodys opponent is the angle on the left, time.(the
ticking watch )
6 Steps to Successful Schedules

Creating a comprehensive schedule is one of the more difficult activities that project managers
face. Schedule creation is often considered more art than science, and results often support this.
What is often more frustrating is that team members often find themselves on one team with a
project manager that creates and manages schedules a particular way and on another team with a
project manager with a different approach.
The Art of Project Scheduling

Why the "art" of project scheduling? If it were a science then every project would be delivered on
time! This sadly does not seem to be the case. In fact, overruns have become so common that
people have lost faith in project deadlines and view them with a great deal of cynicism. In truth,
the art of scheduling is based on experience and the more experience you have, the more accurate
your schedule will be. However, you can still produce an accurate schedule by following some
simple rules.
Keep Your Project From Creeping Away

Delays and changes are a part of every project we do. Do we have to learn to deal with them?
Absolutely. Setting deadlines and scheduling is the best way to keep your project on track.
42
Approach
How to Plan and Schedule More Complex Projects
When a complex or multi-task project is under way, Gantt charts assist in monitoring whether the
project is on schedule, or not. If not, the Gantt chart allows you to easily identify what actions
need to be taken in order to put the project back onto schedule.
Creating a comprehensive schedule is one of the more difficult activities that project managers
face. Schedule creation is often considered more art than science, and results often support this.
What is often more frustrating is that team members often find themselves on one team with a
project manager that creates and manages schedules a particular way and on another team with a
project manager with a different approach.
I often hear from people on teams, "why can't all project managers do things the same way?"
If you have heard this on your team, perhaps it is time that you take a look at the way you and
your team create your team schedules. Perhaps you are not taking a consistent step in developing
team schedules that have been shown to work time and time again.
There are tons and tons of resources out there that claim the perfect answer to your scheduling
problems. But, I believe that you can improve your chances for success just by following the six
simple steps below.
Step 1: Define the Schedule Activities

Take your Work Breakdown Structure (WBS) work packages and decompose them further into
schedule activities.
Take each WBS work package, and decide what activities are required to create that package. For
example, if your work package is "configure new computer hardware," your schedule activities
might include "set up network configuration," "install the video card," "install applications," and
then "set up mail client."
Step 2: Sequence the Activities

Remember back in grade school where you were given a bunch of pictures and you had to figure
out their order. You had to decide which picture represented the 1st activity, the 2nd activity and
so on? Well, that is exactly what the second step is all about. In the second step we sequence the
schedule activities by simply placing them in the order in which they need to happen. For
example, perhaps we need to install the video card first, then set up the network configuration,
install applications and then finally set up the mail client. In some cases two or more activities
can be done simultaneously. Perhaps we can set up the mail client while other applications are
43
Approach
being installed. This step is where we look at the different types of schedule dependencies such as
finish-to-start, start-to-start, finish-to-finish, and start-to-finish to figure out how each of these
activities relate to each other.
Step 3: Estimate the Resources Needed for the Activity

The third step involves estimating what resources will be required to accomplish each activity.
This includes estimating needed team resources, financial resources, and equipment. These
resource needs should be selected for each activity prior to estimating the duration of each
activity which is the next step.
Step 4: Estimating the Duration of Each of the Activities

This step requires you and your team to analyse how long it will take to accomplish each of the
activities. These estimates can be quantified through the following tools:
 Expert Judgement: by conferring with someone who is familiar or experienced in
what it takes to accomplish a particular activity.
 Analogous Estimating: a top-down estimation approach is taken by looking at

similar projects within your organisation for estimates on how long a particular activity
should take.
 Parametric Estimating: basically this is scaling an estimate. For example, perhaps

you know it takes on average 10 minutes to install a software application. If the "install
applications" activity includes the installation of 6 applications, you can use parametric
estimation to estimate that it will take approximately 6 times 10 minutes, or 60 minutes to
install all the applications.
 Three point estimation: sometimes referred to as PERT analysis, is a great tool for
estimating activity durations. You basically take a weighted average of a pessimistic,

expected, and optimistic estimate for the activity duration. This estimate is in the form of
(Pessimistic + 4x(Expected) + Optimistic) / 6
Step 5: Schedule Development

This step is the process where the sequence of activities, resources needed for the activities, and
the duration of each activity is used to optimise the overall project schedule. Tools used in this
process include critical path method, schedule compression, what-if scenario analysis, resource
44
Approach
leveling, and critical chain methods. Each of these topics could have one or more articles
dedicated to it, so we will not go into the detail of each.
Once the schedule is developed, it should be baselined to provide a snapshot of the original
schedule plan of the plan.
Step 6: Monitoring and Controlling the Schedule

The final step is monitoring and controlling the schedule. This step is performed throughout the
life of the project and ensures that the work results lines up with the schedule plan. Schedule
control requires the use of progress reporting, schedule change control systems, such as the use of
project change requests, performance management, and variance analysis to determine if
additional action is required to get the schedule back in line with the plan.
So, those are the 6 steps you need to know to create a successful project schedule.
Top 10 Qualities of a Project Manager

What qualities are most important for a project leader to be effective? Over the past few years, the
people at ESI International, world leaders in Project Management Training, have looked in to
what makes an effective project leader. With the unique opportunity to ask some of the most
talented project leaders in the world on their Project Leadership courses ESI have managed to
collect a running tally on their responses. Below are the top 10 in rank order according to
frequency listed.
Inspires a Shared Vision

An effective project leader is often described as having a vision of where to go and the ability to
articulate it. Visionaries thrive on change and being able to draw new boundaries. It was once
said that a leader is someone who "lifts us up, gives us a reason for being and gives the vision and
spirit to change." Visionary leaders enable people to feel they have a real stake in the project.
They empower people to experience the vision on their own. According to Bennis "They offer
people opportunities to create their own vision, to explore what the vision will mean to their jobs
and lives, and to envision their future as part of the vision for the organisation." (Bennis, 1997)
45
Approach
Good Communicator
The ability to communicate with people at all levels is almost always named as the second most
important skill by project managers and team members. Project leadership calls for clear
communication about goals, responsibility, performance, expectations and feedback.
There is a great deal of value placed on openness and directness. The project leader is also the
team's link to the larger organisation. The leader must have the ability to effectively negotiate and
use persuasion when necessary to ensure the success of the team and project. Through effective
communication, project leaders support individual and team achievements by creating explicit
guidelines for accomplishing results and for the career advancement of team members.
Integrity
One of the most important things a project leader must remember is that his or her actions, and
not words, set the modus operandi for the team. Good leadership demands commitment to, and
demonstration of, ethical practices. Creating standards for ethical behaviour for oneself and living
by these standards, as well as rewarding those who exemplify these practices, are responsibilities
of project leaders. Leadership motivated by self-interest does not serve the well being of the team.
Leadership based on integrity represents nothing less than a set of values others share, behaviour
consistent with values and dedication to honesty with self and team members. In other words the
leader "walks the talk" and in the process earns trust.
Enthusiasm
Plain and simple, we don't like leaders who are negative - they bring us down. We want leaders
with enthusiasm, with a bounce in their step, with a can-do attitude. We want to believe that we
are part of an invigorating journey - we want to feel alive. We tend to follow people with a can-do
attitude, not those who give us 200 reasons why something can't be done. Enthusiastic leaders are
committed to their goals and express this commitment through optimism. Leadership emerges as
someone expresses such confident commitment to a project that others want to share his or her
optimistic expectations. Enthusiasm is contagious and effective leaders know it.
Empathy
What is the difference between empathy and sympathy? Although the words are similar, they are,
in fact, mutually exclusive. According to Norman Paul, in sympathy the subject is principally
absorbed in his or her own feelings as they are projected into the object and has little concern for
the reality and validity of the object's special experience. Empathy, on the other hand,
46
Approach
presupposes the existence of the object as a separate individual, entitled to his or her own
feelings, ideas and emotional history (Paul, 1970). As one student so eloquently put it, "It's nice
when a project leader acknowledges that we all have a life outside of work."
Competence
Simply put, to enlist in another's cause, we must believe that that person knows what he or she is
doing. Leadership competence does not however necessarily refer to the project leader's technical
abilities in the core technology of the business. As project management continues to be
recognised as a field in and of itself, project leaders will be chosen based on their ability to
successfully lead others rather than on technical expertise, as in the past. Having a winning track
record is the surest way to be considered competent. Expertise in leadership skills is another
dimension in competence. The ability to challenge, inspire, enable, model and encourage must be
demonstrated if leaders are to be seen as capable and competent.
Ability to Delegate Tasks

Trust is an essential element in the relationship of a project leader and his or her team. You
demonstrate your trust in others through your actions - how much you check and control their
work, how much you delegate and how much you allow people to participate. Individuals who
are unable to trust other people often fail as leaders and forever remain little more that micro-
managers, or end up doing all of the work themselves. As one project management student put it,
"A good leader is a little lazy." An interesting perspective!
Cool Under Pressure

In a perfect world, projects would be delivered on time, under budget and with no major problems
or obstacles to overcome. But we don't live in a perfect world - projects have problems. A leader
with a hardy attitude will take these problems in stride. When leaders encounter a stressful event,
they consider it interesting, they feel they can influence the outcome and they see it as an
opportunity. "Out of the uncertainty and chaos of change, leaders rise up and articulate a new
image of the future that pulls the project together." (Bennis 1997) And remember - never let them
see you sweat.
Team-Building Skills
A team builder can best be defined as a strong person who provides the substance that holds the
team together in common purpose toward the right objective. In order for a team to progress from
a group of strangers to a single cohesive unit, the leader must understand the process and
47
Approach
dynamics required for this transformation. He or she must also know the appropriate leadership
style to use during each stage of team development. The leader must also have an understanding
of the different team players styles and how to capitalise on each at the proper time, for the
problem at hand.
Problem Solving Skills

Although an effective leader is said to share problem-solving responsibilities with the team, we
expect our project leaders to have excellent problem-solving skills themselves. They have a
"fresh, creative response to here-and-now opportunities," and not much concern with how others
have performed them. (Kouzes 1987)
Research methodology
Introducing Quality & Quality Management Systems, in the next Gen Project
Management Systems
Quality is a fluid concept, difficult to define and hard to manage largely because it so subjective.
Quality means
 Fitness for use (Joseph M Juran 1988): The customer defines the fitness.
 Compliance with specific requirements , ( Crossby )
 Conformance to requirements ( crossby,1979 )
 Conformance to specifications (Crossby 1980s) .Note the difficulty with this definition of
quality is that the specifications may not be what the customer wants .Crossby treats this
as a separate problem.
 Degree of excellence.
 Meeting requirements. (Oakland).
 Customer Satisfaction ( Juran ,1993 )
 Delighting customers
48
Approach
 Freedom from defects, imperfection or contamination.
 The total composite product and service characteristics of marketing ,engineering
,manufacture and maintenance through which the product or service in use will meet the
expectations by customers (Feigenbaum,1983,1991 )
 Value to some person ( Gerald M Weinberg )
 Quality is pride of Workmanship .( W Edwards Deming ) .
The Evolution of Quality System:
In 1040‟s Shewhart introduced statistical quality control to achieve economy in manufacturing

.Deming ,Juran and crossby between 1950 and 1980 showed that Quality needs can be managed
.Ishikawa introduced 7 QC tools to the workers and brought in a quality revolution at the
grassroots .
Today quality has come to be seen as the personal responsibility of everyone .The focus has
shifted to process management and process optimization.
Many organizations have made quality innovations and established distinct quality cultures and
developed their own standards using concepts like JIT, War on waste, Zero Defect, Kaizen and
Six Sigma.
SCOPE :
ISO 9001:2000 standards specifies requirements for a Quality Management systems.

1. Where an organization needs to demonstrate its ability to consistently provide product
that meets customer and regulatory requirements ,and
49
Approach
2. Where an organization aims to enhance customers satisfaction through the effective
application of the system and assurance of conformity to customer and applicable
regulatory requirements.
 Product is a result of activities or processes (set of interrelated or interacting activities
which transform inputs into outputs ).There are four generic product a categories advised
in ISO 9001:2000 standard –
 Services
 Software
 Hardware
 And Processed material.
All the requirements of ISO 9001:2000 Standard are generic .The requirements mentioned in
the ISO 9001:2000 Standards are generic .The requirements mentioned in ISO 9001 : 2000
standard are intended to be applicable to all organizations regardless of type ,size and product
provided .Accordingly ISO 9001:2000 QMS requirements are applicable to all types of
business ,whether they are manufacturing industries .
Developing and Implementing ISO 9001:2008 QMS

Step 1 : Commitment from the top Management
The top management of the organization should demonstrate a commitment and

determination to implement and determination to implement ISO 9001:2000 quality
management system .Top Management must be convinced that registration and certification
will enable the organization to demonstrate a visible commitment to quality and continual
improvement .The top management must be aware of the overview of ISO 9001:2000 Quality
management System.
 Over view of ISO 9001:2000 ( amended to 9001:2008 )

 Identification of Goals and expectations
 Management responsibility in ISO 9001:2000
 Formulation of Quality Policy
 Formulations of Quality Objectives
 Appointment of management representive
50
Approach
 Establishing a steering committee and a task force
 Why Appoint a Consultant
 Step-by-step process for Implementation.
The top Management team should identify the goals the organization wants to achieve .Typical
goals of an organization may be following
 Providing more efficient products (services)
 Be more profitable
 Producing products (services) that consistently meet customer satisfaction.
 Achieving customer Satisfaction
 More business
 Maintaining market share (business )
 Improving communication in the organization
 Improving morale in the organization
 Reducing costs and liabilities
 Reducing waste and rework
 Increasing confidence in the production process
 Technical up gradation.
The top management will have to identify what others need from the organization .There are
expectations of interested parties such as customers (end users), employers, suppliers,
shareholders & society .
Step 2 Appointment of Management representative (MR)
The Top Management should appoint a Management representative to coordinate quality

systems activities .Appointment of MR is a requirement of ISO9001:2000.The requirement is
that top management of the organization nominates someone from management with
authority and responsibility for quality management system. The person nominated as
Management Representative should be a member of Management in the organization .The
responsibility and authority of Management representative cannot be assigned to outside
person.
51
Approach
Step 3 : Establishing a Steering committee and a task force.

The top management of the organization should set up a steering committee .The chief
executive of the organization should head the steering committee members should include the
organization‟s functional heads and the Management representative .
The committee should be responsible for overall planning of the implementation process,
giving directions and allocating resources.
The steering committee should be set up a task force .The management representative should
be made the Coordinator .The task force should be allocated the work of preparation of
documentation ,such manual ,procedures, work instructions ,etc .
the steering committee members .The Steering committee members should have good
understanding of organizations processes and also good communication –writing skills.
The members of the Steering committee and the task force should be trained on ISO
9001:2000(ISO 9001:2008 latest version) with amendments QMS by Professional training
organization .It is advisable that the management Representative Should under go Lead
Auditor training, so that he may be able to understand insights of the Standard ISO
9001:2008 .QMS .How ever undergoing Lead Auditor training is not mandatory.
Step 4: Appointing a Consultant.
Appointing a consultant is not necessary. However, the steering committee should determine
whether a consultant is required .Appointing a consultant may be worth while investment. A
good consultant will affect the speedy transfer of knowledge and skills to organization and he
will be needed to keep the implementation programme on track
Step 5; Obtain Information about ISO 9000 family.
The management representative should collect information about the ISO 9000 family .If you
have appointed a consultant, then it will be easier for you .For general information, look in to
code book of ISO 9000 published by ISO Central secretariat, Geneva.
Following purchases are recommended:
 ISO 9000:2005 Quality Management Systems –Fundamentals and vocabulary
 ISO 9001:2000 Quality management Systems –requirements
 ISO 9004:2000 Quality management Systems –Guidelines
 ISO 19011:2002 Guidelines on quality /Environmental Management Auditing.
 Various other publications/Literature providing knowledge on ISO 9001:2000.
52
Approach
Step 5: Start ISO awareness program in your Organization.
The ISO awareness program should be conducted
The Purpose and the Intent of ISO 9000:2000 series
Many organizations have made quality innovations and established distinct quality cultures and
developed their own standards using concepts like JIT, War on waste, Zero Defect, Kaizen and
Six Sigma .
Principles of QM Principles: The quality management principle is a comprehensive and

fundamental belief, for leading and operating an organization, aimed at continually improving the
performance on a long term basis by focusing on customers while addressing the needs of all the
other stake holders.
ISO 9001:2000 QMS standards is built upon eight quality management principles described in
ISO 9000 Standard .Briefly they are:
1. Customer focus
2. Leadership
3. Involvement of people
4. Process Approach
5. Systems approach to Management.
6. Continual Improvement.
7. Factual approach to decision-making
8. Mutually beneficial supplier relationship.
53
Approach
Literature review
QUALITY MANAGEMENT SYSTEM STANDARD
The basic spirit behind ISO 9000 has been that the supplier organization always wants to improve
the processes and implementation of the standard should be a good instrument for the supplier
organization to achieve this improvement, unfortunately, many organization considered
implementation of the ISO 9000 standards as a vehicle for third party certification (the focus is on
certification) and through that enhancing the business without actually improving the process.
This and other factors led some ISO 9000 certified companies to fail in the business and in the
competition, which was strongly highlighted by some as the result of lack of efficacy of the world
standard. It is not rare, where the authors had seen that even smaller companies which had
developed and implemented the system with the basic spirit of improving the processes, have
actually been benefited in the long run. Once one of our professors told that one should do
research with the spirit of finding something new, the Ph.D. degree would come to him as a by
product, similarly, the organization implementing the ISO-9001:2000 with the basic spirit in mind
would actually be successful in the long run and invariable observed growth of their business.
54
Approach
1.8 THE CLAUSES OF ISO 9001:2000 AT A GLANCE
The information contained in ISO9001:2000 in the form of various clauses and sub-clauses is
discussed in detail in Chapter 2. However, Table 1.1 Provides „ISO 9001:2000 at a glance‟.
Table 1.1 ISO 9001:2000 at a glance
Clauses Sub-clauses Sub-Sub clauses Contents

1. Scope 1.1 General  Specification of requirements
1.2 Application  Nature of requirements
 Conditions for exclusion
2. Normative  Provision of the Standard
Reference
3. Terms &  Supplier Organization Customer
Definitions  Others as in ISO 9000
4. Quality 4.1 General
 Identify process, determine sequence,
management Requirements determine method, ensure availability of
system resources monitor, measure and
implement action
4.2 Documentation 4.2.1 General
 Quality policy & Objectives, Manual,
procedure, planning, operation & control
& those of 4.2.4
4.2.2 Quality
Manual  Contents
4.2.3 Control of  Objectives of control
Document  Objectives
4.2.4 Control of
records  Means of evidence and improving
5.Management 5.1 Management effectiveness
Commitment  Top Management‟s role
Responsibility 5.2 Customer focus  Top management to ensure
5.3Quality policy appropriateness, commitment to comply,
continual improvement, review and
communication
55
Approach

5.4 Planning 5.4.1 Quality  Ensure establishment of measurements
Objective and Consistent objectives
5.4.2. QMS  Planning objectives
Planning  Condition for ensuring integrity of QMS
 Define responsibility and authority and
5.5 Responsibility, 5.5.1 Responsibility communicate within the organization
authority and and authority
communication  Member of management with defined
responsibility and authority to
5.5.1 Management 1. Ensure establishment, implement and
representative maintain QMS
2. Promote awareness of customer
requirements
 Communication processes to convey
effectiveness of QMS within the
5.5.3 Internal organization
communication
 Review of QMS
5.6 Management 5.6.1 General
 Audit results, customer feedback
review
5.6.2 Review input  Product performance and conformity
 Results of preventive & corrective actions
 Follow up from previous review
 Decisions and actions on improvement of
1. Effectiveness of QMS & processes
2. Product related to customer and
5.6.3 Review resource needs
Output  Determine and provide the resources for
1. Implementation & maintenance of
QMS
6. Resource 6.1 Provision of 2. Enhancement of customer satisfaction
Resources  Basics of competence
 Activities related to improvement of
human resources
 Provisioning and maintenance of related
infrastructure
 Provisioning of appropriate environment
6.2 Human 6.2.1 General  Determination and development of
Resource 6.2.2 Competence appropriate process
awareness  Requirements as specified or implied
6.3 Infrastructure and training statutory/regulatory, and additional
6.4 Work
Environment
7. Product 7.1 Planning of
realization product realization 7.2.1 Determination
7.2 customer of product related
related process requirements
56
Approach
7.2.2. Review of  Activities related to product requirements

product
related
requirements
 Subject matter of communication
7.2.3 Customer
7.3 Design and communication  Determination of stages, review and
Development 7.3.1 D & D validation for a stage and responsibility
review Planning and authority
 Different kinds of inputs
7.3.2 D & D
Inputs  Criteria for outputs
7.3.3 D & D
output  Objectives of review
7.3.4 D & D
review
 Manner and objective
7.3.5 D & D
Verification
 Manner and objective
7.3.6 D & D
Validation
 Activities related to changes
7.3.7 Control of D
7.4 Purchasing & D changes
7.4.1 Purchasing  Objectives, manner and criteria
process
7.4.2 Purchasing  Description of product and related
information requirements
7.4.3 Verification  Implementation of inspection activity
of purchased
7.5 Production and product  Criteria for controlled conditions
Service 7.5.1 Control of
Provision production &
service
provision  Objectives and arrangements for
7.5.2 Validation of processes
processes  Items and activities
7.5.3 Identification
& traceability  Related activities
7.5.4 Customer
property  Related activities
7.5.5 preservation
7.6 Control of of product  Choice, objectives and related activities
monitoring and
measuring
devices
57
Approach
8. Measurement 8.1 General 8.2.1 Customer  Objectives

Analysis and 8.2 Monitoring Satisfaction  Required information
improvement and 8.2.2 Internal audit
measurements 8.2.3 Monitoring &  Objective and related activities
measurement  Criteria for suitability
of process
8.2.4 Monitoring
and measure-  Objective and related activities
ment of
product
8.3 Control of  The objectives and manner of dealing
non with nonconforming product
conforming
product
8.4 Analysis of
 Data coverage and purpose of analysis
data
 Guidance for carrying out improvement
8.5 Improvement 8.5.1 Continual
work
Improvement
 Various documented procedures with
8.5.2 Corrective
defined requirements
action
8.5.3 Preventive  Various documented procedures with
action defined requirements
Findings and analysis
Sample QMS Procedures at the Performing Organisation
KIE Projects Pvt Limited.

Sample QMS Procedure on ‘Control of Documents’
Organization Procedure No.KIE/QP/01
Name QMS Procedure Amendment No. 00
KIE Project (P) Control of Documents Page 1 of …..
Ltd Effective Date DD-MM-YYYY
1. Purpose: The Purpose of this QMS procedure is to define a procedure for control of
documents.
2. Scope: This QMS procedure is applicable to all departments of our company.
58
Approach
3. Reference: ISO 9001:2000 Clause 4.2.3
4. Cross Reference: Quality Manual Para …… (Please mention appropriate reference).
5. Responsibility: Management representative and respective departmental heads.
6. Procedure:
The Quality Manual and QMS Procedures of our company are documented in a standard
format having the following information:
 Organization name
 Type of document (quality manual or QMS procedure)
 Title (for example, Control of Documents)
 Document number
 Page number
 Effective date
 Prepared by
 Copy number
 Date of issue
 Approved by
 Issued by
The Managing Director is the competent authority to approve for adequacy prior to the issue
of the Quality Manual and QMS Procedure(s). thereafter, the Management Representative issues
these documents.
Controlled copies of documents are stamped controlled copy in red ink and issued to
locations where they are required for effective functioning of the quality management system.
The Management Representative ensures that controlled copies of relevant documents and
their amendments, if any, are promptly distributed t o holders. The Management Representative
takes necessary steps to immediately remove superseded documents from all points of issue or
use. He destroys superseded documents to prevent any unintended use. However, the
Management Representative retains a set of all superseded documents under his issuing authority
for reference. Such documents are stamped superseded.
6.5 Each document binder has an index indicating the current revision status of the
documents. When an amendment is made, the amendment number of the document is
revised upwards and the same is indicated on the document, index and amendment
record sheets. Changes to documents are described in brief in the amendment record
sheet of the respective document binders.
6.6 The index has following details:
59
Approach
Amendment Amendment Amendment
Sr. Document /
Title No. No. No.
No. Procedure No.
Effective Date Effective Effective
Date Date
6.7 The amendment record sheet has following details:

Sr. Document /
Amendment Reason for
No. Procedure No. Effective Date
No. Amendment
6.8 A list of controlled copyholders of documents/procedures are maintained with

following details:
Copy No. Holder Documents (Sr. No.) issued as per index
Such list is distributed to controlled copyholders.

6.9 Auditor's copy of documents is under the control of the Management Representative
and issued to the auditor(s) whenever required by him/them.
6.10 A master list of procedures, work instructions, formats/charts, etc. are maintained by
the Management Representative. The current revision status of these documents is
also indicated in the list.
6.11The Management Representative ensures that:
 Changes and the current revision status of documents are identified
 Relevant versions of applicable documents are available at points of use
 Documents remain legible and readily identifiable.
6.12 Documents of external origin (such as National! International Standards, Statutory
Rules/Regulations, etc.) are identified and their distribution are controlled by
maintaining following list:
Sr. No. Document of External Origin Holder
The Management Representative maintains such list.

7. Distribution: Following are the holders of controlled copy of this QMS procedure:
60
Approach
 Managing Director
 Management Representative
 Manager (Purchase)
 Manager (Works)
 Manager (Marketing)
 Manager (Customer Service)
 Auditor.
(Please note that the above list is illustrative)
Prepared by Copy Date of Issue Approved by: Issued by:
AKM. No. 1 DD-MM-YYYY Sd/-M.D. Sd/-M.R.
Sample QMS Procedure on 'Control of Records'

Organization Procedure No. KIE/QP/02
Name QMS Procedure Amendment No. 00
KIE Projects P Control of Records Page 1 of 7
ltd Effective date: DD-MM- YYYY
1. Purpose: The purpose of this QMS procedure is to define a procedure for control of records in
the organization.
2. Scope: This QMS procedure is applicable to all departments of our company implementing
ISO 9001:2000.
4. Cross Reference: Quality Manual Para (Please mention appropriate reference).
5. Responsibility: Management Representative and respective departmental heads.
6. Procedure:
6.1 Records in our organization are maintained to provide evidence of conformity to
requirements and of the effective operation of the quality management system. The
records are established and maintained as per documented procedure and are accessible to
all users.
6.2 Records are maintained in a legible manner and are readily retrievable.
6.3 Records are stored in suitable facilities to prevent damage, .deterioration or loss.
6.4 Following records have been identified and are kept in respective files indicating the file
number and retention time:
Records File No. Retention time
61
Approach
Management review QMS/RF/001 5 years
Education, training, skill
and experience QMS/RF/002 Pl. see Para. 6.5
Evaluation of suppliers QMS/RF/003 5 years
(Above list is illustrative. Please complete the list of records as per your organization's
needs and QMS requirements.)
6.5 Records of education, training, skill and experience of employees are kept in the
personnel files of employees concerned. Such records are kept till employee remains in
the service of the organization.
6.6 After expiry of the retention period, a particular record may be disposed of with the
sanction of the General Manager in-charge of the department concerned. For example,
record of evaluation of a supplier may be disposed of with the sanction of the General
Manager (Purchase).
6.7 Records are maintained and kept in good manner by the respective department
heads/personnel as indicated below:
Records Holder of records
Management review Management Representative
Education, training, skill
and experience Manager, HRD
Evaluation of suppliers Manager (Purchase)
Internal audit Management Representative
(Above list is illustrative. Please complete the list of records as per your organization's
needs and QMS requirements.)
7. Distribution: Following shall be holders of controlled copy of this QMS procedure:
 Managing Director
 Management Representative
 Manager (Purchase)
 Manager (Works)
 Manager (Marketing)
 Manager (Customer Service)
 Auditor.
(Please note that the above list is illustrative.)
62
Approach
………….. No. 1 DD-MM-YYYY Sd/-M.D. Sd/-M.R.
Sample QMS Procedure-Internal Audit

Procedure No. KIE/QP/03
Organization
QMS Procedure Amendment No. 00
Name
Internal Audit Page 1 of 7
KIE
Effective date: DD-MM- YYYY
1. Purpose: The purpose of this QMS procedure is to define a procedure for internal audit
in the organization.
2. Scope: This QMS procedure is applicable to all departments of our company
implementing ISO 9001:2000.
5. Responsibility: The Management Representative shall be responsible for planning and
execution of internal audit in our organization at planned intervals.
6. Procedure:
6.1 The internal audits in our organization are conducted to verify the compliance
and effectiveness of the quality management system in our organization to ensure
that the quality management system:
 Conforms to the planned arrangements, to the requirements of ISO 9001:2000
and to quality management requirements established by our organization
 Is effectively implemented and maintained.
6.2 The frequency of internal audit is at least once in a year. Accordingly, each
activity/location unit is audited at least once a year.
6.3 Based on the recommendation of the Evaluation Panel and selection procedure
for internal auditors, the Management. Representative decides the audit team and
team leader. Qualification criteria for internal auditors are on the basis, of
International Standard ISO 19011:2002.
6.4 The Management Representative decides the quantum of work relating to internal
audit. He advises the tentative dates to the auditors and auditees (i.e. department
heads of the departments under audit). Reference form is used: KIE/QF/11-Audit
Scope.
63
Approach
6.5 The audit team leader decides the exact dates and time with team members and
informs the same to auditee and the Management Representative.
6.6 The Audit Team Leader prepares checklist for system adequacy audit in
consultation with team members. Checklist form: KIE/QF/12 should be used.
6.7 It is the duty of the Audit Team Leader to carry out adequacy system audit based
on our Quality Manual. Observations are noted in checklist form No. KIE/QF/12.
6.8 On the fixed date and time, a formal entry meeting is conducted by the audit team
with the head of the auditee department with the following agenda:
 Introduction of team members
 Scope of audit
 Guide for auditors
 Special requirements of safety kits (if needed)
 Any other point.
Responsibility: Audit Team Leader.
6.9 Thereafter, the team members as per direction of the Audit Team Leader conduct
the audit. During audit, the respective team members in his observation notes
record objective evidence. In case of nonconformity, an acceptance is obtained
from the guide or person concerned at the place of audit. This is properly
recorded in Corrective Action Request (CAR) form No. KIE/QF/13.
A summary of audit along with CAR forms is prepared and presented in
the exit meeting at the end of audit to the head of department. If a follow-up audit
is agreed upon, then follow-up audit is conducted at a decided date.
On completion of corrective actions, a particular nonconformity may be
cleared and the same is recorded in the CAR form.
6.10 A final report on form No. KIE/QF/14 is submitted to the auditee department by
the Audit Team Leader with a copy to the Management Representative.
6.11 Corrective action is planned and initiated by the department head under
intimation to the Management Representative.
6.12 Management Representative monitors timely compliance of CARs. The
Management Representative maintains records of internal audits. Management
Representative puts the results of internal audit for Management Review.
6.13 There may be instances where audit team may consist of single internal auditor
and such auditor acts as Audit Team Leader.
7. Documents:
64
Approach
Audit Scope Form : Form No. KIE/QF/11
Checklist Form : Form No. KIE/QF/12
Corrective Action Request (CAR) Form : Form No. KIE/QF/13
Audit Report Summary Form : Form No. KIE/QF/14
8. Distribution: Following are holders of the controlled copy of this QMS procedure:
1. Managing Director
2. Management Representative
3. Manager (Purchase)
4. Manager (Works)
5. Auditor.
Specimen: Form No. KIE/QF/11

Organization Name: KIE Projects (P) ltd
Audit Scope
Department/Area ……………………
Audit No………………….
1. Audit Date(s) planned
2. Audit Team
3. Audit Scope
Check (x)
[ ] Full
[ ] Closing out (See 4)
[ ] Specific (See 5)
4. Audit Scope: Closing out
Reference of previous audit report(s)
5. Audit Scope: Specific
Details of aspects to be checked
6. Standard covered: ISO 9001:2000
7. Distribution
1. Audit Team Members:
2. Auditee Department:
8. Signature of MR and Date:
65
Approach

Sheet ………….of……………
Organization Name: KIE
Checklist Form
Clause Quality 1 2 Remarks/
Sl. No. Aspect
ISO Elements System Compliance Comments
Please indicate with following codes:

At Serial No. l - System At Serial No. 2 - Compliance
A-Defined A-Compliance in full
B-Defined with deviation B-Compliance with deviation
C-Not defined C-Non-compliance MINOR
D-Not applicable D-Non-compliance MAJOR
Note: For B, C and D, auditor should indicate his remarks/comments.

Organization Name: KIE Projects (P ) Ltd
Corrective Action Request (CAR)
Department:
Auditor(s):
Department Representative:
Audit Reference No. and Date:
Quality Manual Procedure Reference:
Standard: ISO 9001:2000
Non-compliance Remarks (by the auditor) Major/Minor
Auditor Signature with date Auditee Signature with date

Corrective Action Recommended/Agreed (Auditee should make his remarks)
Tentative date for completion
Auditee Signature with date Auditor Signature with date
66
Approach
Follow-up Action
Action Completed (Verification should be done)
Auditor Signature with date

Audit Report Summary
1. Department
2. Audit No.
3. Audit Team
4. Date(s) of Actual Audit
5. Total No. of Nonconformances reported (6+7+8)
6. No. of nonconformances for which QMS requirements not defined
7. No. of nonconformances for which QMS requirements not implemented
8. No. of nonconformances where the practice is not effective
9. Enclosures (please indicate total number of pages)
10. Signature of auditors with date
(1) ………………………………….
(2) ………………………………….
11. Review by the Management Representative
12. Signature of the Management Representative with date
Sample QMS Procedure on 'Control of Nonconforming Product'
Procedure No. KIE /QP/04
Organization
QMS Procedure Amendment No. 00
Name
Control of nonconforming Page 1 of ………..
KIE Projects P
product Effective date: DD-MM- YYYY
ltd
1. Purpose: The purpose of this quality management system procedure is to define a procedure
for control of nonconforming product in the organization.
ISO 9001:2000.
67
Approach
3. Reference: ISO 9001:2000 Clause 8.3
5. Responsibility: The Manager (works) is authorized to take suitable steps for control of
nonconforming product.
6. Procedure:
6.1 Our manufacturing processes undergo various inspections and tests. A nonconforming
product is normally detected during one of the inspection and/or test stages.
6.2 The moment any nonconformity is noted, the product is clearly identified with suitable
code or mark. This code or mark makes it apparent that the product does not conform to
requirements. Details of such nonconforming product are recorded in the Record
Performa of nonconforming product (Form No. KIE/QF/15).
6.3 Such nonconforming product is physically segregated and kept at a place meant for storing
nonconforming products pending review.
6.4 Details of such nonconforming product are brought to the knowledge of the Manager
(works) for review.
6.5 The manager (works) reviews the nature of nonconformity of the product and he may take
one of the following decisions:
 Releasing nonconforming product as the nonconformity is so minor as to have no
effect on the performance of the end-products, subject to approval by the customer
(where applicable).
 To rectify the nonconformity by reworking, thereby ensuring complete compliance
with specified requirements.
 By repairing or reprocessing so as to meet specifications.
 By regarding the product to a. lower quality category with whose requirements it
complies or by marking as a second product to be sold at a reduced price.
 By declaring the nonconforming product as scrap, if none of the above actions can
be taken.
6.6 When a nonconforming product is to be used as it is or after repair, it is said to be under
"acceptance on concession". In contractual situation, a reporting is made to the customer,
describing the nature on the nonconformity, the quantity affected and the details of the
rectification proposed.
6.7 Decision taken by the manager (works), based on the review of the nonconforming
product, is quickly implemented to minimize the effect on production schedule.
Accordingly, product needs rework/repair/reprocess is sent to the department concerned
68
Approach
promptly. Disposal of products (declared as scrap) is done periodically by the manager
(works) as per his delegated authority.
7. Documents: Performa Record of Nonconforming Product- KIE/QF/15.
4. Manager (Works)
5. Auditor.
(Please note that above list is illustrative)
Specimen: Form No. KIE /QF /15

Proforma Record of Nonconforming Product
Department: …………………….
Reporting No.: ………………….
1. Description of the product (with batch number, if any):

2. Nature of the nonconformity observed:
3. Identification mark/code marked on the nonconforming product:
4. Have you physically segregated the product? If yes, kept where?
5. Comments/Recommendations:
6. Signature of Reporting Personnel, designation and date
Review by the Manager (Works)

The abovementioned nonconforming product may be
[ ] Released as the nonconformity is so minor as it will have no effect on the
performance of the end product.
[ ] Repaired.
[ ] Reprocessed.
[ ] Regarded to lower quality category.
[ ] Marked as second product for selling at a reduced price.
[ ] Declared as scrap.
Specific remarks, if any:
69
Approach
Date: Signature of the Manager (Works)
Disposal Action Taken

Date: Signature with designation
Sample QMS Procedure on 'Corrective Action'

Organization
Amendment No. 00
Name QMS Procedure
Page 1 of 2
KIE Projects Corrective action
(P) Ltd
1. Purpose: The purpose of this quality management system procedure is to define a procedure
for corrective action in our organization.
ISO 9001:2000 QMS.
3. Reference: ISO 9001:2000 Clause 8.5.2 .
4. Cross Reference:
1. Quality Manual Para (Please mention appropriate reference).
2. QMS Procedure No. KIE/QP/04.
5. Responsibility:
1. Head of departments
2. Manager (Works).
6. Procedure:
6.1 Our organization is committed to eliminate causes of nonconformities in order to
prevent recurrence.
6.2 For reviewing nonconformities and taking necessary actions, there is a QMS
procedure in our organization and the Manager (Works) is authorized to deal such
nonconformities. Please refer to the QMS Procedure Ref. No. KIE/QP/O4.
70
Approach
6.3 Customer complaint received in the organization is brought to the notice of the head of
the department to which it relates. The head of the department reviews the customer
complaint, evaluate the need for action, determine and implement the action needed.
6.4 If the customer complaint relates to nonconformity, of the product manufactured by
our organization, then such customer complaint is sent to the Manager (Works) for
his review and necessary action.
6.5 Our organization maintains records of customer complaints in a register, having
following details:
1. Sr. No.
2. Date of receipt of customer complaint
3. Customer's name and address
4. Brief details about the nature of customer's complaint
5. Actions suggested/taken
6. Results of action taken
7. Date(s) of reply to customer
8. Date of closure of customer complaint
6.6 Monthly report of customer complaints is prepared by each department and sent to the
Manager (Customer Relations) and a copy to the Management Representative.
6.7 The Manager (Customer Relations) reviews the corrective actions taken periodically
and submits his consolidated report to the Management Representative once in a
quarter.
2. Managt!ment Representative
4. Manager (Customer Relations)
5. Manager (Works)
6. Auditor.
Sample QMS Procedure on 'Preventive Action'
71
Approach
Organization
Amendment No. 00
Name QMS Procedure
Page 1 of 2
KIE Projects Preventive action
(p) Ltd
1. Purpose: The purpose of this QMS procedure is to define a procedure for preventive
action in our organization.
2. Scope: This QMS procedure is applicable to all departments of our company
implementing ISO 9001:2000 QMS.
4. Cross Reference:
Quality Manual Para………… (Please mention appropriate reference).
5. Responsibility:
1. Manager of departments, and
2. Management Representative.
6. Procedure:
6.1 Our organization is committed to eliminate causes of potential nonconformities in
order to prevent their occurrence.
6.2 Customer complaints, internal audit reports, customer feedback, employee's
suggestions are used as inputs for preventive actions.
6.3 It is the responsibility of the managers of departments and the Management
Representative to take suitable steps to eliminate the causes of potential
nonconformities.
6.4 Applying and adhering to the stipulated norms, procedures and processes reduce
potential nonconformities.
6.5 Managers of departments and the Management Representative meet once in a
quarter to discuss potential nonconformities, evaluating the need for action,
determining and implementing the action needed. The Management Representative
calls such meeting. Top Management Executive(s) is/are also invited in such
meetings.
6.6 The Management Representative maintains records of the minutes of such meetings
and records of results of action taken.
72
Approach
6.7 Status of preventive actions is reviewed in the Management Review meetings,
which is held once in six-month period.
7. Distribution: Following are holders of the controlled copy of this QMS Procedure:
4. Manager (Customer Relations)
5. Manager (Works)
6. Auditor.

Note: Please note that the quality management system documentation of one
organization can differ from another due to:
 The size of the organization
 Type of activities
 The complexity of procedures, and their interactions
 The competence of personnel.
Above QMS procedures have been given only for guidance purpose.
11. Closing a Project:

Project closure is an important aspect of project management that is often
overlooked. A project that is not closed will continue to consume resources, albeit slowly.
To receive acknowledgment from the customer that the project has ended the
customer acceptance form is used. Once signed off the project team is disbanded and no
more work is carried out.
At this point it is important to know whether the project has achieved its goals
and objectives. This is done using the project closure report. This document
communicates how well the project has performed against its original business case,
quality criteria, costs, duration and tolerances.
73
Approach
Rather than .leave valuable project experiences locked in peoples heads, it's a
good idea to complete and publish a lessons learnt report. This document is used to pass
on any lessons that can be usefully applied to future projects.
12. Project Plan Development:

The Project Plan Development is a process whose output is a project plan
document, a document that form the basis for implementing the software development
project, and is a source of information on various entities of the project and the software
product proposed for development.
The document is prepared using knowledge areas and the life cycle model of
development. A typical project plan document would have the following contents:
Introduction - Project name, customer, project code

- Objective/purpose of the project
- Background information
- References and contexts
Project organization - Project manager and the team
- Skill profiles
- Organization chart
- Reporting structure, roles and responsibilities
Name and address of vendor and business partners
-
participating in the project
- Persons associated with the project, DBA, SA, NA
SOW, broad scope and boundaries: major functions,
Scope -
applications
Deliverables - Software products in detail
- Documentation
- Training
- Support
- Services
List of projects of similar nature and access
Project references -
information
Project time line - Project duration broken down into major blocks by
74
Approach
deliverables and putting dates of offers
Mention on development platforms, deployment
Infrastructure - platforms, upgrades, purchases of hardware and
software, offsite and onsite requirements
Contracts, document to be prepared for signatures.
Relationship -
Approvals to be obtained
Major WBS SOW and broad scope to be modeled
- into two layered WBS for understanding
assumptions and constraints
Master Gantt chart showing WBS, PERT Network
Schedule -
and Critical Path assumptions and constraints
Cost budget, resource budget billing schedule and
Budgets -
cash flows
This project plan document is used as master plans document to initiate and co-
ordinate all activities in the project planning, scheduling and control. It is also used for
probing into knowledge areas and integrating them in the life cycle development process.
13. Project Execution Plan:

The Project Execution Plan is used for managing and performing various tasks
described in the project plans. The execution plan translates the project plan into a set of
executable activities, assigning responsibilities, indicating when to begin and complete
the work, use of tools and technologies and output executables. In other words, project
integration management rides over project planning and execution. Project planning
decides what to execute, when and in which order. Project execution gives effect to the
project plan.
Project execution is effected through a work authorization system. It is a system
giving a green signal to start the activity or task after ensuring that the necessary inputs
and resources are available to start the activity. The system could be manned or
automated, linked to a system that monitors the progress of the preceding depending
activities, and triggering the start of the activity with communications sent to persons in
the project team.
Having started the activity, it needs to be monitored for different aspects such as
time, cost and quality and an assessment action is expected to control the progress of the
75
Approach
activity. Here also, the conventional system is to conduct review meetings and assess the
status. In the automated system, the project MIS will trigger various actions to set the
progress right.
Use of project management tools, like Microsoft-Project (MS-Project) or
Primavera, is very effective for planning, scheduling and assessing the progress of the
activities, tasks and WBS.
He must define each of the alternatives. Hence, the definition involving a determination
of consequences or impact of each of the proposed alternatives.
The individual must exercise a choice between the alternative i.e. he has to make a
decision with maximum input, feedback and participation of superiors as well as
subordinates.
Planning is a systematic attempt to achieve a set of goals within the specified
time limit under the constraints of available resources restrictions involving the least
sacrifice. Broadly speaking planning involves two different methodologies.
a) Planning by incentive and
b) Planning by direction.
Planning by incentive mainly depends on the controlling of economic tools to
push economic resources towards the attainment of set goals within the specified, period.
Planning by direction gives more emphasis on the direct participation of the
central planning authority in the economic activities to attain the set goal within the
estimated time limit.
Planning is decision making based upon futurity. It is a continuous process of
making entrepreneurial decisions with an eye to the future, and methodically organizing
the effort needed to carry out these decisions. The following figure vividly explains the
key elements involved in the planning structure. This type of well-structured project plan
helps to establish an effective monitoring and control system.
Project planning structure:

The various activities involved in project planning is given in the following chart as
76
Approach
Project planning
Work Description and Instruction

Project
Objectives
Management
Decision Network
Making Scheduling
Reports Master
Schedules
Time / Cost
Performance Budgets
7.2 PRODUCT REALISATION PROCESSES
77
Approach
7.2.1 CONTRACT REVIEW
Purpose: To analyse the customer specifications and convert them into our requirements.
Process Flow and Records:
PROCESS FLOW RECORDS
Customer Enquiry
Studying the Customer

Requirements Project Analysis
Report (GN/01)
Feasibility Study
Quoting
Negotiation and Finalisation
Contract/Order
Remark: Jobs taken as a job work from the parent organization will not include quoting,
negotiation and finalization. However, such jobs go through feasibility study to
understand the requirements of the customer and compare with our capability.
Measure of Effectiveness:
 Number of times potential customers are lost.
7.2.2 New Job Analysis
78
Approach
Purpose: To understand the customer specifications, decide on the work flow and communicate
down the line after confirmed order.
Process Flow and Documents/Records:
PROCESS FLOW DOCUMENTS/RECORDS
Customer
Specifications SP/CU/XX
Studying the customer specifications

by project management team (PMT)
and creating the report with quality Quality New Job
plan plan (QP) Analysis
QP/CU/XX Report
(GN/02)
New Job Analysis
Report and Quality
Plan
 Number of customer complaints related to specs
 Number of amendments to Quality Plan
Remark: The new job specifications will be added in the Master List of Documents (F/QSP-
01/02) when it is different from job to job. The process manual will be updated when a
revision takes place.
7.2.3 Materials Purchasing
79
Approach
Purpose: To purchase the materials to satisfy user requirements.
Process Flow and Documents:
 Number of shortages not due to indentor.
80
Approach
7.2.4 Sub-Contracting
Purpose: To evaluate and select Sub-contractors as per company requirements.
Process Flow and Documents/Records:
 Number of errors per 100 pages for sub-contracted jobs.
7.2.5 Quality Control
81
Approach
Purpose: To control the output quality of the product.
 Number of customer complaints.
7.2.6 Server Administration
Purpose: (i) To create user identification codes (ID) and give security to users
(ii) Monitoring and managing the server
82
Approach
 Number of complaints per month against server administration
Remarks: Backup of server is taken on daily basis.
7.2.7 Trouble Shooting
Purpose: Solving the user problem timely and appropriately
83
Approach
 Number of complaints not resolved within due time.
7.2.8 Preventive Maintenance
Purpose: To ensure trouble free working condition of infrastructures.
84
Approach
 Number of breakdown of Machines/Server/Network
7.2.9 Infrastructure/Upgradations
Purpose: To provide latest technological improvements for working environment.
85
Approach
7.2.10 Software Development
86
Approach
Purpose: To enhance productivity and to reduce manual work wherever possible. The following
are the phases described briefly.
7.2.11 Customer Requirements Phase
Purpose: Understanding the requirements, analyzing the same for computerization.
7.2.12 Design Phase
87
Approach
Purpose: To bring out the abstract requirement specification into the form of actual software
design.
88
Approach
7.2.13 Coding Phase
Purpose: Releasing the software for validation to meet customer specification.
7.2.14 Testing Phase
89
Approach
Purpose: To ensure the software developed, meets the user requirements.
 Number of complaints per software developed
 Number of time overruns
Document Details: Maintenance Manual – (MA/SD/01)
90
Approach
7.2.15 Personnel Management (Recruitment)
Purpose: To recruit suitable personnel for the job.
 Increase in productivity
91
Approach
7.2.17 Invoicing
Purpose: Timely raising of bills and follow-up of payments.
 Number of wrong invoicing
92
Approach
7.2.18 Stores
Purpose: To ensure the availability of consumables and spares.
 Number of times production held up due to shortage of materials.
TREE DIAGRAM
93
Approach
What is it?
It is a technique used for systematically and sequentially developing the required means to
accomplish the objective. It breaks down a topic into its component element showing the logical
and sequential links.
When Used?
1. In quality planning process, when we want to identify progressively finer levels of
actions needed to achieve the desired goal.
2. Identification of root causes of problems
3. Designing new products/services
4. Creating an implementation plan etc.
How to Use?
1. Establish the objective (target)
2. Subdivide the goal statement into major secondary categories or means
3. Break each major heading into greater detail
94
Approach
4. Repeat step 3 again to branch into components, sub-components of each major heading
5. Review the diagram for logic and completeness
PROCESS OF CERTIFICATE – AN ORGANIZATION
The Questioning / Auditing Techniques
95
Approach
Auditing is a skilled job. It should be done in a systematic manner, effectively as per the defined
procedure.
Audit technique
 Focus more on the process, and less on procedures.
Some documented, work instructions, check-lists may be necessary in order for the
organization to plan and control its processes, but the driving force should be the
process performance.
 Focus more on results, and less on records
Some records may be necessary in order for the organization to provide objective
evidence that its processes are effective (generating the planned results)
Value-added auditor should be aware of and give credit for other forms of evidence.
 Use “plan-do-check-act” to evaluate organization process effectiveness.
 Has the process been planned?

 Is it being carried out according to plan?
 Are the planned results being achieved?
 Are the opportunities for improvement being identified and implemented?
 By correcting non-conformities
 By identifying root causes of problems and implementing corrective action
 By identifying trends, and the need for preventive action
 By innovation
 Remember the 8 quality management principles!
 Adopt a “holistic approach to evidence-gathering through out the audit, instead of

focusing on individual clauses of ISO 9001:2000.
96
Approach
These are also open  In what way the Customer  These types of questions
questions, which aim at Complaints discussed in are advisable to ask as
getting information clarify, Management Review they keep the auditee at
PROBING regarding the subject. meetings? ease & also focus on the
subject matter.
 How do you verify the  Don‟t repeat such type of
requirement of Design input question as the auditee
in drawings? might get a feeling that
you are not listening
It is a direct question, which  What is your authority?  Provides very limited
leads straight answers like  Do you personally review information.
„YES‟ or “NO”. the Product NCs daily?  Don‟t shoot closed
Such questions are used to  Do you control the Drawing questions one after
get specific answers for s before enclosing with the another, before answers
CLOSED certain purposes like PO raised on supplier. for previous ones are
CONFIRMING the final received.
Evidence.
The TONE of closed

questions is to be in a
friendly way otherwise the
auditee will not be
comfortable.
UNACCEPTABLE TYPE OF QUESTIONS

Types of Explanation Examples Caution Points
questions
INTERROGA Auditing is not investigation. Such  Don‟t you realize that  NEVER EVER
TIVE methods put the auditee in a defensive your calibration method USE SUCH
mood & facts cannot be found. is useless & that is not QUESTIONS
Auditing is a friendly approach & acceptable to us?
finding facts by the method is much  Your internal Auditors
difficult than investigation, which is are not confident of their
much more authoritative. Authoritative jobs. Mr. MR, don‟t you
is not a good sign in Auditing. feel that from the records
97
Approach
of Internal Audit?
SARACASTIC Auditors are invites at the place of  Is this a Calibration  NEVER EVER
COMMENTS audit – has no right to criticize Records? Being so USE SUCH
educated & experienced, QUESTIONS
you are doing calibration
like this? It‟s surprising
The Methodology of Assessment
The Assessment Process consists of combination of following Samples:

1. Selection of the Process.
2. Verification of Actual processes in comparison with Documented Procedures.
3. Interview Personnel.
Logical way to proceed on with questions.

Let us take the example of the FUNNEL TECHNIQUE and look from different angle.
98
Approach
ACCEPTABLE TYPE OF QUESTIONS
Types of Explanation Examples Caution Points

questions
To get the general opinion  Could you explain in  Open Questions may
of understanding level of brief the system you side track the objectives
the auditee on Quality maintain here? & focus
System, Open Qs. Are  Could you please give  Sometimes the auditee
asked. your views on the may not able to answer
OPEN
Open questions lead to interpretation of the as required.
wide range of answers, results?  May give general
which can be used by  How do you process answers. Which may not
auditor to select his/her these results in be relevant to the
next leading or probing passing or not objective of audit.
questions. passing?
LEADING A leading Question  So you verify the  This type of question
generally suggests an temperatures of Baths might take more time to
answer which is in built in every two hours reach the fact.
the question itself. alternatively, as per
procedure, don‟t you?
 You mentioned, you
A leading question also us Sampling Table for  These types of questions
leads to another this type of should be avoided when
Open/Probing question verification, which one you have very less time
which is more specific in of these five & how to complete the audit.
nature compared to open you use it by giving a
question. demo please?
THE QUESTIONING TECHNIQUES
99
Approach
Important issues should be practiced during this process:-
1. Put the Auditee at Ease

People find Audits to be STRESSFUL SITUATIONS. It is the responsibility of the
auditor to create an atmosphere that auditee does not have FEAR in mind, Relaxes first to
face the same. Generally it is human tendency to be transparent when at ease. For audit
process has to go smooth way, it very much important for the auditor to create rapport
with the auditee, s that he doesn‟t go defensive, which shall be a hindrance in finding the
facts.
2. Speak at the auditee education level and also not underestimate

The Auditee might be More Knowledgeable & Experienced than the auditor or may be
less. In the Internal Audit, every one knows each other; there should not be a problem in
understanding this fact. Find out at what level the auditee is and converse with him/her in
the same level, to know the facts. The Auditor should not underestimate the auditee as
Auditee is the master of his/her process & Auditor is the Master of his/her Job. So the
main important fact in auditing is not to Overestimate or Underestimate the Auditee .but
to have a dialogue in the same frequency of the Auditee –Otherwise the ultimate resultant
may not be matching the objective of this positive audit.
3. ENSURE COMPREHENSION & SOLICIT FEEDBACK

It is very important that Auditee Fully Understands the Questions, if not the auditor is
bound to get unexpected response. One way to avoid this is to solicit the feedback form
the Auditee for important questions.
4. PATIENCE TOWARDS UNRESPONSIVE AUDITEE & EVASIVE ANSWERS

This unresponsiveness / Evasive Answers of the auditee may be deliberate, but most of
the time it is unintentional. The Auditor should show his patience to put the auditee on
the track of audit & ask questions in different ways to do so. It is a tact & art of a Good
Auditor to bring Auditee on the track in smooth & cordial way, avoiding authoritative .
AUDIT PROCESS IS MORE OR LESS A FUNNEL
100
Approach
AUDITING Is BASED ON SAMPLE METHODOLOGY. THE SAMPLES PICKED UP

WOULD BE AT THE DISCRETION OF THE AUDITOR. THESE SAMPLES ARE
NOT THE FUNCTIONAL AREAS, AS ALL FUNCTIONS ARE TO BE AUDITED AS
PER THE PLAN. THESE SAMPLES ARE:
A. THE PEOPLE - INTERVIEWED To UNDERSTAND THE

SYSTEM & JUDGE HOW MUCH THE
PERSONNEL HAVE UNDERSTOOD THE
REQUIREMENTS OF QUALITY W.R. T.
SVSTEM, To IMPLEMENT THE
DOCUMENTED SVSTEM
B. THE PROCESSES - IF THERE ARE SIMILAR PROCESSES, THEN
BASED ON HIS/HER JUDGEMENT /
EXPERIENCE.
C. THE RELA TED DOCUMENTS - ANY DOCUMENT WITHIN THE QUALITY
SYSTEM CAN BE PICKED UP BY AUDITOR
AS A SAMPLE.
101
Approach
THE AUDIT PROCESS CAN CONTAIN ANY ONE SAMPLE OR COMBINATION OF
SAMPLES. WHICH BECOME LATER CALLED AS OBJECTIVE EVIDENCE FOR
RAISING NON-CONFORMANCE AGAINST THE DEFINED SYSTEM.
The difference between Typical Project management & Six Sigma Project
management.
The Project Management Body of Knowledge (PMBOK) became an accepted standard (as
established by the Project Management Institute) that is still widely used in many industries
around the world. At a basic level, many of the methodologies advocated by PMBOK and Six
Sigma have a great deal in common. Both seek to establish a sound plan; identify and
communicate with stakeholders; conduct regular reviews; and manage schedule, cost, and
resources.
Six Sigma is not just another project management initiative or process improvement programme.
Six Sigma is not just a new term for project management nor is it a mere repackaging of old
concepts. It is more than that because it is a robust continuous improvement strategy and process
that includes cultural and statistical methodologies. Six Sigma is complementary with existing
project management programmes and standards but differs in significant ways. Both disciplines
seek to reduce failures, prevent defects, control costs and schedules, and manage risk. Generally,
professional project management attempts to achieve these goals by encouraging best practices on
a project-by-project basis, often through the mechanism of a project office that promulgates
policy, provides templates and advice, promotes appropriate use of tools such as critical path
method, and perhaps performs periodic project reviews.
Too many project management methods have failed not because they weren't adding value but
because one could not measure the effectiveness of the methodology or quantify the value added
102
Approach
by process changes. Six Sigma provides a structured data-driven methodology with tools and
techniques that companies can use to measure their performance both before and after Six Sigma
projects. Using Six Sigma, management can measure the baseline performance of their processes
and determine the root causes of variations so they can improve their processes to meet and
exceed the desired performance levels.
Six Sigma allows managers to take their projects to new levels of discipline and comprehensive
commitment. For standard project management ideas, you can approach them ad hoc and
implement them as you learn them. One can't do Six Sigma halfheartedly, and that is a good
thing. Six Sigma is not for dabblers. One can't implement it piecemeal. If you're in, you're in
deep, and you're in for the long haul. Again, that is a good thing because that level of
commitment not only gets everyone involved and keeps them involved but also leads to more
substantial and far-reaching change in your processes.
There are many challenges facing project managers: data gathering and analysis, problem solving,
understanding and evaluating existing processes, developing and tracking measurements in a
standardized manner, and making quantitative evaluations. Six Sigma methodologies provides
tools and techniques to help a manager be successful in all of these challenges. This success is
accomplished by means of understanding what the methodology is, how it is applied, and how it
used.
Six Sigma is not simply another supplement to an organization‟s existing management methods.
It is a complementary management methodology that is integrated into and replaces the existing
ways of determining, analyzing, and resolving/avoiding problems, as well as achieving business
and customer requirements objectively and methodically. Six Sigma can be applied to operational
management issues, or it can directly support strategic management development and
implementation. Six Sigma's set of tools are more broadly applicable than those commonly
applied within typical project management. Six Sigma is more oriented toward solutions of
problems at their root cause and prevention of their recurrence rather than attempting to control
potential causes of failure on a project-by-project basis.
The breadth, depth, and precision of Six Sigma also differentiate it from typical project
management. Six Sigma has a well-defined project charter that outlines the scope of a project,
financial targets, anticipated benefits, milestones, etc. It's based on hard financial data and
savings. In typical project management, organizations go into a project without fully knowing
what the financial gains might be. Six Sigma has a solid control phase (DMAIC: Define-
103
Approach
Measure-Analyze-Improve-Control) that makes specific measurements, identifies specific
problems, and provides specific solutions that can be measured.
Six Sigma is a robust continuous improvement strategy and process that includes cultural
methodologies such as Total Quality Management (TQM), process control strategies such as
Statistical Process Control (SPC), and other important statistical tools. When done correctly, Six
Sigma becomes a way toward organization and cultural development, but it is more than a set of
tools. Six Sigma is the strategic and systematic application of the tools on targeted important
projects at the appropriate time to bring about significant and lasting change in an organization as
a whole.
Why Is Six Sigma So Effective?

The scientific tools and techniques no doubt contribute a lot towards the success of Six Sigma
improvement projects, but they just cannot be taken as the sole factors responsible for Six
Sigma's effectiveness because they only compliment the inherent logic underlining Six Sigma and
as such are no more than a means to an end.
So what really makes Six Sigma so effective? Well, for that, you only have to take a closer look
at the most commonly utilized Six Sigma quality improvement methodology, i.e. DMAIC that
stands for Define, Measure, Analyze, Improve and Control.
Look out for similarities between standard business practices and the DMAIC phases stated
above, some of which are described below:
The Define Phase

The Define phase is quite similar to the standard business practice of identifying common
problems of a given business process with the aim to devise effective solutions for overcoming
the given problems and issues. It can easily be compared with an entrepreneur's effort to improve
the delivery systems of his business by conducting a review of all the various major and minor
components of the overall delivery system.
The Measure Phase

If we consider the above example, the Measure phase will seem no different from the
entrepreneur's effort to assess the negative impact that the identified problems can potentially
have on his overall business. This is quite necessary for the entrepreneur, because it is only then
will he be able to concentrate his efforts on overcoming problems that hold the most potential for
damage.
104
Approach
The Analyze Phase

The Analyze phase is quite similar to the entrepreneur's effort to make a list of all the available
alternatives and test each of them individually to know which alternative will work best for
getting the desired results.
Just like the entrepreneur would prefer, the Analyze phase too calls for selecting only those
alternatives for final implementation, which hold the most potential and are cost-effective.
The Improve Phase

This phase is no different from the entrepreneur's effort to ensure that the projects selected for
improvement are implemented in the prescribed manner. Just like the entrepreneur would prefer,
the Improve phase too stresses completing projects within the stipulated time and costs.
The Control Phase

Just as the entrepreneur would like to check the effectiveness of the improvement projects, the
Control phase too stresses assessing whether or not the improvement initiatives are performing as
per expectations. Taking remedial measures if there is a mismatch is inherent to the Control
phase, just as an entrepreneur would like to do.
Now, I think one can understand exactly why Six Sigma is so very effective. It's simply because it
follows sound business logic that hardly ever fails to deliver.
How to Initiate a Six Sigma Project
Although one cannot have a project-specific vision right from the very beginning of a Six Sigma
initiative, you can develop a comprehensive viewpoint. An all-encompassing viewpoint definitely
helps to reach out beyond the scope of the project.
Selecting the Right Project

Six Sigma projects need to be selected with care. Select a project only after you have weighed its
pros and cons properly. However, this does not mean that you should not attempt to solve the
most pressing problems first, just make sure that you have weighed the constraints properly.
105
Approach
If you want to begin your Six Sigma initiative successfully, then follow the tips given below for
project selection.
The first thing to remember is that not all projects will help to save the same amount of money.
This will help you to realise that you should not only look at the monetary aspect of a project; the
other important features are eliminating draconian procedures, improving employee contentment
and the promise of producing a good result that induces further improvement in other projects.
Think carefully while deciding about the placement of Six Sigma "belts" and other members of
the Six Sigma team. This is the team that will ensure that the organization stays on the path of
success. You should carefully analyse the cost benefits of recruiting black belts from outside as
opposed to grooming belts in-house. Whatever the decision, make sure that you earn cost-benefits
in the long term and also keep in mind affordability.
For more effective implementation of a Six Sigma project, sub-divide the project deployment in
two or three phases. The phases can be strategic, tactical and operational, which will
methodologically use and follow statistical tools for taking the imperatives beyond the employee
level.
Scrutinize the Deployment Strategy

Now that you have identified the project, contemplate the project deployment strategy in the
background of both the top and bottom line developments. Once you are done with this, don't
start right away with the implementation - instead try to contrast the projected outcome against
the set management goals. You should maintain a checklist that will help you to question the
strategic steps involved in all phases.
Unless you execute a draft strategy, you will never know what the real strategy will look like.
Another formidable tool that involves a collective opinion for the foundation of the project is
brainstorming. This is done so that at no point in time can the black belts and the project leaders
afford to forget the huge sum of money that has been poured into the project.
Factoring and Monitoring Midway Course Correction

Sometimes a project deviates from its track. If the deviation remains undetected, then it can pose
a threat to the entire project. In this case, the internal and external Six Sigma auditing team should
conduct regular midway auditing and monitoring, to shed light on the problem and its possible
causes. Regular detection is essential to keep deployment efforts from straying in undesirable
directions.
106
Approach
Other Initiatives
 The organization should establish a route of communication for the "belts"
 The organization should establish a core group to execute the findings of the deployment
team
 The training of Six Sigma team members should be consistent
 The organization should keep an eye on the execution of the survey of internal customers.
Optimizing Six Sigma Project Selections

To bring about a successful process, the project should be disciplined and defined. Below are
three steps that are incorporated for a profitable process:
Establishing the Project Selection Steering Committee

Every Project Selection Steering Committee should be made up of managers who have undergone
training as Six Sigma Champions, or any other key Six Sigma knowledge resources, like the
Black Belts, Master Black Belts or deployment Champions, who can apply their knowledge in
establishing the manageability and achievability of projects under consideration .
Generating Project Ideas

Every company has its own share of opportunities, problems, issues and frustrations, which are
by far the vital sources of prospective projects. Each idea needs to be evaluated in the course of a
project selection workshop. Approximately two weeks prior to the workshop, each project
Champion should put together a list of project opportunities in their area, taking into account that
the Six Sigma project should support the organizational strategies and be integrated to the basic
business issues.
Employing predefined guidelines, every opportunity also has supporting project rationale data as
well as historical volumes, financial impact and defect type. Project Champions and their team
members together identify the process improvements that could be positive to the customers,
employees and the business.
Six sigma tries to find and delete any defects or errors during the manufacturing and business
process.Its goal is to create a level of manufacturing so that a high number of output will meet
107
Approach
the minimum specification .Now it has grown and quality demands and strives to keep the
defect level at 3.4 defects per million opportunities (DPMO) or below .The goal should be to
keep it lower.
To generate feasible project ideas, project leaders must ask the following questions:
1. Reduction of Defects
 Are there any occurrences of high volumes of rework and/or defects?
 Have there been any failures besides the preferred specifications?
 Does the given process possess a high degree of variation ?
 Would any scientific adjustments to the process result in forceful changes?
 Does the process have any residual scrap?
 Which inputs need to be managed for producing an unfailing output ?
2. Reduction of Cycle Time
 Is the resultant production of the process below the one expected?
 Do any of the processes depend on multiple hand-offs between the individuals?
 Is the process being delayed because of machine/computer downtime?
 Does the process require a lot of overtime ?
3. Reduction of Resource Consumption
 Does the process need more workers for doing the job?
 Does the process undergo a high variation in the consumption of material?
After identification, project information is reviewed in a standardised quad chart format that is
presented to the steering committee.
108
Approach
Assessing and Prioritizing Projects with a Project Selection Matrix
In the course of the formal project selection, every identified project is evaluated together for
determining integration opportunities and gauging projected profits. Current ongoing projects are
also included in this evaluation; thereafter all the projects are ranked for verifying the main
concerns employing the project selection matrix.
A key question that ought to be answered during the workshop is whether or not the project is an
applicant for the DMAIC methodology. Value stream mapping design, or Lean for Six Sigma can
prove to be a more appropriate methodology for a number of projects. Towards the end of the
process, Black Belt resources are allocated projects on the basis of the prioritisation list.
The process of project selection gives a clear-cut way of gathering suitable data from every area
of the business, classifying on the basis of improvement categories and finally applying the
rating for prioritisation. Every project selection process aims to establish a clear path for
executing process improvements that are beneficial to the business as one.
Why People Capability Maturity Management CMM.
The IDEAL model is an organizational improvement model that serves as a roadmap for
Initiating, Planning and guiding improvements .This model is life cycle for organizing the phases
the phases of an improvement programs .The IDEAL model defines systematic ,five phases
,continuous process improvement approach with concurrent sixth element addressing the project
management tasks in five phases .
1. Initiating – establish support and responsibilities for improvement
2. Diagnosing –identify the problems to be solved
3. Establishing –select and plan specific improvement activities.
4. Acting –design ,pilot, implement and institutionalize improvements
5. Learning –identifying improvements in IDEAL-based activities.
109
Approach
The Carnegie Mellon University Software Engineering Institute developed the P-CMM model to
help businesses manage knowledge workers across global borders, as well as between graying
and millennium generations, Similar to CMMI, P-CMM has five maturity levels, but the model is
focused on the need to improve the capabilities f a workforce as differentiating factor from the
competition.
In a highly competitive global business recruiting talents with technical skills is not enough
anymore, on top of the their technical competencies, workers must have necessary business skills,
particularly making decisions, but also consistent with the visions of their organization. Moreover
as organization‟s internal processes mature so should workers decision-making and
implementation proficiency. Infact P-CMM was developed to develop workers competencies
according to the needs of process maturity levels.
Many organization practices have matured over time particularly in the area of software
engineering .However practitioner observed that workers must appreciate their roles and
responsibilities in their larger organization .This where P-CMM comes in.Human resource and
work force managers on their strength of their technical skills alone :But inorder to harness
technical knowledge of workers into tangible products (for e.g. : A piece of software ),managers
have realized that the staff within must be compatible with the internal process improvements .
110
Approach
In a nutshell, it means helping workers help top managers steer project processes according to
current capability levels and project directions, as well as providing framework for optimizing
employee competencies for greater measurable value .For human resources and worker
development practioners, P-CMM serves as the framework for developing employees from mere
knowledge workers and knowledge managers.
To do so one needs to revisit the P-CMM level 5 architecture. Organizations that have reached
certain level of maturity assign people to immediate managers. There is still a certain degree of
randomness at this level, but the role that employees play in a smaller organization (for example,
for e.g. a project team or a department) is being reviewed and measured according to agreed-upon
standards the managers expect from their subordinates .The focus is mostly on the performance of
workers, not on the long term competency development.
Things change for the better as participation is encouraged among workers .Career path and
competency development gain more attention from the top management. while collaborative
activities are encouraged among the staff members. Planning and analysis
are introduced in the people management process.
As people gain competencies through training and mentoring, it is expected that they empowered
to eventually make professional and organizational decisions. The work force as a whole should
develop integrated and complimentary competencies and be able to manage their skills sets at
organizational level .They must be able to make or suggest suggest based on what they know and
the processes established in the organization.
Structure of the People CMM
111
Next Generation ProjectOrganizational
management systems –A Quality
Capability
Approach
Results in
Maturity Levels
are contained in
Process Areas
Model describe objectives

Components
Process Area Goals
achieve
Practices
Address address
Implementation Institutionalization
Conclusion and recommendations

When organizations have developed integrated capability sets among workers, it is then they can
continue to innovate products, services and processes .Innovation is nearly impossible when
people who should be championing new directions in their business domains have no clear course
on how they can get from basic service delivery level to top class product development
112
Approach
.Moreover, poaching by competing firms & high turn over can be prevented if employees value
of their place and their contribution to the organization .
17 Must Ask questions –For Planning Successful Projects

Why do some projects proceed smoothly and some have problems ? .Below mentioned 17
insightful queries that can expose the uncertain aspects of the project there by avoid expensive
surprises later on .
1. How do you describe your project ?

Explain as expressively the ultimate “big picture” vision and the purpose of your completed
endeavor. How will it look feel ,taste,sound,perform,increase productivity ,help your
customers or otherwise benefit human kind ?
2. What are your goals and objectives?

What are you trying to accomplish ?List the project goals and objectives that are
clear , concise and achievable and measurable.
3. Who will benefit from your project ?

Example of audiences or beneficiaries include : clients, customers ,Local communities
,wildlife, or any specific target market ,students and specific population Segments
4. Will you be creating any products ?

Books,Publications,studies,reports ,manuals, video, audio ,multimedia
productions,tools,instructional materials ,graphics, software and information
systems,websites,data base widgets and special equipment.
5. Will be providing any kind of services?

E.g. Providing building services, telephone Lines , business software training ,day care
,statistical analysis, copy editing ,customer satisfaction surveying .
6. What methods will you use ? :

1. For example: will you start researching on your customers/audiences/end-user needs ?
Will you use phases of design ,development ,implementation ,pilot testing and rollout ?
113
Approach
7. What kind of Schedule do you anticipate ?
2. Will you project or programme involve an incremental implementation process that
might occur over several months or years ?If so what long term phases are you
anticipating? Are there critical milestones with these phases ? Can you create a detailed
schedule for near term tasks you will be performing?
8. Will you need any partners or collaborators ?

Many types of projects will benefit from teaming up with partners who can offer
complimentary strengths or a long term track record in an important area. Do you
anticipate joining forces with other organizations ,consultants or agencies to complete the
projects ? If so what experience ,expertise ,credibility ,funding or other benefits will each
participating party bring to the table ?.
9. Will you need specific Information or Advice? :

Do you plan to seek information and help from subject matter experts or other advisors? Will you
need to perform research, and if so, what sources will you tap? Examples include Internet
resources, company documentation, service reports, trouble logs , customer feedback, surveys,
focus group data, evaluation forms, census data, libraries, and formal studies.
10. Will You Need Special Systems or Equipment?

Some projects require setting up a technology infrastructure to create or deliver the products or
services. Examples of items in your infrastructure might include: Servers, networks, computers
and peripheral devices, and multimedia, sound , or video systems.
11. Will You Need to Use Special Tools or Templates?

Some projects require using a certain set of software tools or a specific set of templates or
techniques. It's important to specify these at the beginning so that everyone will be clear about
what's required.
12. How Will You Evaluate Project Success?

How will you measure the progress and effectiveness of your project? Will you collect
information on how you are carrying out your stated objectives (process evaluations), and how
well you are serving the needs of your target audiences (outcome evaluations)?
13. Who Needs to Review and Approve Decisions?
114
Approach
Will there be a clear process for submitting items for review and approval, and a set timeframe
for receiving comments back? What protocol will be used? A key consideration is whether there
will be a single responsible party with the authority to reconcile differing opinions if a review
team can't reach a consensus.
14. How Might Your Project Evolve over Time?

Why should what happens in the future be so important today? One reason is that implementing
downstream opportunities can be hindered or helped by decisions that occur at the start. It's not
unusual for a short-lived, "one-time only" effort to take on a life of its own by adding unexpected
phases, variations, and versions - so why not plan ahead?
15. Who Will Be Responsible for What?

This aspect is especially important when multiple parties will contribute to the outcome, and even
more so when they are dependent on one another. For example, your detailed schedule for Task X
might specify that "Completing Task X depends on Person Y in Company C providing the ABC
Results by such-and-such a date."
16. What Risks Should You Plan to Manage?

Nothing is more difficult that anticipating, flagging, and managing potential risks to a project as a
whole, or to the successful completion of your part of it. After all, no one wants to admit potential
failure, right? However, risk is a normal part of everyday life, and with proper attention, we can
manage it!
17. What Open Issues Remain?

What issues and concerns remain after all topics above have been considered? You and your team
may be keeping a running list of unanswered questions and unknowns. What are these items, and
how and when do you think they will be resolved? Do they present risks until they are answered ?
By thinking through the questions above, you can achieve your project goals with much less
guesswork and far fewer problems than you may have experienced in the past.
115
Approach
It probably won't surprise anyone who refers to a Gantt chart on a regular basis, but
projects are business. “Not many people realize that about 20 percent of the world's GDP
is project driven, and in fact if you look at the US alone, about 12 trillion dollars is spent
annually on projects,” says Oracle's Guy Barlow, industry strategist for the project-
intensive oil, gas and utilities sectors. “So being able to help companies successfully
execute their projects and portfolios within this framework of risk is something that's
imperative, especially given the economic downturn.”
Recent Quote in the News Paper “Business Standard “.
Appendices (appendix 1 ,appendix2 , appendix 3 )

Implementing Project Quality management:
Quality management and Project Management have similar characteristics:
 Customer Satisfaction
116
Approach
The project must satisfy the customer requirements by delivering what it promised in order to
satisfy the needs of the customer .The Project team has to identify the customers and
understand their stated and implied needs .Transform their needs into workable solutions
.Design, develop and deliver product/service/Solutions that fulfill their needs .The PMBOK
states it as “conformance to requirements “and “fitness to use “.
 Prevention
Quality is planned into a project, not inspected in .It is always more cost effective to prevent
mistakes than to correct them.
 Management Responsibility :
The project team must work towards the quality goal, but management must provide the
needed resources to deliver on the quality promises. The top management must be committed
in creating and deploying well defined process, systems, methods and resources for achieving
those goals.
Plan-Do-check-Act.
Dr W.Edwards Deming, arguably the world‟s leader in the quality management theory was
the first to set the bar with his “plan do check act “approach to quality management .This is
proven process method which can be applied to project management process.
Plan: Establish a well defined process and methods with clear objectives to deliver
products/service as per agreed specifications.
Do: Deploy the planned process and methods across the organization/Project.
Check: Measure and evaluate the effectiveness of the process, take appropriate actions which
are required for Improvement?
Act: Based on the effectiveness of the process, take appropriate actions which are required for
117
Approach
CHECK
DO
ACT
PLAN
Repeating the above cycle again and again will result in continuous improvement of the
process and will take us closer to perfect process and product closer to the specification .
APPENDIX 2
Philosophy of Management .
118
Approach
Cost Curve
Appendix 3
Table 2.7. Life Cycle Phase Definitions.
119
Approach
ENGINEERING MANUFACTURING COMPUTER
CONSTRUCTION
PROGRAMMING
 Startup  Formation  Conceptual  Planning, data gathering and
 Definition  Buildup  Planning procedures
 Main  Production  Definition and  Studies and basic engineering
 Termination design  Major review
 Phase-out  Implementation  Detail engineering/
 Final audit  Conversion construction overlap
 Construction
 Testing and commissioning
 Pricing and estimating may be easier if well-structured work definitions exist.

 There exist key decision points at the end of each life cycle phase so that incremental
funding is possible.
As a final note, the reader should be aware that not all projects can be simply transposed into
life-cycle phases (e.g., R&D). in such a case it might be possible (even in the same company) for
different life-cycle-phase definitions to exist because of schedule length, complexity, or just the
difficulty of managing them.
SYSTEMS THINKING
Ultimately, all decisions and policies are made on the basis of judgment; there is not any other
way, and there never will be. In the end, analysis is just an aid to the judgment and intuition of
the decision-maker.
The systems approach may be defined as a logical and disciplined process of problem solving.
The word process indicates an active ongoing system that is fed by input from its parts.
Systems approach definitions should be considered. The systems approach:
 Forces review of the interrelationship of the various subsystems.

 Is a dynamic process that integrates all activities into a meaningful total system.
 Systematically assembles and matches the parts of the system into a unified whole.
 Seeks an optimal solution or strategy in solving a problem.
The systems approach to problem solving has phase of development similar to the life-cycle
phases shown in figure 2-7. these phase are defined as follows:
 Translations: Terminology, problem objective, and criteria and constraints are defined
and accepted by all participants.
120
Approach
 Analysis: All possible approaches to or alternatives to the solution of the problem are
stated.
 Trade-off: Selection criteria and constraints are applied to the alternatives to meet the
objective.
 Synthesis: The best solution in reaching the objective of the system is the result of the
combination of analysis and trade-off phases.
Other terms essential to the systems approach are as follows:

 Objective: The function of the system or the strategy that must be achieved.
 Requirement: A partial need to satisfy the objective.
 Alternative: One of the selected ways to implement and satisfy a requirement.
 Selection Criteria: Performance factors used in evaluating the alternatives to select a
preferable alternative.
 Constraint: An a absolute factor-which describes conditions that the alternatives must
meet.
A common error by potential decision-makers (those dissatisfied individuals with authority to

act) who base their thinking solely on subjective experience, judgment, and intuition is that they
fail to recognize the existence of alternatives. Subjective thinking is inhabited or affected by
personal bias resulting from conditions within the brain and sense organs.
Objective thinking, on the other hand, is a fundamental characteristic of the systems approach
and is exhibited or characterized by emphasis upon the tendency to view events, phenomena, and
ideas as external and apart from self consciousness. Objective thinking is unprejudiced and exists
independent of the mind.
The systems analysis process, as shown in the above figure , begins with systematic examination
and comparison of those alternative actions that are related to the accomplishment of the desired
objective. The alternatives are then compared on the basis of the resource cost and the associated
benefits. The inputs from the constraints and limitations identify the explicit consideration of the
uncertainty variables. The loop is then completed using feedback in order to determine how
compatible each alternative is with the objectives of the organization.
The above analysis can be arranged in steps:
121
Approach
 Input data to mental process.
 Analyze data.
 Predict outcomes.
 Evaluate outcomes and compare alternatives.
 Choose the best alternative.
 The action.
 Measure results and compare them with predictions.
The systems approach to thinking is most effective if individuals can be trained to be ready with
alternative actions that directly tie in with the prediction of outcomes. The basic tool is the
outcome array, which represents the matrix of all possible circumstances. This outcome array
can be developed only if the decision-maker thinks in terms of the wide scope of possible
outcomes. Outcome descriptions force the decision-maker to spell out clearly just what he is
trying to achieve (i.e., his objectives).
Systems thinking is vital for the success of a project. Project management systems urgently need
new ways of strategically viewing, questioning, and analyzing project needs for alternative non
technical as well as technical solutions. The ability to analyze the total project, rather than the
individual parts, is the first prerequisite for successful project management.
Typical project Life cycle phases
References (Bibliography)
1. PROJECT MANAGEMENT, Dr Harold Kerzner, PhD.
122
Approach
2. ISO 9000:2000: Quality Management systems – Fundamentals &
vocabulary
3. ISO 9001:2000: Quality Management systems – Requirements
4. ISO 9004:2000: Quality Management systems – guidance for performance
in improvement
5. ISO 19011:2002: Guidelines for quality &/or environmental management
systems auditing.
6. ISO 10005:1995: Quality management-guidelines for quality plans.
7. ISO 10006:2003: Quality management systems – guidelines for quality
management in projects.
8. ISO 10007:2003: Quality management systems-guidelines for configuration
management.
9. ISO 10012:2003: Measurement management systems-Requirements for
measurement processes and measuring equipment.
10. ISO 10013:2001: Guidelines for quality management system
documentation.
11. ISO/TR10014:1998: Guidelines for managing the economies of quality.
12. ISO10015:1999: Quality management – Guidelines for training.
13. ISO 9001:2008
14. PMBOK, Project Management Institute, Austin TX
15. Guide to ISO 9001:2000, Implementation, Improvement tools and
techniques.
16. Transition to TQM & Six Sigma., Sally
17. Authors: A.K Chakraborty, P.K Basu, S.C Chakravarthy.
18. Implementing ISO 9001:2000 Quality Management Systems by Divya
Singhal & K.R Singhal.
19. The Six Sigma Leader, Peter S .Pande.
20. The People Capability maturity Model,
Guidelines for improving the working workforce,
123
Approach
By Bill Curtis, William E Hefley & Sally A Miller
21. Metrics and Models in Software Engineering
By Stephen H Kan.
22. Project and Quality Management ,(ICBMS text book)
23. The Daily Drucker, 365 days of Insight, Motivation, for getting the right
things done.
24. Competing for the future , Hamel & Prahalad
25. Project Smart (UK) .Adele Sommers ,PhD
26. Project Management Manual ,Primavera Images
27. First things First , By Stephen Covey .
124

Next Generation Project Management Systems - A Quality Approach .

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Next Generation Project Management Systems - A Quality Approach .

Încărcat de

Drepturi de autor:

Formate disponibile

Next Generation Project management systems –A Quality

Aims and objectives:

Need for study

Understanding Project Management:

The potential benefits from Project Management are:

 Project management is planning ,organizing ,directing and controlling of company

What we want to have in our project plan is:

 Specific: Clearly defined and precise.

 Attainable: Don't ask for the impossible.

 Relevant: Is the criterion actually related to the aim of the project?

The Purpose of WBS:

 The project Scope statement.

 The project Scope management.

 Organizational process assets

 Approve change requests (PMBOK guide)

 Work break down templates.

Using tools you will create the following outputs

 Work breakdown Structure.

 Project Scope Statement (Updates on Primavera tool )

 Project Scope management Plan (updates)

 Requested changes-PMBOK (guide)

Pitfalls: Five commonly occurring Pitfalls

1. Level of Work Package Detail

2. Deliverables Not Activities or Tasks

3. WBS is not a Plan or Schedule

4. WBS Updates Require Change Control

5. WBS is not an Organisational Hierarchy

Using the Charts

Building SMART goals.

S - Specific, significant, stretching

M - Measurable, meaningful, motivational

A - agreed upon, attainable, achievable, acceptable, action-oriented

R - realistic, relevant, reasonable, rewarding, results-oriented

Clear to anyone that has a basic knowledge of the project

Know if the goal is obtainable and how far away completion is

Know when it has been achieved

 Agreement with all the stakeholders what the goals should be

Within the availability of resources, knowledge and time

Enough time to achieve the goal

Not too much time, which can affect project performance

A Project Management Primer – Basic principles- Scope triangle

Core requirements remain, everything will be fine.

In this situation you have, three questions

 Cut Quality – to trade off some non essentials requirements

The Context of Project Failure

There are a number of increasingly popular project management methodologies aimed at

PRINCE2 (Projects In Controlled Environments)

 The degree of user involvement

 Executive management support

 An experienced project manager

First Things First

A broad aim is fine to start with:

We want to reduce the number of outages affecting our systems

We want to take a higher proportion of payments online

We want to increase customer satisfaction

An insufficient level of accountability and responsibility at an appropriately senior level for

 Who was responsible for the success of the project?

 Were there any consequences for the failure of the project?

The Road Map

Define the Scope and Objectives

9. Firstly, understand the project objectives. To make a company profile? Or to make a

Define the Deliverables