Managing IT Projects

Chapter 1Projects Overview & Basic Concepts & Definitions

Projects Overview & Basic Concepts & Definitions

What is project? Why learn project managementAlmost 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.

Projects Overview & Basic Concepts & 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.

Projects Overview & Basic Concepts & 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……

Projects Overview & Basic Concepts & 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

Projects Overview & Basic Concepts & 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

Projects Overview & Basic Concepts & 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.

Projects Overview & Basic Concepts & 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)

Projects Overview & Basic Concepts & 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.

Projects Overview & Basic Concepts & 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.

Projects Overview & Basic Concepts & 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."

Projects Overview & Basic Concepts & 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 productConstructing new buildingSetting 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.

Why do project fail?

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.

Why do project fail?

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.

Why do project fail?

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 Charter2. Business case/Feasibility Study3. Scope Statement / Terms of reference4. Project Management Plan / Project Initiation Document 5. Work Breakdown Structure6. Change Control Plan 7. Risk Management Plan8. Communications Plan9. Governance Model10. Risk Register11. Issue Log12. Action Item List

Important Aspects related to Project Management

13 Resource Management Plan14 Project Schedule15 Status Report16 Responsibility assignment matrix17 Database of risks18 Database of lessons learned19 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) Planning3) Execution and controlling4) Closure

Project Life cycle

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 objectives2. 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 Management16 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,

Product perspective & work 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.

Product perspective & work 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.

Product perspective & work 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.

Product perspective & work 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.

Product perspective & work 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)

Product perspective & work 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)

Product perspective & work 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.

Product perspective & work 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.

Ten Step Process Flow

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 ProjectSet 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 CharterProject Plan – GANTT ChartMethod StatementRisk AnalysisContingency PlansBudgetMeeting MinutesQuality PlanSpecificationProject Contact Directory - a list of participants complete with contact details

Project Charter

Key Dates in the Project:Identify Milestone events and datesDetail any key decision points and their deadlinesProject 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 PersonnelIdentify 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 tomeet 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).

Financial evaluation of project 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.

Financial evaluation of project 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:

nNPV Σ __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 × SalesSales 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 managementFrequent 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 ultimatelyallow faster client response, better price performance, or otherbusiness 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.

Project Stakeholders

• 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 projectThe 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 Stakeholders

• 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 Stakeholders

• 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 Stakeholders

• 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 Stakeholders

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

Project Stakeholders

• 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 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: http://www.facebook.com/welearnindia p // /

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

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