Analyze Phase: Perform Project Startup
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Perform Project Startup in the Analyze phase is to initiate various project control activities so that a project folder system is available and project control documentation is ready for use.
This activity begins after a project manager has been assigned and has received any project initiation documentation, specifically the Project Request.
The project manager should complete the major project startup activities as follows:
Create the folder system for the project. This is also known as the project workbook. Go to G:\Bet\Projects\5-Project Folder Template. Select the folder, make a copy of the folder and rename the folder to the project name. This folder directory contains the latest version of the GIS PMP templates. They are also filed in the correct folder per the GIS PMP Checklist.
Request access to the folder system for business users. All GIS members should already have access to the G:\BET\Projects directories.
Create Action Items & Issues document.
Create Assumptions and Constraints document.
Create PMP Checklist.
Create Risk Mitigation Plan.
Create Status Report document. Review and follow the detailed instructions in the Status Report workbook. In the Project Control folder, create a short cut to G:\BET\Projects\1-Status Reports so that the status reports are readily available to the project team.
Create Communication Plan.
Analyze Phase: Complete Scope Statement
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Complete Scope Statement in the Analyze phase is to define the project scope, high level requirements and business and system impacts so that the project team and the sponsor are in agreement as to the starting framework for the project. The scope statement becomes the baseline for all future project activities.
As soon as the project has been approved through the Project Initiation process and a project manager has been assigned, the project request must be expanded into a full scope statement. This document forms the basis for an agreement between the project team, and the requestor and sponsor by identifying both the project objectives and the project deliverables. The scope statement includes:
Justification for the project – indicate why the project is important and what benefits the corporation will realize.
A description of the product – indicate the features it must have and the functions it should perform.
Deliverables of the project – indicate the customers/users of the product, security needs, reporting needs, etc.
Project objectives – indicate what and how a successful project will be measured. Often project objectives are also defined as a hierarchy of high level requirements which will later evolve to detailed requirements.
Each project team should have a Change Control Board (CCB) which is used to determine how to disposition requested changes. The CCB is comprised of the sponsor, requestor, project manager and other key stakeholders identified by the team. Significant project changes must go back through the GIS Approval Committee process. Contact a PMO member to get on the agenda for review or for assistance in deciding if the changes are considered significant. Depending on the impact of the changes, the project may need to also go back to the GIS PST.
After the document has been completed and approved, save as a baseline version.
The Scope Management activity in the Project Control portion of the PMP is used to evaluate project change requests throughout the project lifecycle.
Approved project change requests that impact base-lined documents should be incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of Plan Resources in the Analyze phase is to identify, obtain and manage all project resources (all goods and services, including human resources) so that the appropriate resources are available when needed throughout the life cycle of the project.
Obtaining resources is an iterative process throughout all phases of the project. Early in the Analyze phase the project manager identifies as best as possible the roles (skills) and effort needed to complete the project plan. The project manager estimates the project duration and forecasts using the Resource Requirements document. Any known computer resources which are critical to the success of the project should be documented on the Critical Computer Resource Log (see instructions included in the template).
Resources may come from many organizations, not only GIS. It is especially important to gain approval and commitment for business resources needed by the project team.
Resource requirements are continuously updated throughout the life of the project as the project progresses and more detail is known. Updated effort forecasts are entered in the monthly capacity plan.
During the Complete Scope Statement activity, the project manager works with the appropriate managers (and TDMs when needed) to identify the resources that will be required to complete the requirements document, the WBS and the resource requirements (skills).
Project manager also contacts the business managers for business resources needed on the project, including resources needed to support testing throughout various phases of the project.
Managers identify resource availability and assign resources to the project.
Once the requirements document and the WBS are complete, the project manager updates the Resource Requirements by resource role. For example: DBA, Web Developer, Tester. If two or more of the same role are needed (2 DBAs, 3 Testers, etc.) enter each on its own row. This includes business resources required throughout the project. It also includes resources for code reviews, identification and delivery of maintenance & support turnover documentation, backup when key resources are unavailable and resources which will be required for production support once the product is deployed.
Project manager estimates the effort needed per resource role based on the WBS.
Through the project life cycle, the project manager reviews resource requirements with the appropriate managers at agreed-to intervals, to identify changes in resource needs. Due to constrained resource skills and availability, it is imperative that resource changes/needs are communicated as far in advance as possible.
The procurement processes are outside of the GIS PMP and are managed by the Sourcing department. The following URL provides links to related forms, instructions and information: http://gandalf.stortek.com/wwsrc/purchasing.shtml
See your manager for assistance in determining the specific steps which must be followed for the individual project's circumstances.
At times it may be necessary to obtain resources through external sources, such as consulting firms. At StorageTek, the project manager makes the request to purchase goods and/or services to their manager.
New hardware and software purchases must go to the TRC (contact the architecture manager or the architecture team lead).
Once the forms are complete, they go through a series of approvals and end up in the Sourcing Department which is responsible for procurement management activities.
The project manager’s responsibility is to work with the purchasing agent to clarify and validate the project’s requirements for the goods/services being purchased.
After the document has been completed and approved, save as a baseline version in the Project Control folder.
When updated, save as a new version. If there are significant changes to resource assignments or effort, you must also obtain approval from the appropriate managers.
Analyze Phase:
Conduct Kickoff Meeting
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of Conduct Kickoff Meeting in the Analyze Phase is to hold an initial project meeting so that all team members are brought up to speed on project information.
Project Kickoff is an opportunity to bring the project team together to discuss scope, requirements, processes, roles and responsibilities, expectations, project organization, project documentation, project tools and all other project information. This activity includes planning for, conducting, attending and documenting the kickoff meeting. Prior to the meeting make all documents available to the project team for review. Invite not only project team members but also business and technical subject matter experts who may be impacted as well as other interested business, technical or organizational areas.
There may be a couple of kickoff meetings – one for the initial core team that will complete the requirements document and the WBS. A second one with the expanded team identified and assigned when the schedule is built.
Analyze Phase:
Determine Requirements
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Determine Requirements in the Analyze phase is to obtain, understand, validate, document and gain business signoff for all business and technical requirements so that the project is positioned to meet stakeholder expectations.
The high-level requirements used to establish project scope are refined to detailed business and technical requirements that clearly define the functions and services to be delivered and the critical attributes of those functions and services. Review the scope statement to identify high-level requirements and determine if there are any additional requirements. Once all high-level requirements have been captured, drill down to the detailed requirements.
Individual requirements should be unambiguous, understandable, complete, appropriate, and verifiable. The set of requirements should be consistent, complete, maintainable, and traceable. An example of a poor requirement is “Easy to use”. A better requirement would be “No more than 3 mouse clicks from entry to home page to lowest level of information.”
Each individual requirement must also include user acceptance criteria. Identifying user acceptance criteria assists in understanding the full extent of the requirement. User acceptance criteria evolve later into test cases for use during the testing cycle.
User acceptance testing and formal acceptance of the product is based on compliance with the detailed requirements. Delivery of products and services will be measured at the end of the project against the agreed upon baseline requirements as well as any additional requirements approved by the sponsor and requestor during the scope management process.
Requirements fall into several categories, consider requirements in each category to assist in definition of all project requirements:
Functional requirements describe the features of the system in user language. They include requirements for business functions, transactions, tasks, user profiles and access control, security issues, training, documentation, information/data, reports, data conversions, content and content management and international/global/localization. They also include any ISO compliance or regulatory requirements.
Performance requirements identify any requirements for capacity, speed, up time, batch-processing turn around window, data management and retention, and business continuity.
Interface requirements identify automated interfaces to other internal systems and applications. They also include external interfaces to vendors, suppliers, customers, government agencies, and companies such as 401K administrators. Include frequency and formats when known. Identify both incoming and outgoing interfaces.
Design requirements identify requirements for operating system, hardware, software, user-interface standard and type, architecture and security structure. Please note that this requirement type does not imply that you should include application or system design in the requirements document. Instead it asks you to identify if there are any design constraints that must be considered to be a project requirement.
Implementation requirements identify requirements for program language, use of existing equipment, installation and training.
Maintenance and support requirements are identified by the support teams and include requirements which are necessary in order to take over production support of the new/enhanced project product.
If requirements extend beyond the project scope the scope statement must be revised or the requirement must be excluded (see Project Control: Scope Management). Example, the scope statement indicates that the audience will be US only, however, there is a requirement that France needs the application. This change must go through the formal project change control process.
Each project team should have a Change Control Board (CCB) which is used to determine how to disposition requested changes. The CCB is comprised of the sponsor, requestor, project manager and other key stakeholders identified by the team. Significant project changes must go back through the GIS Approval Committee process. Contact a PMO member to get on the agenda for review or for assistance in deciding if the changes are considered significant. Depending on the impact of the changes, the project may need to also go back to the GIS PST.
After the document has been completed and approved, save as a baseline version.
The scope management activity in the Project Control portion of the PMP is used to evaluate project change requests throughout the project lifecycle.
Approved project change requests that impact baselined documents should be incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
Analyze Phase:
Apply Measurement Guidelines
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
The purpose of Apply Measurement Guidelines in the Analyze phase is to ensure applicable measurements are documented so that the success of the project can be assessed objectively and to identify triggers for re-planning activities.
The measurement guidelines document the measurement activities required on all GIS projects. Any deviations from this plan or project specific measurements must be documented and approved by the appropriate manager.
Project metrics are captured and analyzed for the following reasons:
To provide the project manager with information needed to manage, track and report progress and assess performance during project execution.
To identify which measurements will be recorded and reported including their purpose, frequency of collection, granularity and source and to identify when corrective actions are needed.
To document project metrics and use them in future estimating of projects with similar characteristics.
To provide information that can be used to identify areas for process improvement.
To identify specific thresholds or measurements used on the GIS dashboard.
To relate project measurements to the objectives of the organization.
Measurements will be taken during the project and at the end of the project. Consistent measuring will ultimately allow the GIS organization to better manage customer expectations, improve the development process and improve our estimating ability.
Analyze Phase:
Determine Project Solution Approach
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Determine Project Solution Approach in the Analyze phase is to use a decision analysis method to assess various solution approaches against project requirements so that the project team, business users, sponsor and requestor have an understanding of the product to be delivered by the project.
In general the project approach will define the manner and methods to successfully complete the project objectives and commitments. The project approach may be defined in one or more ways.
This activity defines the boundaries for the project and/or the general manner and methods for successful project completion against objectives and commitments. At this point in the project lifecycle the solution/approach should be described in business terms. Engineering terminology will be included at the time of solution (technical) design. The boundaries identify the primary functions and services to be delivered by the project. The approach provides a general agreement on how the functions and services will be provided. For example, a web page vs. an SAP module.
The project team, sponsor and requestor also need to determine if the ultimate product will be delivered through a series of generations (phases). If so, the team needs to determine what portion of the product will be delivered in each generation.
In addition, they must determine if they will use an iterative or fast-track approach within the project lifecycle. If multiple iterations will be performed, the project must determine the iteration approach for the project, specifying iteration objectives. If a fast-track approach will be used, the team must pay particular attention to additional risk this method will introduce into the project lifecycle. These decisions will help determine how the project schedule is built, how the commit date (or dates) will be established for the project, as well as how reporting on percent project complete will occur.
Determine Project Solution Approach Instructions:
Determine a way to define a project approach. Examples are solution alternatives, product groupings, project iterations, project phases and fast-tracking.
Determine a set of factors or criteria to use to evaluate the approaches. Possible factors are:
Business objectives
Business and technology direction
Key success factors
High-level business requirements
Project constraints
Policies
Project strategies/tactics
Cost
Timelines
Resources - number and skills
For each approach, if there is more than one to be considered, follow a decision analysis method where each approach is evaluated against the same criteria.
Document the recommendation resulting from the decision analysis activity.
Analyze Phase: Assess Technical & Architectural Impact
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
Objectives:
The purpose of Assess Technical & Architectural Impact in the Analyze phase is to review the technical impact of the proposed project solution against existing or proposed architectural standards as well as the existing technical and application infrastructure so that the project's product will be planned within the generally accepted architectural framework and there will be a complete understanding of the technical infrastructure/architectural requirements and resources needed for implementation of the project.
The architectural design document is completed by the architect with the assistance of the project manager, technical project team members, and when appropriate a supplier, and provides basic architectural information that helps the architecture team determine impacts to the current architecture and/or the need to present the project to the TRC for review. Many projects will fit into the existing infrastructure and applications environment. However, others may require changes to StorageTek’s defined architecture and/or purchase of new hardware and software. The TRC must approve all such changes. The CIO must approve all new software.
When the architecture team has the opportunity to review project impacts early in the project lifecycle, they can also contribute suggestions as to the appropriateness of various solutions.
If necessary, initiate (or update) the Critical Computer Resource Log with those items which are determined to be critical to the project's success.
This activity provides the opportunity for a detailed architecture walkthrough. The detailed walkthrough of architecture documentation also includes sign off from all Green Team members. See the Green Team Process for more details. Documentation to be used and included at this time, where applicable, will be as follows:
Physical/logical diagram, including HW/SW requirements (Boxes, OS, DB, tools, etc.)
Special configurations, settings, etc.
Any licensing considerations, vendor documentation, contacts
Special considerations for impact to existing systems or environments
Documents proof-of-concept lab test results
Detailed information about the impact to the infrastructure will also help the project manager understand other areas that should be contacted for the purpose of determining requirements.
Architects and Green Team members work side by side on architecture issues throughout the project, where necessary.
Project manager sends a copy of the requirements document, the scope statement and the project solution approach to the architecture manager and team lead.
Architecture manager or team lead will assign the appropriate architects and communicate their names to the project manager.
Project manager coordinates a meeting between the technical project team members, the assigned architects and a supplier if appropriate. All invited participants must either attend or send a designated representative to the meeting so that re-work is minimized.
The architects will produce the architectural design.
The architects will also decide if the project needs to go to TRC.
If TRC is not required, the project manager informs the TDMs of project objectives for production support considerations.
If this is a project that has already gone to TRC, the architects perform a detailed walkthrough of architecture documentation with sign off from all Green Team members.
Analyze Phase:
Setup Development & Test Environments
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Setup Development & Test Environments in the Analyze phase is to complete all technical tasks necessary to ensure the readiness of the development and test environments so that the project team has complete access to fully configured development and test environments.
This activity ensures that the appropriate project-specific development and test environments are in place. This activity includes designing and building the architecture. This involves the full spectrum from obtaining hardware and software to installation and configuration of the hardware and software, network, PC, etc. It includes the installation and setup of new tools. It also includes security design and access, database setup and installation. Training may also be necessary before the setup can be completed.
Analyze Phase:
Create Test Approach
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
TestDirector |
Objectives:
The purpose of Create Test Approach in the Analyze phase is to develop, document and plan the types of anticipated project tests so that all impacted resources are aware of project expectations and a preliminary schedule is developed for all project testing.
All projects must plan for unit testing, code reviews, functional testing, release testing, user acceptance testing and production validation. When needed, projects should also plan for performance testing.
Standards – unit testing, etc. – for the project
High level test cases (use cases)
Tools needed for testing
Resources (roles) needed for testing
Testing scope
Methods of testing, including capturing results, feeding information back to the team (*TestDirector is used to track functional and release test results)
Training needed before testing can happen
Facilities for testing (location, PCs, etc.)
Planning far enough ahead when need to bring in users, especially from outside
Gaining business user commitment to providing needed resources
Who will write the test cases, test scripts
Setup of test environment
* The project manager contacts the test team to request a project folder be set up in TestDirector for their project. The test team can also provide training for the TestDirector tool if necessary.
Analyze Phase:
Create Project Schedule
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Create Project Schedule in the Analyze phase is to develop the project schedule (work breakdown structure, work effort estimates, dependencies and resource assignments) so that the resources and effort can be documented so that all project stakeholders have a common expectation of what can be expected from the project and so that the project manager has a tool to use to guide and manage the project.
As part of this activity the project manager with the assistance of the project team identifies all work to be done on the project. WBS activities that are too large for effective management are broken out into smaller activities or tasks. Task dependencies and resource assignments are documented. The project schedule will then be determined based on the agreed-upon staffing level and work effort estimates. The critical path should be analyzed and resource leveling completed to ensure that the schedule is realistic.
Although creating the project schedule should be an iterative effort, it also provides a baseline for progress measurement and project control. Keep in mind that any changes to resource needs, especially timing, must be reviewed with managers of the resources. Communicate to all management, GIS and business, the level of effort and time frame in which resources are required.
The project schedule lists planned dates for performing activities and meeting milestones. It is expected that this document will change over time as part of the Schedule Management activity under the Project Control phase.
GIS uses the MS Project application for project schedules.
Identify major deliverables required to complete the project and break them into smaller, more manageable activities until they are defined to the point that the project team members have sufficient details to accomplish the activity. Start with the basic structure of the GIS PMP by using the schedule template. Add tasks as necessary for the specific project. Project managers are free to adjust the predecessors and successors to fit the project's needs. Tasks may also be re-organized to fit the project's needs.
Identify whether or not the team can adequately estimate costs and durations at the level the activity is identified. If not, break the activity down into smaller activities/tasks. For example, if the activity is “Build the Production Environment”, it may be difficult to estimate resources and duration at this level. Break this into smaller activities/tasks such as “Setup server”, “Install OS”, “Build database”, etc. Perform this step for each major activity.
To help verify that the activity/task has been captured at the right level, ensure:
that the activity is required
that the team can estimate the duration and resources required for the activity
that it can be assigned to a single entity (person, team, department, etc.).
If not, repeat Step 2. Complete this step for each deliverable.
For each activity identify the predecessor and successor activities. During this step, consider the types of dependences (finish to start, finish to finish, start to start and start to finish) and lead and lag time.
Link activities to "child" activities rather than to "parent" activities.
All activities must be linked to at least one successor and one predecessor activity. The only exception is the first and last activities. This will allow Microsoft Project to automatically determine the project's critical path. It will also provide the ability to predict how delays or early finishes will impact the entire project schedule.
Estimate the duration of each activity based on the activity, resource skill levels and availability, experience, historical data and known risks. Standard project management practices indicate resources should not be scheduled for more than 70% of their available time. This allows time for meetings, training, etc. In addition, there are formulas which can be used to help with estimating. Always build some “padding” into the schedule to compensate for unknowns. Be sure to document how the schedule was built in case adjustments need to be made in the future.
Review the schedule to ensure that all project deliverables are represented on the schedule. Use the requirements document to complete this step. For example, if one of the requirements is to provide a web-based tutorial for the application being built, make sure that the tasks required to build the web-based tutorial are on the schedule.
Each project team should have a Change Control Board (CCB) which is used to determine how to disposition requested changes. The CCB is comprised of the sponsor, requestor, project manager and other key stakeholders identified by the team. Significant project changes must go back through the GIS Approval Committee process. Contact a PMO member to get on the agenda for review or for assistance in deciding if the changes are considered significant. Depending on the impact of the changes, the project may need to also go back to the GIS PST.
After the document has been completed and approved, save as a baseline version in the Project Control folder.
The Scope Management activity in the Project Control portion of the PMP is used to evaluate project change requests throughout the project lifecycle.
Approved project change requests which impact baselined documents should be incorporated into a new version of the document. Do not overwrite the baseline version or subsequent versions – there should be a version for each change after the initial baseline document.
Analyze Phase:
Create
Cost Plan
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of Create Cost Plan in the Analyze phase is to identify expected project costs so that stakeholders understand the estimated project costs for planning and decision making purposes.
The cost plan is a way to identify estimated project costs, both expense and capital. These costs should be broken out by each month of the project, throughout the project life cycle. The summary of this information is recorded, tracked and monitored in the status report.
Use the cost plan template (detailed instructions included) to calculate and document estimated project costs. Record this in the "Forecast Costs" portion of the "Cost" sheet in the status report.
Prior to the Design, Cost Plan & Schedule review, make any necessary changes to the cost plan. Be sure to identify and document each change. Along with the Design, Cost Plan & Schedule review, cover the forecast costs with the sponsor and requestor and obtain their approval. This becomes the “baseline”. Record this in the "Baseline Costs" portion of the "Cost" sheet in the status report.
Project managers do not usually have visibility to actual budgets. For monitoring and reporting purposes, assume that baseline costs are equal to actual costs unless you are aware of significant differences. If significant negative differences, determine corrective action plans and record in the status report.
Update the "Actual Costs" portion of the "Cost" sheet of the status report each month.
Update the project status report as appropriate:
If minimal or no difference, status is green.
If noticeable variance, status is yellow and requires a corrective action plan.
If significant variance, status is red and requires a corrective action plan.