Page 100 -

CHAPTER 3 PROJECT MANAGEMENT CONCEPTS 71

relatively simple project might require the following work tasks for the customer com-
munication activity:

1. Develop list of clarification issues.
2. Meet with customer to address clarification issues.
3. Jointly develop a statement of scope.
4. Review the statement of scope with all concerned.
5. Modify the statement of scope as required.
These events might occur over a period of less than 48 hours. They represent a process
decomposition that is appropriate for the small, relatively simple project.
Now, we consider a more complex project, which has a broader scope and more
significant business impact. Such a project might require the following work tasks for
the customer communication activity:

1. Review the customer request.
Adaptable process model
2. Plan and schedule a formal, facilitated meeting with the customer.
3. Conduct research to specify the proposed solution and existing approaches.
4. Prepare a “working document” and an agenda for the formal meeting.
5. Conduct the meeting.
6. Jointly develop mini-specs that reflect data, function, and behavioral features
of the software.
7. Review each mini-spec for correctness, consistency, and lack of ambiguity.
8. Assemble the mini-specs into a scoping document.
9. Review the scoping document with all concerned.
10. Modify the scoping document as required.
Both projects perform the framework activity that we call “customer communica-
tion,” but the first project team performed half as many software engineering work
tasks as the second.

3.5 THE PROJECT

In order to manage a successful software project, we must understand what can go
wrong (so that problems can be avoided) and how to do it right. In an excellent paper
“At least 7 of 10
signs of IS project on software projects, John Reel [REE99] defines ten signs that indicate that an infor-
failures are mation systems project is in jeopardy:
determined before a
design is developed 1. Software people don’t understand their customer’s needs.
or a line of code is 2. The product scope is poorly defined.
written . . .”
3. Changes are managed poorly.
John Reel