qwertyuiopasdfghjklzxcvbnmqw

ertyuiopasdfghjklzxcvbnmqwert
yuiopasdfghjklzxcvbnmqwertyui
opasdfghjklzxcvbnmqwertyuiopa
sdfghjklzxcvbnmqwertyuiopasdf
ghjklzxcvbnmqwertyuiopasdfghj
klzxcvbnmqwertyuiopasdfghjklz
PROJECT
MANAGEMENT
xcvbnmqwertyuiopasdfghjklzxcv
MBA,SMU,SEM.-
2,ASSIGNMENT-01

bnmqwertyuiopasdfghjklzxcvbn
5/20/2010

Robin Smith
mqwertyuiopasdfghjklzxcvbnmq
wertyuiopasdfghjklzxcvbnmqwer
tyuiopasdfghjklzxcvbnmqwertyu
iopasdfghjklzxcvbnmqwertyuiop
asdfghjklzxcvbnmqwertyuiopasd
fghjklzxcvbnmqwertyuiopasdfgh
jklzxcvbnmqwertyuiopasdfghjklz
xcvbnmrtyuiopasdfghjklzxcvbn
mqwertyuiopasdfghjklzxcvbnmq
 1. Define project management, resource, process and project cycle. Explain the life-cycle of
a project. What are the roles and responsibilities of a project manager?
Ans-
Project management:- It is the discipline of planning, organizing, and managing resources to
bring about the successful completion of specific project goals and objectives. It is sometimes
conflated with program management, however technically a program is actually a higher level
construct: a group of related and somehow interdependent projects.
A project is a temporary endeavor, having a defined beginning and end (usually constrained by
date, but can be by funding or deliverables, undertaken to meet unique goals and objectives, usually to
bring about beneficial change or added value. The temporary nature of projects stands in contrast
to business as usual (or operations) , which are repetitive, permanent or semi-permanent functional
work to produce products or services. In practice, the management of these two systems is often found
to be quite different, and as such requires the development of distinct technical skills and the adoption
of separate management.

Resources- In project management terminology, resources are required to carry out the project tasks.
They can be people, equipment, facilities, funding, or anything else capable of definition (usually
other than labour) required for the completion of a project activity. The lack of a resource will
therefore be a constraint on the completion of the project activity. Resources may be storable or non
storable. Storable resources remain available unless depleted by usage, and may be replenished by
project tasks which produce them. Non-storable resources must be renewed for each time period, even
if not utilised in previous time periods.

Resource scheduling, availability and optimisation are considered key to successful project
management.

Allocation of limited resources is based on the priority given to each of the project activities. Their
priority is calculated using the Critical path method and heuristic analysis. For a case with a constraint
on the number of resources, the objective is to create the most efficient schedule possible -
minimising project duration and maximising the use of the resources available.

Process- A process is a set of interrelated actions & activities performed to achieve a pre-specified
product, result, or service.
* Each process is characterized by its inputs, the tools & techniques that can be applied, and the
resulting outputs.

Inputs are the prerequisites or entry criteria to start a process. Output are the exit criteria or the result
of the process with which the process ends. Tools & techniques are methods applied on the entry
criteria to achieve required results. The output of one process generally becomes an input to another
process
or is a deliverable of the project. Defining boundaries of each process ensures better control over the
entire project and project objectives.

Project management processes are grouped into 5 different categories called as Process Groups. They
are : Initiating, Planning, Executing, Monitoring & controlling and Closing. These process groups
provide guidance in applying appropriate project management knowledge and skills during the
project.

Initiating Process Group – Those processes performed to define a new project or a new phase of an
existing project by obtaining authorization to start the project. Here is the Input, Tools & Techniques,
Output(ITTO) in the form of Mind Map for Initiating Process Group Processes.
• Planning Process Group – Those processes required to establish the scope of the project, refine the
objectives, and define the course of action required to attain the objectives that the project was
undertaken to achieve.

• Executing Process Group – Those processes performed to complete the work defined in the project
management plan to satisfy the project specifications.

• Monitoring and Controlling Process Group – Those processes required to track, review, and
regulate the progress and performance of the project; identify any areas in which changes to the plan
are required; and initiate the corresponding changes.

• Closing Process Group – Those processes performed to finalize all activities across all Project
Management Process Groups to formally close the project.

Each one of these process groups have well-defined interactions between them. Also, these process
groups closely resembles Deming’s PDCA (Plan-Do-Check-Act).
In case of big projects, each of these process group processes can be repeated for each phase instead
of defining process groups for the whole project. This extra effort gives more control over the project.

* PLAN: coming up with new or changed process components to improve results. Directly relates to
planning process group in Project Management. Either new plans are created during start of the
project or plans modified & re-baselined based on inputs from other project processes.
* DO: Implementing the plan and measure its performance. Directly relates to execution process
group.
* CHECK: Assessing the measurements and report the results to decision makers. Directly relates to
monitoring and controlling process groups.
* ACT: Deciding on changes needed to improve the process. This is the change requests and process
changes outputs of monitoring & controlling processes. Project manager & management team review
all the change requests/required plan & process changes and approves them.

Project Cycle- The Project Life Cycle refers to a logical sequence of activities to accomplish the
project’s goals or objectives. Regardless of scope or complexity, any project goes through a series of
stages during its life. There is first an Initiation or Birth phase, in which the outputs and critical
success factors are defined, followed by a Planning phase, characterized by breaking down the project
into smaller parts/tasks, an Execution phase, in which the project plan is executed, and lastly a
Closure or Exit phase, that marks the completion of the project. Project activities must be grouped
into phases because by doing so, the project manager and the core team can efficiently plan and
organize resources for each activity, and also objectively measure achievement of goals and justify
their decisions to move ahead, correct, or terminate. It is of great importance to organize project
phases into industry-specific project cycles. Why? Not only because each industry sector involves
specific requirements, tasks, and procedures when it comes to projects, but also because different
industry sectors have different needs for life cycle management methodology. And paying close
attention to such details is the difference between doing things well and excelling as project managers.

Diverse project management tools and methodologies prevail in the different project cycle phases.
Let’s take a closer look at what’s important in each one of these stages:

1) Initiation
In this first stage, the scope of the project is defined along with the approach to be taken to deliver the
desired outputs. The project manager is appointed and in turn, he selects the team members based on
their skills and experience. The most common tools or methodologies used in the initiation stage are
Project Charter, Business Plan, Project Framework (or Overview), Business Case Justification, and
Milestones Reviews.

2) Planning
The second phase should include a detailed identification and assignment of each task until the end of
the project. It should also include a risk analysis and a definition of a criteria for the successful
completion of each deliverable. The governance process is defined, stake holders identified and
reporting frequency and channels agreed. The most common tools or methodologies used in the
planning stage are Business Plan and Milestones Reviews.

3) Execution and controlling

The most important issue in this phase is to ensure project activities are properly executed and
controlled. During the execution phase, the planned solution is implemented to solve the problem
specified in the project's requirements. In product and system development, a design resulting in a
specific set of product requirements is created. This convergence is measured by prototypes, testing,
and reviews. As the execution phase progresses, groups across the organization become more deeply
involved in planning for the final testing, production, and support. The most common tools or
methodologies used in the execution phase are an update of Risk Analysis and Score Cards, in
addition to Business Plan and Milestones Reviews.

4) Closure
In this last stage, the project manager must ensure that the project is brought to its proper completion.
The closure phase is characterized by a written formal project review report containing the following
components: a formal acceptance of the final product by the client, Weighted Critical Measurements
(matching the initial requirements specified by the client with the final delivered product), rewarding
the team, a list of lessons learned, releasing project resources, and a formal project closure notification
to higher management. No special tool or methodology is needed during the closure phase.
Project Management Life Cycle

Project Management Life Cycle comprises four

phases...

Initiation involves starting up the project, by

documenting a business case, feasibility study, terms
of reference, appointing the team and setting up a
Project Office.

Planning involves setting out the roadmap for the

project by creating the following plans: project plan,
resource plan, financial plan, quality plan, acceptance plan and communications plan.

Execution involves building the deliverables and controlling the project delivery, scope, costs,
quality, risks and issues.

Closure involves winding-down the project by releasing staff, handing over deliverables to the
customer and completing a post implementation review.

A more detailed description of the MPMM Project Management Methodology and Life Cycle
follows:

Project Initiation

Project Initiation is the first phase in the Project Life Cycle and essentially involves starting up the
project. You initiate a project by defining its purpose and scope, the justification for initiating it and
the solution to be implemented. You will also need to recruit a suitably skilled project team, set up a
Project Office and perform an end of Phase Review. The Project Initiation phase involves the
following six key steps:
Project Planning

After defining the project and appointing the project

team, you're ready to enter the detailed Project
Planning phase. This involves creating a suite of
planning documents to help guide the team
throughout the project delivery. The Planning Phase
involves completing the following 10 key steps:

Project Execution

With a clear definition of the project and a suite of detailed project plans, you are now ready to enter
the Execution phase of the project.

This is the phase in which the deliverables are physically built and presented to the customer for
acceptance.

While each deliverable is being constructed, a suite of management processes are undertaken to
monitor and control the deliverables being output by the project.

These processes include managing time, cost, quality, change, risks, issues, suppliers, customers and
communication.
Once all the deliverables have been produced and the customer has accepted the final solution, the
project is ready for closure.

Project Closure

Project Closure involves releasing the final deliverables to the

customer, handing over project documentation to the business,
terminating supplier contracts, releasing project resources and
communicating project closure to all stakeholders. The last remaining step is to undertake a Post
Implementation Review to identify the level of project success and note any lessons learned for future
projects.

The Role of a Project Manager

A new employee in the company mailroom noticed an older man sitting in the corner, sorting mail,
weighing packages, adding postage and doing other simple jobs. He asked his supervisor who the man
was.

That's Joe." the supervisor said. "He has been with the company for 35 years and is getting close to
retirement."

"Really." the new employee replied. "And he's been in the mailroom the whole time?"

"No, he left a number of years ago. But he asked for a transfer back - after spending several years as a
project manager."
On the surface, the role of a project manager should be easy to describe. In fact, from a textbook
perspective it probably is. But the challenge to understanding roles and responsibilities is that they are
different from company to company. So, although this webpage will provide an overall perspective of
the role, you still need to determine what the role of a project manager is at your company, or in your
organization.

Process Responsibilities

Once the project starts, the project manager must successfully manage and control the work,
including:

• Identifying, tracking managing and resolving project issues

• Proactively disseminating project information to all stakeholders

• Identifying, managing and mitigating project risk

• Ensuring that the solution is of acceptable quality

• Proactively managing scope to ensure that only what was agreed to is delivered, unless
changes are approved through scope management

• Defining and collecting metrics to give a sense for how the project is progressing and whether
the deliverables produced are acceptable

• Managing the overall schedule to ensure work is assigned and completed on time and within
budget

Again, this does not mean that the project manager physically does all of this, but they must make
sure it happens. If the project has problems, or scope creep, or faces risks, or is not setting
expectations correctly, then the project manager is the person held accountable.

To manage the project management processes, a person should be well organized, have great follow-
up skills, be process oriented, be able to multi-task, have a logical thought process, be able to
determine root causes, have good analytical ability, be a good estimator and budget manager, and
have good self-discipline.

People Responsibilities

In addition to process skills, a project manager must have good people management skills. This
includes:
 • Having the discipline and general management skills to make sure that people follow the
standard processes and procedures

• Establishing leadership skills to get the team to willingly follow your direction. Leadership is
about communicating a vision and getting the team to accept it and strive to get there with
you.

• Setting reasonable, challenging and clear expectations for people, and holding them
accountable for meeting the expectations. This includes providing good performance feedback
to team members

• Team building skills so that the people work together well, and feel motivated to work hard
for the sake of the project and their other team members. The larger your team and the longer
the project, the more important it is to have good team-building skills.

• Proactive verbal and written communicator skills, including good, active listening skills.

Again, you are responsible for the success of the project. If the team has poor morale and is missing
deadlines, you need to try to resolve it. If team members don't understand exactly what they need to
do and when it is due, then you are responsible.

Multiple Roles

Depending on the size and complexity of the project, the project manager may take on other
responsibilities in addition to managing the work. For instance, the project manager may assist with
gathering business requirements. Or they may help design a database management system or they
may write some of the project documentation. Project management is a particular role that a person
fills, even if the person who is the project manager is working in other roles as well.

For instance, a project manager might manage the project for 45% of their time, perform business
analysis for 25%, work on design for 15% and write documentation for 15%. This does not mean that
one of the responsibilities of a project manager role is to spend 15% of their time on design. Instead, it
just means that the project is not large enough to need a full-time project manager. The project
manager spends the rest of their time in other project roles such as Business Analyst, Designer and
Technical Writer. Depending on the size of your projects and the way your company is organized, a
project manager’ time may be allocated one of three ways.

• They may have a full time role on a large project.

• They may have project management responsibilities for multiple projects, each of which is
less than full time, but the combination of which adds up to a full-time role.
 • They may fill multiple roles, each of which requires a certain level of skill and responsibility.
On one project, for instance, they may be both a project manager and an analyst.

1. Explain the various steps in the identification process of a project. What are the tools
used in project planning? How can risks be prioritized?
Ans-

Traditionally, project management includes a number of elements: four to five process groups, and a
control system. Regardless of the methodology or terminology used, the same basic project
management processes will be used.

The project development stages[19]

Major process groups generally include:

 Initiation

 Planning or development
 Production or execution

 Monitoring and controlling

 Closing

In project environments with a significant exploratory element (e.g., Research and development),
these stages may be supplemented with decision points (go/no go decisions) at which the project's
continuation is debated and decided. An example is the Stage-Gate model.

Initiation

Initiating Process Group Processes[19]

The initiation processes determine the nature and scope of the project. If this stage is not performed
well, it is unlikely that the project will be successful in meeting the business’ needs. The key project
controls needed here are an understanding of the business environment and making sure that all
necessary controls are incorporated into the project. Any deficiencies should be reported and a
recommendation should be made to fix them.

The initiation stage should include a plan that encompasses the following areas:

 Analyzing the business needs/requirements in measurable goals

 Reviewing of the current operations

 Financial analysis of the costs and benefits including a budget

 Stakeholder analysis, including users, and support personnel for the project

 Project charter including costs, tasks, deliverables, and schedule

Planning and design
Planning Process Group Activities[19]

After the initiation stage, the project is planned to an appropriate level of detail. The main purpose is
to plan time, cost and resources adequately to estimate the work needed and to effectively manage
risk during project execution. As with the Initiation process group, a failure to adequately plan greatly
reduces the project's chances of successfully accomplishing its goals.

Project planning generally consists of

 determining how to plan (e.g. by level of detail or rolling wave);

 developing the scope statement;

 selecting the planning team;

 identifying deliverables and creating the work breakdown structure;

 identifying the activities needed to complete those deliverables and networking the activities in
their logical sequence;

 estimating the resource requirements for the activities;

 estimating time and cost for activities;

 developing the schedule;

 developing the budget;

 risk planning;

 gaining formal approval to begin work.

Additional processes, such as planning for communications and for scope management, identifying
roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting
are also generally advisable.
For new product development projects, conceptual design of the operation of the final product may be
performed concurrent with the project planning activities, and may help to inform the planning team
when identifying deliverables and planning activities.

Executing

Executing Process Group Processes

Executing consists of the processes used to complete the work defined in the project management
plan to accomplish the project's requirements. Execution process involves coordinating people and
resources, as well as integrating and performing the activities of the project in accordance with the
project management plan. The deliverables are produced as outputs from the processes performed as
defined in the project management plan.

Monitoring and controlling

Monitoring and controlling consists of those processes performed to observe project execution so that
potential problems can be identified in a timely manner and corrective action can be taken, when
necessary, to control the execution of the project. The key benefit is that project performance is
observed and measured regularly to identify variances from the project management plan.
Monitoring and Controlling Process Group Processes

Monitoring and Controlling includes:

 Measuring the ongoing project activities (where we are);

 Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and
the project performance baseline (where we should be);

 Identify corrective actions to address issues and risks properly (How can we get on track again);

 Influencing the factors that could circumvent integrated change control so only approved changes
are implemented

In multi-phase projects, the monitoring and controlling process also provides feedback between
project phases, in order to implement corrective or preventive actions to bring the project into
compliance with the project management plan.

Project Maintenance is an ongoing process, and it includes:

 Continuing support of end users

 Correction of errors

 Updates of the software over time

Monitoring and Controlling cycle

In this stage, auditors should pay attention to how effectively and quickly user problems are resolved.

Over the course of any construction project, the work scope may change. Change is a normal and
expected part of the construction process. Changes can be the result of necessary design
modifications, differing site conditions, material availability, contractor-requested changes, value
engineering and impacts from third parties, to name a few. Beyond executing the change in the field,
the change normally needs to be documented to show what was actually constructed. This is referred
to as Change Management. Hence, the owner usually requires a final record to show all changes or,
more specifically, any change that modifies the tangible portions of the finished work. The record is
made on the contract documents – usually, but not necessarily limited to, the design drawings. The
end product of this effort is what the industry terms as-built drawings, or more simply, “as built.” The
requirement for providing them is a norm in construction contracts.

When changes are introduced to the project, the viability of the project has to be re-assessed. It is
important not to lose sight of the initial goals and targets of the projects. When the changes
accumulate, the forecasted result may not justify the original proposed investment in the project.

Closing

Closing Process Group Processes

Closing includes the formal acceptance of the project and the ending thereof. Administrative activities
include the archiving of the files and documenting lessons learned.

This phase consists of:

 Project close: Finalize all activities across all of the process groups to formally close the project
or a project phase

 Contract closure: Complete and settle each contract (including the resolution of any open items)
and close each contract applicable to the project or project phase
Tools used in project planning-

project management tools

Here are examples and explanations of four commonly used tools in project planning and project
management, namely: Brainstorming, Fishbone Diagrams, Critical Path Analysis Flow Diagrams, and
Gantt Charts. Additionally and separately see business process modellingand quality management,
which contain related tools and methods aside from the main project management models shown
below.

The tools here each have their strengths and particular purposes, summarised as a basic guide in the
matrix below.

Matrix key:

B = Brainstorming
F = Fishbone/Ishikawa Diagrams *** - main tool
C = Critical Path Analysis Flow Diagrams ** - optional/secondary tool
G = Gantt Charts * - sometimes useful

B F C G

Project brainstorming and initial concepts, ideas, structures, aims, etc *** **

Gathering and identifying all elements, especially causal and hidden

* *** **
factors

Scheduling and timescales ** ***

Identifying and sequencing parallel and interdependent activities and

* *** *
stages

Financials - costings, budgets, revenues, profits, variances, etc * * ** ***

Monitoring, forecasting, reporting * ** ***

Troubleshooting, problem identification, diagnosis and solutions ** *** ** *

'Snapshot' or 'map' overview - non-sequential, non-scheduled ** ***

Format for communications, presentations, updates, progress reports,

* * ***
etc

brainstorming

Brainstorming is usually the first crucial creative stage of the project management and project
planning process. See the brainstorming method in detail and explained separately, because it many
other useful applications outside of project management.

Unlike most project management skills and methods, the first stages of the brainstorming process is
ideally a free-thinking and random technique. Consequently it can be overlooked or under-utilized
because it not a natural approach for many people whose mains strengths are in systems and
processes. Consequently this stage of the project planning process can benefit from being facilitated
by a team member able to manage such a session, specifically to help very organised people to think
randomly and creatively.

Fishbone diagrams

Fishbone diagrams are chiefly used in quality management fault-detection, and in business process
improvement, especially in manufacturing and production, but the model is also very useful in project
management planning and task management generally.

Within project management fishbone diagrams are useful for early planning, notably when gathering
and organising factors, for example during brainstorming.

Fishbone diagrams are very good for identifying hidden factors which can be significant in enabling
larger activities, resources areas, or parts of a process.

Fishbone diagrams are not good for scheduling or showing interdependent time-critical factors.

Fishbone diagrams are also called 'cause and effect diagrams' and Ishikawa diagrams, after Kaoru
Ishikawa (1915-89), a Japanese professor specialising in industrial quality management and
engineering who devised the technique in the 1960s.

Ishikawa's diagram became known as a fishbone diagram, obviously, because it looks like a fishbone:
 A fishbone diagram has a
central spine running left
to right, around which is
built a map of factors
which contribute to the
final result (or problem).

For each project the main

categories of factors are
identified and shown as the
main 'bones' leading to the
spine.

Into each category can be

drawn 'primary' elements
or factors (shown as P in
the diagram), and into
these can be drawn
secondary elements or
factors (shown as S). This
is done for every category,
and can be extended to
third or fourth level factors
if necessary.

The diagram above is a very simple one. Typically fishbone diagrams have six or more main bones
feeding into the spine. Other main category factors can include Environment, Management, Systems,
Training, Legal, etc.

The categories used in a fishbone diagram should be whatever makes sense for the project. Various
standard category sets exist for different industrial applications, however it is important that your
chosen structure is right for your own situation, rather than taking a standard set of category headings
and hoping that it fits.

At a simple level the fishbone diagram is a very effective planning model and tool - especially for
'mapping' an entire operation.
Where a fishbone diagram is used for project planning of course the 'Effect' is shown as an aim or
outcome or result, not a problem.

The 'Problem' term is used in fault diagnosis and in quality management problem-solving. Some
fishbone diagrams can become very complex indeed, which is common in specialised quality
management areas, especially where systems are computerised.

This model, and the critical path analysis diagram are similar to the even more complex diagrams
used on business process modellingwithin areas of business planning and and business process
improvement.

Project critical path analysis (flow diagram or chart)

'Critical Path Analysis' sounds very complicated, but it's a very logical and effective method for
planning and managing complex projects. A critical path analysis is normally shown as a flow
diagram, whose format is linear (organised in a line), and specifically a time-line.

Critical Path Analysis is also called Critical Path Method - it's the same thing - and the terms are
commonly abbreviated, to CPA and CPM.

A commonly used tool within Critical Path Analysis is PERT (Program/Programme/Project

Evaluation and Review Technique) which is a specialised method for identifying related and
interdependent activities and events, especially where a big project may contain hundreds or
thousands of connected elements. PERT is not normally relevant in simple projects, but any project of
considerable size and complexity, particularly when timings and interdependency issues are crucial,
can benefit from the detailed analysis enabled by PERT methods. PERT analysis commonly feeds
into Critical Path Analysis and to other broader project management systems, such as those mentioned
here.

Critical Path Analysis flow diagrams are very good for showing interdependent factors whose timings
overlap or coincide. They also enable a plan to be scheduled according to a timescale. Critical Path
Analysis flow diagrams also enable costings and budgeting, although not quite as easily as Gantt
charts (below), and they also help planners to identify causal elements, although not quite so easily as
fishbone diagrams (below).

This is how to create a Critical Path Analysis. As an example, the project is a simple one - making a
fried breakfast.

First note down all the issues (resources and activities in a rough order), again for example:
Assemble crockery and utensils, assemble ingredients, prepare equipment, make toast, fry sausages
and eggs, grill bacon and tomatoes, lay table, warm plates, serve.

Note that some of these activities must happen in parallel - and crucially they are interdependent. That
is to say, if you tried to make a fried breakfast by doing one task at a time, and one after the other,
things would go wrong. Certain tasks must be started before others, and certain tasks must be
completed in order for others to begin. The plates need to be warming while other activities are going
on. The toast needs to be toasting while the sausages are frying, and at the same time the bacon and
sausages are under the grill. The eggs need to be fried last. A Critical Path Analysis is a
diagrammatical representation of what needs done and when. Timescales and costs can be applied to
each activity and resource. Here's the Critical Path Analysis for making a fried breakfast:

This Critical Path Analysis example below shows just a few activities over a few minutes. Normal
business projects would see the analysis extending several times wider than this example, and the time
line would be based on weeks or months. It is possible to use MS Excel or a similar spreadsheet to
create a Critical Path Analysis, which allows financial totals and time totals to be planned and tracked.
Various specialised project management software enable the same thing. Beware however of
spending weeks on the intricacies of computer modelling, when in the early stages especially, a
carefully hand drawn diagram - which requires no computer training at all - can put 90% of the
thinking and structure in place. (See the details about the most incredible planning and
communications tool ever invented, and available for just a tiny fraction of the price of all the
alternatives.)
project critical path analysis flow diagram example

Gantt charts

Gantt Charts (commonly wrongly called gant charts) are extremely useful project management tools.
The Gantt Chart is named after US engineer and consultant Henry Gantt (1861-1919) who devised the
technique in the 1910s.

Gantt charts are excellent models for scheduling and for budgeting, and for reporting and presenting
and communicating project plans and progress easily and quickly, but as a rule Gantt Charts are not as
good as a Critical Path Analysis Flow Diagram for identifying and showing interdependent factors, or
for 'mapping' a plan from and/or into all of its detailed causal or contributing elements.

You can construct a Gantt Chart using MSExcel or a similar spreadsheet. Every activity has a separate
line. Create a time-line for the duration of the project (the breakfast example shows minutes, but
normally you would use weeks, or for very big long-term projects, months). You can colour code the
time blocks to denote type of activity (for example, intense, watching brief, directly managed,
delegated and left-to-run, etc.) You can schedule review and insert break points. At the end of each
line you can show as many cost columns for the activities as you need. The breakfast example shows
just the capital cost of the consumable items and a revenue cost for labour and fuel. A Gantt chart like
this can be used to keep track of progress for each activity and how the costs are running. You can
move the time blocks around to report on actuals versus planned, and to re-schedule, and to create
new plan updates. Costs columns can show plan and actuals and variances, and calculate whatever
totals, averages, ratios, etc., that you need. Gantt Charts are probably the most flexible and useful of
all project management tools, but remember they do not very easily or obviously show the importance
and inter-dependence of related parallel activities, and they won't obviously show the necessity to
complete one task before another can begin, as a Critical Path Analysis will do, so you may need both
tools, especially at the planning stage, and almost certainly for large complex projects.

gantt chart example

A wide range of computerised systems/software now exists for project management and planning, and
new methods continue to be developed. It is an area of high innovation, with lots of scope for
improvement and development. I welcome suggestions of particularly good systems, especially if
inexpensive or free. Many organizations develop or specify particular computerised tools, so it's a
good idea to seek local relevant advice and examples of best practice before deciding the best
computerised project management system(s) for your own situation.

Project planning tools naturally become used also for subsequent project reporting, presentations, etc.,
and you will make life easier for everyone if you use formats that people recognize and find familiar.
Project financial planning and reporting

For projects involving more than petty cash you'll probably need a spreadsheet to plan and report
planned and actual expenditure. Use MSExcel or similar. Financial accounting for small projects can
sometimes be managed using the project's Gantt Chart. Large projects are likely to require some sort
of require dedicated accounting system, although conceivably Gantt Charts and financial management
accounts can easily be administered within a spreadsheet system given sufficient expertise. If you
don't know how to put together a basic financial plan, get some help from someone who does, and
make sure you bring a good friendly, flexible financial person into your team - it's a key function of
project management, and if you can't manage the financial processes your self you need to be able to
rely completely on whoever does it for you. The spreadsheet must enable you to plan, administer and
report the detailed finances of your project. Create a cost line for main expenditure activity, and break
this down into individual elements. Create a system for allocating incoming invoices to the correct
activities (your bought-ledger people won't know unless you tell them), and showing when the costs
hit the project account. Establish clear payment terms with all suppliers and stick to them. Projects
develop problems when team members get dissatisfied; rest assured, non- or late-payment is a
primary cause of dissatisfaction.

Remember to set some budget aside for 'contingencies' - you will almost certainly need it.

project contingency planning

Planning for and anticipating the unforeseen, or the possibility that things may not go as expected, is
called 'contingency planning'. Contingency planning is vital in any task when results and outcomes
cannot be absolutely guaranteed. Often a contingency budget needs to be planned as there are usually
costs associated. Contingency planning is about preparing fall-back actions, and making sure that
leeway for time, activity and resource exists to rectify or replace first-choice plans. A simple
contingency plan for the fried breakfast would be to plan for the possibility of breaking the yolk of an
egg, in which case spare resource (eggs) should be budgeted for and available if needed. Another
might be to prepare some hash-browns and mushrooms in the event that any of the diners are
vegetarian. It may be difficult to anticipate precisely what contingency to plan for in complex long-
term projects, in which case simply a contingency budget is provided, to be allocated later when and
if required.
Communicate the project plan to your team

This serves two purposes: it informs people what's happening, and it obtains essential support,
agreement and commitment. If your project is complex and involves a team, then you should involve
the team in the planning process to maximise buy-in, ownership, and thereby accountability. Your
project will also benefit from input and consultation from relevant people at an early stage.

Also consider how best to communicate the aims and approach of your project to others in your
organization and wider network.

Your project 'team' can extend more widely than you might first imagine. Consider all the possible
'stakeholders' - those who have an interest in your project and the areas it touches and needs to attract
support or tolerance.

Involvement and communication are vital for cooperation and support. Failing to communicate to
people (who might have no great input, but whose cooperation is crucial) is a common reason for
arousing suspicion and objections, defensiveness or resistance.

Agree and delegate project actions

Your plan will have identified those responsible for each activity. Activities need to be very clearly
described, including all relevant parameters, timescales, costs, and deliverables. Use the SMART
acronym to help you delegate tasks properly. See the delegation tips and processes. Using proper
delegation methods is vital for successful project management involving teams. When delegated tasks
fail this is typically because they have not been explained clearly, agreed with the other person, or
supported and checked while in progress. So publish the full plan to all in the team, and consider
carefully how to delegate medium-to-long-term tasks in light of team members' forward-planning
capabilities. Long-term complex projects need to be planned in more detail, and great care must be
taken in delegating and supporting them. Only delegate tasks which pass the SMART test. Other
useful materials to help understand team delegation are theTannenbaum and Schmidt Continuum,
and Tuckman's group forming/performing model. The Johari Window model is also an excellent
review framework for quickly checking or reminding about mutual awareness among team members
in large complex projects, where there is often a risk of project fragmentation and people 'doing their
own thing' in blissful isolation - which seriously undermines even the best planned projects.
Manage, motivate, inform, encourage, enable the project team

Manage the team and activities in meetings, communicating, supporting, and helping with decisions
(but not making them for people who can make them for themselves). 'Praise loudly; blame softly.' (a
wonderful maxim attributed to Catherine the Great). One of the big challenges for a project manager
is deciding how much freedom to give for each delegated activity. Tight parameters and lots of
checking are necessary for inexperienced people who like clear instructions, but this approach is the
kiss of death to experienced, entrepreneurial and creative people. They need a wider brief, more
freedom, and less checking. Manage these people by the results they get - not how they get them.
Look out for differences in personality and working styles in your team. Misunderstanding personal
styles can get in the way of team cooperation. Your role here is to enable and translate. Face to face
meetings, when you can bring team members together, are generally the best way to avoid issues and
relationships becoming personalised and emotional. Communicate progress and successes regularly to
everyone. Give the people in your team the plaudits, particularly when someone high up expresses
satisfaction - never, never accept plaudits yourself. Conversely - you must take the blame for anything
that goes wrong - never 'dump' (your problems or stresses) on anyone in your team. As project
manager any problem is always ultimately down to you anyway. Use empathy and conflict handling
techniques, and look out for signs of stress and manage it accordingly. A happy positive team with a
basic plan will outperform a miserable team with a brilliant plan, every time.

Check, measure, and review project performance; adjust project plans; inform project team
and others

Check the progress of activities against the plan. Review performance regularly and at the stipulated
review points, and confirm the validity and relevance of the remainder of the plan. Adjust the plan if
necessary in light of performance, changing circumstances, and new information, but remain on track
and within the original terms of reference. Be sure to use transparent, pre-agreed measurements when
judging performance. (Which shows how essential it is to have these measures in place and clearly
agreed before the task begins.) Identify, agree and delegate new actions as appropriate. Inform team
members and those in authority about developments, clearly, concisely and in writing. Plan team
review meetings. Stick to the monitoring systems you established. Probe the apparent situations to get
at the real facts and figures. Analyse causes and learn from mistakes. Identify reliable advisors and
experts in the team and use them. Keep talking to people, and make yourself available to all.
Complete project; review and report on project; give praise and thanks to the project team

At the end of your successful project hold a review with the team. Ensure you understand what
happened and why. Reflect on any failures and mistakes positively, objectively, and without
allocating personal blame. Reflect on successes gratefully and realistically. Write a review report, and
make observations and recommendations about follow up issues and priorities - there will be plenty.

Follow up - train, support, measure and report project results and benefits

Traditionally this stage would be considered part of the project completion, but increasingly an
emphasised additional stage of project follow-up is appropriate.

This is particularly so in very political environments, and/or where projects benefits have relatively
low visibility and meaning to stakeholders (staff, customers, investors, etc), especially if the project
also has very high costs, as ICT projects tend to do.

ICT (information and communications technology) projects often are like this - low visibility of
benefits but very high costs, and also very high stress and risk levels too.

Project management almost always involves change management too, within which it's very
important to consider the effects of the project on people who have to adapt to the change. There is
often a training or education need. There will almost certainly be an explanation need, in which for
example methods like team briefing have prove very useful.

Whatever, when you are focused on project management it is easy to forget or ignore that many
people are affected in some way by the results of the project. Change is difficult, even when it is good
and for right reasons. Remembering this during and at the end of your project will help you achieve a
project that is well received, as well as successful purely in project management terms.

Define the Risk Identification Process

Risk Identification is the process which seeks to understand the project, determine which risks are
likely and document the characteristics of the risks. It is mostly concerned with opportunities and
threats. Risk identification is never really completed until the project is also completed. It is a process
which is undertaken throughout the life of the project.

The approach one must take is to gather as much relevant data as possible and schedule a risk
management meeting with the core team members. Including the core team members is the surest way
to secure support for a structured and thorough approach to identifying risks.
Tools and Techniques of Identifying Risks

The most common tools and techniques used for developing a list of project risks are brainstorming,
nominal grouping technique, mind mapping, Delphi technique and lessons learned from similar
projects.

1. Brainstorming

The steps involved are as follows:

• Chose a facilitator other than the project manager;

• Chose a scribe to capture the risks and opportunities;

• Use a category or categories to start the creativity flowing; Do not judge or analyze during this
effort; and

• Focus on getting the universe of risks and opportunities for the project.

2. Nominal Grouping Technique

The steps involved are as follows:

• Gather the core team for a risk workshop;

• Use flip-chat paper or a white board the collect the information for the team;

• Begin by requesting that each person identify potential areas of risk;

• Request that each person write about three (3) to five (5) risk events for each area. Participants
should not share lists.

• Request that the first person provide the first item on his/ her list then proceed to the next
person and repeat the request for his/ her first item; and

• Repeat until everyone's items have been listed.

This helps to avoid duplicate listings of the same risk(s) and also saves time taken to perform this
task.

3. Mind Mapping

The steps involved are as follows:

• Begin by drawing a circle that represents a risk category;

• Represent major risks for that category with lines connecting with the circle;

• For each major risk, identify smaller risks that are part of that risk;
 • Do not judge or evaluate at this point; and

• Continue until no more risks can be identified.

At the end of this activity, there should be a fish bone diagram that shows the different relationships
for each risk.

4. Delphi Technique

The steps involved are as follows:

• Identify a person to act as the facilitator;

• The facilitator identifies qualified experts to participate in the exercise;

• The facilitator poses questions to the experts individually;

• The facilitator then conducts a factor analysis on the data to identify common themes;

• This information is shared with the panel of experts for validation;

• The list of themes is refined and again shared with the panel; and

• The facilitator then creates a single results document.

5. Lessons Learned from Similar Projects

The steps involved are as follows:

• Identify comparable projects using the project characteristics;

• Locate the relevant post project review reports;

• Review the lessons learned documents for a list actual risk events that occurred, response(s) to
the risk event, effectiveness of the risk event and any new risks identified during the project.

Additionally, categories such as cost, schedule, technology, resources, environmental, legal, economic
and political can be used to group risk. Personal experience and intuition (thinking outside the box)
are also quite useful in risk identification.

Involving the stakeholders early in the project opens communication and there is less risk of
interpreting what the stakeholders want and/ or require.

Make sure that there is an adequate amount of the correct information. By applying more than one of
these various tools and techniques appropriately, the list of risks and opportunities will be the most
comprehensive.

At the end result of the risk identification process the project teams knows what may happen and what
will be the impact. The team understands the source and can estimate when it may occur.
 1. What is the importance of PMIS? List out the macro issues in project management and
explain each. What is the modern mantra in project management?
Ans-

A project management information system (PMIS)can provide a framework to help guide the
progress of your next major IT project. Here's how one company decided that a PMIS was needed to
help increase project success rates.

We all know that accurate, timely, and relevant information is essential to the decision-making
process of a project and that relying on an inadequate information system puts a project at risk. We all
know that information is a valuable resource for project managers. Despite the fact that we all know
these things, project managers often fail to deliver the types of information needed to ensure project
success. Implementing a project management information system (PMIS) is one way to address
critical project information needs.

One of my major clients, an international engineering firm, decided to break the cycle of
miscommunication and derailed projects by ordering the development and implementation of a PMIS
that is able to provide upper management with adequate information about all the projects in the
organization’s portfolio. Traditionally, engineers and project managers do not communicate project
status adequately with upper management and functional departments. They believe that projects are
their responsibility and they have the authority to deliver them. Furthermore, functional departments
are often reluctant or do not have time to provide information to project engineers. These
circumstances often lead to late, over budget, and low quality projects.

First of two parts

This is the first of two articles on the implementation of a project management information system
(PMIS) in a major engineering company. The articles document the author's first-hand experiences
with the implementation of a PMIS in this global organization.

Symptoms of the problem

The following symptoms that made us realize the necessity for implementing a PMIS:

There was a loss of control through the systematic analysis of the information gathered.

There was no system for integrating the time, cost, scope, and quality objectives.Projects were often
late, over budget, and of low quality.

To overcome the shortage in information, managers created project organizations within the corporate
organization that led to duplication and waste of time, money, and effort.

The inability of the project manager/team to report accurately the status of the project in terms of
time, cost, and work remaining.

Here is the approach we decided to use for the progressive development of the PMIS:

Identify what is needed.

• Compare the current situation with what is needed to achieve the aim of the PMIS set by upper
management.

• Bridge the gap between what is needed and what was already in place.

Questions in search of answers

The symptoms we studied pointed to a number of questions:

• What information do we need in order to adequately plan, organize, and control our project?

• What information do we need to share with other stakeholders?

• What information do we need about other projects in the organization that interface with our
project?

• What information do we need in order to coordinate our project’s activities with other initiatives in
the organization?

• What is the cost of not having accurate, timely, and relevant information about our project?

• What is the cost of having accurate, timely, and relevant information about our project?

• Is the available information suitable for decision making?

• Do we have too much data but not enough information?

• What value does the PMIS add to the project?

Improvement objectives
We agreed that the new system should meet improvement objectives for the project management
process. This meant we needed to state the improvement objectives as early as possible so that we
could define the requirements of the system in terms of these objectives and facilitate the system’s
acquisition process. We decided the improvement objectives for the new system should:

• Enable the project team to identify and isolate sources of significant variances and determine the
reason why a project deviated from its plan.

• Allow the project team to track the status of the work packages in order to determine the work that
is completed and the work that is still pending.

• Help the project team manage project schedules by providing the basis for work package resource
allocation and work timing.

• Interface and be compatible with larger legacy information systems.

• Help the project team forecast the impact of certain risks on time, costs, and quality baselines.
• Give the project team insight into what revisions to the baselines they need to implement, when
they should implement these revisions, and why they are implementing these revisions.

• Integrate with the work breakdown structure (WBS), which provides the capability to report the
status of the work packages throughout the project’s life cycle. These reports include identification
of the work package, its associated cost code and schedule, and the individual responsible for the
work.

Reengineering the project management process

We analyzed the existing management process and decided that it was inadequate for solving the
business problem, or meeting the improvement objectives. Thus, significant changes were required.
We had to spend a considerable amount of time developing and documenting the new process before
going to the acquisition phase.

There was a wide gap between the information requirements we had identified and the existing
project management processes and methods. Thus, we needed to develop a considerable number of
project management procedures. We settled on eight categories of procedures. Following is a partial
list of the procedures and their categories:

Procedures for project definition

• Preliminary estimate

• Preparation of technical specifications

• Startup review

Procedures for estimating and cost control

• Bottom-up estimate preparation

• Cost control

• Cost feedback

Procedures for scheduling

• Glossary of planning terminology

• Project milestones
 Procedures for human resource management
 Coding procedure
Procedures for procurement management

• Selecting vendors

• Appraising vendors

Procedures for materials management

• Expediting

• Inventory control

• Inspections for quality assurance

• Vendor data

Procedures for documents management

• Numbering system

• Distribution profiles

• Filing structure

Procedures for integrating the proposed PMIS with other information systems
 Data dictionary
In this article, we have identified the need for the system, the symptoms of the problem, issues to
consider, improvement objectives, and the infrastructure required (in terms of manual procedures) to
implement a PMIS. In the next article in this series, we will expand our definition of a PMIS, describe
the information needs of stakeholders, the main components of a PMIS, and the acquisition process.

Organizational Issues in Project Management

1. Organization will have structures, hierarchies, Functions, Communication Patterns,

Decision centre and most importantly cultures - which define them and make them unique.

2. Make changes with the outcome in mind and not the tasks the result in them.
 3. Such a work culture is very conductive for problem solving which is the aim of all
creativity.

4. To implement changes successfully, it is essential that employees are involved in the

implementation of change.

5. Opportunities for creativity are many in project.

6. When multiple projects are handled restructuring is almost a continuous.

10 Mantras for effective Project Management

A rising number of software projects today boast of precise processes and carefully calibrated time
schedules, thanks to the 10 P’s that are helping redefine project management
Sleepless nights and endless cups of coffee…A budget over shot and the sword of an almost missed
deadline hanging dangerously low…Freshly discovered bugs in the final version of the software
solution and the sales head screaming…Is that what software projects are all about? While some of
these occurrences still trigger off the adrenaline levels of project managers across the Indian IT
industry, the Indian software industry has come a long way since those chaotic days of the boom.
The buzz of words like knowledge management, formal management training and company-wide
project planning practices reverberating across the annals of Indian software companies speaks
volumes about the maturing of the industry itself.
Dataquest brings to you ten practices that have transformed the face of software project
implementation by Indian companies…
Th
e
pro
gre
jec
tss
of
sta
a
tus
pro
en
jec
co
1 Planning Specs for the Perfect PM
tEven
mp is as the sales team revels in the
What does the senior
mo
ass
euphoria of having bagged a plum management look for when
nit
es
deal, it is time for swift action at the elevating a team leader to a
ore
inf
delivery end. But unlike the flurry of project manager?
duncoordinated activity that often set
or
thr
ma
projects rolling in the past, projects nImpeccable technical
ou
tio
today, start with a company-wide credentials and proven
ngh
meeting involving all the stake- professional expertise
mo
on
holders of the project. Anand Shankar
R nDeftness in client
nth
bu
Lal,
E PM at Infogain explains how a interaction
ly
dg
project kick off meeting includes not
D: nSkills at cost control
pro
et,
just the project team and senior
Th nOverall insight into
jec
sco
management,
is
A but other associated the project apart from
tM
pe,
groups like quality assurance and
sig knowledge about
hig
eff
system support in order to understand
nif
BE
G one’s own module
hli
ort
the
ies project requirement, milestones
R:
R
,ght nAbility to build
and risks.
tha
Th
EE
sch rapport with and
etrep
N:
"When you promise 24X7 service to motivate other team
ort
ed
the
var
Th
customers, logistical requirements of members
seiati
ule
var
people working at the backend nGood design, analytical and
an
,var
iati
on
become extremely important. estimation skills
diati
res
on
is
Arrangements for food, transport and
the
our
is
bet
on nSkills to effectively communicate
the security of teams working round
Re
ce,
mo
we
is with the onsite co-ordinator
the clock need to be tackled. For this
so
qu
re
en
les nCommercial acumen, exposure
reason, involving HR and
urc
alit
tha
s10 and understanding of the client’s
administrative heads (who will be
ytha
neresponsible for making these
% business
Uti
sta
20
nan
arrangements) in the planning meeting nSpeed in picking up new things
liz
tus
d%
10
helps. Attending these meetings gives nEmotional management – ability
ati
an
off
20
%.
them a feel of the importance of the to tackle team members in
on
dTh
tar
%
project to the company and stressful situations
Sta
the
get
eoff
automatically buys greater nEffective written and oral
te
ov
-an
pro
commitment." says Kanad Chaterjee, communication
era
dme
tar
jec
senior Project Manager, HCL Tech
nts
ll
ne
tget nPresentation skills
.To
edsdeal with the chronic problem of
sta
but
sch nProblem solving capability
vague,
Th
tus
esc
cor
ed inaccurate and un-testable
.especifications, it needs to be ensured nAdherence to schedules
ala
rec
uk
that
hig
Cri
tio
etiv a requirement baseline must be nNegotiation capacity
agreed
tic
enhli
is upon before the beginning of Most companies have processes to
project
ght
al
to
act planning activities. evaluate prospective project
rep
pro
sen
ion
mo managers on behavioral and
"A
ort mature
Ti
jec
ior
is
st
So technical competencies. If there are
estimation
sck
ts
ma
in
on
ur team any weaknesses in the competency
should
er
giv
of
na
pla
tar
ce: be assigned areas, they are strengthened and
to
ea
ge
ce
get
M agree to the then promoted.
most
pro
BT
me
to
an
ah realistic
estimate
,jec
nt
dbri
in of project
size,
t
too
for
ng
the
dr effort and
cost.
,sta
act
it
are At least two
tus
are
ion
ba
Br
ide
-su
ck
no
itis
m
nti
Hi
on
hpro
ma
fie
gh
tar
ble
Te
ry
d.
Ris
get
ms
lec
wit
Su
.k.
om
 Pr
De
Te
Ar
vel
am
chi
oje
op
lea
tec
ct
er:
td:
M
Th
(of
an
e
fsh
ag
on
big
or
er:
e
pic
e/o
He
independent estimates should be arrived at, preferably using two different methodologies, based onhas wh
tur
nsi
actual data of similar past projects. Initial software estimates and schedules should be looked on asgre eo
te
high risk due to the lack of definitive information available at the time they are defined. The estimates po
gu
co-
at
and schedules should be refined as more information becomes available," says Vipul Doshi, COO, tea ysse
or
InterGlobe Technologies. sse
for
di
m
s
the
na
ma
When it comes to allocating resources/talent or hiring new talent for various modules, SEED Infotech
go
mo
tor
na
guidelines advise PMs to first identify all possible roles required in a project, identify personnel fitting
od
dul
):
ge
these roles, allocate responsibilities, authorities and accountabilities. Vishweshwar Hegde, general
pro
e.
Ov
me
manager, global quality function, Mindtree Consulting highlights the importance of a comprehensive
gra
He
era
nt
estimation technique (with tools) to address effort, schedule, cost and project profitability up front at
m
has
ll
ski
proposal stage of the project.
mi
det
tec
lls,
"In a nutshell, planning a project is 99% common sense and 1% technical sense," says D Ramesh, ke ng
hail
Project Manager, Accel Software and Technologies. ski
ed
lea
eps
2 People lls,
kn
d.
the
At the end of the day, companies have realized that technology and process deliverables do fall intotea is
ow
He
place, it is the allocation of human resources and managing them that required deft handling. "No m res
led
kn
sharing of resources across projects is the basic principle. Though this means higher pressure on mo po
ge
ow
resource optimization, it is well worth the cost," points out Sudhir Goel, vice president, delivery at tiv nsi
sab
MphasiS BFL Group. Goel explains that just-in-time recruitment is difficult and is very rarely ble
out
ho
ate
attempted. for
his
dw
co
/he
all
an
When it comes to figuring out who is doing what, activities, which requires instant client interaction rdin
dthe
are entrusted onsite. If resource usage is heavy, the function is carried out on homeground. Time zone g
mo
ens
deviations can be put to advantage by assigning complimentary tasks to teams in diverse zones. ure an
dul
Advises D Ramesh, PM at Accel Software and Technologies, "Put the best people in the most critical ed
ses
Th
places of a project. But do not let the team know about the critical tags. Know the learning curve oftha uni
an
wo
e
each member of your team. Give a little more weightage to in-house talent (The ‘known devil’ d
trk
Bu
dictum)." When dividing the teams into geographical locations, the logistics of the implementationthe tes
has
tog
ild
phase need to be kept in mind. tin
go
eth
tea
ing
gSo
od
er
m
Bl
the
ins
an
is
ur
oc
mo
digh
on
ce:
ks
tdul
tak
tra
M
of
es.
int
es
ck.
BT
the
oA
the
He
(M
Pr
"For example, for a client based in qui
oth
ke
wo
ah
oje
London, UK, I may send my team ck
yer
rks
in
ct
leads for the design to the UK. The int
mo
tec
clo
dr
Te
implementation team may be located egr
dul
hni
sel
aam
in Mumbai. The team leads bring back the design details, and ramp up the team. And when it’s time ati
es
ycal
Br
for the implementation phase, it is good to have a team coordinator with excellent business and wit on
as
de
itis
technical skills liaising with the clients at UK. Unless absolutely necessary, the implementation team tes
we
hcis
h
should not be further geographically distributed. That simply increases the challenges, "explains MBT tTe
ll.
ion
the
Project manager, Shilpa Kapadia. sh
He
s.
Ar
lec
oul
has
He
chi
HCL Tech follows the system of having "shadows" (backups for team members). "These people areom d
go
has
tec
closely involved in the project but their cost is borne by the software company, not by the client. In)t. be
od
go
case a team member has to leave at short notice, the shadows are ready to take over," explains do
des
od
He
Pradeep Sharma, Project Manager, HCL Tech. ne
ign
tec
sh
by
an
hni
oul
a
dcal
de
est
ski
ha
vel
im
lls,
ve
op
ati
ex
er
on
cel
bef
ski
len
M
Un
de
oti
rst
vat
Op
an
ion
ini
d
an
on
my
sd
tea
re
an
m
wa
d
an
rd:
inv
3 Processes
d
Ac
olv
The key reason why companies have been able to eliminate the ambiguity in projects is because
the
kn
em
precise processes have been laid down and are being followed.
ir
ow
ent
"According to the traditional mode of work, a task would be assigned with a request for an update
neE
:led
every two hours.
ed
gin
ver
gs:
yo
Typically, a at the
Be
Ke
per
ne
end of two hours,
ing
Sh
epi
so
has
aone
ilp would
nng
an
discover that the
Go
aopi
tea
wh
task is well behind
od
Ka
om
nio
schedule, with the
Le
pa
me
ndo
result that a task
ad
di
mb
es
an
which merits eight hours of work now needs to be accomplished only in six hours," says Anant
er
a,
daers
Koppar, CEO, Kshema Technologies and probably one of the few CEOs certified by the Project
Pr
ha
gre
wo
Management
oje Insititute. Koppar explains that in the above scenario, established processes would
pp
at
uld
enforce discipline, making monitoring easier.
ct
y
job
lik
M
Yogen
e,res Chawla, General Manager, Systems, CSC, India elaborates on the usage of automated
an
workflow
ult
sta
to systems. "The beginning of a new module is initiated by a Project Manager who assigns the
ag
sanalysis request to a Business Analyst. On completion of the analysis, an alert automatically goes to
ys
be
er,
the
in technical staff. The automated system controls the flow of the work through design, coding,
lat
he
M
reviews
a
e,
ard and testing phases with automated alerts sent from one resource to another on completion of
BT
the
bet
.or A various stages of the work product. The acceptance testing by functional experts (or Business
sp
Analysts
ter
co
sof as we call them) and their signoff on the workflow system triggers the Delivery team to
eci
package
del
me
tw the work product for final deliver to the customer. Project teams at multiple locations have
fie
access to common databases and use the same workflow systems to ensure consistency and
sive
are
scoordination
ry
in
en amongst the project teams," says Chawla.
the
of
ear
gin
Birlasoft too uses automated tools for detailed schedules of the project, budgeting and activities like
pe
the
ly,
eer
projecting tracking, timesheets, defecting prevention and VOC (voice of customer) capturing.
op
pro
go
wo
At
jec Sonata Software, tools are used for estimating the project size and effort. Tools provide a set of
le
es
rki
standard
ma
at.
ng templates for work breakdown structure for various types of projects like new development,
application
na
If
lon
on re-engineering, maintenance etc.
ge
These templates are enhanced by adding new activities based on the lessons learnt from past projects.
agthe
me
yAs the project progresses, team members suddenly find that the days appear to be getting shorter. It is
wa
sm
nt
here that metrics data provides a strong handle to the Project Manager on any deviations from the
kn
y.
all
ski
planned values.
ow
Ev
mo
lls
the
ery
dul
"The
Pr deviations are tracked and discussed with the senior Management at the review meetings for all
yprojects after analysis of data by metrics group. The deviations are analysed for root cause and then
ebo
oje
ca
dy
of
corrective
ct actions are defined for final closure of the project.," explains Rajesh Tikku, Vice-President
nDelivery, Infinite Computer Solutions.
lik
the
M
co
es
fin
an
Mphasis
unt
to
al BFL has a system of weekly/monthly audit by the QMS team that reports to the CEO/COO.
ag
"This
on
be
pro audit uses a quantification process to assign numbers to each metric. Based on overall scores, a
ers
project’s
yo
not
du health can be determined. Any unapproved deviation from the schedule is an automatic
sh
over-ride
u,
ice
ct, and puts the project in a red status. Another control mechanism is the use of special
ou
milestones
dthe
not in the project schedule which provide symptomatic indication of future successes and
ld
failures,
y’l
for
kn " explains Sudhir Goel, Vice President - Delivery at MphasiS BFL Group.
fol
l
his
ow
lo
be
or
ing
w:
the
her
ho
re
har
w
dwh
it
en
wo
all
yo
rk.
co
u
Ev
me
4 Prudence
These are difficult times and budgets are tight no doubt. Even as adherence to processes and the
inevitable long work hours that come along ensure that deadlines are stuck to, sticking to a budget
remains a greater challenge. As Wipro Technologies’GM, software engineering V Subramanyam
says, "In the early days, infrastructure, conveyance and people costs were covered under a general
head and approved quite easily. Now things have changed. Cost estimation sheets are monitored
closely. All travel for instance, cannot be billed, but needs to be justified."
Similarly, there is no procuring of technical tools (even if the project demands it) unless it been
specified to client. Subramanyam explains how the setting up of an organization-wide tools lab helps
where tools and licenses can be shared across projects.
Anand Shankar Lal, PM, Infogain suggests budgeting small expenses even if the probability of
incurring them is very less. "The more detailed budgeting is done, the probability of sticking to it is
higher, because during operations, the project team encounters a situation where a lot of cost drivers
are not identified and hence they run into trouble. Budgeted versus actual expenses are taken as one of
the important indicators of the project performance," he says.
Preparing a budget or estimation involves making top-down estimate and verifying this with a
bottom-up estimate. A top-down estimate involves making an inventory of the features required in the
system, and estimating the effort to develop each feature. Next is preparing a bottom up estimate. This
involves determining precise components that go into building the features of the system, estimating
the time for each, and summing up the total time for the development of various components.
"The next step is to perform a gap-analysis between the top-down and bottom-up approaches.
However, if there is a major gap, that might mean some thing has been missed in either estimate for
which the Project Manager would need to reconcile the gap (if any) between the two estimates,"
explains Shilpa Kapadia, Project Manager, Delivery Group at MBT.
"At an organization level, Project Management Reviews (PMRs) are conducted at milestones to check
for the metrics performance, resource utilization, profit and loss status with a cross-functional team
from each of the stakeholders’ areas involved in the the PMR. This ensures that there are no cost
overruns, effort variance and schedule variance and the project is performing within the budget. A
project is also tracked till closure,"says Sarama Pani - Group Head, Quality Management Group at
MBT.
5 Patience
Clients and their changing requirements have been an integral aspect of software implementation.
Over time, companies have learnt to anticipate change and be prepared to tackle it without crumbling
under pressures of time and budgets.
Mindtree’s Vishweshwar Hegde advises the setting up of a strong Change Management process to
address multiple dimensions. "Technical impact: analyzing what parts of the products get impacted.
Financial impact on cost, effort and schedule due to the change. Customer impact: early
communication of the same to the customer and negotiations.
Strong risk management practices based on the past risk repository and structured risk assessment to
prevent some of the impacts of changes" says Hegde.
At Birlasoft, complete change management is done to deal with changing client specs. Any change
raised by client is analyzed for impact of cost schedule, work items etc. Change is accepted or
rejected by software configuration control board.
Appropriate project re-planning is done according to change.
Amit Kinariwala, head, Enterprise Technologies Group, LG Soft India cites a case in which the client
was not very clear about the requirements. "All the departments at the client place had their
requirements and own stories to tell. For two months I was at the client site with them adding
functionality requirements. There were no cost overruns initially. But by the fourth month, the
customer wanted to have some major changes in the processes, which were already delivered to them!
Only due to the staged deliveries were we able to satisfy the customer that they need to revert back on
changes quickly else it will cost them more.
Thus finally the customer agreed for schedule changes and also paid for it," says Kinariwala.
6 Persistence
Even as the traditional tussle between the Sales team’s attitude to notch up client wins and the
technical team’s struggle to deliver the promised goods continues, top level project managers are
increasingly being called upon to smoothen interaction with the client.
V Subramanyam, GM, software engineering, Wipro Technologies points out that clients too are
becoming more focussed on what they want. "Earlier they used to give end to end project
deliverables. The trend now is quick deliverables small time frames."
Sunil Kumar Mittal, general manager, HCL Tech describes how a particular overseas client of the
company was being extremely persistent with the sales team to try and bring the cost of the project
down. "There were two other companies in the fray, who were willing to do the project at a lower
cost. After a two-hour conference call, I could convince the client that we were offering specific
advantages in terms of deliverables and quality. The argument was that we would be able to deliver
what the other two software companies were offering at a lower cost, but if the client wanted
additional deliverables, he would have to pay extra," recalls Mittal.
7 Perfection
There is little doubt that the Indian software brand has arrived where it has today, primarily because
of the quality of services offered. Testing, documentation and quality assurance are not activities that
teams take lightly after the "hot hob" of coding is done.
For instance, all projects at LGSI need to have Defect prevention leader (DPL). The DPL is required
to accumulate and aggregate all the defects (internal reviews raised by client) and perform a causal
analysis on them. The outcome of the DP analysis is discussed with the complete team so that most of
the recurring defects are avoided in the future.
Rajesh Tikku, vice president, Delivery, Infinite Computer Solutions says the trick is in not only
maintaining delivery timelines but also a very high standard of the quality of deliverables. "People
may not remember that you delivered a day late, but they will always remember that you delivered
bad code," he says.

8 Precaution
Despite stringent quality checks and a product that is certified as perfect by multiple authorities in the
organization, cases of software acting up before the client are not uncommon. Kshema executive VP,
Y K Maheshwari explains that the testing tool identified at the beginning of the project, may not work
in a new operating system. "We discuss this again with the client and look at using a new tool," he
says. This is primarily because the hardware and software environment onsite is bound to be different.
Once again, the trick is to anticipate such hiccups and allocate enough resources at the client end
during the "acceptance phase" until things start functioning smoothly.
"As a precaution, we try to simulate the hardware environment that is prevalent at the client site. At
times, we request the client to ship that hardware to our location so that we can test the software in
actual client-life conditions," says Ramakrishna of Kshema Technologies.
"And apart from testing the software in the developer’s machine, we also test it in a virgin machine to
see id it throws up any unexpected bugs," adds Kshema COO Anand Mutalik. Breaking down work
and delivering modules in stages could also solve this problem to a certain extent so that all problems
do not pop up at the last stage.
9 Practice
Knowledge management and incorporating the learnings from one project into the next project
undertaken by the company has long been part of the holistic vision of companies. But as project
managers struggle to first deliver all that the client wants, often imeeting unrealistic deadlines, jotting
down learnings often takes a backseat. Over the years, software companies have found ways to pool
learnings from past projects and collect them in a central repository to be used by teams across the
organization. But how does one ensure that the knowledge and experience gained during one project
is actually deposited into this repository?
"Project Managers are not allotted the next project until the completion report, along with learnings is
not logged in," smiles Sunil Mittal of HCL Tech.
10 Professionalism
It has been a long journey for Indian software. Companies large and small are continuously striving to
put up a face that speaks of commitment, reliability and more than anything else, the confidence that
global clients will take them seriously.
May it be processes or people, professional training in project management is the order of the day.
Kshema Technologies has made PMI certification mandatory for all project managers in the company.
"As CEO it gives me the confidence that things will run professionally in all projects undertaken by
the company. I can do my audits without spending more time. India has been poor at cost
management and this has reflected in margin pressure. The PMI model accurately calculates how
much money has been spent, how much money we have and how much work has been done,"says
Kshema CEO Anant Koppar.
We certainly have come a long way from the days of ad hoc customer demands and rushed IT jobs.
Companies no longer place the smartest techie on board as the head of the operation and expect things
to work out on their own. India’s large software companies have already done it and the smaller ones
are doing their best to ensure that those at the helm of projects are professionally trained.
After all, a project is what brings in the bucks for Indian software, sustains burgeoning teams of
software professionals and signifies that the bench is a good while away.