Successfully reported this slideshow.
Your SlideShare is downloading. ×

Component 4 project iniation process.pdf

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
fundraising training.pptx
fundraising training.pptx
Loading in …3
×

Check these out next

1 of 46 Ad

More Related Content

Advertisement

Component 4 project iniation process.pdf

  1. 1. Component 4: Project initiation process
  2. 2. Indicative content • In this section we will discuss about five important aspects: • 1. How projects come about? • 2. Project charter • 3. Project scope statement • 4. Creating the Work Breakdown Structure 5. Logical Framework of the project
  3. 3. 1. How do projects come about?
  4. 4. 1.1. Origin of new project • A new project can emerge from a visit, an brainstorming in an ordinary meeting or even from an insight. • A project can also result from the extension of existing project, the opportunity created by a new policy, or just from the availability of funds from external suppliers... • Project initiation is the formal recognition that a project or the next phase in a existing project should begin and resources should be committed to the project. • According to the PMBOK, profit oriented project come about as a result of one of six needs or demands: • a) Market demand: the demand of the market place can drive the need for a project. For example, the pressure from customers to speed up bank operations conducted same banks in Rwanda to initiate the use of electronic cards (ATM).
  5. 5. • b) Business demand: the increasing of bank transactions from members of African Diaspora with African continent drove many banks to adopt systems such as western union, money gram, etc… • c) Customer request: generally speaking most companies have customers and their request can drive to new projects. E.g.: Request from young customers were at the origin of the development of MP3, and at the origin of the introduction music and movies programmes in cell phone. • d) Technical advance: In theses times of ICT revolution, there is always a newer, better version of software coming to market. E.g. Electronic registration at U.R.
  6. 6. • e) Legal requirements: private industries and governmental agencies both generate new projects as a result of law passed every legislative season. • Example: the requirement that food labels appear on every package describing ingredients and the recommended daily allowance. • f) Social demand: an new project can also result from a social demand. • Example: The persistent observation of fast spreading diseases such as cancer led recently to a new project of vaccination of girls from twelve years old in Rwanda.
  7. 7. 1.2 Feasibility studies (see first component) • After the opportunity for a project become evident, the next step might be to go ahead and initiate it, which means you are ready to jump right into creating a charter for the project. • Before you take that plunge, you should know that some organizations will require a feasibility prior to making a final decision about starting the new project. • Feasibility studies are undertaken for several reasons: • One is to determine if the project is viable; • A second reason is to determine the probability of the project to succeed; • Feasibility can also examine the viability of the product to be produced. •
  8. 8. • In a context of dependence to external funds, good feasibility study can be also interpreted as a source of credibility and external legitimacy. • Feasibility studies may be conducted as separate projects, as subprojects, or as the first phase of the life cycle of the project. • Normally, those who are involved in conducting the feasibility study should not be the same ones who will work on the project. • This is because project team members can be interested in maintaining their positions and salaries than making needed changes and therefore may tend to influence the feasibility outcome.
  9. 9. • There is five types of feasibility studies: • A)Technical Feasibility involves • Materials and inputs • Production technology/appropriate technology • Product mix-4ps: price, product( good, service), place (distribution channels) and promotion • Plant capacity (include; Feasibility, availability capacity) • Location site • Machinery/ equipment( electrical, mechanical, processing equipments) • Structures and civil works like parking yards, fence, flower gardens, stores and garages)
  10. 10. • B) Financial Feasibility involves: • Cost of project • Sources of budgeting/means of financing: grants, shares, loans, donations, savings…. • Cost of capital-interest on borrowed money • Profitability • Tax (e.g. VAT), • Financial projections ( e.g. cash flow, income)
  11. 11. • Economic feasibility • Level of savings • Level of investment • Costs of benefits • Level of employment • Forex earnings( forex exchange) • Production capacity • Pricing policy
  12. 12. • Political feasibility • Government programs, policies • Legal frame work-laws,-regulations etc • Market Feasibility • Market share • Aggregate demand i.e. who are you targeting • Supply and competition • Imports and exports • Consumer preferences and attitudes • Market policies
  13. 13. 2. Develop the project charter
  14. 14. • The development of the project charter is to formally authorize the project to begin and committing resources. • The project charter is the official written acknowledgement and recognition that a project exists. • It ties the work of the project with the ongoing operations of the organization. • The charter documents the business or demand that the project was initiated to address, the project justification and it includes a description of the product or the service to be delivered.
  15. 15. • According to the Guide of PMBO, in order to create a useful and well documented project charter, you should include at least these elements: - Purpose or justification of the project; - Business justification of the project including return on the investment analysis; - Requirement that must be completed satisfactory according to the stakeholders, sponsors and customers expectations; - Stakeholders and other departments implication and the level of participation needed ; - Assumptions, constraints, milestone schedule, budget summary… - Project team including the name of the manager and their authority levels; - Many of these elements are defined in details in the following section.
  16. 16. The project charter sign-off • The project charter is not complete until you have received sign-off from the project sponsor, senior management and key stakeholders. • Sign-off indicates that the document has been read by those signing it (lets hope so anyway) and that their agree with its content and are on board with the project. • It also involves the major stakeholders right from the beginning and hopefully wins their continued participation in the project going forward. • If some one has a problem with any of the elements in the charter, now it is the time to raise his concern.
  17. 17. • One of the thing to do prior to publishing the charter is to hold a kick-off meeting with key stakeholders to discuss the charter and to obtain their support to the project. • Even if the guide to the PMBOK does not bring stakeholders into the picture until the planning process begins, it is imperative to identify key stakeholders as soon as possible and involve them in the creation of the project charter and the preliminary scope statement, so that they can provide their inputs before signing the project charter. • Signing the project charter document is the equivalent of agreeing to and endorsing the project. But this does not mean that project charter is not written in the stone. • As more details are uncovered and outlined and as the planning begins, more project issues will come to light. •
  18. 18. • The charter will occasionally be revised to reflect these new details, project plans will be revised and project implementation will change to incorporate the new information and direction. • The last step in this process is publishing the charter. This simply means distributing a copy of the project charter to the key stakeholders, the customers, the management team and others who may be involved within the project. • At this step, publishing the project charter can take several forms, including printed format or electronic format distributed via the company e-mail system or on the company’s intranet.
  19. 19. 3.Project scope statement
  20. 20. • After this first step, the project is officially under way as stakeholders have been informed, the project manager has been assigned and the project objectives and description have been identified. • If the project charter is presented as a brief overview of what will be done, the purpose of this second step- the project scope statement- is to document the project objectives, deliverables and requirements so that they can be used to direct the project team’s work and as a basis for future project decisions. • The scope statement is an agreement between the project initiator and the project customer that states precisely what the work of the project will produce.
  21. 21. • Simply put, the scope statement tells everyone concerned with the project exactly what they are going to get when the work is finished. • According to the guide to the PMBOK, project scope statement provide all stakeholders with a fundamental understanding of the content of the project. • It elaborates the work of the project and guides the activities initiated by the project team during the executing process. • Therefore, all change request will be evaluated against the scope statement.
  22. 22. • If the change request is outside the bounds of the project scope, it should be denied or call for new official agreement. • Since the scope statement serves as a baseline for the project, if questions arise or changes are proposed later in the project, they can be compared to what is documented in the scope statement. • Making change decisions is easier when the original deliverables and requirements are well documented. • The criteria outlined in the scope statement will also be used to determine if the project was completed successfully.
  23. 23. • According to Heldman (2003; 2009), the project scope statement should include the following elements: • Objectives of the Project • Product s scope description • Product acceptance criteria • Project deliverables • Project requirements • Project boundaries • Project exclusions • Project constraints • Project assumptions • Approval Requirements
  24. 24. • 3.1. Defining the objectives of the Project Objectives are quantifiable criteria used to measure project success. • Their describe the what the project team is trying to do, accomplish or produce. • In this sense, project objectives are used as measurements to determine satisfaction and successful completion. • The definition of the objectives should follow the smart rule: • S- Specific: objectives should be specific and written in clear, concise and understandable terms . • M-Measurable: objectives should be measurable and if possible by using recognized standards. • A-Accurate: objectives should describe precisely what is required. • R-Realistic and tangible: objectives that are impossible to accomplish are not realistic and not attainable. They must be centered to reality. • T-Time bound: objectives should have a time frame with an end date assigned to them.
  25. 25. • 3.2. Product scope description • The product scope description is crucial especially for industrial projects. It describes the characteristics of the product or service of the project. • If the product scope description is contained in the project charter, you can reference the project charter in the project scope statement. • A even better idea is to copy and paste the information from the project charter into the project scope statement. • Discussion: What about product scope description in social project ?
  26. 26. • 3.3. Project deliverables • Deliverables are measurable outcomes, measurable results, or specific items that must be produced to consider the project phase completed. • Deliverable like objectives must specific and verifiable. • Most project have multiple deliverables (e.g. separate parts of an industrial product before their assemblage in order to constitute the entire product to be furnished to customers). • Deliverables and objectives are sometimes referred to as critical success factors. • Critical success factors are those elements that must be completed in order for the project to be considered as complete.
  27. 27. • For example, if you are building a bridge, one of the deliverables might be to produce a specific number of trusses (ties) that will be used to help support the bridge. • Without the trusses, the bridge cannot be completed. As the bridge might not stand without them, trusses are critical success factors. • Not all deliverables are necessarily critical success factors, but many of them will fall into this category and should be documented as such.
  28. 28. • 3.4. Product requirements • After all the deliverables are identified, the project manager needs to discover and document all the requirement of the project. • Requirement describe the characteristics of the deliverable • They may also describe functionality that the deliverable must have or specific conditions the deliverable must meet in order to satisfy the objective of the project. • According to the guide to PMBOK, requirements are conditions that must be met or criteria that the product or service of the project must possess in order to satisfy the project documents, a contract, a standard or a specification.
  29. 29. • For industrial project ,requirements may include things like dimensions, ease of use, color, specific ingredients etc. • For unquantifiable project like training, requirements may include the qualification of the trainers and trainees, the description of the module to be taught, evaluation standards, etc.
  30. 30. • 3.5. Project boundaries/ Project exclusions • Project boundaries define what is and what is not included in the work of the project. • In the scope statement, some state by excluding what is not covered by the project. 3.6. Product acceptance criteria • Product acceptance criteria include the process and the criteria that will be used to determine if the deliverable and the final product or service of the project are acceptable and satisfactory. •
  31. 31. 3.7. Project constraints • Constraints are anything that either restricts the actions of the project team or dictates the actions of the project. • Constraints put you in box (hope you are not claustrophobic (Heldman, 2005). • In many project managers work within the triple constraint combination of scope, time, and cost. • Time constraint usually comes in the form of an enforced deadline commonly known as the “make it happen now” scenario. • Budget constraint limits the project team’s ability to obtain resources and might potentially limit the scope of the project. • Scope constraint limits the ability of managers to include some crucial activities in the project. In external founded project, we usually hear comment like this: “ Please the component X cannot be part of the project because the budget supplier do not include it in its priorities”. •
  32. 32. • But experience from project managers show that constraints are not limited to time, budget and scope and can take on many forms: • Quality constraint: while the guide to PMBOK does not list quality as a constraint, in practice restricted specifications of the product or service can often be a constraint. • Most of time, one of the other constraints (time and budget) intervenes in the determination of the quality. • It is difficult to produce high quality on a restricted budget and within a tightly restricted time. • One of the most popular says on this aspect is: I can give it to you fast or I can give it to you cheap, but I cannot give it to you fast and cheap.
  33. 33. • Schedule constraint: • Schedule constraints can cause interesting dilemmas for the project manager. This generally happen when the project manager need to use a product from another company, while its operators are not ready to furnish the needed product on time. In such context, your project plan will call for adjustment due to external constraint. • Technology constraint: • Technology is a marvelous thing that facilitate the implementation of planned work, but it can be also a constraint. • For example, your project might require the use of a technology that is still new, as it has not been released on a wide-scale basis. • One impact might be that the project will take an additional six months because the new technology is not ready or has not been well tested before being extended to a wide range of activities.
  34. 34. • Directive constraints: • Directive from management can be constraints as well. Your department may have specific policies that management requires for the type of work you are about to undertake. • This may add time to the project, so you must consider those policies when identifying project constraints. • Sometimes you may face contradicting directives from powerful stakeholders (see example). • Constraints, particularly the triple constraints, can be used to help drive out the objectives and requirements of the project.
  35. 35. • If it is difficult to discern which constraint is the most important for the project ask the project sponsor something like this: Mr. X if you could only have one of these two alternatives, which could you choose? • “The product is delivered on the date you have stated, or the quality is manufactured to the exact specifications you have given”. • If He replies with the date response, you will conclude that your primary constraint is on time. If, He replies with the quality response you will conclude that your primary constraint is no on time but on quality aspects. • Briefly, understanding the constraints and which one carries the most importance will help you out later on in the project planning process.
  36. 36. • 3. 8. Project assumptions • Assumptions, for the purposes of project management, are things you believe to be true. • For example, if you’re working on a large construction project, you might make assumptions about the availability of materials and reasonably priced. • You might also assume that finding contract labor is either easy or difficult, depending on the economic times and the availability of labor in your locale context. • Each project will have its own set of assumptions, and the assumptions should be identified, documented, and updated throughout the project.
  37. 37. • Projects can fail, sometimes after lots of progress has been made, because an important assumption was forgotten or the assumption was incorrect. • Defining new assumptions and refining old ones are forms of progressive elaboration. • Briefly, when defining your project assumptions, think about some of the factors you usually take for granted. Many times they’re the elements everyone expects will be available or will behave in a specific way. • Think about factors such as key team members’ availability, access to information, access to funds, access to equipment, management support ...
  38. 38. • 9. Approval Requirements • Approval requirements are not an official component of the scope statement according to the PMBOK® Guide, but Heldman (2009) recommend to know something about them as approval requirements refer to how the objectives, deliverables, project management documents, and other outcomes and results of the project will be approved. • According to Heldman (2009), this is different from product acceptance criteria—that element describes how the product itself will be approved, whereas this element describes the requirements that must be met in order to approve the deliverables. • An example product acceptance criteria might be “All widgets must measure three inches.” A deliverable approval requirement might be that the director of sales must approve a prototype before the project can proceed. • This section might also contain the process and approval requirements of the project scope statement.
  39. 39. 4. Creating the Work Breakdown Structure
  40. 40. • Creating the Work Breakdown Structure • The work breakdown structure (WBS) maps the deliverables of the • project with subdeliverables and other components stemming from each major deliverable in a chart format. • The PMBOK® Guide describes a WBS as “a deliverable-oriented • hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables… • In this perspective, the WBS defines the total scope of the project. • Thus, a WBS is a deliverable-oriented hierarchy that defines, organizes and sometimes schematize the work of the project in a table. • Like the scope statement, the WBS serves as a foundational agreement among the stakeholders and project team members regarding project scope.
  41. 41. • The WBS should detail the full scope of work needed to complete the project. • This breakdown will smooth the way for estimating project cost and time, scheduling resources, and determining quality controls later in the Planning processes. • Project progress will be based on the estimates and measurements assigned to the WBS segments. • So, again, accuracy and completeness are required when composing your WBS.
  42. 42. An example of WBS
  43. 43. 5. Logical framework
  44. 44. • Normally all strategic actors have no time to read all the content of the project. • Some of them goes to the logical framework that can be state here as a summary of the WBS. • Basic Principles; • •1. The Logical Framework should be concise. It should not normally take up more than two sides of paper. • 2. The Logical Framework should be treated as a free-standing document and should be comprehensible to those coming to it for the first time. Acronyms should therefore be avoided. • 3. If beneficiaries are included in the project, they should also take part in the design of the Logical Framework. • 4. The Logical Framework will provide a basis for subsequent monitoring and evaluation. It must therefore be kept under regular review and amended whenever the project changes course.
  45. 45. Example of LFW Hierarchy of Aims Objectively verifiable indicators at the beginning (input) Expected verifiable indicators at the end of the project (output) Means of Verification Risks & Assumptions Responsible of each activity Strategic objective 1 Specific objective 1 1 Activity 1 Activity 2 Specific objective 1 2 Activity 3 Activity 4 Strategic objective 2 Specific objective 21
  46. 46. • Objectively Verifiable Indicators :These are the measures, direct or indirect that will verify to what extent the objectives have been fulfilled. The term objectively implies that if these should be specified in a way that is independent of possible bias of the observer. • Means of Verification :These statements specify source of the information or the measurements or verification specified in the indicators column. • Assumptions:/Risks These are important events, conditions, or decisions which are necessarily outside the control at the project, but which must remain favorable/ controlled for the project objective to be attained. • Strategic objective :The higher level objective that the project is expected to contribute to. • Specific objective :The effect which is expected to be achieved as the result of a specific activities. There is a tendency for this to be expressed in terms of the change in behavior‘ of a group, or institution and the project outputs are expected to facilitate this change. • Activities: These are the activities that have to be undertaken by the project to produce the outputs. • Outputs: These are the tangible results that the project management team should be able to guarantee delivering. • Inputs: These are the resources that the project ―consumes‖ in the course of undertaking the activities. Typically they will be human resources, money, materials, equipment, and time. • Good LFWs clarify the situation (problem) at the beginning of the project so that these indicators can be compared to the outputs at the end of the project.

×