Managing IT Projects


Published on

In this presentation we will talk about effective ways, overview and concept of “Managing IT Projects”.
To know more about Welingkar School’s Distance Learning Program and courses offered, visit:

Published in: Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Managing IT Projects

  1. 1. Managing IT ProjectsChapter 1Projects Overview & BasicConcepts & Definitions
  2. 2. Projects Overview & Basic Concepts & DefinitionsWhat is project? Why learn project management Almost any human activity that involvescarrying out a non-repetitive task can be aproject. So we are all project managers! We allpractice project management (PM).But there is a big difference between carryingout a very simple project involving one or twopeople and one involving a complex mix ofpeople, organizations and tasks.
  3. 3. Projects Overview & Basic Concepts & DefinitionsThe art of planning for the future has alwaysbeen a human trait. In essence a project can becaptured on paper with a few simple elements:a start date, an end date, the tasks that have tobe carried out and when they should befinished, and some idea of the resources(people, machines etc) that will be neededduring the course of the project.
  4. 4. Projects Overview & Basic Concepts & Definitions Project Management is the discipline oforganizing and managing resources (ie.people) in such a way that the project iscompleted within defined scope, quality, timeand cost constraints. A project is a temporaryand one-time endeavor undertaken to create aunique product or service, that brings aboutbeneficial change or added value. This propertyof being a temporary and a one-timeundertaking contrasts with processes, or……
  5. 5. Projects Overview & Basic Concepts & Definitionsoperations, which are permanent or semi-permanent ongoing functional work to createthe same product or service over and overagain. The management of these two systemsis often very different and requires varyingtechnical skills and philosophy, hence requiringthe development of project management.The first challenge of project management is toensure that a project is delivered within definedconstraints. The second, more ambitiouschallenge is the optimized allocation
  6. 6. Projects Overview & Basic Concepts & Definitionsand integration of inputs needed to meet pre-defined objectives. A project is a carefullydefined set of activities that use resources(money, people, materials, energy, space,provisions, communication, quality, risk, etc.) tomeet the pre-defined objectives.As a discipline, Project Management developedfrom different fields of application includingconstruction, engineering, and defense. In theUnited States, the forefather of projectmanagement is Henry Gantt, called the father
  7. 7. Projects Overview & Basic Concepts & Definitionsof planning and control techniques, who isfamously known for his use of the "bar" chart asa project management tool, for being anassociate of Frederick Winslow Taylorstheories of scientific management[1], and for hisstudy of the work and management of Navyship building. His work is the forerunner tomany modern project management toolsincluding the work breakdown structure (WBS)and resource allocation.
  8. 8. Projects Overview & Basic Concepts & DefinitionsThe 1950s mark the beginning of the modernproject management era. Again, in the UnitedStates, prior to the 1950s, projects weremanaged on an ad hoc basis using mostlyGantt Charts, and informal techniques andtools. At that time, two mathematical projectscheduling models were developed: (1) the"Program Evaluation and Review Technique" orPERT, developed as part of the United StatesNavys (in conjunction with the LockheedCorporation)
  9. 9. Projects Overview & Basic Concepts & DefinitionsPolaris missile submarine program[2]; and (2)the "Critical Path Method" (CPM) developed ina joint venture by both DuPont Corporation andRemington Rand Corporation for managingplant maintenance projects. Thesemathematical techniques quickly spread intomany private enterprises. In 1969, the Project Management Institute(PMI) was formed to serve the interest of theproject management industry.
  10. 10. Projects Overview & Basic Concepts & DefinitionsThe premise of PMI is that the tools andtechniques of project management arecommon even among the widespreadapplication of projects from the softwareindustry to the construction industry. In 1981,the PMI Board of Directors authorized thedevelopment of what has become the A Guideto the Project Management Body of Knowledge(PMBOK), containing the standards andguidelines of practice that are widely usedthroughout the profession.
  11. 11. Projects Overview & Basic Concepts & DefinitionsDefinitions•PMBOK (Project Management Body of Knowledgeas defined by the Project Management Institute -PMI):"Project management is the application ofknowledge, skills, tools and techniques to projectactivities to meet project requirements."[•PRINCE project management methodology: "Theplanning, monitoring and control of all aspects ofthe project and the motivation of all those involvedin it to achieve the project objectives on time and tothe specified cost, quality and performance."
  12. 12. 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 product Constructing new building Setting new corporate websitePublic issue of shares & so on
  13. 13. Why do project fail?No one prevented them from failing. We definesuccess as a lack of failure and failure as a lackof success. If you eliminate the possibility forfailure, the only possibility you have left issuccess.You can try to do all the things to makesomething succeed and still be blindsided bysomething you didnt notice, didnt consider. Sotrying to do all the right things wont necessarilyensure success.
  14. 14. Why do project fail? In risk management, we look at what might bea problem. In failure prevention, we look atwhat will definitely cause this to fail and letsmake sure it doesnt happen.Compared to the causes of failure, risks arefriendly. You can watch them, mitigate them,see if they happen. Risks have a probability.But there are definite causes of failure that, ifyou have them in your project, your project willfail, like objectives not aligned with businessstrategy or missing data.
  15. 15. Why do project fail? And if you have something that will definitelycause your project to fail, theres only one thingleft to do, and thats to get rid of it.People problems. Business and technicalproblems boil down to people problems. Callingsomething a technical problem is a convenientlabel to say "Its not something I can handle." Ifthe server goes down, "its a technicalproblem." Well, you either fix it or get someoneto handle it. Its a people problem. People solveproblems.
  16. 16. Why do project fail? People create problems. "It was a technicalproblem because the software was buggy."Well, it was people who created buggy softwareor made the decision to buy the software. Itsthe extent to which we take responsibility forsolving problems that gets them solved. Sometimes projects drags to such a extent thatthe management aborts it midway. The myth ofIT is that its about computers and technology.Its not -- IT is about people.
  17. 17. Important Aspects related to Project Management1. Project Charter2. Business case/Feasibility Study3. Scope Statement / Terms of reference4. Project Management Plan / Project Initiation Document5. Work Breakdown Structure6. Change Control Plan7. Risk Management Plan8. Communications Plan9. Governance Model10. Risk Register11. Issue Log12. Action Item List
  18. 18. Important Aspects related to Project Management13 Resource Management Plan14 Project Schedule15 Status Report16 Responsibility assignment matrix17 Database of risks18 Database of lessons learned19 Stakeholder Analysis
  19. 19. Project Life cycleThe 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.
  20. 20. Project Life cycleProject 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,
  21. 21. Project Life cyclebut 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
  22. 22. Project Life cycle
  23. 23. Project Life cycleFigure illustrates the life cycle of a typicalproject. As previously mentioned, a uniquefeature of ERATO is that all projects are time-limited and are automatically finished anddispersed without exception after five years.This policy prevents funded projects frombecoming "entrenched bureaucracies," socommon to other Japanese researchprograms. It also fosters considerablepersonnel mobility and invigorates the systemby creating the resources to start three or fournew projects every year.
  24. 24. Project Life cycleAn example of a lifecycle models is the genericwaterfall approach. This model provides a basicoutline that can be used on any project. Basicallyyou start off understanding the requirement of thesolution, designing a solution, building and testinga 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 asmall project you still go through these basic steps,although some of them may be a mental exercise.
  25. 25. Project Life cycleIf 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 receivingsome type of service request that describes the workrequired (analysis and requirements), which you take andmentally map into the work to be performed (design). Youthen make the enhancement changes required, test them(test) and implement them (construct, test, implement). Theclassic waterfall approach is the lifecycle model you wouldprobably end up with if you knew nothing aboutmethodology and just had to build a project work plan fromscratch.
  26. 26. Project Management ActivitiesProject Management is composed of several different types of activities such as:1. Planning the work or objectives2. Analysis & Design of objectives3. Assessing and controlling risk (or Risk Management)4. Estimating resources5. Allocation of resources6. Organizing the work7. Acquiring human and material resources8. Assigning tasks9. Directing activities10. Controlling project execution
  27. 27. Project Management Activities11 Tracking and Reporting progress12 Analyzing the results based on the facts achieved13 Defining the products of the project14 Forecasting future trends in the project15 Quality Management16 Issues Management17 Issues solving18 Defect prevention18 Project Closure meet19 Communicating to stakeholders
  28. 28. 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.ApplicationThe applications for the WBS are as varied as the approaches to using it. In some organizations it is used strictly for work definition,
  29. 29. 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.
  30. 30. 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.ContentThe WBS consists of a variety of levels, each defining the project in greater detail.
  31. 31. Product perspective & workbreakdown 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., 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.
  32. 32. 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.
  33. 33. Product perspective & work breakdown structure ApproachesGiven 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) Subcomponent part (work package)
  34. 34. 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) Specific work element (work package)
  35. 35. 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.ConsiderationsThe 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.
  36. 36. Product perspective & work breakdown structureIf they are flexible, existing organizational practice canprevail. If, however, a customer prefers or demands aproduct orientation and the supporting organization hasa history of task-oriented WBS s, some conflict in workdefinition may ensue.These actual costs normallyinclude a percentage to acknowledge the organization’sinvestment and expense in administering a project. Thisburden rate may be different for human and materialresources, depending upon the organization’saccounting practices. Normally, budget costs are brokenout by resources and materials so that the burden foreach can be easily incorporated and so thatmanagement can discern between human resourcecosts and material resource costs.
  37. 37. Ten Step Process Flow
  38. 38. Project CharterA project Charter is a document which embodies the projectgoals and commitment of stakeholders to a project & itsoutcomes. It includes followings. Project Title:Prepared by: Date:Version: Background to the Project Set out where you are now, where the project will be takingyou and what the benefits of the project will be. Make surethere is a clear understanding of what the project is about andthat all interested parties share the same aims and objectives.All too often people either do not know Why the project isbeing initiated or have a conflicting idea as to what therequired outcome is.
  39. 39. Project CharterAims & Objectives: Set out exactly what it is that the project is aiming toachieve. The more precise and specific you are the morelikely you are to achieve the end result. Having measurableresults is also important, there is a truism that if somethingcannot be measured it cannot be controlled. Criteria of Success: How exactly will you know that your project has been asuccess, spell it out. Like a journey you will know when youhave arrived. Consequences of Failure: Focusing people on what the downside is may reinforce theneed to achieve the objectives of the project.
  40. 40. Project CharterWe live and work in a fast paced and ever changing world,just standing still is not good enough. If you don’t respondquickly to change it is likely your competitors will,consigning you and your business to second place or evenworse. Assumptions: Just because things are obvious or apparent to you does notmean others think in the same way or perceive the situationfrom the same viewpoint as you. If there are any assumptionsin your plan clearly define them, that way there can be noconfusion or breakdown in communication. If things gounsaid they can go unnoticed. Constraints:
  41. 41. Project CharterWhat factors limit or impact upon your project and yourplanning. Clearly identify all factors impacting on yourplans and the steps you have taken to accommodate them. Risk Analysis: What risks are there to your project. List them out andconsider their probability and potential impact upon yourplans. How would you know when a risk had arisen, backtrack to try and identify the warning signs and then monitorthem closely. Contingency plans: Your plan should go according to schedule but if it does notwhat are you going to do?
  42. 42. Project CharterProject Documentation: Identify the documents relating to your project and wherethey are kept. Typical documents would include: Project CharterProject Plan – GANTT ChartMethod StatementRisk AnalysisContingency PlansBudgetMeeting MinutesQuality PlanSpecificationProject Contact Directory - a list of participants completewith contact details
  43. 43. Project CharterKey Dates in the Project: Identify Milestone events and datesDetail any key decision points and their deadlines Project Control: Spell out how you intend to monitor and control yourproject. Reporting procedures and the frequency of updates.If people involved in your project are aware that regularupdates are required they will hopefully be aware of the needto avoid disappointing the Project Manager. Key Project Personnel Identify the key people involved and their roles in yourproject, their details should also be kept in the project contactdirectory
  44. 44. Financial evaluation of projectproposalsFinancial analysis is conducted for revenue generatingprojects of government agencies, government-owned and –controlled corporations (GOCCs), government financialinstitutions (GFIs) and local government units. The activityassesses the financial viability of a project and its ability tomeet its debt-service obligations. The section on financial analysis presents the valuation offinancial benefits and costs of the project (using constantprices). The results of the financial analysis are presentedas the financial net present value (NPV), financial internalrate of return (FIRR), weighted average cost of capital(WACC) and/or the benefit-cost ratio (BCR).
  45. 45. Financial evaluation of project proposalsThe Secretariat determines the financial viability of a projecteither from the “all capital” viewpoint and the “equity capital”viewpoint. The former looks at the discounted returns to allreal investment flows for the project as a whole, irrespectiveof whether these come from equity or from loans. The latterlooks at proponent’s (investor’s) equity contributions as theinvestment 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 onthe validated submissions of the project proponents of thebenefit and cost streams. A project is financially viable in the“all capital” approach if the resulting FIRR is greater than theWACC and the NPV is greater than zero using the WACC asthe discount rate.
  46. 46. Financial evaluation of project proposals A project is financially viable under the “equity capital”approach when the resulting FIRR exceeds the cost ofequity contribution of the proponent while NPV shouldbe greater than zero using the cost of equity capital asdiscount rate. The NPV is the difference between thepresent values of project benefits and project costs. Thefinancial 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
  47. 47. Efficiency and ProductivityElements of ROI ROI = Operating Income ÷ Investment ROI = Operating Income × Sales Sales Investment ROI = Return on Sales × Asset Turnover = Efficiency × Productivity
  48. 48. Assessing Return on Investment Analyze trends. Compare to competitors. Decompose and compare to competitors. Look for signals suggesting where there might be problems.
  49. 49. 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.
  50. 50. Project GoalsA 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).
  51. 51. Project GoalsFor 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
  52. 52. Project GoalsGoals 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.
  53. 53. Project GoalsGoals are high-level statements that provide the overall context for what the project is trying to accomplish. Lets 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.
  54. 54. Project GoalsThe 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.
  55. 55. Project Goals It may instead be a vision statement, which is ahigher level statement showing direction andaspiration, but which may never actually beachieved.It is important to understand business and projectgoal statements, even though goals are not a part ofthe Ten Step Project Definition. Goals are mostimportant from a business perspective. The projectmanager needs to understand the business goals thatthe project is trying to contribute to. However, youdo not need to define specific project goals. On theother hand, objectives definitely are important.
  56. 56. Project Stakeholders •Project stakeholders are those entities within orwithout an organization which:a) Sponsor a project or,b) Have an interest or a gain upon a successfulcompletion of a project.Examples of project stakeholders include the customer,the user group, the project manager, the developmentteam, the testers, etc. Stakeholders are anyone who has an interest in theproject. Project stakeholders are individuals andorganizations that are actively involved in the project, orwhose interests may be affected as a result of projectexecution or project completion.
  57. 57. Project Stakeholders• They may also exert influence over theproject’s objectives and outcomes. The projectmanagement team must identify thestakeholders, determine their requirements andexpectations, and, to the extent possible,manage their influence in relation to therequirements to ensure a successful project The following are examples of projectstakeholders:Project leader Project teammembers Upper management Project customerResource Managers Line Managers Productuser group Project testers
  58. 58. Project Stakeholders• Project leader (or project manager) – thehead of the project; defines, plans, controls, and leadsthe project• Project team members – produce the outputs(deliverables) for the project; participate in the projectmanagement process; contribute their skills and effortto perform tasks• Sponsor (or upper manager) – the personwith formal authority who is ultimately responsible forthe project; oversees the project; acts as a liaisonbetween the upper management team and the projectleader; provides authority, guidance, and maintainsproject priority
  59. 59. Project Stakeholders• Project customer – the person or group whoseneeds and requirements drive the project; receives thefinal output(s) that the project produces; providesproduct requirements and funding• Functional managers (also known asresource managers or line managers) – providecompany policy an resources, particularly people whoare involved in the project
  60. 60. Project Stakeholders• Project leader (or project manager) – thehead of the project; defines, plans, controls, and leadsthe project• Project team members – produce the outputs(deliverables) for the project; participate in the projectmanagement process; contribute their skills and effortto perform tasks• Sponsor (or upper manager) – the personwith formal authority who is ultimately responsible forthe project; oversees the project; acts as a liaisonbetween the upper management team and the projectleader; provides authority, guidance, and maintainsproject priority
  61. 61. Project Stakeholders• Project customer – the person or groupwhose needs and requirements drive the project;receives the final output(s) that the project produces;provides product requirements and funding• Functional managers (also known asresource managers or line managers) – providecompany policy an resources, particularly people whoare involved in the project "Satisfy stakeholders!" is the project managersmantra. For successful projects, its not enough todeliver on the customers demand; projects have tomeet all stakeholder expectations.
  62. 62. Project Stakeholders• Identifying stakeholders is a primary task because allthe important decisions during the initiation, planningand execution stages of the project are made by thesestakeholders. The five primary project stakeholders are the projectmanager, the project team, the functionalmanagement, the sponsor, and the customer. In alarger sense, anyone who participates in the project oris impacted by its results is a stakeholder. Eachstakeholder has an essential contribution to make andall stakeholder expectations need to be met.Contribution made by different people to the project isthe principal criteria for identifying stakeholders.
  63. 63. Project RiskRisk refers to future conditions or circumstancesthat exist, outside of the control of the project team,that will have an adverse impact on the project ifthey occur. Whereas an issue is a current problemthat must be dealt with, a risk is a potential futureproblem that has not yet occurred. A reactiveproject manager tries to resolve issues when theyoccur. A proactive project manager tries to resolvepotential problems before they occur. This is the artof risk management.
  64. 64. Project Risk Not all issues can be seen ahead of time and somepotential problem that seems unlikely to occur, mayin fact occur.However, many problems can be seen ahead of timeand they should be managed through a proactiverisk management process. Everything in life has some degree of risk. Walkingacross the street can be risky. In the same respect,clients do not expect their projects to be risk-freeeither.
  65. 65. Project Risk The project manager should perform a risk assessment withthe project team and the client. If you are lucky, you mayfind that you only have low risks. However, this assessmentwill alert the client and the project team to any medium andhigh-level risks that may cause future problems.Risk is not necessarily bad, since it is a feature common toall projects. All projects have some degree of uncertainty dueto the assumptions associated with them and the environmentin which they are executed. Projects with a higher level ofrisk require more rigorous risk management and moremanagement focus. Although the risks cannot be eliminatedentirely, many can be anticipated and managed ahead oftime.
  66. 66. Project Risk The purpose of risk management is to identify therisk factors for a project and then establish a riskmanagement plan to minimize the probability thatthe risk event will harm the project.The first time you perform a risk evaluation is in theDefine the Work step. Additional risk identificationshould occur throughout the project on a scheduledbasis (monthly or quarterly) or at the completion ofa major milestone.
  67. 67. Project Planning Project Planning means different things to differentpeople. To some the Project Plan is all of the projectmanagement documentation: the project definitiondocument, organization chart, quality plan, schedule,change control procedure, risk management strategy,etc. (And some use the term Quality Plan to mean all ofthese.) To others the Project Plan is simply theschedule that shows who will do which work tasks andwhen, and to them Project Planning is the act ofbuilding this schedule.Here we will use the term Project Planning in this secondsense: building the task by task schedule which we will callthe Project Plan.
  68. 68. Project Planning Large projects and small projects are very differentanimals in terms of the Project Planning that theyneed. For a very small project a back-of-an-envelope plan may be perfectly adequate. Theremight even be no written down plan at all.But for a large project the Project Planning will needto produce a detailed, formal plan showing preciselywho will do which bits of work and when.
  69. 69. Project Planning Project Planning conceals a trap for the unwary.Most project leaders get experience of ProjectPlanning on small projects. They learn a lesson overand over again: you dont need to bother with all thatformal Project Planning stuff. And theyre right, youdont need to do much, if any, formal ProjectPlanning on a small project. But you then give thatperson a large project, they know they dont need tobother with formal Project Planning, so they dont.And you have a disaster in the making.
  70. 70. Project PlanningMany 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 ProjectPlans· Work Task Size , Step by Step Guide to Constructing aProject Plan ·
  71. 71. 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 PlanUsed· 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
  72. 72. 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 PlanUsed· 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
  73. 73. Project ExecutionThe most important issue in this phase is to ensureproject activities are properly executed andcontrolled. During the execution phase, the plannedsolution is implemented to solve the problemspecified in the projects requirements. In productand system development, a design resulting in aspecific set of product requirements is created. Thisconvergence is measured by prototypes, testing, andreviews..
  74. 74. Project Execution As the execution phase progresses, groups acrossthe organization become more deeply involved inplanning for the final testing, production, andsupport. The most common tools or methodologiesused in the execution phase are an update of RiskAnalysis and Score Cards, in addition to BusinessPlan and Milestones Reviews
  75. 75. Project Execution Project execution involves1) Action of the plan2) Mobilizing the resources3) Assigning work4) Assigning tools & equipment5) Inspecting and correcting defects
  76. 76. Project Tracking Tracking refers to Checking the progress of theproject. A review undertaken at a milestone in generallytakes a 1) Complete stock of the proposal 2) A more specific agenda 3) A comprehensive review of one particularaspect of the project in detail
  77. 77. 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 todenote the process of continuously monitoring aproject
  78. 78. Managing IT Projects End of Chapter 1
  79. 79. “Like” us on Facebook:  p // / “Follow” us on Twitter: com/WeLearnIndiaWatch informative videos on Youtube: