UNIT I STUDY GUIDE

Project Requirements Elicitation:

Client Needs and Project Scope

Course Learning Outcomes for Unit I

Upon completion of this unit, students should be able to:

4. Determine project requirements.

4.1 Compose a project charter and project requirements documents using requirement collection
tools.

Required Unit Resources

Chapter 1: Introduction: Why Project Management?
It is not required to read the case studies at the end of the chapter.

In order to access the following resource, click the link below.

Kutsch, E., Ward, J., Hall, M., & Algar, J. (2015). The contribution of the project management office: A
balanced scorecard perspective. Information Systems Management, 32(2), 105–118.
https://libraryresources.columbiasouthern.edu/login?url=https://search.ebscohost.com/login.aspx?dire
ct=true&db=bsu&AN=102122016&site=ehost-live&scope=site

Unit Lesson
The Project Charter

The project charter and project requirements enjoy a chicken and egg relationship. In a perfect world, the
project requirements, meaning what the project should deliver to satisfy the client, would be clear, and the
project charter would execute those requirements to produce the desired deliverables. However, it is rarely
the case that requirements are fully captured and understood prior to the initiation of the project charter. In
practice, a general idea about project requirements exists, but then the project team goes to work on fleshing
out the requirements on the way to developing the project scope once the project is approved.

But what exactly is the project charter? The charter is a document that formally authorizes the project team to
do the work of producing project deliverables, acquiring resources in the process, and spending money. In a
traditional, functional, business organization, the authorization of the project is necessary since projects
operate outside of the traditional functional team. Resources are drawn from the departments in the
organization and assigned to the project team. The formal charter authorizes the project team to acquire
resources in this manner. Further, when department managers assign project team members to the project,
the cost of the team members are then allocated to the project for accounting purposes. Once again, it is the
charter that grants the authority to do this.

The project charter is also a means for communicating to stakeholders that a project has been authorized by
senior management. In essence, the charter gets everyone on the same page. Whenever questions exist
about the project and its mission, the charter may be referred to for answers. The project charter provides
clarity by including the following elements.

1. Project sponsor is the executive authority responsible for authorizing the project.
2. Project manager is the identity of the individual who will lead the project.
3. Purpose or justification is the succinct overview of the mission and client.
4. Brief description is a simple statement succinctly describing target scope.
5. Succinct description of risks and constraints is the initial description of limitations and possible
concerns.

MGT 6305, Project Management 1

 6. Target milestones are key dates of interest. UNIT x STUDY GUIDE
7. Proposed budget is the target budget—typically a top-down budget request.
Title
8. Signature block includes the authorization signatures.

Getting Started

What triggers the development of the charter? This depends upon how the company is organized, as well as
its overall strategy. For example, a company that develops and manufactures products for the market at large
is likely to charter a project internally as part of its ongoing market research and product development cycle.
In this case, the sponsor is likely to first insist on the development of the product scope by chartering market
research and feasibility studies. Eventually the process shifts to a focus on chartering the development of a
complete project plan and its associated execution. A company that builds homes to specification (i.e., spec
homes) is likely to charter a project in this manner. On the opposite end of the spectrum are companies that
charter projects to fulfill contractual obligations for a specific client. A homebuilding company that builds
custom homes will draft a detailed contract with a specific client based on client requirements. Often, the
project is chartered with a contract that includes an SOW (statement of work) that is an input to the
development of the project scope. While it may appear that the SOW is equivalent to the project scope—this
is rarely the case. The project team takes the SOW, evaluates it, clarifies it, and fleshes it out in greater detail.
Regardless of whether the charter is triggered internally according to process, or externally due to a
contractual relationship, nothing happens in the project until it is formally authorized by means of the charter.

A Plan and a House

Building a house is in some ways similar to developing a project plan. Both benefit from a sound foundation.
The foundation of a project plan is the project scope. Scope is all about what the project will deliver. How
does a project manager determine the project scope? Scope originates from the requirements of the client.
When it comes to project requirements, however, appearances can be very deceiving. Clients are known to
ask for many things, but what a client asks for does not constitute requirements. Requirements must be
elicited and vetted by the project team. This process involves probing questions as well as making the client
aware of constraints associated with the schedule and budget. It should also be mentioned that what a client
wants may not necessarily reflect what the client needs. Generally speaking, wants are many, but needs are
few. Also, it is not uncommon for a client to state what is thought to be needed—but in the end—the client
misunderstands his or her own needs. In the case of a homebuilding project, a client may ask for a specific
type of countertop but decide later after seeing the installation that this is not exactly what was needed.

It should also be recognized that some settings in which clients are asked for requirements may
unnecessarily bias the result. The focus group in market research is one example of this. Focus groups may
result in groupthink depending upon the composition of the team, thereby resulting in sending the wrong
impression about what is really needed in the project scope. Further, it is essential to ask the right questions.
Asking a client in a focus group, “What do you think about this product?” may lead to a positive response.
However, this is not the same question as, “Would you buy this product for $19.99?” A stated positive
impression of a product does not necessarily mean that the client will actually purchase the product if given
the chance. For the client, there is no penalty for a wrong answer in requirements gathering, but the project
team and sponsor will suffer as a result.

Getting the requirements right requires that project managers understand what the client needs at least as
much or perhaps better than the client. Successfully arriving at this understanding is almost as much an art as
it is a science. Project managers do this by asking questions in different ways and seeking to provide visual
cues to the client. As an example, it is easier for a client to grasp a prototype than it is for them to understand
written specifications. Also, when a client asks for something, it is a good idea to probe to better understand
the client’s rationale and to understand how the client intends to use the requested feature. It is often the case
that careful questions can lead to a solution that costs less and takes less time and gives the client 80% of the
functionality originally requested. Asking hard questions is sometimes avoided by project managers out of
concern that they will upset the client. It is important to remember that getting requirements right benefits the
client. Satisfaction of the client is the ultimate goal—so it is important to not avoid challenging discussions

MGT 6305, Project Management 2

associated with vetting requirements. In the case of developing requirements for
UNITthexconstruction
STUDY GUIDE of a home,
some important questions should be asked. Title

This small sample of questions illustrates some of the challenges with requirements elicitation. For example,
Questions #1 and #2 relate to the fact that it is common for clients to focus on lowest costs without
considering the total lifecycle costs. Agreeing immediately with the initial request without question may lead to
delivering a product with features for which the client is not happy. Questions #3 through #5 relate to the
space and layout of the home. Probing questions for these elements of the project may lead the client to
consider that which was not previously thought of.

Managing Requirements

Client requirements drive the development of the project scope and the specifications governing the
production of project deliverables. The project team refers back to requirements throughout the project to
make sure it is on the right track. The exercise of ensuring that the project is correctly following the
specification is known as verification. While this is essential for directing the efforts of the project team, it is
just as important—if not more so—to validate project requirements. This equates to the confirmation that the
specifications used in the projects align with client requirements. In practice within every project, it is
important to be able to trace project work to the specification and then link the specification back to
requirements. Otherwise, the project team will end up working on the wrong thing. Given the singular focus of
a project on unique deliverables, getting the requirements and scope correct is essential.

Suggested Unit Resources

In order to access the following resources, click the links below.

Review the Chapter 1 PowerPoint presentation to supplement the textbook reading and lesson content. You
can also view a PDF version of the Chapter 1 presentation.

MGT 6305, Project Management 3