MANAGEMENTUL PROIECTELOR DE INVESTITII STRAINE DIRECTE

1. MANAGEMENTUL PROIECTELOR DE INVESTITII STRAINE DIRECTE LECT.DR. ROXANA VOICU-DOROBANTU

2. PARTEA 1: MANAGEMENTUL PROIECTELOR PARTEA 2: INVESTITIILE STRAINE DIRECTE STRucturacursului

3. Despre curs • Cursulurmăreşte: • săfamiliarizezestudenţii cu conceptele, metodeleşitehnicilespecificemanagementului de proiect, cu precădere in contextulproiectelorinvestiţionaleinternaţionale • să ofere studenţilor un cadru specific de înţelegere a fenomenului investiţional global, atât din perspectiva investiţiilor străine directe, cât şi a celor de portofoliu • să construiască şi să consolideze capacitatea studenţilor de analizare a tendinţelor şi caracteristicilor investiţiilor străine directe şi a celor de portofoliu din perspectiva motivaţiilor, strategiilor şi riscurilor specifice • Modulul de MPISD se desfăşoarăpeparcursul a 7 intâlniri de curs şi 7 intâlniri de seminar pentrufiecaregrupă : • CURSURI: • Vineri, 5.10.2012 – orele 15.00 – 18.00 – sala 1201 - C1, C2 • Vineri, 12.10.2012 – orele 15.00 – 18.00 – sala 1201 – C3, C4 • Vineri, 19.10.2012 – orele 15.00 – 18.00 – sala 1201 – C5, C6 • Vineri, 26.10.2012 – orele 16.30 – 18.00 – sala 1201 – C7 • Pentruplanificareaseminariilorpegrupe, urmăriţiorarul. • Evaluare • Evaluarea se va face pebazaunuiexercitiu de grup, cevafipredat in ziuaexamenului. • Exercitiul se varealiza in grupe de 5 studenti, repartizati in ordinealfabetica. • Temaexercitiului: realizareaunuiproiect de investitiestrainadirectapentru o companieprezentapepiata din Romania pe o piatainternationala. • Nu existarestrictii cu privire la forma saudimensiuneaexercitiuluipredat in scris. Acestavatrebuisaacoperetoateinformatiilerelevantepentru un manager pentru a puteaimplementaproiectul. • Bibliografie • B Lientz, K P Rea – International Project Management, Butterworth Hienemann, 2003 • JC Binder - Global project management : communication, ollaboration and management across borders, Gower, 2007 • P Dinsmore, J Cabanis-Brewin – The AMA Handbook of project management, AMACOM, 2006 • B Solnik – International Investments, McGraw-Hill, Reading, MA, 2004 • A Horobeţ – Managementul riscului în investiţiile internaţionale, Editura AllBeck, Bucureşti, 2005 Detalii administrative

4. PARTEA 1: MANAGEMENTUL PROIECTELOR

5. 1.1: DefiniresiIstoric 1.2: Principiifundamentale 1.3 Etapa 1: Pregatireaunuiproiect 1.4 Etapa 2: Planificareaunuiproiect 1.5. Etapa 3: Implementareaunuiproiect 1.6. Proiecteglobale 1.7. ? STRucturapartii 1

6. Traditional Project Management Models • Defining, Organizing, Planning, Executing, Monitoring, Finishing • Purpose, Scope, Estimating, Budgeting, and Deadlines • Work breakdowns, Dependencies, Key Resources • Scheduling: PERT, CPM, GANNT • Reporting, milestones, adjustments The “Textbook account” of project management

7. Preparations for the project • Planning the Project • Managing the Project In-Progress Traditional Project Management Traditional PM Focus

8. Source: Dinsmore, 2006 Product vs project life cycles

9. Use structure to combat scale and complexity • Make future possibilities more predictable, foresee problems, develop contingency plans • Thoroughness – Checklists as a way of being sure • Forces us to confront things that are hard to think about in detail • Helpful even when the details don’t unfold if expected • Eisenhower: “The plan is nothing. Planning is everything.” • The danger… • Structure can become an end in itself • Obsession with documents, milestones • A distraction or, worse, a constraint on the ability to adjust The Idea Behind Formalizing PM…

10. Source: Dinsmore, 2006 Strategic model for managing projects

11. Define who is going to do what • Define roles and responsibilities • Identify people, resources; ensure their commitment to project • Identify a project leader, specify her/his authority and responsibilities • Important questions: • Who is the PM? What decisions are within PM’s area of authority? Is this authority sufficient to carry out the project? • Who is on team? Full-time or part-time? What are their areas of expertise? Their roles? • Who is the project sponsor? Is he or she at sufficiently high level in the organization to provide the project with support and a good chance of success? Creating a Project Organization

12. Source: Dinsmore, 2006 Project management process groups’ interactions

13. 1. Introduction/overview • 2. Mission and objectives • 3.Work scope • 4. Planning basis: deliverables, requirements, constraints, approaches, assumptions, exclusions • 5. Work breakdown structure • 6. Organization development plan • 7. Resource plan • 8. Procurement and logistics plan • 9. Logic and schedules • 10. Cost estimates, budgets, and financial management • 11. Risk analysis and contingency plan • 12. Quality and productivity plan • 13. Environmental, safety, and health protection plan • 14. Security plan • 15. Project planning, control, and administration plan • 16. Documentation and configuration management plan • 17. Appendix The project management plan

14. Make sure the proposed project is well understood an that all stakeholders agree on what it will accomplish • Clearly spell out expected outcomes, deliverables, objectives • Agree scope – what’s in, what’s not in • Document agreements formally, in writing, to surface/eliminate ambiguity in different stakeholders’ expectations • Important questions: • What is the scope? • What does the project need to accomplish? • By when? Defining the Project’s Objectives and Scope

15. A Formal Objective Statement • Short, simple language, unambiguous • Should Scope, Resources, and Schedule • A Famous Example: “Put a man on the moon and return him safely to Earth by the end of the decade at a cost of $9 billion.” • Scope – “Put a man on the moon and return him safely to Earth.” • Schedule – “By the end of the decade.” • Resources –”At a cost of $9 billion.” • The advantage in keeping it short and simple: Longer statements offer greater opportunity for people to come away with different understanding of what the project will accomplish while mistakenly assuming they have reached agreement Formal Objective Statement

16. What’s In/Out List • List 1: Things included in the work product • List 2: Things excluded from the work product • Work Product Example: A Business Plan • Is included: 30 pages + 10 pages of appendix, spiral bound, cover sheet with 300 word executive summary, one section must be financial projections, another must spell out marketing plans • Not included: Potential customer market segment analysis, a formal presentation What’s In/Out List for Project Work Products

17. Determine how the project will “operate” from day to day • Set norms for meetings, updates, communication • Establish “official” processes for logging, reviewing, updating progress on issues • Set norms and escalation procedures for disagreements and unresolved issues • Important questions: • What do we do when we encounter a new problem? • Who do we go to for help in making decisions? • How do we check progress on a known issue? Setting Up Project Norms

18. One of the most useful concrete tools in issue tracking • A running list of “open issues” • Log issue, assign priority and problem solving owner, current status, resources assigned to address • Revisit list on a regular basis (daily, weekly) The Humble Checklist

19. It’s a good idea to have a common collection point for all project documentation • Objective statements • Organization definitions and roles • Issue checklists • Etc. Project “Workbook”

20. Need to identify all of the work required by a project • Identify tasks and sub-tasks • Assign “owners” for each task • Estimate how long each task will take • Important questions: • Are all tasks identified? • Do all tasks have owners? • How long will it take to do each task? The Work Breakdown Structure

21. WBS – work breakdown structure

22. Work breakdown structure, or the WBS = hierarchical structure defining tasks that can be completed independently of other tasks, facilitating resource allocation, assignment of responsibilities, and measurement and control of the project.

23. Terminology for Different Levels • tasks, sub-tasks, and work packages • phases, entries, and activities. • Organization by Deliverables or Phases • deliverables or phases of the project life cycle. • higher levels in the structure generally are performed by groups. • lowest level in the hierarchy often comprises activities performed by individuals, • a WBS that emphasizes deliverables does not necessarily specify activities. • Level of Detail • facilitates resource allocation and the assignment of individual responsibilities. • ! Beware: micro-management OR tasks too large to manage effectively. • Defining tasks so that their duration is between several days and a few months works well for most projects.

24. The 100% rule states that • the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management. • The rule applies at all levels within the hierarchy: the sum of the work at the “child” level must equal 100% of the work represented by the “parent” and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work… • It is important to remember that the 100% rule also applies to the activity level. • The work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package. The 100% rule

25. You can create a WBS top down or bottom up • Top down – Start with largest work groupings and break into smaller and smaller pieces • Bottom up – Brainstorm specific low level tasks, group them into larger groupings Top down vs. Bottom up

26. Guestimates by task owners • Guestimates by a group, including experts who have “done this kind of work before” • Other group consensus processes • Statistical models that relate “size” of a project result to time and effort estimates • Suppose a project is expected to produce a software product with about 60,000 Lines of Code (written software) • According to statistical model: 60,000 Lines of Code translates into 200 person months of effort • 200 person days of effort = it’ll take 20 people 10 months, or 10 people 20 months (or 2 people 100 months, etc.) Estimating is done in many ways…

27. Frederick Brooks, author of The Mythical Man Month: “Adding more people to a late project makes it later” • “Adding more people to a late project helps less than you might think, and it helps less and less the more people you add ” -- 20 people for 10 months is not the equivalent to 10 people for 20 months (or 2 people for 100 months) – • The more people work on a project, the more overhead required to coordinate work (and the less spent on value-adding work) “Brooks’s Law” Overall Productivity Number of people

28. Given what you need to do, figure out when things will happen and when you’ll be finished (when you’ll deliver project results) • Identify dependencies between tasks (e.g., task A must be done before task B can be started) • Use task time estimates and dependencies to create a schedule, typically by generating a “Gantt Chart” • Important questions: • Have all dependencies been identified? • Is there a way to eliminate dependencies? • Does estimated completion fit with project objectives? Developing a Project Schedule

29. PERT – Program evaluation and review technique

30. 1957 - the Critical Path Method (CPM) was developed as a network model for project management. • a deterministic method that uses a fixed time estimate for each activity • does not consider the time variations that can have a great impact on the completion time of a complex project. • PERT = a network model that allows for randomness in activity completion times. • Assumptions to create the network diagram: • an activity is a task that must be performed and an event is a milestone marking the completion of one or more activities. • before an activity can begin, all of its predecessor activities must be completed. • project network models represent activities and milestones by arcs and nodes. PERT

31. Identify the specific activities and milestones. • Determine the proper sequence of the activities. • Construct a network diagram. • Estimate the time required for each activity. • Determine the critical path. • Update the PERT chart as the project progresses. Steps in the PERT Planning Process

32. a.  Identify Activities and Milestones • The activities are the tasks required to complete the project. • The milestones are the events marking the beginning and end of one or more activities. • It is helpful to list the tasks in a table that in later steps can be expanded to include information on sequence and duration. • b.  Determine Activity Sequence • This step may be combined with the activity identification step since the activity sequence is evident for some tasks. • Other tasks may require more analysis to determine the exact order in which they must be performed. • 3.  Construct the Network Diagram • You may use software for this step Steps in the PERT Planning Process

33. d.  Estimate Activity Times • Weeks are a commonly used unit of time for activity completion, but any consistent unit of time can be used. • For each activity, the model usually includes three time estimates: • Optimistic time - generally the shortest time in which the activity can be completed. It is common practice to specify optimistic times to be three standard deviations from the mean so that there is approximately a 1% chance that the activity will be completed within the optimistic time. • Most likely time - the completion time having the highest probability. Note that this time is different from the expected time. • Pessimistic time - the longest time that an activity might require. Three standard deviations from the mean is commonly used for the pessimistic time. • PERT assumes a beta probability distribution for the time estimates. For a beta distribution, the expected time for each activity can be approximated using the following weighted average: • Expected time  =  ( Optimistic  +  4 x Most likely  +  Pessimistic ) / 6 • This expected time may be displayed on the network diagram. • To calculate the variance for each activity completion time, if three standard deviation times were selected for the optimistic and pessimistic times, then there are six standard deviations between them, so the variance is given by: • [ ( Pessimistic  -  Optimistic ) / 6 ]2 Steps in the PERT Planning Process

34. e.  Determine the Critical Path • That sequence of tasks that are the “bottleneck” in the schedule • The critical path is determined by adding the times for the activities in each sequence and determining the longest path in the project. • The critical path determines the total calendar time required for the project. • If activities outside the critical path speed up or slow down (within limits), the total project time does not change. • The amount of time that a non-critical path activity can be delayed without delaying the project is referred to as slack time. • If the critical path is not immediately obvious, it may be helpful to determine the following four quantities for each activity: • ES - Earliest Start time • EF - Earliest Finish time • LS - Latest Start time • LF - Latest Finish time Steps in the PERT Planning Process – critical path

35. ES - Earliest Start time EF - Earliest Finish time • LS - Latest Start time LF - Latest Finish time • These times are calculated using the expected time for the relevant activities. • The earliest start and finish times of each activity are determined by working forward through the network and determining the earliest time at which an activity can start and finish considering its predecessor activities. • The latest start and finish times are the latest times that an activity can start and finish without delaying the project. LS and LF are found by working backward through the network. • The difference in the latest and earliest finish of each activity is that activity's slack. • The critical path then is the path through the network in which none of the activities have slack. Steps in the PERT Planning Process – critical path

36. Source: syque.com Critical path - example

37. The variance in the project completion time can be calculated by summing the variances in the completion times of the activities in the critical path. • Given this variance, one can calculate the probability that the project will be completed by a certain date assuming a normal probability distribution for the critical path. • The normal distribution assumption holds if the number of activities in the path is large enough for the central limit theorem to be applied. • Since the critical path determines the completion date of the project, the project can be accelerated by adding the resources required to decrease the time for the activities in the critical path. • Such a shortening of the project sometimes is referred to as project crashing. Steps in the PERT Planning Process – critical path

38. The results of this process for arriving at a project schedule are often poorly received • “That project completion date is far too late!” • So a “what if” exercise ensues • To shorten a project’s overall duration (to be “done” sooner), you must shorten tasks on the Critical Path (“What if task 14, on the critical path, could be done faster?) or remove tasks from the Critical Path (Does task 15 really depend on task 14 – what if we can, by making an adjustment, do them at the same time, thus moving task 14 off the Critical Path?) • Sometimes when you shorten the Critical Path, a different sequence of tasks becomes the new Critical Path (the “bottleneck” shifts) – that is, you’ve shortened the old Critical Path to a point where it is no longer the Critical Path Critical Path “What If” Analysis

39. f.  Update as Project Progresses • Make adjustments in the PERT chart as the project progresses. As the project unfolds, the estimated times can be replaced with actual times. In cases where there are delays, additional resources may be needed to stay on schedule and the PERT chart may be modified to reflect the new situation. Steps in the PERT Planning Process

40. Benefits • Expected project completion time. • Probability of completion before a specified date. • The critical path activities that directly impact the completion time. • The activities that have slack time and that can lend resources to critical path activities. • Activity start and end dates. • Limitations • The activity time estimates - subjective and depend on judgement. • Even if the activity times are well-estimated, PERT assumes a beta distribution for these time estimates, but the actual distribution may be different. • Even if the beta distribution assumption holds, PERT assumes that the probability distribution of the project completion time is the same as the that of the critical path. • Because other paths can become the critical path if their associated activities are delayed, PERT consistently underestimates the expected project completion time. • The underestimation of the project completion time due to alternate paths becoming critical is perhaps the most serious of these issues. To overcome this limitation, Monte Carlo simulations can be performed on the network to eliminate this optimistic bias in the expected project completion time. pert

41. The results of this process for arriving at a project schedule are often poorly received • “That project completion date is far too late!” • So a “what if” exercise ensues • To shorten a project’s overall duration (to be “done” sooner), you must shorten tasks on the Critical Path (“What if task 14, on the critical path, could be done faster?) or remove tasks from the Critical Path (Does task 15 really depend on task 14 – what if we can, by making an adjustment, do them at the same time, thus moving task 14 off the Critical Path?) • Sometimes when you shorten the Critical Path, a different sequence of tasks becomes the new Critical Path (the “bottleneck” shifts) – that is, you’ve shortened the old Critical Path to a point where it is no longer the Critical Path Critical Path “What If” Analysis

42. With tasks and dependencies identified, assign people and other resources (e.g., specialized equipment) to tasks • Allocate resources across tasks • Make sure resources available can cover tasks • Make sure key there are no conflicts for key resources (same person/machine can’t be two places at once) • Analyze the merits of different ways of allocating resources • Re-examine scope, schedule, and resources • Important questions: • Is work spread reasonably across resources? • Should we make adjustments to scope, schedule, or resources? • Assigning more resources is one way of shortening the CP Assigning Project Resources

43. A very common problem: Some resources are over allocated while others are under allocated • People working on some tasks are overwhelmed, while others have nothing much to do • Over allocated resources end up being asked to multi-task • Literally, work on more than one task at once • Their time gets allocated in smaller and smaller fractions • But there are big hidden costs in doing this… • Switching tasks takes effort • People work more hours • Burn out, morale issues • Worst for key people Key Resources and “Switching Cost” Value-add time on each task Number of tasks

44. The gantt chart – example a shedule

45. The gantt chart – an excel example

46. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. • Terminal elements and summary elements comprise the work breakdown structure of the project. • Some Gantt charts also show the dependency (i.e., precedence network) relationships between activities. • Pitfalls: • Attempt to define the project work breakdown structure at the same time that they define schedule activities.  the WBS should be fully defined to follow the 100% Rule, then the project schedule can be designed. • Difficult to grasp for projects with more than 30 activities • The equal horizontal dimension of activities does not take into consideration the resource load of each activity Gantt charts

47. With tasks, CP, and resource assignments in place, you are positioned to make explicit planning tradeoffs • Analyze the impact on schedule of different feasible allocations of available resources • Determine impact on schedule and budget of adding (or subtracting) resources (keeping in mind Brooks’s Law) • Determine impact of changes in project scope • Important questions: • Are schedule and cost consistent with project objectives? • If not, can they be made so? • Or should we change the objectives? • Can we eliminate dependencies by working differently? • Are we trying to do too much? Making Tradeoffs

48. In considering scope, resource, and schedule tradeoffs, often the question of how you might “chunk” the project comes up • What if we divide this project into smaller projects? • Can improve fit between available resources and schedule • Might allow most important objectives to be delivered sooner, at the cost of waiting longer for some other, less important objectives • Can also have budget implications – dividing a project up into smaller chunks can make it appear more expensive • Although it can sometimes turn out cheaper if the smaller projects have fewer problems than the big one would have… • Which brings us to… Project Structure – How many “chunks”?

49. As much as possible during planning stages of a project, draw attention to project risks and develop plans for managing them. • Identify likely sources of risk • Develop plans to minimize probability that risks will materialize • Might result in new tasks being identified, which will require additional resource requirements • Develop plans to minimize impact if risks do materialize • Important questions: • Have we identified all the risks we can? • Which should we worry most about (because the are very likely or would have major impact on the project)? Planning for Project Risks

50. There is a relationship between project structure and risk • In general, larger projects involve greater risks than a series of smaller projects (smaller projects are less complex and constitute smaller failures even when something does go wrong) • An additional advantage in “chunking” large projects into smaller ones: Can incorporate learning from early chunks into later chunks • Certain projects have characteristics that make risks harder to anticipate and make smaller chunks more beneficial • If project outcomes are difficult to specify in advance (thus must be “discovered” to some extent – such as when a user of a product can’t easily envision how the product might be used differently) • If project objectives are likely to change while the project is in progress (due to changes in technology, moves by competitors, etc.) Project Structure and Risk