Description
The project initiation phase is the first phase within the project management life cycle, as it involves starting up a new project. Within the initiation phase, the business problem or opportunity is identified, a solution is defined, a project is formed, and a project team is appointed to build and deliver the solution to the customer. A business case is created to define the problem or opportunity in detail and identify a preferred solution for implementation. The business case includes:
A detailed description of the problem or opportunity
A list of the alternative solutions available
An analysis of the business benefits, costs, risks and issues
A description of the preferred solution
A summarized plan for implementation
About Requirements – More than half of the errors in a project originate with the requirements and analysis activities done prior to product design. Requirements are the heart of any project. They describe what the outcome of a project must be, what it must do, or the qualities it must have. In order to be successful, the project manager and his or her team need to identify and manage the project requirements. However, knowing that one must identify and manage the project requirements and actually doing so are two different things. Most projects fail as a result of incomplete requirements, poorly written requirements or misinterpreted requirements.
Discussion Points:
What is the value of developing a Business Case in project?
Discuss the various types of Requirements.
Address the significance of including the User-Experience (UX) in making project management as it applies to managing information technology.
https://archive.org/details/project-management-101 – Project initiation Page 43
Unformatted Attachment Preview
2
Copyright © 2007. J. Ross Publishing. All rights reserved.
IDENTIFYING AND
DEVELOPING
CUSTOMER
REQUIREMENTS
More than half of the errors in a project originate with the requirements and
analysis activities done prior to product design. Requirements are the heart
of any project. They describe what the outcome of a project must be, what
it must do, or the qualities it must have. In order to be successful, the project
manager and his or her team need to identify and manage the project requirements. However, knowing that one must identify and manage requirements and actually doing so are two different things. Most projects fail as
a result of incomplete requirements, poorly written requirements, or misinterpreted requirements.
Requirements are generated or elicited from current systems, end users,
and other key stakeholders. They generally come from the customer and
describe a need. However, requirements are generated not only as a result
of stated needs but also due to organizational needs for technical or business
capabilities.
Too many people think of the fulfillment of requirements as applying
only to outcomes that are tangible products. The best way to think of a
project outcome, however, is to ask: What is the end result of this project? The
J. Ross Publishing; All rights reserved
17
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
18
Project Scheduling and Cost Control
answer may be a product, but it can also be a service or even a new procedure
or process improvement. Understanding the purpose of a project makes it
easier to identify the requirements, which is not always an easy task.
Obviously, many other areas must be addressed and resolved in project
management. This chapter focuses on the number one problem project
managers face: understanding, identifying, and managing requirements.
Copyright © 2007. J. Ross Publishing. All rights reserved.
WHO DEFINES REQUIREMENTS?
Not all projects have completely definable requirements all the time. In fact,
many projects, particularly those involving new or cutting-edge technology,
may start with only general ideas about the purpose of the end product. In
these instances, it is appropriate to develop the system requirements as the
project progresses. However, even under these circumstances, and perhaps
even more so, the requirements definition process has to be disciplined,
documented, and scrupulously followed.
The customer defines requirements. That is, the customer, whether internal to an organization or external, desires a product or a service to meet
some need and then communicates this need to the provider. The problem
is that the customer often cannot describe precisely what is being requested.
Sometimes the product may be too cutting edge to even understand fully its
functional capabilities, or the customer may know exactly what is needed but
may not be able to communicate the requirements clearly.
To make matters worse, the producing organization may not have a
process for identifying and analyzing requirements—and thus may be incapable of correctly interpreting them even when they are clearly communicated. In addition, the producing organization may not have a sophisticated
enough process to accurately relate customer requirements to organizational
strategic and business needs.
WHAT ARE REQUIREMENTS AND
WHY DO WE NEED THEM?
At the most basic level in project management, it should be understood that
the customer or buyer establishes requirements usually as a result of some
operational need. Equally important, however, is that the provider organi-
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
Identifying and Developing Customer Requirements
19
zation also has a need to improve its capability, competitiveness, or dominance in a particular area. Hence, some requirements are the result of the
provider organization’s strategic objectives and may be driven by a company’s
need to improve or change its core business.
A specific requirement is something a product (or service) must do or
a quality a product must have. Any requirement exists primarily because the
customer wants the product to have a particular functionality or quality. A
requirement also can exist simply because the product type demands certain
functions or qualities. For example, to be truly functional, a product that is
used in testing might need to be self-aligning or self-calibrating to a preset
tolerance. Hence, a secondary requirement to self-align is inherent in the
functional capability of the product because of the primary requirement to
test rapidly, often, and accurately.
Most of us can readily accept that a product must have certain functional
requirements, but many of us do not realize that there also are nonfunctional
requirements. Understanding the different types of requirements is crucial
to identifying and planning to meet them.
Project managers and their teams need requirements definition from the
customer in order to accurately define, plan for, and deliver the product or
service the customer needs. Without requirements, there is no project.
Copyright © 2007. J. Ross Publishing. All rights reserved.
TYPES OF REQUIREMENTS
Assuming the customer defines the requirements accurately and completely,
the project manager must also understand—and be able to identify—the
different types of requirements, which complicates the project manager’s
job. Basically, there are two types of requirements: functional and nonfunctional. However, there is another type that is often overlooked: generated or
hidden requirements.
Functional Requirements
A functional requirement is one that a product must have in order to provide the capability needed by the ultimate user. Actually, functional requirements are the fundamental basis for a product in the first place. If a product
does not perform a function, do a job, or complete a task, then the need for
it is eliminated.
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
20
Project Scheduling and Cost Control
The following is an example of a functional requirement statement:
The product shall produce an amended resource availability roster at the end of every work shift.
To be serviceable to the user, this product must provide the capability of
keeping track of and reporting on the available resources each time a work
shift comes to an end.
Generally, a description provided by the customer will yield several and
even hundreds of functional requirements, depending upon the complexity
of the product. For every functional requirement, however, there also can
be one or more nonfunctional requirements.
Nonfunctional Requirements
A nonfunctional requirement is a quality or property that a product must
have. Sometimes this type of requirement is critical to the success of a product, but often a nonfunctional requirement simply enhances the look of a
product or in other ways identifies a product as something unique to an
organization. Nonetheless, it is a requirement and it is important to the
customer—sometimes even more important than a functional requirement.
The following is an example of a nonfunctional requirement:
Copyright © 2007. J. Ross Publishing. All rights reserved.
The Essex Company logo will be prominently displayed on the
front of the product.
This requirement—displaying the company’s logo—clearly does not affect
the functionality of the product. The product will work regardless of whether
the logo is present. To the Essex Company, however, prominence of the logo
may be of significant marketing importance, particularly if the product is
critical to an operation and its contribution is seen by hundreds of people.
Consider, for example, the timing equipment at the Olympics games. As
important as the accuracy and reliability of the equipment are, it is just as
important, to the provider at least, that its name be prominently displayed
on or with the equipment.
Nonfunctional requirements are often overlooked during the requirements identification process, or if not overlooked, they are considered less
important and not given the appropriate attention. This negligence can be
catastrophic.
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
Identifying and Developing Customer Requirements
21
Hidden or Generated Requirements
Hidden or generated requirements are those that are generated in order to
accomplish another requirement, usually in the provider organization. For
example, a stated required functional capability by the customer may be
beyond the technical capabilities of the provider organization. Hence, to
meet the requirement, the provider must either develop the requisite capability, hire experts that can provide the capability, or team with another
company or hire a vendor to provide the expertise.
The obvious answer to eliminating problems resulting from requirements interpretation is for the customer to establish clear and concise requirements and for the provider to ensure they are precisely interpreted. But
how are these actions brought together to yield the desired result? There are
three key steps: a clearly written set of requirements, a medium for transmitting these requirements to the provider, and a process for ensuring the
provider and the customer are in complete agreement about the intent of
the project and the results desired. The first step is to provide a clearly
written set of requirements.
Copyright © 2007. J. Ross Publishing. All rights reserved.
WRITING REQUIREMENTS
Written requirements are expected when the customer is external to an
organization. If an organization lives or dies by its ability to bid for contracts
(as in the defense industry, for example), it would be inconceivable that
written requirements would not be provided in the form of a statement of
work (SOW). When the customer is internal to an organization, it is more
likely that a written description of the desired product or service not only
will not be provided but also will not even be considered. Whether the
customer is external or internal to an organization, all projects should have
written requirements, and each internal project should be viewed and managed just as if it is governed by a binding contract. The reasons will become
clear in the following sections.
The best requirements-writing guides are the requirements or specification documents from previous successfully completed projects. An
organization’s “lessons learned” archives quickly yield the basic elements for
developing a working template for writing the next project SOW. Some tips
for describing requirements and developing a good SOW are given in Figure
2.1.
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
22
Project Scheduling and Cost Control
1. Describe the work—Describe all the work to be done as completely,
clearly, and concisely as possible.
2. Do not dictate how to do the work—Write a functional description of the
desired product or service when possible.
3. Clearly differentiate requirements—Describe only one requirement per
requirement statement.
4. Avoid ambiguous statements and words—Avoid words or phrases that
do not have exact meanings.
5. Repeat the statement of requirements for clarity and legality—If requirements are embedded in other documents attached to the contract,
repeat them in the SOW or include them by reference.
6. Include illustrations, tables, charts, and diagrams—Include anything in
the SOW that aids in understanding the requirements.
7. Flow down requirements—Pass on any requirements from prime contracts to subcontracts. Requirements imposed on the prime provider by the
customer must be included in the vendor’s SOW for the vendor’s area of
work responsibility.
8. Always have the statement of work reviewed/critiqued by others—A
review by an objective reader will reveal how clearly the SOW is written.
Copyright © 2007. J. Ross Publishing. All rights reserved.
FIGURE 2.1. Tips for Writing Good Statements of Work
Writing a good SOW—that is, developing a project requirement statement—is an art and is the ultimate test of a good writer. A requirement
should be written in as simple language as possible and should be stated in
one sentence. If describing a requirement takes more than one sentence or
requires two or more verbs and/or conjunctions, then there are probably two
or more requirements in the statement.
Consider the following requirement statement:
The product shall be capable of testing 300 samples per hour and
shall print test results on a standard-size sheet of paper (8.5 by
11 inches) in a two-column, tabular format.
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
Identifying and Developing Customer Requirements
23
There are actually two requirements in this statement. The first deals with
how many samples the product must test per hour, and the second addresses
the test report characteristics. The point here is that whether writing or
interpreting requirements, it is important that they be completely differentiated to avoid overlooking one or more of them.
Copyright © 2007. J. Ross Publishing. All rights reserved.
THE STATEMENT OF WORK
We have discussed that the customer develops and writes requirements as
a part of the SOW, but have not yet discussed precisely what this document
is. The SOW is the second step in bringing the customer and the provider
to an understanding of the purpose of the project. In short, the SOW is how
the requirements are transmitted to the provider. It basically defines the
project scope and is the communication medium in the process of defining
a project.
An SOW is most often associated with a request for proposal, which is
the formal document issued by a buying organization inviting potential
offerors to bid on a contract. However, organizations need to practice writing SOWs for their internal projects as well. As we shall see, the SOW is a
definitive description of the work, and having such a document can only aid
the project team in fulfilling the desires of the customer, whether internal
or external.
There are several reasons why an SOW is critical to project success. First,
this is the document that completely describes the work to be done. Second,
the SOW describes what constitutes “acceptance.” That is, the SOW should
always contain a section that describes what the project team must do to
provide an acceptable product or service and, likewise, how the customer
will measure when the project is complete. Unless this completion criterion
is explicitly stated in the SOW, the project may never be completed because
the customer can always claim the deliverable did not meet the intended
desires or needs. Third, the SOW takes precedence over all other documents.
For instance, if a specification attached to the SOW describes the desired
functionality of the product differently than the SOW describes it, the SOW
is the document that must be followed. Of course, the discrepancy between
the two documents should be pointed out to the customer for clarification
and possible amendment. However, the essential point is that many provid-
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
24
Project Scheduling and Cost Control
ers will have assumed that, for instance, the engineering specification describing the product is precisely what has to be delivered, only to find themselves redoing the product, at company expense, because the SOW described
something slightly different.
For smaller, less costly projects, the buyer might issue a specification or
a needs statement. The difference is in the amount of detail, but whatever
term is used to describe the customer’s needs, the purpose is the same: to
describe the needs of the customer. In this book, we will concentrate on the
SOW because that is the most difficult and most detailed of the needs descriptions. However, even SOWs can take on a different focus or amount of
detail depending on the type of SOW used to describe a particular project.
Types of Statements of Work
There are three major types of SOWs:
䊏
䊏
䊏
Design or detailed specification
Level of effort
Performance oriented
Although there are other types and variations of each of these, these three
generally meet the needs of most projects.
Copyright © 2007. J. Ross Publishing. All rights reserved.
Design or Detailed Specification Statement of Work
A design or detailed specification SOW tells the provider how to do the
work. It may include precise measurements, tolerances, materials, quality
control requirements, and any other specific constraints determined to be
important to the customer.
There are definite advantages and disadvantages to this type of SOW.
Some of the advantages are:
䊏
䊏
䊏
䊏
The customer is able to describe precisely what is required and
how it is to be built.
There generally is less potential for misinterpreting the customer’s
requirements.
The provider is relieved of bearing the risk for the project.
Up-front efforts are generally reduced. That is, generally less design
and less testing of various technical solutions are required.
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
Identifying and Developing Customer Requirements
25
The disadvantages of this type of SOW are:
䊏
䊏
䊏
The customer must bear the major risk burden for the project
because the customer is dictating the solution and how it is to be
provided. When the customer provides too much detail in the
specifications or in the description of a requirement, then the
customer is defining or “forcing” a solution.
The customer may not get the most cost-effective or most functional product since this approach precludes evaluation of other
solutions.
It generally produces poor projects in the information technology
world because it dampens or even eliminates creativity.
This type of SOW is generally used in a manufacturing or construction
business, but other work efforts are often described in this format. It can be
used to good effect in the information technology environment, but it should
be used discriminatingly and only for small, highly defined projects. Otherwise, the very essence of any high-tech creativity is compromised.
Copyright © 2007. J. Ross Publishing. All rights reserved.
Level-of-Effort Statement of Work
The level-of-effort SOW is an excellent type of SOW that is used effectively
in practically any type of service industry or project. A level-of-effort SOW
can be written for almost any type of service unless it is an inherent organizational service. The real deliverable under this type of effort is an hour
of work. That is, the customer contracts for time and pays the provider
according to the amount of time spent providing the task. Usually, this type
of contract has a weekly or monthly cap on the amount of compensated
work, which requires the provider to closely control the amount of scheduled work. The provider generally has to produce proof, in the form of
certified time sheets, to the customer before payment is made. This type of
SOW can also be used within an organization to track how much effort is
expended in accomplishing such projects as upgrades to managerial systems
control processes.
Performance-Based Statement of Work
The most efficient and effective SOW model is the performance-based SOW.
The performance-based SOW is always the preferred method for transmit-
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
26
Project Scheduling and Cost Control
ting the customer’s needs because it structures all aspects of an acquisition
around the purpose of the work and not around how to accomplish the
work. This approach has a number of advantages for both the customer and
the provider. The two most important advantages are:
1. The provider or contractor has the freedom to develop and evaluate different solutions to meet the customer’s requirements.
2. The customer can concentrate on obtaining the desired provider
instead of the provider’s processes.
This approach usually costs less than the design or detailed specification
SOW because the focus is on functionality rather than meeting precise engineering measurements. That is, it is generally more important that a desired result is obtained from turning a knob than it is that the knob be
turned precisely one-quarter turn to obtain the result. The cost of engineering the latter example is significantly higher than designing for functionality.
It is possible that some combination of SOW types may be needed. For
example, an information technology project that is part of a satellite communications system must of necessity contain specifications that describe
close engineering tolerances. Likewise, satellite size and weight constraints
are described in the SOW and accompanying documents, but many of the
other project requirements are described in terms of the functions the system
must perform.
Copyright © 2007. J. Ross Publishing. All rights reserved.
Benefits of a Well-Written Statement of Work
The SOW, as the most essential document in any solicitation, contract, or
important internal project initiative, must be written so that all technical and
nontechnical readers can understand it. But writing a good SOW is not easy.
It requires close attention to detail and a thorough understanding of the
need.
The investment of time and effort to write a clear and high-quality SOW:
䊏
䊏
Enables offerors or internal project teams to understand clearly
the customer’s requirements and needs
Allows project teams to more accurately schedule and cost the
effort and to develop a higher quality technical solution to meet
the requirement
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
Identifying and Developing Customer Requirements
䊏
䊏
䊏
䊏
27
Minimizes the need for change orders or other project adjustments, which increase project cost and usually schedule duration
Provides a milieu for establishing performance and completion
criteria
Provides both the customer and the project team a way to assess
performance and progress
Reduces claims and disputes in a contracted effort
The Statement of Work Format
The SOW can be thought of as the project specification. Although many
SOWs will contain engineering specifications, usually as attachments or appendices, many will not, nor should they. This is especially true of SOWs
that have been prepared as performance-based documents. Thinking of the
SOW as a specification, however, gives an added emphasis to the importance
of the document, if there is still any doubt. This thinking also helps focus
the writer’s attention on providing clear and concise descriptions of the
work, and it helps focus the reader on the salient points of the document.
There are several SOW format variations that are effective and useful, but
generally all SOWs have the same basic sections. A general format is provided in Figure 2.2. The SOW format is straightforward, but the section on
scope is described below as a guide to the type of detail expected in each of
the sections.
Copyright © 2007. J. Ross Publishing. All rights reserved.
Scope
The scope section is really an introduction to the project. In one sense, the
word is a little misleading because we think of the SOW as providing the
project “scope,” so it is logical to assume that the scope section would do
exactly that. However, this section is simply a high-level statement of what
is described in the rest of the SOW and generally what the project is about.
The following is an example of the scope section:
This Statement of Work defines the effort required for the design,
engineering development, software programming, fabrication, and
test of a prototype of the (Project Name) Information Technology
System to determine system feasibility. It includes the associated
project management, human engineering, and logistics support
planning requirements.
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
Copyright © 2007. J. Ross Publishing. All rights reserved.
28
Project Scheduling and Cost Control
I.
II.
III.
IV.
V.
VI.
VII.
VIII.
IX.
X.
XI.
XII.
XIII.
XIV.
XV.
XVI.
XVII.
XVIII.
XIX.
XX.
XXI.
XXII.
XXIII.
XXIV.
XXV.
XXVI.
XXVII.
XXVIII.
XXIX.
XXX.
XXXI.
XXXII.
XXXIII.
XXXIV.
XXXV.
Scope
Background
Applicable Documents
Specifications
Standards
Industry/Organizational Documents
Other Documents
Requirements
General Project Description
Detailed Project Requirements
Systems Engineering
Systems Analysis and Control
Baseline Generation
Software Design
Hardware Design
Training Design, Delivery, and Installation
Concept of Operations
Maintenance/Customer Support
Design Reviews
System Requirements Review
System Design Review
Program Management
Program Management System
Risk Assessment, Mitigation, and Management Program
Life Cycle Cost Analysis and Control
Program Electronic Database
Acceptance Criteria
General Guidelines
Buyer’s Measure of Acceptability
Product Demonstration Milestones
Test/Review Requirements
Provider’s Responsibility for Demonstrating Product Acceptability
Reporting Requirements
Review Meetings
Status Reports
FIGURE 2.2. Statement of Work Format
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
Identifying and Developing Customer Requirements
29
The SOW format in Figure 2.2 may be more comprehensive than needed
for a specific project, particularly if the project is relatively small and does
not have the usual complexities of most projects. If that is the case, use the
applicable sections of the format and skip the others. Likewise, add any
sections not in the format that are important to the success of the project.
Remember that every project is unique, so providing a format that fits every
situation is difficult if not impossible.
The focus thus far in this chapter has been primarily from the viewpoint of
the customer. Understanding what requirements are, how the customer develops them, and how they are transmitted to the provider is essential to understanding the next step: interpreting an SOW and identifying the requirements.
Copyright © 2007. J. Ross Publishing. All rights reserved.
IDENTIFYING PROJECT REQUIREMENTS
Generally, identifying project requirements is not difficult if the SOW and
other project documents are carefully examined. This does not mean that it
is a small task, because the task of identifying requirements becomes more
difficult as the project size and complexity grow. Even for small projects,
vagueness of requirements makes the task formidable. Still, the task need not
be difficult if there is a disciplined process in place.
Defense industry companies generally have a well-defined requirements
identification processes because their survival is directly dependent upon
their ability to successfully bid on and win contracts. Other companies,
public or private, that are dependent upon bidding for business also know
how to identify and interpret customer requirements. Most other companies
and organizations typically have a very difficult time identifying their customers’ requirements and often do not even realize the need for it. The
process outlined below should help you if your organization does not have
a process to identify requirements in place.
Every company may approach requirements identification in a slightly
different way, but the basic process is essentially the same regardless of the
industry and regardless of whether the customer is internal or external. The
steps in this process are:
䊏
䊏
Determine whether the project is one that should be pursued
Look for special conditions stated by the customer
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
30
Project Scheduling and Cost Control
䊏
䊏
Capture all the requirements in every document pertaining to the
project
Develop a matrix that cross-references each requirement to where
it is found and where it is addressed in the project plan
Although only four steps are listed in this process, each step has multiple
substeps. They are addressed in detail in the next several sections.
Copyright © 2007. J. Ross Publishing. All rights reserved.
Determining Whether to Pursue a Project
Many companies assign people or even a department to be responsible for
determining whether a project, internal or external, is one that should be
pursued. This would seem to be an obvious thing to do, but the fact is, there
are just as many companies that do not have any kind of a formal review
process and therefore find themselves in the middle of a project that never
should have been started.
Bid or project review generally is accomplished by an ad hoc committee
constituted specifically for the purpose, which sits in review as the need
arises. Figure 2.3 presents a checklist for considering whether to bid on an
external solicitation. The checklist is equally applicable, with minor alteration, for determining the viability of pursuing a project that develops within
an organization.
The first two checklist questions deal with examining a solicitation or
project in light of a company’s core business and whether the project will
improve the company’s market share or meet other corporate goals. Many
companies chase contracts or projects that appear achievable or customers
offer opportunities the company thinks it knows enough about to satisfy
minimal project requirements, believing that these factors provide enough
advantage. The company discovers too late that it does not have the requisite
expertise and experience or that the project is not a part of its core business.
Even if an upcoming project is within the core business, it does not mean
the project would further the company’s goals. If, for example, a company
is targeting projects that provide opportunities to enhance its technical capability, then projects should be under the core business umbrella but with
elements that enhance its expertise.
Questions 3, 4, and 5 in Figure 2.3 focus attention on the current internal
capability to perform the project. Before embarking on a bid for any contract
or before pursuing any project, it is necessary to understand if there are any
J. Ross Publishing; All rights reserved
Taylor, J. (2007). Project scheduling and cost control : Planning, monitoring and controlling the baseline. J. Ross Publishing.
Created from apus on 2024-03-11 02:09:41.
Identifying and Developing Customer Requirements
______
1.
Is the project consistent with our core business?
______
2.
Will the project meet or further our corporate goals?
______
3.
What experience gaps do we have in the organization?
______
4.
What technical gaps do we have in the organization?
______
5.
What personnel gaps do we have in the organization?
______
6.
What do we know about the customer/stakeholders?
______
7.
What does the customer know about us?
______
8.
Would a team member (another organization or company) improve our chances of winning the contract (successfully completing the project) by enhancing our internal capability or impr
