Lecturer-2 Project Initiation

Project Initiation and Planning
11-Sep-14 1 Facilitator: Amed Salman Imtiaz, IPED, SUST

Project Phases
Project Initiation

The Initiation Phase is the first phase in the project. In this phase a
business problem (or opportunity) is identified and a business case
which provides various solution options is defined.
A feasibility study is then conducted to investigate the likelihood of
each solution option addressing the business problem and a final
recommended solution is put forward.
Once the recommended solution is approved, a project is initiated
to deliver the approved solution. A Terms of Reference is
completed, which outlines the objectives, scope and structure of
the new project, and a Project Manager is appointed.
The Project Manager begins recruiting a project team and
establishes a Project Office environment.
Approval is then sought to move into the detailed planning phase.
The output of the first phase is a document called a charter.

Project Charter
1 Why is the project required?
2 What are we trying to
achieve?
3 What are the deliverables?
4 What is the anticipated cost?
5 How long will it take to
complete?

The direction and constraints for the project are outlined in a document
called the charter.
The project charter is an official, written document that acknowledges and
recognizes that a project exists.
It's usually published by the project sponsor but can also be published by
another upper-level manager.
It's important that the charter be published by a senior-level manager since
it gives more weight and authority to the document and it demonstrates
management's commitment and support for the project.
The project charter usually comprise the answers of the following
questions:
7 What are the performance
criteria?
8 What are Key Performance
Indicators(KPI)?
9 What are the main risks?
10 What are success criteria?
11 Who are the main
stakeholders?

Purposes for the Charter
The primary purpose of the project charter is twofold: It acknowledges that the project
should begin and it assigns the project manager. Let's look a little closer at all the project
charter purposes.
Acknowledges that the project should begin The charter announces to all the stakeholders
that the project has received approval and been endorsed by upper management. It serves
as official notification to the functional business units that their cooperation is needed and
expected.
Commits resources to the project The project charter commits the organization's resources
to the work of the project. This includes time, materials, money, and human resources.
Ensures that everyone is on the same page When the purpose, objectives, and an overview
of the project are written down and agreed upon, everyone understands the purpose from
the beginning and confusion is eliminated.
Appoints the project manager The project charter serves as the official notification and
appointment of the project manager. The project sponsor formally assigns authority and
responsibility for the project to the project manager. This means that stakeholders are put
on notice that the project manager will soon be requesting resources from their areas.
Provides an overview of the project and its goals The project charter is the first detailed
stab at describing the project purpose, overview, goals, and high-level deliverables. While
the concept document covered some of these things in a high-level fashion, the project
charter goes into more detail.

Essential Elements of a Project Charter
The following elements should be contained in a project charter:
Project overview The overview includes the purpose of the project and also explains the
reason for undertaking the project. It should also describe the product or service of the
project and reference the product description. A copy of the product description should be
attached to the project charter.
Project objectives Project objectives should include the factors that help determine whether
the project is a success.
Business justification Its recommended to state the justification of selected the project from
the business point of view in the project charter. This includes describing the benefits to the
organization of taking on the project and the impacts to the organization if it doesn't.
Resource and cost estimates If the initial cost estimates are made, then these can be
included in this section. This section might include the cost of the feasibility study if one was
conducted and the costs of the proposed alternatives.
Roles and responsibilities Roles and responsibilities, with the names of the participants
under each title, should be stated clearly in the project charter
Sign-off This section is very important. Space, for signatures from the project sponsor, key
stakeholders, senior management, customers, and anyone else appropriate for this project,
need to be allocated in a project charter.
Attachments Any other documentation that will help clarify the project, including the
product description and the feasibility study, should be attached to the project charter.

Holding the Project Kickoff Meeting
The purpose of the kickoff meeting is to accomplish verbally what you
accomplished in writing, that is, communicate the objective and
purpose of the project, gain support and the commitment of resources
for the project, and explain the roles and responsibilities of the key
stakeholders.
The following agenda are generally dealt during such meeting:

The first thing to do is introduce all the key players in the meeting,
even if these folks have all worked together for quite some time.
Next the project overview, including project purpose and objectives,
should be described to all the stakeholders.
Now the roles and responsibilities of all the stakeholders should be
communicated and discussed. Its need to be made sure that everyone
leaves the meeting understanding what's required of them during the
course of the project.
The closing agenda item for this meeting is a question and answer
session. Everyone should be allowed to have the opportunity to voice
their questions and concerns.
Project Planning
Project planning is perhaps the most important activity of any project. A lack of
proper and thorough planning will rapidly become obvious as the project moves into
the subsequent phases. As a result, much time and energy must be dedicated to
this activity.

Planning any activity requires careful thought and preparation. Before stepping into
action, be sure that you can answer the following questions:

1. WHAT are you planning to do?
2. WHY do you want to do this project?
3. WHEN and WHERE will the activity take place?
4. WHO will benefit from the project?
5. WHAT staff members(s) will need to approve the project?
6. WHAT funds are needed?
7. WHEN will the basic planning be done?
8. WHAT committees are necessary?
9. WHAT kind of publicity is needed?
10. WHO deserves a special thank you?
11. WAS the project worthwhile?
12. WHATS next? WHERE do we go from here?

Project Planning
Project planning:
identifies specific community problems that stand in the way of meeting
community goals
creates a work plan for addressing those problems and attaining the goals
describes measurable beneficial impacts to the community that result from the
projects implementation
determines the level of resources or funding necessary to implement the project

Why is project planning important?
The success and sustainability of a project is very closely tied to its planning
process. Projects often fail due to poor planning, many times because they do not
define the problems well or take important factors into consideration such as the
needs and views of everyone involved in and affected by the project. Effective
planning provides detail and structure to project work plans and establishes a way
to continue the project after the grant funding ends, meaning it is sustainable.
Project Planning
Project Planning helps us to:
think ahead and prepare for the future
clarify goals and develop a vision
identify issues that will need to be addressed
choose between options
consider whether a project is possible
make the best use of resources
motivate staff and the community
assign resources and responsibilities
achieve the best results
There are four basic reasons for project
planning:
To eliminate or reduce uncertainty
To improve efficiency of the operation
To obtain a better understanding of the
objectives
To provide a basis for monitoring and
controlling work
Planning Phase
1. Define an orderly arrangement of activities and resources to deliver the
product or service.
2. Begin by outlining all tasks (the work)
3. Identify the resources (people, hardware, software, services, etc.)
required for all tasks
4. Organize the tasks into sequences of chronological events (schedule)
5. Develop a spending plan within the budget
5. Arrange to procure external resources
6. Identify all stakeholders and the method (how), frequency (how often),
and content (what) of communications to them
7. Analyze risks and decide what can be done about them
Accept, Mitigate, or Transfer
8. Determine how to measure success

Output of Planning Phase Project Plan

Project Planning
Depending on complexity, project plans can contain:

1. Work Breakdown Structure
2. Resource Breakdown Structure
3. Schedule
4. Budget and Spending Plans
5. Performance Plan
6. Risk Management Plan
7. Procurement Plan
8. Communications Plan
9. Change and Configuration Management Plan
10. Quality Management Test Plan
11. Quality Management IV&V Plan

The Project Plan is used to guide project execution and project
control.

Project Planning
Step 1: Project Goals
A project is successful when the needs of the stakeholders have been met. The best way
to do this is by conducting stakeholder interviews. Take time during the interviews to draw
out the true needs that create real benefits. The next step, once you have conducted all
the interviews, and have a comprehensive list of needs is to prioritize them. From the
prioritized list, create a set of goals that can be easily measured. Once you have
established a clear set of goals, they should be recorded in the project plan.
Step 2: Project Deliverables
Using the goals you have defined in step 1, create a list of things the project needs to
deliver in order to meet those goals. Specify when and how each item must be delivered.
Add the deliverables to the project plan with an estimated delivery date. More accurate
delivery dates will be established during the scheduling phase, which is next.
Step 3: Project Schedule
Create a list of tasks that need to be carried out for each deliverable identified in step 2.
For each task identify the following:
The amount of effort (hours or days) required to complete the task.
The resource who will carryout the task.
Once you have established the amount of effort for each task, you can workout the effort
required for each deliverable, and an accurate delivery date. Update your deliverables
section with the more accurate delivery dates.

Practical Approach to Project Planning.
Step 4: Supporting Plans
This section deals with plans you should create as part of the planning process.
These can be included directly in the plan.

Human Resource Plan
Identify by name, the individuals and organizations with a leading role in the
project. For each, describe their roles and responsibilities on the project.
Next, describe the number and type of people needed to carryout the project.
For each resource detail start dates, estimated duration and the method you
will use for obtaining them.

Communications Plan
Create a document showing who needs to be kept informed about the project
and how they will receive the information. The most common mechanism is a
weekly or monthly progress report, describing how the project is performing,
milestones achieved and work planned for the next period.

Step 4: Supporting Plans
Risk management is an important part of project management. Although often
overlooked, it is important to identify as many risks to your project as possible,
and be prepared if something bad happens.
Here are some examples of common project risks:
Time and cost estimates too optimistic.
Customer review and feedback cycle too slow.
Unexpected budget cuts.
Unclear roles and responsibilities.
Stakeholder input is not sought, or their needs are not properly understood.
Stakeholders changing requirements after the project has started.
Stakeholders adding new requirements after the project has started.
Poor communication resulting in misunderstandings, quality problems and
rework.
Lack of resource commitment.
Risks can be tracked using a simple risk log. Add each risk you have identified
to your risk log; write down what you will do in the event it occurs, and what you
will do to prevent it from occurring. Review your risk log on a regular basis,
adding new risks as they occur during the life of the project. Remember, when
risks are ignored they don't go away.

1. Aim of Project
What do we want to produce? The aim of the project is a mixture of the reasons
for doing the project and the benefits that are expected from it. This section of
the plan can be either fulfilled by linking to the main business case, or by
restating it in language for the expected audience. For example, your business
case may have been written for high level approval in your organisation. You
may want to now put it in terms the project executive expects.
2. Outputs
Given the aim of the project, what do we actually need to produce to get there?
What will your completed project be made up of? These need to be clearly
defined. For example, your project's aim may be to upgrade the IT
infrastructure in an organisation. Your final output would be a completed
computer network, a new computer on every desk, and all appropriate software
installed and ready to go.
Essential Elements of Project Planning.
3. Quality Criteria
Now we have the outputs, we need to understand what quality they need to be of.
This means we need the completed output to be of a certain quality, and we need
to define what that quality is. These targets tell you what success is, what
completion of the project is. They need to be SMART:
Specific: Clearly defined and precise.
Measurable: e.g. not "new computers," but "computers with 2Gb of memory," etc.
Attainable: Don't ask for the impossible.
Relevant: Is the criterion actually related to the aim of the project?
Time-based: Enough time to achieve this. There is no point expecting a year's
worth of work in one week!
It is important you take some time with the stakeholders in your project to produce
this list. The final customer of the project will naturally be very involved, but don't
forget your business head - don't promise everything without considering the
costs. Your project executive, and a representative of those who will be doing the
work, will have major inputs into this also.
Finally, you will also need to decide who has the final say over the quality of the
outputs. Hopefully your work on defining the quality criteria will mean there are no
arguments over the quality (i.e. no qualitative judgements, only quantitative) but
you need to make sure you schedule in time and people to do the evaluation
work.
4. Resources
We have now set down what outputs we need to produce, and what quality they need to be
at. This means we are now in a position to look at the resources we will need to achieve
this. Resources include staff time, particular knowledge or skill sets, money (e.g. buying
equipment), and time (some tasks can't be increased by throwing more people at the
problem, e.g. delivery times, setting time for concrete, etc.).
5. Management Structure
How are we going to manage the work? You need to describe the general approach to the
project here. Who will be the decision makers for the various different streams of work? For
example, you may be doing a significant procurement - who makes the decision about what
company to buy from?
How will we share progress on the project? Who will we share it to? For example, you may
decide to have regular project team meetings - who needs to attend? What level of
information will you be sharing? Who else needs to be kept informed, at what level of detail,
and how often? For example, you may want to keep the project executive updated at an
overview level of detail on a weekly basis, while you keep other managers appraised at a
higher level of detail.
You will also need to spell out the relationship of yourself to the project executive, in terms
of the monitoring of progress. Equally, you need to put down how you will be monitoring
progress of the allocated tasks.
There is no one right answer for how this should be done, and indeed it will vary with every
project. Make sure you think about the size and complexity of the project, and also the
organisation's ethos and current management style.
6. Milestones
Here you need to think about how you will break up the project. Unless it is very
small, you don't want to have the entire project as one lump of work, with the only
check on progress at the very end. Instead, it makes sense to break the project
up into discrete chunks, where related tasks can be lumped together, with a
sensible milestone at the end of them. For example, in the technology refresh in
the example above, you may want to break the project down into something like:
1. Requirements Gathering
2. Tender Writing
3. Tendering Process
4. Contract Negotiation
5. Deployment
6. Testing
It makes sense to have a defined milestone, so you know when each section is
completed. There is also another benefit of breaking the project into chunks,
which I'll come back to.
7. Tolerances
You will have already looked at the resources you need. Now we need to set how far you, or
the project executive, can let the project stray from these targets before needing to sound
the alarm. For example, you could set a tolerance in terms of finance of +/- 5%, and a
tolerance in terms of time of +/- 10%. Equally, you may want to look at tolerances of quality
- i.e. how far from the quality criteria are you willing to accept?
It is remarkably unlikely that a project will not deviate from its resource or quality targets.
Setting tolerances allows you to be able to manage the project without continually seeking
guidance from the project executive as to whether you should carry on. This is not to say
that you should be happy with these deviations, and you should try to avoid them, and
monitor them closely. That way you can build your understanding of the project for the
future.
8. Dependencies
This is where you look at what needs to happen before something else. You need to start
thinking about the dependencies so you, and the project team, can understand the impact
of changes in any part of the project.
These dependencies should include both those internal to the project (i.e. those under your
control), and those external to it (i.e. those outside of your control). For example, you may
need an accurate figure for the number of staff in the organisation. This needs to come from
your HR department, and would be an external dependency.
9. Risks
Simply, what could go wrong? What could happen that would damage your ability to deliver
the project? Are there things you can do to avoid them, or minimise them?
10. Scheduling
This is the Gantt chart-style information that many people envisage when a project plan is
mentioned. In this, you need to put down what you expect to happen when. It will include
your dependencies, milestones, and probably resources. At this point, it will be a relatively
high overview of the whole project.
The schedule needs to include the overview, with the project broken down into sensible
chunks. This is the other advantage of breaking the project into chunks we mentioned
above. By having the project broken up in this way, you will be able to start planning the first
section in quite some detail, extending out for a few weeks. But from then on, it will start to
be based more and more on blind guesswork and faith. Don't try to be artificially precise -
keep it vague, use rough figures.
11. Contractual Aspects
This critical section of the plan includes a complete list and description of all reporting
requirements, customer-supplied resources, liaison arrangements, advisory committees,
project review and cancellation procedures, proprietary requirements, any specific
management agreements (e.g., use of subcontracts), as well as the technical deliverables
and their specification, delivery schedules and a specific procedure for changing any of the
above

Defining Tasks
Tasks are a single piece of work, or units of related work, that must be completed
in order to satisfy a project deliverable or the requirement of a deliverable. When
you've completed all the tasks of the project, the product or service of the project
is complete. And there you have itdefine all your tasks, complete them, and
your project is complete.

In planning a project, the project manager must structure the work into small
elements that are:
Manageable, in that specific authority and responsibility can be assigned
Independent, or with minimum interfacing with and dependence on other
ongoing elements
Integratable so that the total package can be seen
Measurable in terms of progress

Breaking Down the Project Activities
Managing the Work
The purpose of task definition is to allow you to break down the work of the
project into manageable components so that you can easily determine time,
resource, and cost estimates. Each task should be broken down to the point
where these estimates are easily derived. Breaking down the deliverables into
tasks makes the project manager's job easier because the work is subdivided into
small units that are easily assigned to one team member or a group of team
members. You can communicate the details of the work to the right team
members, manage and track project progress, and provide a way to logically
group similar tasks together.

The WBS breaks all the work in the project into separate tasks (tasks
may also be referred to as activities). There are two kinds of tasks on a
WBS: summary tasks and work packages.

Install the sprinkler system for a lawn is a summary task, because it includes
several subordinate tasks. Installing a sprinkler system might include several
of these distinct, subordinate tasks, such as digging trenches or installing
pipes. Each of these separate tasks is called a work package. By performing
all these simple work packages, you accomplish a summary task

Managing the Work
Let's look at an example. You've been assigned as the project manager for your
company's upcoming annual conference. Customers from all over the world fly to
your city to attend this conference and learn about your company's products, take
some training classes, and meet with vendors. One of the deliverables of this
project includes connecting and setting up 200 PCs for use at the training
seminars held during and after the conference. One of the tasks associated with
this deliverable might be loading software on each PC. Another task might be to
run two power strips for each table in the ballrooms of the hotel where the training
is being held.

At this point, you don't need to worry about in which order the tasks appear; just
start a list of tasks for your project and give yourself room in between each major
heading to come back and add to them. You'll find as you start breaking down
tasks that you'll think of new tasks for some of the deliverables you've already
broken down, so if you leave yourself some space, you can add these tasks as
you think of them.
Deliverable Tasks Comments
Set up 200 PCs for training
seminars the evening
before the conference
begins in the designated
ballrooms.

Sign lease agreement for PCs.
Coordinate with
procurement department.
Arrange delivery of PCs. Part of lease agreement.
Run electric extension cords and
power strips.
Coordinate with hotel staff.
Load software.
Coordinate with IT
department.
Table 1: Task List
Task Sequencing
After you define the tasks, you'll want to sequence them in a logical order. This
will help you when you're ready to create the project schedule later on. For
example, you can't load software onto the PCs until they've been delivered
and they have a source of electricity, so it makes sense to list the "Load
software" task last in this list. When you're working on small projects, you can
easily combine the task definition with the task sequencing process. As you
list the tasks, group them into a logical order at the same time. Larger projects
require a two-step process. First identify the tasks; then sequence them.

Task sequencing also provides a way for you to keep similar types of work
together. In our example project, the IT department is in charge of hooking up
the PCs and loading the software. They also have the responsibility for setting
up the PC connections from the speaker's podium to the overhead projection
system. A logical place to include these tasks would be in our task list shown
earlier in Table 1. In other words, we've grouped tasks that are similar in
nature in the same place.

Task Sequencing
Task identification and sequencing allows the project manager to define
estimates and costs and to determine the skills needed for the work of the
project. For instance, the task called "Load software" tells us what type of
skills are needed to complete this task. Obviously, we need folks who have
some understanding of how PCs work and how to troubleshoot problems if the
software doesn't load correctly. This means that we're going to have to work
with the functional manager of the IT group to assign some resources to these
tasks or contract with a vendor to perform these tasks for us.

Your project budget, the project schedule, and resource assignments are
determined primarily from the task identification phase and sequencing
exercises. As you can see, these are important steps in the project Planning
phase, so you want to take the time here to do a thorough job. But don't feel
that you're out there all on your own. Hold a team meeting or two and do some
brainstorming to come up with all the tasks necessary to complete the
deliverables. Then, after you've compiled your final list, review the list with the
team before moving on to the network diagramming or project schedule phase
to be sure you haven't missed anything.

Determining Milestones
If you're over the age of 15, you've experienced some milestones in your life:
Reaching age 16 (driving!), then 18 (graduation from high school), then 21,
and, well, you get the idea. Milestones in projects work the same way.
Milestones are markers along the way that let you know that a significant
accomplishment has been reached. Milestones are not tasks but they can
consist of a grouping of tasks. You don't perform actions to complete a
milestone; in other words, they aren't work. Instead, they signify that a
grouping of work has been completed or a significant accomplishment has
been reached.
Milestones might be based on deliverables, or a grouping of deliverables, or a
grouping of tasks. For example, one milestone for our conference project
might be, "Ballrooms prepped and PCs set up for training."
Some project managers like to use milestone charts as one way to report on
project progress. A milestone chart should include a listing of the milestones
with their expected completion dates and their actual completion dates. Table
2 shows a sample portion of a milestone chart for the annual conference
project.
Milestones are a way to help monitor the progress of the project. They are a
great tool to use for reporting to executive management because they show at
a glance where the project stands and what remains to be completed.
Milestone charts work particularly well for smaller projects.

30
Determining Milestones

Milestone Expected
Completion Date
Actual Completion
Date
Vendor registration complete 05/15/03 05/15/03
Website updated with conference info 07/01/03 07/01/03
Brochures mailed to prospective attendees 08/01/03 08/01/03
Training classes designed and approved 09/15/03
Ballrooms prepped and PCs set up for training 11/14/03
Table 2: Milestone Chart
A work breakdown structure (WBS) is a tool used to graphically display the
deliverables of the project in a hierarchical fashion. It organizes the work of
the project into logical groupings similar to a milestone chart but displays the
information in a tree form or an outline form. Basically, what it means is Work
Breakdown Structure is a breakdown of work into as small a task as possible

The work breakdown structure acts as a vehicle for breaking the work down
into smaller elements, thus providing a greater probability that every major
and minor activity will be accounted for.

The WBS is the single most important element because it provides a common
framework from which:
The total program can be described as a summation of subdivided elements.
Planning can be performed.
Costs and budgets can be established.
Time, cost, and performance can be tracked.
Objectives can be linked to company resources in a logical manner.
Schedules and status-reporting procedures can be established.
Network construction and control planning can be initiated.
The responsibility assignments for each element can be established.

Constructing the Work Breakdown Structure
Work breakdown structure (WBS))

the work breakdown structure can be used to provide the basis for:
The responsibility matrix
Network scheduling
Costing
Risk analysis
Organizational structure
Coordination of objectives
Control (including contract administration)

PURPOSE OF WBS
The main purpose of Work Breakdown Structure is that firstly, it helps to define
and organize the scope of the total project more accurately and specifically.
The most common way this is done is by using a hierarchical tree structure.
Each level of this structure breaks the project deliverables or objectives down
to more specific and measurable chunks.

The second reason for using a Work Breakdown Structure in your projects is
to help with assigning responsibilities, resource allocation, monitoring the
project, and controlling the project. The WBS makes the deliverables more
precise and concrete so that the project team knows exactly what has to be
accomplished within each deliverable.

This also allows for better estimating of cost, risk, and time because you can
work from the smaller tasks back up to the level of the entire project. Finally, it
allows you double check all the deliverables' specifics with the stakeholders
and make sure there is nothing missing or overlapping. Besides, using the
tree structure, you may also use Mind Mapping methodology, if you are
familiar with it.

Work breakdown structure (WBS)
The first step to creating your WBS is to get all your team, and possibly key
stakeholders, together in one room. Your project team is your most vital asset to
this process. Your team possesses all the expertise, experience, and creative
thinking that will be needed to get down to the specifics of each deliverable.
Next, we have to get the first two levels setup. The first level is the project title,
and second level is made up of all the deliverables for the project. At this stage it
is important to function under The 100% Rule. This rule basically states that the
WBS (specifically the first two levels) includes 100% of all the work defined in the
project scope statement and management plan. Also, it must capture 100% of all
the deliverables for the project including internal, external, and interim. In reality
the WBS usually only captures between 90-95%, but 100% is our goal.

Once we have gotten the first two levels set, it is time to launch into our
decomposition or breakdown. Decomposition is the act of breaking down
deliverables in to successively smaller chunks of work to be completed in order to
achieve a level of work that can be both realistically managed by the Project
Manager and completed within a given time frame by one or more team
members..

Work breakdown structure (WBS)

This level of breakdown and detail is called the Work Package. Work packages
are the lowest level of the WBS and are pieces of work that are specifically
assigned to one person or one team of people to be completed. This is also the
level at which the Project Manger has to monitor all project work.

The very common question is how specific or small does a chunk of work need to
be to still be considered a work package? Well PMBOK does not seem to give a
definitive answer on that. Most project managers concur that this varies by
project, but can usually be measured using the 8/80 Rule. The 8/80 Rule says
that no work package should be less than 8 hours or greater than 80 hours.
Notice we said that the work package is the lowest level of the WBS. Activities
and tasks are not included in the WBS. They will be planned from the work
packages once they are assigned.

Organizing the WBS Levels
A WBS is similar to a company organization chart or a family tree. It can also be shown in
outline form, which we'll get to shortly. It starts out with the big picture, and each
successive level gets more and more detailed. Like an org chart, it's a hierarchically
oriented view that shows which tasks "report" to which dependencies.
There is no set number of levels in a WBS, but it is recommend not going more than five
or six levels deep because the WBS will get bogged down in too much detail. If you're
working on a large project you will have sub-project managers working with you who will
be responsible for developing their own WBS from the project level WBS.
The highest level of the WBS, level one, is the project level. The next level holds the
deliverables or major milestones of the project. The succeeding levels are further
breakdowns of the deliverables that may include tasks or groupings of tasks. Does this
sound familiar? The deliverables are defined in the scope statement, and you defined the
tasks in the task identification process.
Now it's a matter of plugging them into the WBS. Keep in mind that for small projects you
could skip the task identification process and perform it at the same time you're defining
the WBS. Until you're experienced at this, though, you should break down the tasks first
and then plug them into the WBS.
Remember when defining your WBS levels that deliverables are typically described as
nouns or as past-tense events such as "PCs set up," "Brochures mailed," etc. Tasks,
which are developed from the deliverables, are usually described as action words: create,
develop, establish, and so on.

Organizing the WBS Levels
Let's look at some examples. The next graphic shows the level-one and level-two details
for our conference project. Keep in mind that the level-two deliverables in this figure are
only a sample. Your project would have many more deliverables than this
Level one shows the project name. This is always the first level in any WBS. Level two
for this WBS shows some of the deliverables or milestones for this project.
Now let's take a look at the next two levels:


Level three in this WBS shows a grouping of tasks, sometimes called summary tasks. For
example, "Obtain PCs" is a summary task under the "PCs set up" deliverable found at level
two. The "Obtain PCs" summary task at level three has tasks under it that must be completed
in order to consider the "Obtain PCs" summary task complete. In order to complete the
deliverable called "PCs set up," the two level-three summary tasks shown on the WBS,
"Obtain PCs" and "Set up PCs," must have all of their tasks completed. The same is true for
the other deliverables.
39

The idea is to start the WBS with the project and then continue to break down the
deliverables into smaller, more manageable units in each subsequent level. These levels
could include milestones, a grouping of tasks, or individual tasks. The idea is to keep adding
levels to the WBS until you've broken the work out to the point where responsibility for each
unit of work can be assigned to a specific person or to a team. This is also the level that
allows you to easily determine estimates and the skills needed to complete these tasks
40
Work Packages
A work package is the lowest level of a WBS. This is the level where
assignments, estimates, and resources are easily determined. It doesn't
matter whether the WBS has three levels or five levels; the lowest level in
either case is considered the work package level.

In the WBS shown earlier, level four is the work package level. In that
example, the individual tasks like 10.1.1 Sign lease agreement and 10.1.2
Arrange delivery are the work packages and are assigned to individuals or
teams to complete. If we broke off the WBS at level threein other words, if
we didn't include level-four tasksthen level three would be the work package
level.

Work packages may include individual tasks, milestones, or subprojects within
the project. If you're working on a very large project, the project should be
broken down into smaller subprojects rather than individual deliverables. Level
one still remains the overall project, level two becomes subprojects within the
project, and level three may also be subprojects within the subprojects, or this
level might start the breakout of deliverables. In this case, level three is the
work package level. Here is an example WBS with projects and subprojects.

In a structure like this, subproject managers may be assigned to the level-two
subprojects. All subproject managers report to a single project manager who has
responsibility for the overall project.
Level-two subproject managers (also called assistant project managers) assign the
level-three subprojects to teams or individual project assistants. At this point, the project
assistants create their own WBS for the level-three subproject they've been assigned.
For large projects, you can see that this could get rather complicated. However, the
effort is well worth it in the end since you have a logical, graphical depiction of the
project breakdowns in one place.
Once the WBS has been reviewed and approved by the project manager and project
sponsor, it's a good idea to tape up a copy of it in the project team meeting room. And
don't forget, a copy of the WBS should be filed in your project note-book for future
reference
Identification Codes
You may have noticed numbers next to each of the WBS elements. These
identifiers, or WBS codes, allow you to uniquely identify each element of the WBS.
They're used to track the cost of the work, or the cost of each element in the WBS.
They also serve as reference numbers to other planning information. As you begin
assigning tasks and defining resource needs and such, you'll want to document
some of this information (the act of documenting will become contagious over time),
and the codes provide you a handy way to tie the information back to the WBS.
For example, you might want to note that WBS item 10.2 was assigned to the IT
department. Maybe there are several costs involved with this summary task that
you need to break out. That information can be recorded in the WBS reference
document or WBS dictionary. The dictionary is created as a simple Word document
or spreadsheet document that lists each WBS reference number down the left side
with comments regarding that WBS element to the right. This document should be
filed in the same section of your project notebook as the WBS.
Your budget officer will need these numbers as well to track the cost of the project.
Depending on the WBS you've constructed, level-two and level-one elements are
simply a roll-up of the costs from all the levels beneath them. These codes come in
handy when using the outline view for the WBS. We'll look at that next.

Constructing the Responsibility Assignment Matrix
We've seen a couple of examples of roles and responsibilities charts in the slides. The
Responsibility Assignment Matrix (RAM) is the same idea. After you've constructed
your WBS, you're ready to determine the types of skills and resources needed for the
project. The RAM will help you do that.
A RAM is usually depicted as a chart, with the types of resources needed listed in each
row and the WBS elements as the columns. The intersection of a row and column
contains an indicator that shows what level of activity is needed by the resource. This
could consist of a simple word like Approve or Review, or it could contain a code that
ties to a legend if you need to be more specific than a one-or two-word description.
Table 3 shows an example RAM for the "PCs set up" summary task.

Resource Lease Agreement Install Power Strips Load Software
Procurement Dept. Create N/A N/A
Hotel staff N/A Install N/A
IT Dept. N/A Review Install
The WBS clarifies and provides necessary details for a number of project
management activities. Building a WBS helps to:

Provide a detailed illustration of project scope. Though the statement of work
defines scope at the conceptual level, a comprehensive look at a projects
scope can be accomplished only with a WBS.
Monitor progress. The tasks on the WBS become the basis for monitoring
progress because each is a measurable unit of work.
Create accurate cost and schedule estimates. The WBS will detail costs for
equipment, labor, and materials on each task.
Build project teams. Every team member wants clear work assignments and
a sense of how his or her work fits into the overall effort. A good WBS does
both. You can also increase the teams commitment to the plan by having
them participate in building the WBS.

P (Product)BS/WBS
Figure: PBS
Figure : WBS

Lecturer-2 Project Initiation

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lecturer-2 Project Initiation

Загружено:

Авторское право:

Доступные форматы

Project Initiation and Planning

11-Sep-14 1 Facilitator: Amed Salman Imtiaz, IPED, SUST

Вам также может понравиться