Chapter 3: SEP Phase II-Analysis and Detailed Planning Phase

---

Overview

Let’s begin by taking a look at the SEP Phase II roadmap (Figure 3.1). For the three tracks of SPMO, Sponsor, and Project Manager, the tasks accomplished between phases 2 and 7 are redundant. The SPMO basically monitors progress, continues to ensure that all required steps are completed, and assembles documents into the project binder with deliverables as they become finished products. The SPMO will also perform internal audits or work with the Internal Audit Team of the organization, if it exists, and develop project scorecards at the end of each phase. The Sponsor will review progress using the scorecards and provide approvals or guidance as needed.

Figure 3.1: SEP Phase II Roadmap.

The Project Manager is much more involved with the Core Team and plays the role of administrator, providing updated project files to interested parties, creating budget and progress reports, monitoring the issue status log, and so on. We will concentrate on the work done by the Core Team, because this is where all the action is from this point forward. This phase of project development will be focused on providing the framework for the entire project life cycle. Each step of this phase addresses important planning and documentation considerations that will affect all future project work and ultimately play a leading role in dictating the project’s critical path.

Did you know that the best-run projects use some common approaches to managing the effort? These common approaches include the following:

• Planning and executing project tasks in staged deliveries

• Having the progress of the project tracked by both senior management and the user community

• Having open reviews of the project status (good and bad news) conducted on a recurring basis

In order to complete this phase, we must complete the following checklist:

	Project Objective Statement Completed
	Project Definition Document Completed
	Flexibility Matrix Completed
	Project Definition Document Notebook Completed
	Data Analysis Document Completed
	Technical Analysis Document Completed
	High-Level Solutions Document Completed
	Bids/Proposals Document Completed
	Project Schedule Completed
	Risk Analysis Completed
	Change Management Process Standard Completed
	Status Reports Completed
	Review Package Completed
	Review Meeting Documents Completed
	Project Budget Worksheet Completed
	Capital Equipment Request Form(s) Completed
	Phase II Completion Approval Signoff Completed

3.0.1 Project Objective Statement (POS)

The POS states what work you are going to do (the scope), by when (the schedule), with how many or how much (the resources or cost). It provides clarity and focus for the project team. It should be fewer than 50 words in length and stated in clear, concise, unambiguous terms. The Core Team should draft this statement.

3.0.2 Project Definition Document (PDD)

The PDD is a high-level summary of the project. It should document information in the following order: description, purpose, strategic alignment, completion criteria, project start, customers, dependencies, and hardware/ software requirements. For each of these topic areas, you need to address, at a minimum, the items listed:

• Description and purpose: This is the 40,000-foot view of the project and why it is needed.

• Strategic alignment: How does it align with business goals?

• Quick wins and long-term strategy: Why is this good?

• Target customer(s): Who are the users of this project deliverable?

• Dependencies: What are committed dates and commitments to/from other projects?

• Staffing: What is required, both in terms of skills and balance of experience?

• Risk of doing versus not doing the project: Provide an impact assessment.

• ROI analysis: What is the return on investment? Does it make fiscal sense to do this?

• Assumptions made: Are you making calculated assumptions or taking unneeded risks?

• Implementation constraints: What limiting factors would hinder success?

• Contingency plan: What happens if the plan goes all wrong?

3.0.3 Flexibility Matrix (FM)

This is a matrix to help the team decide and prioritize the tradeoff between scope, schedule, and resources (Figure 3.2).

Figure 3.2: Flexibility Matrix.

For each of the three items in the left-most column—schedule, scope, and resources—determine which level of flexibility is most applicable. Is the schedule fixed and are you tasked to drive the project to a date? If so, mark an X in the Least Flexible column for schedule. Is the project scope subject to change or is it set in stone? If scope makes no difference, then mark the appropriate column, indicating most flexible. Repeat this for resources and your flexibility matrix will quickly reveal your program priorities.

3.0.4 Project Definition Document Notebook (PDDN)

The PDDN is a binder containing the PDD, the POS, and the Flexibility Matrix. This notebook should also contain a formal presentation that can be used as an overview of the project for any visitors or other interested parties. The standard project binder should also contain PowerPoint templates designed for standardization of formal project presentations.

3.0.5 Data Analysis Document (DAD)

The DAD is a detailed study that is performed to determine if the data requirements presented in the URD can actually be implemented with the data currently available from sources obtained in-house, from commercial off-the-shelf (COTS) sources, or through an impending, near-term deliverable. Let’s examine each of these sources in turn.

3.0.6 In-House Analysis

Performing the in-house analysis requires that the Core Team ask several questions regarding the availability and completeness of information. The team must determine whether the information available will meet all of the user requirements or not. If not, the team needs to determine how many of the total requirements are met by the information available. Furthermore, it must ascertain where the additional information required will be obtained. When examining the data, the team must ask if the data is appropriate for release in its present form and format or determine if it will have to be reworded or reformatted. What is the sensitivity of the data? Are there special confidentiality or security concerns that must be addressed?

3.0.7 Commercial Off-the-Shelf (COTS) Sources

An examination of commercially available data sources is required. This includes knowledge brokers and data aggregators; however, the same process of examination for in-house evaluation needs to be performed for each candidate reviewed. The Core Team must ask several questions regarding the availability and completeness of COTS information. The team must determine whether the COTS information will meet all user requirements. If it will not, the team needs to determine how many of the total requirements are met by the COTS information. It must ask where any additional information required will be obtained and determine the availability of such information.

3.0.8 Near-Term Deliverables (NTD)

In many organizations, large initiatives depend on completion of subprojects or other initiatives within the organization. These types of deliverables are called near-term deliverables (NTD). Once again, the same process of examination for in-house evaluation needs to be performed for each deliverable used in a project. The Core Team will need to ask several questions regarding the availability and completeness of NTD information. The team must determine whether pending NTD information will meet all of the user requirements. If it will not, the team needs to determine how many of the total requirements are met by NTD information. Once again, it must also ask where any additional information required will be obtained and determine the internal availability of such information.

3.0.9 Data Risk Analysis (DRA)

The DRA is a subjective assessment regarding the likelihood of not achieving project data objectives because of the availability of information, the delivery of information, any data-formatting issues, sustainability, feasibility, and security of data. If the information is difficult to obtain or it is questionable as to whether the information will be made available for the project, the risk to the project increases significantly. If the data is formatted so that much additional work will be needed to make the information usable, there is a significant risk involved. There may not be a choice in the matter, but the DRA will bring these matters to light before the issue arises and save the Core Team much time and effort in defending decisions after the fact.

Sustainability refers to the duration of the validity of the data. The team must ask itself how long this data will be usable to the project. If a project is built around data that is transient in nature, that increases the risk of success and should be known before commencement of work. Finally, does the data proposed for use in a project constitute a security risk to the business? If so, then the Core Team must question the wisdom of using such data and the risks of proceeding. There may be a need to proceed with such sensitive data, and the team incurs a responsibility to provide mechanisms for data protection during the course of the project. The answers to these questions provide varying degrees of risk to the success of the project. The Core Team needs to understand all such implications before proceeding with a project.

3.0.10 Technical Analysis Document (TAD)

There are five key components of a basic TAD. These components are as follows:

1. Software Reengineering Assessment

2. Technology Analysis

3. Technical Risk Assessment

4. In-House Contractor Analysis

5. Lease-Purchase Analysis

The ultimate purpose of a TAD is to save time and money in the execution of a project. Exploring each of the following components will help the Core Team make decisions that enhance the probability of the project being executed in a manner that is most cost-effective and timely. Each of the five key components is explained in detail in the following paragraphs.

Software Reengineering Assessment (SRA)

The purpose of an SRA is to assist the Core Team in making a sound, informed business decision that will determine whether it is practical to reengineer legacy software. It is often much less expensive to make changes to existing legacy packages than to rebuild or replace them from scratch. A formalized analysis of the issue is often the best method of obtaining a clear picture of what the proper course of action for the project should be. The Core Team should first ask if the current software can be modified to meet the new requirements. To answer this question, the team should conduct a cost-benefit analysis. In performing the cost phase of this analysis, it is important to understand what cost analysis entails.

Cost Analysis is defined as any cost associated with the operation of the existing system on an annual basis and includes the following:

• Computer costs

• License and maintenance fees

• Dedicated computer equipment costs

• Data storage costs

• Data communication and distribution costs

• Maintenance costs (excluding maintenance fees)

• Main computer utilization costs

• Personnel costs

• Computer systems operations personnel

• Training costs

• Supply costs

• Miscellaneous costs

• Rental of floor space

• Office furniture costs

Next, you should estimate costs associated with developing the proposed solution using the current system. It is a good idea to also describe the techniques that were used to derive the cost estimates.

When evaluating benefits for this analysis, for each tangible benefit, the team should quantify the dollar value of the expected reductions in operating costs or increased revenues. Identify the projected payback period associated with the changes. For each intangible benefit, describe the added values associated with the system’s implementation and provide the appropriate justifications, where necessary. In performing the benefit phase of this analysis, the following items should be considered:

Tangible Benefits

New sources of revenues

Increased profits

Cost avoidance (staff )

Reduction in maintenance costs

Intangible Benefits

Improved service

More accurate and timely information

Improved control

Greater flexibility

Competitive edge

Improved employee morale

Once all of the cost and benefit factors have been identified and quantified, the Core Team should prepare a formal recommendation and provide written justification for the decision. This becomes a part of the overall TAD. This information should be stored in the project binder once reviewed and approved by the Core Team.

Technology Analysis (TA)

The TA is a study to determine if a technology requirement can be implemented with the current technology available (hardware and software) in house, COTS, or through an NTD from another project currently being executed within the organization. The TA should provide a detailed analysis of what is available and state whether such technology is feasible within the current operational or organizational environment (e.g., hardware/software requirements, operating system requirements, File, Print, Database or Applications Server-specific requirements, networking or Internet requirements, client requirements, browser-specific requirements). The TA should contain a matrix of technology and associated functions with weighted requirements that match directly to specific user acceptance requirements as part of the recommended solution.

Technical Risk Analysis (TRA)

The TRA is a much more subjective assessment. It is one of the Risk Officer’s responsibilities to ensure that this TRA is completed. The TRA reviews the known or expected risks regarding the likelihood of not achieving the project’s technical objectives due to any of the following factors:

• Technology assessment/availability

• Key issues with technology beyond team control

• Programmatic issues that may arise

• Support issues that would be outside the control of the Core Team

• Feasibility of implementation

• Security issues

• Alternative approaches

• Strategy integration

3.0.11 In-House/Contractor Analysis (IHCA)

This study is used to determine the feasibility of developing software inhouse. It evaluates the benefits of doing internal work as opposed to contracting the requirements for software development to outside sources. It should take into account each of the five following factors:

1. In-house availability of resources

2. Knowledge of implementation team

3. In-house costs compared to outsourced costs

4. Contractor availability, knowledge, and prior track record

5. Recommendations from contractor references

Lease/Purchase Analysis (LPA)

The LPA is a study to determine the feasibility of leasing versus purchasing equipment and/or software. To accomplish this study, it is quite common to invite vendors to make presentations to your team, to visit other sites or organizations that are already using the package (vendor references), or to install packages in your environment for a trial period (referred to as a pilot program). When performing the LPA, it is recommended that the following items be included:

• Costs of systems modifications required to satisfy the key user requirements

• Costs of additional hardware configurations to support the new package

• Costs of additional software configurations to support the new package

• Costs of additional networking configurations to support the new package

• Training costs for hardware systems administration

• Training costs for the user community

• Training costs for support personnel

• Data conversion costs

• Maintenance costs

• Documentation costs

• Operating costs

• User support costs

3.0.12 High-Level Solution (HLS)

The HLS is an initial response from the Project Manager to the problems and needs presented in the URD. This document is not intended to describe the end solution or final product in great detail. It is meant only to provide a 40,000-foot view (hence the name high-level solution). The information contained within the HLS provides fundamental direction to all groups that will be part of creating the product solution. This document is typically about one-tenth the size of the Product Specifications Document—the fully detailed solutions document. The HLS should present, at a minimum, the following items for review:

• Overview of the proposed solution

• Is/is not lists (detail what is and is not part of the solution)

• Deviations from requirements (exceptions from requirements are noted here)

• Audience (user, support, systems, administration, etc.)

• Functions (high-level and subfunctions needed to meet basic requirements)

• Ease of use (in terms of accessibility, graphical user interface [GUI] standards, etc.)

• Architecture (technical, data, hardware, and software)

• Hardware supported/required

• Software supported/required

• Information and data to be included/excluded

• Performance requirements (hardware, software, network, etc.)

• Publications (used, generated, or needed)

• Standards/ISO compliance

• Reliability

• Serviceability

• Compatibility/migration

• Internationalization/localization requirements (will other language deliverables be needed?)

• Pricing/license agreements

• Packaging requirements and plans

• Security issues

• Future enhancements

As you can see from this list, addressing each of these issues from a highlevel perspective at the beginning of a project will save much grief later in the project. Such issues are often overlooked and kludges are made after the fact to remedy an omission. This creates additional maintenance and development costs and could even cause budget overruns. Taking the time to review and decide on each of these items beforehand is crucial to project success.

3.0.13 Project Deliverables

Many deliverables are necessary to have ready at the final stages of SEP Phase II. Some of these deliverables are intended to go outside the organization to vendors, and some are exclusively for in-house consumption. In general terms, the deliverables intended for in-house use are project management oriented, whereas those used for vendor management most often pertain to billing, contracting, and dollar-related activities. We review some of the more significant deliverables in the following paragraphs.

3.0.14 Bids/Proposals (BP)

If the In-House/Contractor Analysis determines that the best solution for your project is to use outside resources to complete the project, a bid or a proposal should be submitted by each vendor for consideration. This bid should be in response to a Request for Proposal (RFP) that the Core Team sends out to each vendor. The structure of the RFP is covered in the next section. The RFP should be sent to several potential vendors, which are narrowed down by the Core Team from a larger list of many potential candidates. The list may be obtained by reviewing directories or catalogues specializing in software packages or from a review of various computer and trade magazines. Hardware vendors often supply lists of software vendors whose products run on their processors. Finally, the Core Team may consult with professional user groups that can provide software directories for their members (such as IEEE or ACM).

3.0.15 Develop a Request for Proposal (RFP)

This document is intended to be used by the SPMO when the Core Team has found it necessary to solicit outside parties to provide assistance in project execution. It is the official request from your organization to one or more vendors, asking them to submit to your SPMO a written proposal describing how the vendor would satisfy each of the stated requirements in the URD. The RFP would further require the vendor to state how it intends to accomplish all of the objectives stated in the HLS. At a minimum, the RFP sent out to the vendor by the SPMO should contain the following items:

I. Cover letter

II. Title page

III. Table of contents

IV. Structure of the RFP

V. Situation of the system

VI. System requirements description

VII. Functional and data requirements

VIII. Operational requirements

IX. Miscellaneous requirements

X. RFP reply format and evaluation criteria

XI. Appendix of additional info that might enhance the comprehension of the request for proposal (flow diagrams, entity relationship diagrams, etc.)

Once the vendors have submitted their responses, the Core Team should develop a standard list of selection criteria that will be used to evaluate the vendor proposals. The selection criteria should be weighted (i.e., is it essential, important, or just nice to have?). A numeric value should be assigned to each weighting factor.

Next, the Core Team must rate and rank the selection criteria to determine if it satisfies the system requirements perfectly, if it satisfies the system requirements except for a few minor items, if it satisfies the system requirements in general (although some important characteristics might be missing), or if it does not satisfy several important aspects of the requirements or does not satisfy the requirements at all.

During the final evaluation process, all of the criteria are numerically rated and then ranked from high score to low score according to how well the systems requirements are met. A final numeric score is produced for each criteria from each vendor. The vendor that attains the highest average aggregate score is usually chosen to be the contractor for the project.

Sometimes additional factors, such as vendor cost, are added as criteria with numeric ranking assigned based on high, average, or low rankings. The key is to consistently and fairly evaluate each vendor based on the same criteria and make an informed, balanced decision based on objective data.

3.0.16 Funding Documentation (FD)

The funding documentation should contain all of the documents needed in your organization to request capital and/or expense dollars for the project. The funding documents generally go to the Project Sponsor first. If the dollars requested exceed the spending level the Sponsor is allowed to authorize, the funding documentation may need to be prepared to go up the management chain for final approval. The funding package should contain an explanation of the costs to sustain current operations, any savings to be realized, and a calculation of the return on investment (ROI) or economic value added (EVA). Usually, your organization’s finance team will provide instructions on how to calculate ROI or EVA. If there is no available information in your organization, there are many excellent texts on ROI/EVA models at your local bookstore.

The funding package should include any project development costs for hardware, software, data formatting and/or conversion, and programming. Project implementation costs such as training, publications, rollout costs, costs of sustaining the product after delivery, maintenance fees, and support costs are included in the funding documents. Finally, the funding documents should disclose funds that have already been budgeted for this project. An appendix should contain any copies of outstanding and/or approved Capital Expense Requests (CERs), Purchase Orders (POs), and vendor invoices (paid and unpaid) that have been received to date. The funding document should provide a complete picture of the costs (now and in the future) for the project. A Cost Estimate Worksheet (CEW) is often the best tool to gather and present this information. A sample CEW is shown as Figure 3.3 on the following page.

Figure 3.3: Cost Estimate Worksheet

3.0.17 Project Budget (PB)

The Project Budget is simply a financial tracking document used to account for all expenses associated with the project. This will be maintained by the Project Manager and kept in the project database. A spreadsheet (see Figure 3.4) which is aslo known as The Project Budget Template is placed in the standard project binder should be used to record both internal time sheets for employees as well as other expenses required by the project. Here are some examples of such expenses:

Original CAR/expense amounts

Committed/allocated funds

Invoiced amounts

Figure 3.4: Project Budget Template.

---