2.2 Security Access

---

The project data in any corporate project must be protected. The first step in protecting corporate information is to develop and maintain a Security Access Sheet (SAS). As you can see in Figure 2.3, this sheet specifies the dates for which access will be granted, to whom it will be granted, and what that person's role is on the Core Team. Access to the centralized project database, the SPMO database, the SPMO intranet, and the project binder can be granted or withheld by specifying Y/N in the columns provided.

Figure 2.3: Security Access Sheet (SAS).

2.2.1 Project Kickoff Meeting

Once the Project Manager has identified the Core Team and specified access rights to the project, it is time to have a kickoff meeting. The purpose of this meeting is to get all of the Core Team members in the same room and to develop some framework rules for all future activities. This is also the time when any Core Team members who are unfamiliar with software program management should be trained. During SEP Phase I: Initiation, the Core Team is responsible for several key deliverables. These include developing a Framework Rules Document (FRD), revising the CTR, customizing the project deliverables checklist, developing a Project Planning and Documentation Guide (PPDG), and completing the User Requirements Document (URD). We will discuss each step in turn in following sections.

2.2.2 Risk Officer Appointment

When the Core Team meets initially, one of the first activities that should be completed is the appointment of the Risk Officer. It is this person's responsibility to play devil's advocate. Question everything! Ensure that sound reasoning and logic surround all decision making within the Core Team. This role is often unpopular and often meets with great amounts of criticism. The Project Manager is responsible for ensuring that the Core Team appoints someone strong enough to stand his or her ground on tough issues. The Risk Officer does not have the job of stopping progress, but rather of recording and informing the team about concerns that arise during the scope of the project. In reality, group consensus should guide decision making. If the Risk Officer objects strongly to proceedings and feels like the issue is being ignored, he or she is authorized to go directly to the Project Manager or even to the Project Sponsor with concerns. The process of managing risk is covered in greater detail in Chapter 10.

2.2.3 Core Team Roster Revision

During the initial kickoff meeting, the Core Team members will most likely identify folks in the organization who were not selected initially, but should be on the Core Team. This is very often the case in large, cross-functional projects. There is a balance between involving everyone and being crippled by indecision with in a large Core Team. The Project Manager has the final say, of course, in the composition of the team. In general, he or she should include at least one representative and one backup from each functional business unit in the organization. For example, just taking one person and a backup from Sales, Finance, IT, HR, Operations, Call Center, and so on can quickly increase the size of the team dramatically. As you can see, with just these few units, 12 people are already involved. Whatever the final selection results are, the initial CTR must be revised and updated. Any future changes require that an updated roster be turned in to the SPMO as a matter of record. The same rule applies to the SAS as well. One should not be changed without review of the other.

2.2.4 Project Customization Matrix

The Project Customization Matrix is created and reviewed by the Core Team to make inclusion/exclusion decisions about specific areas that are often overlooked at the beginning of an initiative. It is up to the Core Team members to make such decisions based on their knowledge of the company and what is significant or considered relevant to business need. It is folly to assume that everything on the matrix is relevant to every project. Likewise, it is just as much an error to assume that nothing on the matrix applies. Items may be added or deleted from the matrix, but the key issue to remember is that a team of capable, knowledgeable business representatives has taken the time to review and make such decisions about the direction the project will take.

An added benefit of having the Core Team make these decisions before work start is that they gain an awareness of both the scope and magnitude of the initiative, and the Core Team members will begin to appreciate the complexity of the task they have inherited. A sample Customization Matrix is shown as Figure 2.4.

Figure 2.4: Customization Matrix.

---