Log in / Register
Home arrow Computer Science arrow The Privacy Engineer’s Manifesto
< Prev   CONTENTS   Next >

Stage 1: Project Initiation and Scoping Workshop

Project Initiation Defines Project Processes

During project initiation, the project team will develop project mechanisms for:

• Developing a first-cut project plan, including a statement of project objectives and scope. It should also include project tasks, resource roles, task start date and duration, and task dependencies.

• Defining the method for monitoring milestone deliverables.

• Reporting project status, including reporting period accomplishments, next period plans, problems or issues, and suggestions.

• Managing change or service requests.

• Release to management.

Change management is critical to the success of a project and must be fully formalized, approved, and promulgated via service requests. The change management process should be tracked and documented from the receipt of the first service request to the final implementation. Service requests should:

• Trigger all system development activities

• Be made for all scope changes that could affect a project's objectives

• Be made for all scope changes that will affect a deliverable's completion date

• Be analyzed in regard to impact of the project on the entire enterprise

• Have a measurable business benefit stated

Release management should provide a formal process for authorizing the movement from development and test into the production environment. Changes should be scheduled as releases, as much as possible, and the scope of next releases should be made available to all interested parties. The following steps should be performed:

Track problems and issues: Issue number, related project, task problem or issue description, responsible team member, date reported, resolution, date closed, status, priority, reported by whom

Hold analysis, design, and development walkthroughs: Management and technical team

Measure success and design metrics: Process engineering metrics (mean time to failure, repair, and extend), deliverables delivered, resources to deliver

• Obtain user signoff on preagreed to measure of success

Requirements Definition Within the Scoping Workshop

To win a race, the s wiftness of a dart availeth not without a timely start.[1]

Fred Brook's classic article “The Mythical Man Month” begins with the following profound observation: “More software projects have gone awry for lack of calendar time than for all other causes combined. Therefore it is important to get a project off to a running start.”[2]

John Zachman has stated that the beginning phase of any project is scoping objectives.[3] During the first week of any project, a scoping workshop is in order, during which a variety of business users, the privacy team, and information technology (IT) participants meet, preferably out of the office, to develop a project mission statement.

A mixture of user executives, managers, the privacy team, and workers along with knowledgeable IT persons works best, but a less diverse group will be successful as long as the participants understand the business. The scoping workshop participants then develop a context diagram (see examples in Chapters 7, 8, and 9) that shows the suppliers and recipients of information from the engineered solution.

Next, the scoping session identifies major business classes, major business events, major business processes, major business rules, and major business objectives.

The participants then review and set study priorities on major business events, processes, or business classes. Typically, the events, processes, or business classes will be designated either as being a primary focus item, a secondary focus item, or out of scope. For primary and secondary focus items, stakeholders and subject matter experts are identified. The stakeholders and subject matter experts will be use case participants, those interviewed, or both.

Scoping Deliverables

The following deliverable may be developed[4] from the scoping workshop:

• List of business drivers

• Scoping mission statement

• Context diagram

• List of context actors

• List of actor locations

• List of triggering events

• List of information flows

• List of business classes

• List of business processes

• Potential privacy requirements

• Use case schedule using identified subject matter experts

  • [1] Jean de La Fontaine, 1621-1695, Fables as quoted in L. D Eigen and J. P Siegel, The Manager's Book of Quotations (AMACOM, 1991).
  • [2] F. B. Brooks, Jr., The Mythical Man-Month (Addison-Wesley Publishing Company, 1975), p. 14.
  • [3] J. A. Zachman, “A Framework for Information Systems Architecture,” in Handbook of Data Management (Boston: Auerbach Publications, Warren Gorham Lamont, 1993), pp. 3–22
  • [4] These things come to the surface during the scoping workshop and may or may not be formally documented depending upon the time available.
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
Business & Finance
Computer Science
Language & Literature
Political science