project design

1. Component 4: Project initiation
process

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. 1. How do projects come about?

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. • 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. • 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. 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. • 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. • 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. • 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. • Economic feasibility
• Level of savings
• Level of investment
• Costs of benefits
• Level of employment
• Forex earnings( forex exchange)
• Production capacity
• Pricing policy

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. 2. Develop the project charter

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. • 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. 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. • 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. • 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. 3.Project scope statement

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. • 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. • 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. • 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. • 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. • 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. • 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. • 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. • 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. • 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. • 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. 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. • 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. • 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. • 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. • 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. • 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. • 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. • 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. 4. Creating the Work Breakdown Structure

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. • 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. An example of WBS

43. 5. Logical framework

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