VERSION 1.

0
ACME SOLUTION CENTER

FASE 1 GUIA CONCEPTUALIZACIN

Confidencial Prohibida su reproduccin

REVISIN Y APROBACIONES
Registro de Cambios

2016 Techology Solutions Center, S.A. Derechos Reservados

Fecha

Autor

Version

Referencia

Autorizaciones
Nombre

Versin
Aprobada

Posicin

Fecha

Distribucin
Nombre

Posicin

Propiedades del Documento

Elemento

Descripcin

FASE 1 GUIA - Conceptualizacin

Pgina 1

Confidencial Prohibida su reproduccin

TABLA DE CONTENIDOS
Revisin y Aprobaciones............................................................................................. 1
1.

Limitacin de Responsabilidades.........................................................................3

2.

Resumen Ejecutivo............................................................................................... 4

2016 Techology Solutions Center, S.A. Derechos Reservados

3. Estructura del Proyecto.......................................................................................... 4

3.1.

4.

Estrategias (ENFOQUES) del Proyecto............................................................4

3.1.1.

Metas....................................................................................................... 4

3.1.2.

Objetivos................................................................................................. 4

3.1.3.

Supuestos................................................................................................ 4

3.1.4.

Limitaciones............................................................................................ 4

3.1.5.

Alcances del Proyecto..............................................................................4

3.1.6.

Roles y Responsabilidades.......................................................................5

3.1.7.

Protocolos del Proyecto............................................................................5

3.2.

Evaluacin de Riesgos y Desafos..................................................................6

3.3.

Glosario del Proyecto..................................................................................... 6

Alcances y Visin.................................................................................................. 6
4.1.

Oportunidades de Negocio.............................................................................6

4.1.1.

Definicin de Oportunidades...................................................................6

4.1.2.

Visin....................................................................................................... 6

4.1.3.

Anlisis de Beneficios.............................................................................. 7

4.2.

Concepto de Productos..................................................................................7

4.2.1.
4.3.

Requerimientos........................................................................................ 7

Alcances......................................................................................................... 7

4.3.1.

Lista de Caractersticas y funciones........................................................7

4.3.2.

Fuera de Alcance..................................................................................... 7

4.3.3.

CriterioS de Aceptacin........................................................................... 8

1. LIMITACIN DE RESPONSABILIDADES
Este documento ha sido provisto a Ud. por ACME, S.A. (TSC), el mismo contiene
informacin confidencial y propietaria de TSC, sus distribuidores y/o proveedores.
FASE 1 GUIA - Conceptualizacin

Pgina 2

Confidencial Prohibida su reproduccin

2016 Techology Solutions Center, S.A. Derechos Reservados

Su aceptacin a la revisin de este documento constituye su acuerdo a mantener

este documento confidencial y de refrenarse a discutirlo con cualquier tercero sin
el consentimiento por escrito de TSC.
Si por alguna razn Ud. no est de acuerdo o no puede mantener el contenido de
este documento en confidencialidad como se especifica en los prrafos anteriores,
por favor regrese este documento a TSC o destryalo juntamente con cualquier
copia que se le haya hecho. En dicho evento, por favor provea a TSC una carta
que certifique la destruccin del documento. Si TSC no recibe la confirmacin por
escrito de la destruccin del documento, TSC asumir que Ud. ha estado de
acuerdo y ha aceptado la obligatoriedad de confidencialidad expuesta.

FASE 1 GUIA - Conceptualizacin

Pgina 3

Confidencial Prohibida su reproduccin

2. RESUMEN EJECUTIVO
3. ESTRUCTURA DEL PROYECTO
3.1. ESTRATEGIAS (ENFOQUES) DEL PROYECTO

2016 Techology Solutions Center, S.A. Derechos Reservados

[Description: The Project Approaches section defines how the team will manage and support the project.
These sub-sections provide descriptions of project scope, approaches, and project processes.]

3.1.1. METAS
3.1.2. OBJETIVOS
3.1.3. SUPUESTOS
3.1.4. LIMITACIONES
[Description: The Project Goals, Objectives, Assumptions, and Constraints section describe the project environment:

Goals (the projects final purpose or aim)

Objectives (the goals broken into measurable components)
Assumptions (factors considered true, real, or certain, and that await validation)
Constraints (a non-functional requirement that will limit the project teams options).

Project Goals and Objectives are initially derived from the business goals and objectives that are developed during
the opportunity phase and confirmed during the envisioning phase. Assumptions and Constraints may be derived
from strategic Microsoft services (Rapid Portfolio Alignment, Rapid Economic Justification) and research regarding
the customers environment.
Justification: Project Goals and Objectives articulate the customers and teams expectations of the project and can
be converted into performance measurements. Project Assumptions attempt to create explicit information from
implicit issues and to point out where factual data is unavailable. Project Constraints place limits on the creation of
boundaries and decision-making.]

3.1.5. ALCANCES DEL PROYECTO

[Description: The Project Scope section defines the tasks, deliverables, resources, and schedule necessary to
deliver the customers solution. The tasks are expressed in the Master Project Approach, the Milestone Approach,
the Project Estimates, and the Project Schedule. These multiple views allow the customer and project team to look
at the project from different perspectives and to analyze how the work is organized.
Justification: The tasks, deliverables, resources, and schedule exist at a high level of detail. These Project Scope
statements provide the context for more detailed planning during follow-on project phases.]

3.1.5.1.

ESTRATEGIA DE ALCANCES (MILESTONE)

[Description: The Milestone Approach identifies the significant events in the projects lifespan. During
envisioning, these are usually expressed as External Milestones that identify visible accomplishments of highlevel deliverables and illustrate the projects schedule targets. At the highest level, External Milestones can be
associated with the completion of a specific project phase.
The Milestone Approach identifies the basis for establishing milestones. Depending on the nature of the project,
Milestones can be finance-based, progress-based, product-based, and so on. The Milestone Approach defines
this basis and identifies the milestone events that will be tracked.
Justification: Describing Milestones early in the project establishes high-level time targets the customer can
confirm and the team must anticipate during its planning activities. It also identifies the checkpoints where
Milestone Reviews will occur to assess the projects quality and its results.]

3.1.5.2.

ESTIMADOS DEL PROYECTO

[Description: The Project Estimates section contains an estimate of the resources and costs required for the
project teams to accomplish their work. Resources include people, equipment, facilities, and material. Costs are
calculated by applying rates to each type of resource requirement. This section should contain the following
information, broken out by each functional team

A list of resource types

The amount of the resource required

FASE 1 GUIA - Conceptualizacin

Pgina 4

Confidencial Prohibida su reproduccin

The rate applied to each resource

The cost of each resource
Total cost of resources for each functional team

2016 Techology Solutions Center, S.A. Derechos Reservados

This section should also contain the cost for all resources summed together.
Justification: Project Estimates provide information for calculating the budget estimate. They also enable the
project manager and team leads to identify the specific resources needed to perform the work.]

3.1.5.3.

RESUMEN DE CALENDARIO

[Description: The Schedule Summary section identifies and compiles the collective work tasks and their calendar
dates into a complete project schedule that identifies its beginning and end dates. Each major Project Milestone is
identified and assigned a targeted completion date. The schedule is a consolidated scheduleit includes the
work and dates of all project teams.
The scheduling process is iterative. During the envisioning phase, the projects Major Milestones anchor the
schedule. During the planning phase, the schedule will become more granular as the work tasks are broken
down.
Justification: The Schedule provides the basis for the customer to verify timelines and for the project team to
produce a constrained master plan from which it can validate proposed budgets, resources, and timescales.]

3.1.6. ROLES Y RESPONSABILIDADES

[Description: The Roles and Responsibilities section defines how people will be organized in the project. The
assurance of quality resources and structure begins with creating people requirements and follows with
organizing those people into teams and allocating responsibility. Clear statements of skill requirements and roles
and responsibilities enable the project manager to select the right people and communicate to them how they will
contribute to the projects success.]

3.1.6.1.

CONOCIMIENTO, DESTREZAS Y HABILIDADES

[Description: The Knowledge, Skills, and Abilities section specifies the requirements for project
participants. This is expressed by defining the knowledge, skills, and abilities needed to conduct the project.
These requirements should include technical, managerial, and support capabilities. This information is
organized into functional teams and responsibilities. At the highest level, the KSA can be based on the
standard MSF roles. Each functional team, or MSF role, is listed, and the teams knowledge, skills, and
abilities requirements are defined alongside.
Justification: Knowledge, Skills, and Abilities information will facilitate the careful selection of specific
project participants and provide the basis for creating the core team structure.]

3.1.6.2.

ESTRUCTURA DEL EQUIPO

[Description: The Team Structure section defines the projects organizational entities (project manager,
sponsor(s), steering committee, team leads, etc.), illustrates their relationships to one another, and defines
levels of responsibility and reporting structure. When complete, the team structure assigns names to each
organizational entity and explicitly calls out the individual team (or team members) tasked with executing,
reviewing, and approving the projects work. This assignment is spread across all entities participating in
the project: Microsoft, Partners, and Customer.
Justification: The documentation of the projects organizational structure ensures that all project
participants understand their roles in making the project a success, clarifies lines of reporting and decisionmaking, and provides key stakeholders an opportunity to ensure that the projects organizational structure
(project form) will facilitate the work (project function).]

3.1.7. PROTOCOLOS DEL PROYECTO

[Description: Project Protocols are the set of project processes that must be standardized to ensure all project
participants are performing the processes in the same manner. This standardization creates performance
efficiencies and facilitates a common language among the project stakeholders.]

3.1.7.1.

ESTRATEGIA DE ASEGURAMIENTO DE CALIDAD

[Description: The Project Quality Assurance Approach section defines how the project intends to deliver
products that meet the customers quality expectations and Microsoft/Partner quality standards. It addresses
both the projects management and the development of the projects product. This section should include the
following:

FASE 1 GUIA - Conceptualizacin

Pgina 5

Confidencial Prohibida su reproduccin

2016 Techology Solutions Center, S.A. Derechos Reservados

Quality expectations
Process for assurance (audit, reviews, contractor controls)
Process for control (peer reviews, inspections, tests)
Quality organization (entities, roles, and responsibilities)
Templates for the Product Review, Project Milestone Review, and Customer Approval reports
Training requirements

Justification: A well-developed Product Quality Assurance Approach is key to managing customer

confidence and ensuring the development and deployment of a golden solution.]

3.2. EVALUACIN DE RIESGOS Y DESAFOS

[Description: The Risk and Issue Assessment section identifies and quantifies all the risks and issues that have
become apparent through the envisioning phase. This section should be developed early in the phase and be
updated as more information is gathered. At the close of the envisioning phase, this section should contain all risks
and issues that exist at that point in time. The section should include the following:

Risk Identification/Statements: a list of project risks and the conditions and consequences of each of the
risks
Risk Analysis: the objective assessment of any risks significance; the calculation of risk exposure by
assessing probability and impact for each item on the list of risks
Risk Plan: the actions that will prevent and minimize risks and provide a course of action if risks occur
Risk Priorities: the top x risks the project should focus on

Justification: Early identification of risk enables the team to begin managing those risks.]

3.3. GLOSARIO DEL PROYECTO

[Description: The Project Glossary defines the meaning and usage of the terms, phrases, and acronyms found in
the documents used and developed throughout the opportunity, solution development, implementation, and
operations management phases of product or solution development.
Justification: The Project Glossary helps to ensure good communication and understanding by providing
knowledge, understanding, and common usage for terms, phrases, and acronyms.]

4. ALCANCES Y VISIN
4.1. OPORTUNIDADES DE NEGOCIO
[Description: The Business Opportunity section contains the statement of the customers situation. It is expressed in
business language, not technical terms. This section should demonstrate Microsofts understanding of the customers
current environment and its desired future state. This information is the overall context for the project.]

4.1.1. DEFINICIN DE OPORTUNIDADES

[Description: The Opportunity Statement section describes the customers current situation that creates the need
for the project. It may contain a statement of the customers opportunity and the impact of capitalizing on that
opportunity (product innovation, revenue enhancement, cost avoidance, operational streamlining, leveraging
knowledge). It may contain a statement of the customers problem and the impact of solving the problem (revenue
protection, cost reduction, regulatory compliance, alignment of strategy and technology). It should include a
statement that connects the customers opportunity/problem to the relevant business strategy and drivers. The
Opportunity Statement is written concisely using a business executives voice.
Justification: The Opportunity Statement demonstrates that Microsoft understands the customers situation from
the business point of view and provides the project team and other readers with the strategic context for the
remaining sections.]

4.1.2. VISIN
[Description: The Vision Statement section clearly and concisely describes the future desired state of the
customers environment once the project is complete. This can be a restatement of the opportunity; however, it is

FASE 1 GUIA - Conceptualizacin

Pgina 6

Confidencial Prohibida su reproduccin

written as if the future state has already been achieved. This statement provides a context for decision-making. It
should be motivational to the project team and the customer.
Justification: A shared Vision Statement among all team members helps ensure that the solution meets the
intended goals. A solid vision builds trust and cohesion among team members, clarifies perspective, improves
focus, and facilitates decision-making.]

2016 Techology Solutions Center, S.A. Derechos Reservados

4.1.3. ANLISIS DE BENEFICIOS

[Description: The Benefits Analysis section describes how the customer will derive value from the proposed
solution. It connects the business goals and objectives to the specific performance expectations realized from the
project. These performance expectations should be expressed numerically. This section could be presented using
the following subsections:

Business Goals and Objectives

Business Metrics
Business Assumptions and Constraints
Benefits Statement

Justification: Benefits Analysis demonstrates that Microsoft sufficiently understands the customers situation. It
also defines the customers business needs, which may provide vital information for making solution/technology
recommendations.]

4.2. CONCEPTO DE PRODUCTOS

[Description: A Solutions Concept provides a general description of the technical approach the project team will
take to meet the customers needs. This includes an understanding of the users and their needs, the solutions
features and functions, acceptance criteria, and the architectural and technical design approaches.
Justification: The Solution Concept provides teams with limited but sufficient detail to prove the solution to be
complete and correct; to perform several types of analyses including feasibility studies, risk analysis, usability
studies, and performance analysis; and to communicate the proposed solution to the customer and other key
stakeholders.]

4.2.1. REQUERIMIENTOS
[Description: Requirements identify what the solution must do. These Requirements can be expressed in terms of
functionality (for example, a registration Web site solution will allow the users to register for events, arrange for
lodging, etc.) as well as the rules or parameters that apply to that functionality (for example, the user can only
register once, and must stay in lodging approved by the travel department).
Requirements exist at both the user level and the organizational level.
Justification: User and Organizational Requirements are the key input to developing product scope and design
strategies. Requirements are the bridge between the usage analysis and solution description. A complete
statement of Requirements demonstrates that Microsoft understands its customers needs. The statement also
becomes the baseline for more detailed technical documentation in the planning phase. Good Requirements
analysis lowers the risk of downstream surprises.]

4.3. ALCANCES
[Description: The Scope places a boundary around the solution by detailing the range of features and functions, by
defining what is out of scope, and by discussing the criteria by which the solution will be accepted by users and
operations. The Scope clearly delineates what stakeholders expect the solution to do, thus making it a basis for
defining project scope and for performing many types of project and operations planning.]

4.3.1. LISTA DE CARACTERSTICAS Y FUNCIONES

[Description: The Feature/Function List section contains an expression of the solution stated in terms of
Features and Functions. It identifies and defines the components required to satisfy the customers
requirements.
Justification: The Feature/Function List enables the customer and project team to understand what the
project will develop and deliver into the customers

FASE 1 GUIA - Conceptualizacin

Pgina 7

Confidencial Prohibida su reproduccin

4.3.2. FUERA DE ALCANCE
[Description: The Out of Scope section lists and defines a limited set of features and functions excluded
from a product or solutionthat is, the features and functions that fall outside its boundaries. It does not list
everything that is Out of Scope; it only lists and defines features and functions that some users and other
stakeholders might typically associate with a type of solution or product.

2016 Techology Solutions Center, S.A. Derechos Reservados

Justification: Out of Scope documentation helps to clarify the solution scope and explicitly states what will
not be delivered in the solution.]

4.3.3. CRITERIOS DE ACEPTACIN

[Description: Acceptance Criteria define the metrics that must be met in order for the customer to
understand that the solution meets its requirements.
Justification: Acceptance Criteria communicate to the project team the terms and conditions under which
the customer will accept the solution.]

FASE 1 GUIA - Conceptualizacin

Pgina 8