Managing IT Projects

Managing IT Projects

Chapter 1
Projects Overview & Basic
Concepts & Definitions

Projects Overview & Basic Concepts
& Definitions

What is project? Why learn project management
Almost any human activity that involves
carrying out a non-repetitive task can be a
project. So we are all project managers! We all
practice project management (PM).
But there is a big difference between carrying
out a very simple project involving one or two
people and one involving a complex mix of
people, organizations and tasks.

& Definitions

The art of planning for the future has always
been a human trait. In essence a project can be
captured on paper with a few simple elements:
a start date, an end date, the tasks that have to
be carried out and when they should be
finished, and some idea of the resources
(people, machines etc) that will be needed
during the course of the project.

& Definitions

Project Management is the discipline of
organizing and managing resources (ie.
people) in such a way that the project is
completed within defined scope, quality, time
and cost constraints. A project is a temporary
and one-time endeavor undertaken to create a
unique product or service, that brings about
beneficial change or added value. This property
of being a temporary and a one-time
undertaking contrasts with processes, or……

& Definitions

operations, which are permanent or semi-
permanent ongoing functional work to create
the same product or service over and over
again. The management of these two systems
is often very different and requires varying
technical skills and philosophy, hence requiring
the development of project management.
The first challenge of project management is to
ensure that a project is delivered within defined
constraints. The second, more ambitious
challenge is the optimized allocation

& Definitions

and integration of inputs needed to meet pre-
defined objectives. A project is a carefully
defined set of activities that use resources
(money, people, materials, energy, space,
provisions, communication, quality, risk, etc.) to
meet the pre-defined objectives.
As a discipline, Project Management developed
from different fields of application including
construction, engineering, and defense. In the
United States, the forefather of project
management is Henry Gantt, called the father

& Definitions

of planning and control techniques, who is
famously known for his use of the "bar" chart as
a project management tool, for being an
associate of Frederick Winslow Taylor's
theories of scientific management[1], and for his
study of the work and management of Navy
ship building. His work is the forerunner to
many modern project management tools
including the work breakdown structure (WBS)
and resource allocation.

& Definitions

The 1950s mark the beginning of the modern
project management era. Again, in the United
States, prior to the 1950s, projects were
managed on an ad hoc basis using mostly
Gantt Charts, and informal techniques and
tools. At that time, two mathematical project
scheduling models were developed: (1) the
"Program Evaluation and Review Technique" or
PERT, developed as part of the United States
Navy's (in conjunction with the Lockheed
Corporation)

& Definitions

Polaris missile submarine program[2]; and (2)
the "Critical Path Method" (CPM) developed in
a joint venture by both DuPont Corporation and
Remington Rand Corporation for managing
plant maintenance projects. These
mathematical techniques quickly spread into
many private enterprises.
In 1969, the Project Management Institute
(PMI) was formed to serve the interest of the
project management industry.

& Definitions

The premise of PMI is that the tools and
techniques of project management are
common even among the widespread
application of projects from the software
industry to the construction industry. In 1981,
the PMI Board of Directors authorized the
development of what has become the A Guide
to the Project Management Body of Knowledge
(PMBOK), containing the standards and
guidelines of practice that are widely used
throughout the profession.

& Definitions

Definitions
•PMBOK (Project Management Body of Knowledge
as defined by the Project Management Institute -
PMI):"Project management is the application of
knowledge, skills, tools and techniques to project
activities to meet project requirements."[
•PRINCE project management methodology: "The
planning, monitoring and control of all aspects of
the project and the motivation of all those involved
in it to achieve the project objectives on time and to
the specified cost, quality and performance."

& Definitions

•DIN 69901 (Deutsches Institut für Normung -
German Organization for Standardization):
"Project management is the complete set of tasks,
techniques, tools applied during project execution"
Examples of Projects:
Construction of ships,Aircraft or Space Craft.
Launching a new product
Constructing new building
Setting new corporate website
Public issue of shares & so on

Why do project fail?
No one prevented them from failing. We define
success as a lack of failure and failure as a lack
of success. If you eliminate the possibility for
failure, the only possibility you have left is
success.
You can try to do all the things to make
something succeed and still be blindsided by
something you didn't notice, didn't consider. So
trying to do all the right things won't necessarily
ensure success.

In risk management, we look at what might be
a problem. In failure prevention, we look at
what will definitely cause this to fail and let's
make sure it doesn't happen.
Compared to the causes of failure, risks are
friendly. You can watch them, mitigate them,
see if they happen. Risks have a probability.
But there are definite causes of failure that, if
you have them in your project, your project will
fail, like objectives not aligned with business
strategy or missing data.

And if you have something that will definitely
cause your project to fail, there's only one thing
left to do, and that's to get rid of it.
People problems. Business and technical
problems boil down to people problems. Calling
something a technical problem is a convenient
label to say "It's not something I can handle." If
the server goes down, "it's a technical
problem." Well, you either fix it or get someone
to handle it. It's a people problem. People solve
problems.

People create problems. "It was a technical
problem because the software was buggy."
Well, it was people who created buggy software
or made the decision to buy the software. It's
the extent to which we take responsibility for
solving problems that gets them solved.
Sometimes projects drags to such a extent that
the management aborts it midway. The myth of
IT is that it's about computers and technology.
It's not -- IT is about people.

Important Aspects related to Project
Management
1. Project Charter
2. Business case/Feasibility Study
3. Scope Statement / Terms of reference
4. Project Management Plan / Project Initiation Document
5. Work Breakdown Structure
6. Change Control Plan
7. Risk Management Plan
8. Communications Plan
9. Governance Model
10. Risk Register
11. Issue Log
12. Action Item List

Important Aspects related to Project
Management
13 Resource Management Plan
14 Project Schedule
15 Status Report
16 Responsibility assignment matrix
17 Database of risks
18 Database of lessons learned
19 Stakeholder Analysis

Project Life 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 Life cycle

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,

Project Life cycle

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 2) Planning
3) Execution and controlling
4) Closure

Project Life cycle
Figure illustrates the life cycle of a typical
project. As previously mentioned, a unique
feature of ERATO is that all projects are time-
limited and are automatically finished and
dispersed without exception after five years.
This policy prevents funded projects from
becoming "entrenched bureaucracies," so
common to other Japanese research
programs. It also fosters considerable
personnel mobility and invigorates the system
by creating the resources to start three or four
new projects every year.

Project Life cycle
An example of a lifecycle models is the generic
waterfall approach. This model provides a basic
outline that can be used on any project. Basically
you start off understanding the requirement of the
solution, designing a solution, building and testing
a solution and then implementing the solution.
Each of these major areas of focus is called a phase
(Analysis Phase, Design Phase, Construct Phase,
etc.) What could be easier? Even if you have a
small project you still go through these basic steps,
although some of them may be a mental exercise.

Project Life cycle

If you have a forty-hour enhancement project, for instance,
it may seem that you can jump right in with construction.
But are you really? It is more likely that you are receiving
some type of service request that describes the work
required (analysis and requirements), which you take and
mentally map into the work to be performed (design). You
then make the enhancement changes required, test them
(test) and implement them (construct, test, implement). The
classic waterfall approach is the lifecycle model you would
probably end up with if you knew nothing about
methodology and just had to build a project work plan from
scratch.

Project Management Activities

Project Management is composed of several different
types of activities such as:
1. Planning the work or objectives
2. Analysis & Design of objectives
3. Assessing and controlling risk (or Risk Management)
4. Estimating resources
5. Allocation of resources
6. Organizing the work
7. Acquiring human and material resources
8. Assigning tasks
9. Directing activities
10. Controlling project execution

Project Management Activities

11 Tracking and Reporting progress
12 Analyzing the results based on the facts achieved
13 Defining the products of the project
14 Forecasting future trends in the project
15 Quality Management
16 Issues Management
17 Issues solving
18 Defect prevention
18 Project Closure meet
19 Communicating to stakeholders

Product perspective & work
breakdown structure
The work breakdown structure is considered by
many to be the key tool of project management. It is
a decomposition of the project into its component
elements and is used to define the project as a
whole. The WBS provides clarification of the project
deliverables or tasks (depending on organizational
approach or practice). At its various levels, it is used
as a work definition tool, a reporting tool, or a
project summarization tool.
Application
The applications for the WBS are as varied as the
approaches to using it. In some organizations it is
used strictly for work definition,

breakdown structure
which is accomplished by decomposing work
elements (deliverables or tasks) into their parts and
subparts. Because the WBS is broken down into
different levels, its applications at those levels may
vary. And because different organizations break
down the WBS in different ways (primarily task- or
product-oriented categories), those approaches may
lead to different applications as well.
The WBS may be applied in requirements definition by
defining the deliverables from the macro to the
micro level, until the individual components of the
deliverable are clearly delineated.

breakdown structure
It may be applied in work definition by defining the
tasks from the macro level (phase or major task
area) to the micro level (individual discrete work
elements performed by a given individual or
function). It can be applied in cost definition as the
smallest component elements are priced out and
rolled up to create aggregate cost reports. In the
task orientation, the individual discrete work
elements can provide a critical input to network
diagrams.
Content
The WBS consists of a variety of levels, each defining
the project in greater detail.

breakdown structure
At the top, summary or highest level, it is normally
labeled 1.0 or X.0 (where X is a specific project
identifying code), and identifies the project in its
entirety. The next level, the 1.1 (or X.1) level, breaks
down the deliverable into major components or the
project effort into its major tasks. Beyond the X.1
level, there can be a virtually infinite number of
further decompositions (X.1.1, X.1.1.1, X.1.1.1.1,
and so on), as the project is broken out into more
and more finite detail. At the lowest level, however,
should be a discrete deliverable or level of effort
about which the project manager needs to be
aware.

breakdown structure
The WBS should be defined down to the project
manager’s level of control.
In some organizations, that lowest level will be
predetermined by policy or practice. In others, each
project manager must discern the appropriate level
of depth for his or her project(s). In any instance, the
lowest level of the WBS is referred to as a work
package.
One level above the work package is the control
account or cost account level. The control account
or cost account is used primarily for reporting to
management, accounting, or the customer.

breakdown structure
Approaches
Given the variety of approaches that are possible with a
WBS, the key to any successful approach is
consistency. If one section of the WBS is broken out
by deliverables, then the entire WBS should be
deliverables oriented (e.g., if the 1.2.3 section is a
subcomponent, then 1.2.4 should not be a task or
task area). For a deliverables oriented WBS, the
breakdown may be defined as follows:
1.0 Project Description (project) (summary)
1.1 Key Component (summary)
1.1.1 Subcomponent (control/cost account) (summary)
1.1.1.1 Subcomponent part (work package)

breakdown structure
The lowest level of that WBS would be a discrete
part that is a distinct and separate deliverable. It
may be noted that in some major projects, the work
package of one organization being supported by
major vendors may be the project of the vendor
organization.
For a task-oriented WBS, the breakdown may be
defined as follows:
1.0 Project Description (project) (summary)
1.1 Major task area (summary)
1.1.1 Subgroup of tasks (control/cost account)
(summary)
1.1.1.1 Specific work element (work package)

breakdown structure
The approach is largely driven by either
organizational practice or project manager
preference, although the U.S. military takes a firm
position that the WBS should be a deliverables-
oriented document.
Considerations
The WBS evokes passion among some of its users, in
that they are ardent that it should be either task or
product oriented. As such, when beginning work
with a new client or establishing a WBS with a
support organization, it is prudent to explore their
perspectives and applications regarding the WBS.

breakdown structure
If they are flexible, existing organizational practice can
prevail. If, however, a customer prefers or demands a
product orientation and the supporting organization has
a history of task-oriented WBS s, some conflict in work
definition may ensue.These actual costs normally
include a percentage to acknowledge the organization’s
investment and expense in administering a project. This
burden rate may be different for human and material
resources, depending upon the organization’s
accounting practices. Normally, budget costs are broken
out by resources and materials so that the burden for
each can be easily incorporated and so that
management can discern between human resource
costs and material resource costs.

Project Charter
A project Charter is a document which embodies the project
goals and commitment of stakeholders to a project & its
outcomes. It includes followings.
Project Title:
Prepared by: Date:
Version:
Background to the Project
Set out where you are now, where the project will be taking
you and what the benefits of the project will be. Make sure
there is a clear understanding of what the project is about and
that all interested parties share the same aims and objectives.
All too often people either do not know Why the project is
being initiated or have a conflicting idea as to what the
required outcome is.

Project Charter
Aims & Objectives:
Set out exactly what it is that the project is aiming to
achieve. The more precise and specific you are the more
likely you are to achieve the end result. Having measurable
results is also important, there is a truism that if something
cannot be measured it cannot be controlled.
Criteria of Success:
How exactly will you know that your project has been a
success, spell it out. Like a journey you will know when you
have arrived.
Consequences of Failure:
Focusing people on what the downside is may reinforce the
need to achieve the objectives of the project.

Project Charter
We live and work in a fast paced and ever changing world,
just standing still is not good enough. If you don’t respond
quickly to change it is likely your competitors will,
consigning you and your business to second place or even
worse.
Assumptions:
Just because things are obvious or apparent to you does not
mean others think in the same way or perceive the situation
from the same viewpoint as you. If there are any assumptions
in your plan clearly define them, that way there can be no
confusion or breakdown in communication. If things go
unsaid they can go unnoticed.
Constraints:

Project Charter
What factors limit or impact upon your project and your
planning. Clearly identify all factors impacting on your
plans and the steps you have taken to accommodate them.
Risk Analysis:
What risks are there to your project. List them out and
consider their probability and potential impact upon your
plans. How would you know when a risk had arisen, back
track to try and identify the warning signs and then monitor
them closely.
Contingency plans:
Your plan should go according to schedule but if it does not
what are you going to do?

Project Charter
Project Documentation:
Identify the documents relating to your project and where
they are kept. Typical documents would include:
Project Charter
Project Plan – GANTT Chart
Method Statement
Risk Analysis
Contingency Plans
Budget
Meeting Minutes
Quality Plan
Specification
Project Contact Directory - a list of participants complete
with contact details

Project Charter
Key Dates in the Project:
Identify Milestone events and dates
Detail any key decision points and their deadlines
Project Control:
Spell out how you intend to monitor and control your
project. Reporting procedures and the frequency of updates.
If people involved in your project are aware that regular
updates are required they will hopefully be aware of the need
to avoid disappointing the Project Manager.
Key Project Personnel
Identify the key people involved and their roles in your
project, their details should also be kept in the project contact
directory

Financial evaluation of project
proposals
Financial analysis is conducted for revenue generating
projects of government agencies, government-owned and –
controlled corporations (GOCCs), government financial
institutions (GFIs) and local government units. The activity
assesses the financial viability of a project and its ability to
meet its debt-service obligations.
The section on financial analysis presents the valuation of
financial benefits and costs of the project (using constant
prices). The results of the financial analysis are presented
as the financial net present value (NPV), financial internal
rate of return (FIRR), weighted average cost of capital
(WACC) and/or the benefit-cost ratio (BCR).

proposals
The Secretariat determines the financial viability of a project
either from the “all capital” viewpoint and the “equity capital”
viewpoint. The former looks at the discounted returns to all
real investment flows for the project as a whole, irrespective
of whether these come from equity or from loans. The latter
looks at proponent’s (investor’s) equity contributions as the
investment such that the loan proceeds are treated as inflows,
while loan repayments are treated as outflows.
In both cases, the FIRR and the NPV are computed based on
the validated submissions of the project proponents of the
benefit and cost streams. A project is financially viable in the
“all capital” approach if the resulting FIRR is greater than the
WACC and the NPV is greater than zero using the WACC as
the discount rate.

proposals
A project is financially viable under the “equity capital”
approach when the resulting FIRR exceeds the cost of
equity contribution of the proponent while NPV should
be greater than zero using the cost of equity capital as
discount rate. The NPV is the difference between the
present values of project benefits and project costs. The
financial NPV is computed using the following formula:

n
NPV Σ __bi – ci____
i = 0 (1 + r)
where bi = benefits in period I, ci = costs in period i
r = discount rate, n = discounting period

Efficiency and Productivity
Elements of ROI

ROI = Operating Income ÷ Investment

ROI = Operating Income × Sales
Sales Investment

ROI = Return on Sales × Asset Turnover
= Efficiency × Productivity

Assessing Return on Investment

Analyze trends.
Compare to competitors.
Decompose and compare to competitors.
Look for signals suggesting where there
might be problems.

Using Economic Value Added

EVA evaluates income relative to the level
of investment required to earn that income.
It motivates managers to do what they
think is necessary to make economic value
added as large as possible.

Project Goals

A goal is a state of affairs or a state of a concrete activity
domain which a person or a system is going/tends to
achieve or obtain.
A desire or an intention becomes a goal if and only if an
action for achieving it, is activated (see goal-oriented).
Morten Lind and J.Rasmussen distinguished three
fundamental categories of goals related to technological
system management: production goal, safety goal and
economy goal.
The above categories can be decomposed according criteria
related to the numerous types of goal-oriented activities
and goal domains (where the goal is defined).

Project Goals

For any successful business system, it means deriving
profits by making the best quality of goods or the best
quality of services available to the end user (customer) at
the best possible cost. Goal management should include:
Assessment and dissolution of non-rational blocks to
success
Time management
Frequent reconsideration (consistency checks)
Feasibility checks
Adjusting milestones and main goal target

Project Goals

Goals ands objectives are statements that describe
what the project will accomplish, or the business
value the project will achieve. Goals are high level
statements that provide overall context for what the
project is trying to achieve, and should align to
business goals. Objectives are lower level
statements that describe the specific, tangible
products and deliverables that the project will deliver.
The definition of goals and objectives is more of an
art than a science, and it can be difficult to define
them and align them correctly.

Project Goals

Goals are high-level statements that provide the overall context
for what the project is trying to accomplish. Let's look at an
example and some of the characteristics of a goal statement.
One of the goals of a project might be to "increase the overall
satisfaction levels for clients calling to the company helpdesk
with support needs".
Because the goal is at a high-level, it may take more than one
project to achieve. In the above example, for instance, there
may be a technology component to increasing client
satisfaction. There may also be new procedures, new training
classes, reorganization of the helpdesk department and
modifying the company rewards system. It may take many
projects over a long period of time to achieve the goal.

Project Goals
The goal should reference the business benefit in terms of cost,
speed and / or quality. In this example, the focus is on quality of
service. Even if the project is not directly in support of the
business, there should be an indirect tie. For instance, an IT
infrastructure project to install new web servers may ultimately
allow faster client response, better price performance, or other
business benefit. If there is no business value to the project, the
project should not be started.
If you can measure the achievement of your goal, it is probably
at too low a level and is probably more of an objective.
If your goal is not achievable through any combination of
projects, it is probably written at too high a level. In the above
example, you could envision one or more projects that could
end up achieving a higher level of client satisfaction. A goal
statement that says you are trying to achieve a perfect client
experience is not possible with any combination of projects.

Project Goals
It may instead be a vision statement, which is a
higher level statement showing direction and
aspiration, but which may never actually be
achieved.
It is important to understand business and project
goal statements, even though goals are not a part of
the Ten Step Project Definition. Goals are most
important from a business perspective. The project
manager needs to understand the business goals that
the project is trying to contribute to. However, you
do not need to define specific project goals. On the
other hand, objectives definitely are important.

Project Stakeholders
•Project stakeholders are those entities within or
without an organization which:
a) Sponsor a project or,
b) Have an interest or a gain upon a successful
completion of a project.
Examples of project stakeholders include the customer,
the user group, the project manager, the development
team, the testers, etc.
Stakeholders are anyone who has an interest in the
project. Project stakeholders are individuals and
organizations that are actively involved in the project, or
whose interests may be affected as a result of project
execution or project completion.

• They may also exert influence over the
project’s objectives and outcomes. The project
management team must identify the
stakeholders, determine their requirements and
expectations, and, to the extent possible,
manage their influence in relation to the
requirements to ensure a successful project
The following are examples of project
stakeholders:Project leader Project team
members Upper management Project customer
Resource Managers Line Managers Product
user group Project testers

• Project leader (or project manager) – the
head of the project; defines, plans, controls, and leads
the project
• Project team members – produce the outputs
(deliverables) for the project; participate in the project
management process; contribute their skills and effort
to perform tasks
• Sponsor (or upper manager) – the person
with formal authority who is ultimately responsible for
the project; oversees the project; acts as a liaison
between the upper management team and the project
leader; provides authority, guidance, and maintains
project priority

• Project customer – the person or group whose
needs and requirements drive the project; receives the
final output(s) that the project produces; provides
product requirements and funding
• Functional managers (also known as
resource managers or line managers) – provide
company policy an resources, particularly people who
are involved in the project

• Project customer – the person or group
whose needs and requirements drive the project;
receives the final output(s) that the project produces;
provides product requirements and funding
• Functional managers (also known as
resource managers or line managers) – provide
company policy an resources, particularly people who
are involved in the project
"Satisfy stakeholders!" is the project manager's
mantra. For successful projects, it's not enough to
deliver on the customer's demand; projects have to
meet all stakeholder expectations.

• Identifying stakeholders is a primary task because all
the important decisions during the initiation, planning
and execution stages of the project are made by these
stakeholders.
The five primary project stakeholders are the project
manager, the project team, the functional
management, the sponsor, and the customer. In a
larger sense, anyone who participates in the project or
is impacted by its results is a stakeholder. Each
stakeholder has an essential contribution to make and
all stakeholder expectations need to be met.
Contribution made by different people to the project is
the principal criteria for identifying stakeholders.

Project Risk

Risk refers to future conditions or circumstances
that exist, outside of the control of the project team,
that will have an adverse impact on the project if
they occur. Whereas an issue is a current problem
that must be dealt with, a risk is a potential future
problem that has not yet occurred. A reactive
project manager tries to resolve issues when they
occur. A proactive project manager tries to resolve
potential problems before they occur. This is the art
of risk management.

Project Risk

Not all issues can be seen ahead of time and some
potential problem that seems unlikely to occur, may
in fact occur.
However, many problems can be seen ahead of time
and they should be managed through a proactive
risk management process.
Everything in life has some degree of risk. Walking
across the street can be risky. In the same respect,
clients do not expect their projects to be risk-free
either.

Project Risk
The project manager should perform a risk assessment with
the project team and the client. If you are lucky, you may
find that you only have low risks. However, this assessment
will alert the client and the project team to any medium and
high-level risks that may cause future problems.
Risk is not necessarily bad, since it is a feature common to
all projects. All projects have some degree of uncertainty due
to the assumptions associated with them and the environment
in which they are executed. Projects with a higher level of
risk require more rigorous risk management and more
management focus. Although the risks cannot be eliminated
entirely, many can be anticipated and managed ahead of
time.

Project Risk
The purpose of risk management is to identify the
risk factors for a project and then establish a risk
management plan to minimize the probability that
the risk event will harm the project.
The first time you perform a risk evaluation is in the
Define the Work step. Additional risk identification
should occur throughout the project on a scheduled
basis (monthly or quarterly) or at the completion of
a major milestone.

Project Planning
Project Planning means different things to different
people. To some the Project Plan is all of the project
management documentation: the project definition
document, organization chart, quality plan, schedule,
change control procedure, risk management strategy,
etc. (And some use the term Quality Plan to mean all of
these.) To others the Project Plan is simply the
schedule that shows who will do which work tasks and
when, and to them Project Planning is the act of
building this schedule.
Here we will use the term Project Planning in this second
sense: building the task by task schedule which we will call
the Project Plan.

Project Planning
Large projects and small projects are very different
animals in terms of the Project Planning that they
need. For a very small project a back-of-an-
envelope plan may be perfectly adequate. There
might even be no written down plan at all.
But for a large project the Project Planning will need
to produce a detailed, formal plan showing precisely
who will do which bits of work and when.

Project Planning
Project Planning conceals a trap for the unwary.
Most project leaders get experience of Project
Planning on small projects. They learn a lesson over
and over again: you don't need to bother with all that
formal Project Planning stuff. And they're right, you
don't need to do much, if any, formal Project
Planning on a small project. But you then give that
person a large project, they know they don't need to
bother with formal Project Planning, so they don't.
And you have a disaster in the making.

Project Planning
Many aspects of Project Planning including:
· Dividing the Project Into Plan Able Stages
· When to Build the Project Plan
· Who Constructs the Project Plan
· How Simple the Project Plan Can Be for a Small Project
· How Complex the Project Plan Will Be for a Large Project
· Detailed Project Plans and High Level Overview Project
Plans
· Work Task Size , Step by Step Guide to Constructing a
Project Plan ·

Project Planning
•Summarizing the Project Plan for Senior Management
· Communicating the Project Plan
· Getting Team Buy in to the Project Plan
· Making the Project Plan Visible, Getting the Project Plan
Used
· Independent Project Plan Reviews
· Getting Resource Commitments ,· Time Recording
· What Tools Like MSP Can and Cannot Do for You
· Tracking Progress Against the Project Plan
· Revising the Project Plan During the Project

Project Execution

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..

Project Execution

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

Project Execution

Project execution involves
1) Action of the plan
2) Mobilizing the resources
3) Assigning work
4) Assigning tools & equipment
5) Inspecting and correcting defects

Project Tracking

Tracking refers to Checking the progress of the
project.
A review undertaken at a milestone in generally
takes a
1) Complete stock of the proposal
2) A more specific agenda
3) A comprehensive review of one particular
aspect of the project in detail

Project Tracking

Project tracking requires
1) Review
2) Project Status
3) Forecast about the project completion
The term project oversight is also at times used to
denote the process of continuously monitoring a
project

Managing IT Projects

End of Chapter 1

“Like” us on Facebook:
p // /
http://www.facebook.com/welearnindia

“Follow” us on Twitter:
http://twitter.com/WeLearnIndia
http://twitter com/WeLearnIndia

Watch informative videos on Youtube:
http://www.youtube.com/WelingkarDLP

Managing IT Projects

More Related Content

What's hot

Similar to Managing IT Projects

More from We Learn - A Continuous Learning Forum from Welingkar's Distance Learning Program.

Recently uploaded

Managing IT Projects