i.2 Preparing an Organization for Software Program Management

---

Once you, as the business leader, have made the decision to try to establish formal software program management in your organization, there are some preparations to be made. You will need to write some internal communications that begin to talk about the new Software Program Management Office (SPMO). You will need to explain to your user community how the SPMO will assist all of the program managers in executing internal projects using the new procedures. Part of this communication should introduce the concepts of a corporate Systems Engineering Process (SEP), formalized project initiation, and project sponsorship.

Another important point you will need to communicate in your message to the organization is process standardization. You can explain the advantages of having well-defined, best-practice processes as they relate to cost savings in implementation of your internal projects. You can also describe the added benefits, such as a lower cost of training, faster ramp-up time for projects, better communication across the organization, better budget controls, and so on.

Finally, you may want to prepare the organization for an ISO certification. In your communications, you can explain how ISO requires an organization to begin to ' say, do, prove, and improve ' on its internal processes. Software program management helps enable an organization for ISO precertification by implementing a set of standardized processes. While software program management may not provide everything needed in your organization to become fully ISO 9002 certified, it will certainly go a long way toward achieving that goal.

i.2.1 Project Initiation

Projects usually begin when a user, most often someone in the Project Sponsor's organization, submits a written request for something to be done. This is accomplished using a Project Initiation Form (PIF). The user will complete the PIF and submit it to the SPMO. The SPMO will process the request, performing such tasks as logging the request, reviewing it against outstanding corporate goals, and so on, and contact the Project Sponsor to set up a meeting to review the request.

i.2.2 Project Sponsorship

Basically, a sponsor is someone with the authority and budget to authorize funds against the costs of doing project work. Let's face the facts: If no one is willing to pay for doing a project, it just doesn't get done! Project Sponsors take on such responsibility by formally signing a letter of sponsorship, known as the Sponsor Formalization Letter (SFL). The SPMO will prepare the SFL and obtain both written commitment of funding (at this point, funding only to investigate, not for the entire project) and approval to proceed on the project from the sponsor.

i.2.3 Tools Needed to Create an SPMO

The software that is available with this book has all of the documents, files, templates, databases, spreadsheets, presentations, and HTML files needed for you to quickly implement a minimal working, entirely functional intranet-driven SPMO in your enterprise. Everything described in this book is available in the download file. Instructions for obtaining the download and for installing the example intranet-driven SPMO are found in Appendix C of this book. All of the necessary files and documents on the intranet are linked and cross-referenced to the corresponding documents needed for each phase of the SEP. A screenshot that depicts the SPMO intranet start page is shown as Figure i.1.

Figure i.1: Default Intranet SPMO Start Page.

i.2.4 Project Roadmaps

In an effective SPMO, each phase of the SEP has a well-defined set of activities that should be accomplished in order to complete that phase. These processes have been illustrated on charts we refer to as phase roadmaps. As we begin to cover the details of each phase of SEP in the following chapters, we will start each chapter with a look at the phase roadmap for that particular phase. Each step of each track in the roadmap will be covered in detail.

As you will see, these roadmaps are an indispensable tool for the SPMO. They allow all involved parties to communicate in a standardized manner and clearly delineate the various roles and responsibilities. They also set expectations in an organization regarding people's understanding of what is next in the SEP. Adherence to these processes becomes internally enforced over time as the members of the organization gradually develop such expectations while working on projects managed in the SPMO environment.

i.2.5 Project Tracks

For every project, the following four key roles are needed:

1. SPMO

2. Project Sponsor (representing user needs)

3. Project Manager

4. Core Team

These roles are known as tracks in the SEP phase roadmaps. When executing each phase of the SEP, the SPMO follows a different track than the Sponsor or the Core Team would follow. In the Phase I roadmap (shown at the beginning of Chapter 1), you will see an additional track, called Project Requestor. Because the Project Requestor is usually a member of the Sponsor's organization, it is assumed that the Sponsor operates on behalf of the Requestor in all subsequent activities. For this reason, the Project Requestor will not appear as a separate track beyond the first phase.

i.2.6 Project Binders

For every project started in an organization, a set of documents is necessary to complete each step in each track of each phase of the SEP process. Collectively, these documents are referred to as a project binder. The project binder is maintained by the SPMO as work on a particular project is completed. It is very important that a complete record of all project-related activities, decisions, and so on be maintained by the SPMO during the entire life cycle of a project. Such records can help an organization handle the capitalization of costs, document the changes to and maintenance of a system, assist with project continuity, transfer responsibility, and so on. Do not take the value of these binders lightly.

---