Scope, time, and cost management are at the heart of successful project management. This course will give you the tools to develop a project scope, schedule and budget and then status them to predict project performance. Throughout the course, you will learn about change management and techniques to implement it. By the end of this course you will be able to: • Create a requirements document • Create a Project Scope Statement • Identify ways to control the scope of the project • Decompose the work and develop work packages • Create a Work Breakdown Structure • Develop a Critical Path Schedule • Review types of cost estimates and identify whether they are “top down or bottom up” • Review budgets, contingencies and reserves • Calculate planned and earned values to compare with actual cost • Perform a cost and schedule analysis Each week you will prepare a key deliverable for the project plan based on a provided Case Study. These deliverables include: • Project Scope Statement • Project Work Breakdown Structure (WBS) and WBS dictionary • Critical Path schedule sequence diagram • Bar Chart Schedule (Gantt Chart) • Project Cost Estimate • Project Status using an Earned Value Calculation All of this will position you to set up a plan to control your next assignment or your next project whether this is as the project manager or as an area leader. Rice Center for Engineering Leadership is a Registered Education Provider through the Project Management Institute (PMI)®. Learners who complete this course on the Certificate track will be awarded 14 hours of Profession Development Units. These are recognized by PMI for continuing education or can be applied toward the 35 hours of education required for the Project Management Professional (PMP)® certification. PMI and PMP are registered marks of the Project Management Institute, Inc.
Requirements Development
Loading...
Из курса от партнера Rice University
Engineering Project Management: Scope, Time and Cost Management
145 оценки
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
Из урока
Project Scope Management
Познакомьтесь с преподавателями
Tom PhalenLecturer in Engineering Leadership, PMP
Rice Center for Engineering Leadership
Kazimir KarwowskiExecutive Director, PMP
Rice Center for Engineering Leadership
In the last lesson, we discussed the scope management work process.
Then we started to look at the work process to develop a project scope statement,
including developing the scope management plan.
In this lesson, we'll learn how to develop the project requirements,
an essential element of a project scope statement.
We will also look at the scope validation process and discuss its importance.
So, we have a new project.
Where do we find the requirements?
In some cases, the project charter or the contract for
the project defines all of the requirements.
This is typically the case where the project has been studied
extensively and is a well known activity.
The requirements may be referenced in a set of specifications in
a detailed scope statement attached to a reference in these documents.
This is an ideal situation.
However, even when it appears that the requirements are well documented,
many times there are hidden requirements that are not fully explained.
So, what do we do if the project charter or the contract does not contain
all of the requirements?
If the requirements are not well-defined,
or if we want to test to see if there are hidden requirements,
then we will want to look for other sources.
A good place to start is to use some of the processes listed here.
The first approach is to read and incorporate
available data in the requirements traceability matrix.
To do this, we should review the project charter, contract,
bid documents, or specifications,
to the extent they exist.
These sources will contain the written and documented requirements for
the project and give us a starting baseline.
The next step is to survey the stakeholders.
This can be done in several different ways.
Face-to-face interviews, facilitated workshops,
formal surveys or questionnaires.
If there's a product, or process prototype,
that has been produced for our project or a similar project,
we can use this to help us define the requirements.
Finally, we look to similar products and projects to incorporate
similar requirements that have been used in the past.
It is important that we keep track of the source of each one
of these requirements that we collect.
It's not unusual that we go through this process of collecting requirements.
We collect conflicting requirements from different sources.
Different stakeholders will hold
different views on what the project is trying to accomplish.
Other sources may conflict with the stakeholder and each other.
The key in this first step is to document all the sources and all potential requirements.
Do not restrict your requirement collection to strictly technical requirements.
The requirements that you may be asked to assess will probably span a broad range.
Some of the areas included are listed here.
To be considered a successful project we will need to satisfy,
not only the technical requirements,
but also the organization's strategic goals and
the overall quality requirements for the product or service.
A great project satisfies all of these areas,
or at a minimum, has agreement on the priority and the scope for this project.
The next step in the process is to review the requirements.
In order to have a good requirements matrix in your project scope statement,
each requirement must be well understood by all stakeholders,
and there is no ambiguity in what the requirements might be.
The first step in this process is to reconcile conflicting requirements.
Requirements that are not fully aligned with each other should be
identified and then presented to the project sponsor and the customer.
The project manager must facilitate a process to resolve
these conflicting requirements and then agree on the controlling interpretation.
The next step is to make sure
each requirement has a single meaning and that any ambiguity is removed.
A good work process to achieve this goal is described in the chapter 4 of our textbook,
Project Management Toolbox: Tools and Techniques for Practicing Project Management.
This chapter contains a section entitled Requirements Ambiguity Checklist that provides
guidance on how we can make sure our project requirements are well-defined.
I suggest you review this process and incorporate it in your next project.
It includes all of the elements you see here and more.
Earlier we talked about keeping track of where the requirements
you have collected originated.
One good way to do this is a requirements traceability matrix.
Each requirement identified in the collection process is
added to the matrix along with an identification code,
its source, what business objective it satisfied,
and how it will be addressed in the project.
The matrix can also be used to capture
any modifications to the requirement that are made to
resolve conflicts and its overall priority on the project.
It should also include a description of how we will satisfy the requirement,
including the acceptance criteria.
A good requirements traceability metrics will look something like this,
the one we see here on the screen.
As we review all the project's requirements with the project sponsors,
and prepare time and cost estimates,
some of the requirements may be modified or even dropped.
The traceability matrix is a great place to
capture the disposition of any requirement that is modified or dropped,
including the source of the authority to make these changes.
The beauty of this approach,
is that when a stakeholder approaches you at the end of the project,
and asks us why you didn't include a feature or service in the project,
you can go back to the requirements traceability matrix to find the answer.
As part of the project scope development process,
we incorporate these requirements into
the scope statement and add any services that are required to implement the requirements.
Then as a last statement,
we present the completed project scope statement to the project sponsor,
any other approving authority,
for final review, comment, and approval.
The approved project scope statement
becomes our agreement on the products
and services we will deliver as part of the project.
It also includes the agreed acceptance criteria that
outline how we will know that we've met the requirements.
This becomes a key document to define our project.
At this point, we have
an approved requirement matrix that has been incorporated into
the approved project scope statement.
Let's assume that we're executing our project and producing deliverables.
The process to confirm that we're meeting the requirements of
the project is called scope validation.
Scope validation is a confirmation by the customer,
and other identified stakeholders,
that the deliverables from the project meet their needs.
If we have done the scope development process well,
then these needs are well-defined in the project scope statement as project requirements.
So, how is the scope validation
different than inspection checking and quality control teams
that we will study in course three,
Risk and Quality Management?
Scope validation comes after these internal checks have been complete.
This process addresses acceptance by the ultimate customer,
either the project sponsor or the client.
The inputs to the process are checked deliverables,
the requirements captured in the project scope statement,
and the requirements traceability matrix.
The process itself involves review and testing of the deliverables by
the customer to determine whether they meet their needs.
In reality, there are three outcomes from this process.
First, the customer finds a defect with a deliverable that
does not meet the requirements as stated in the project scope statement.
In this case, the project must correct the defect and resubmit.
Second, the customer accepts the deliverables meeting their requirements.
A third, the customer does not accept
the deliverable but acknowledges it met the original scope.
In this case, they should formally issue a change request to modify their requirements
and request a deliverable be modified.
This scope validation process emphasizes
the importance of a complete and unambiguous scope statement.
This project scope statement is the yardstick by which we will be measuring.
It should be as specific as possible,
in order to leave little room for interpretation during the validation process.
The entire scope development process is a key to successful project execution.
It aligns the stakeholders,
including the project team,
on a common set of requirements.
It sets expectations on how you will deliver the products.
It sets the standards for acceptance on the work products.
And finally, it makes up one leg of our iron triangle for project delivery.
So in the next lesson,
we're going to review the scope control process.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
