Group

Project Management
MBA in Information Technology and Communication
COLLEGE RADIAL SAO PAULO 2006
CGM: 2006103634-Josimar Caldas de Souza CGM: 2006102176 - Ismael Paulo Santos CG
M: 2006103636 - Lívia Pereira CGM: 2006103653 - Carlos Eduardo Figueiredo
Project Management
Work submitted to the Faculty Radial essay for consideration to Prof. Ms. Athur
Mandalho.
São Paulo 2006
CASE 1 With Project Management SYSTEMS SUPPORT to project management and process
es in the company
Introduction
One of the more complex activities of those who manage projects is to monitor th
e work of its employees. When it is necessary to upgrade a project is always an
activity exhaustive answer the question "Who worked on what and how much perform
ed?". Furthermore, every project manager needs to give account of how human reso
urces consumed, where and how used. In another instance it is necessary to have
a history so you can plan new projects and consultation elements to approximate
the new value estimates more realistic. The spring is a great tool for planning
and monitoring of projects. Serves as a data source for future historical, but n
ot very friendly automatic update of the effort of a resource.
For this activity WEB RESOURCE CONTROL WRC comes as a supplement which objects t
he launch of activities in a simple and effective.
Figure 1 - Scheme of work of the WRC
WRC - (WEB RESOURCE CONTROL)
It is a tool where those responsible for executing activities that are part of a
project, launch the hours of operation for each action associated with the reso
urce, which can be an analyst, consultant or technician. Hourly updates for the
activities already executed are associated with the resource registered to compl
ete the task.
Patterns of Tool Use Spring
PLANNING
Figure 1 - Steps to Planning within the basic standards required
I - Templates
They are available in the Methodology Manager module, two corporate templates fo
r the Projects: NE0001 - Template Corporate Projects (COM Engagement System) NE0
003 - Template Corporate Projects (SEM Engagement System)
Structure Templates
Figure 2 - Structure of the template (COM system involvement)
It is found in the templates the following main features: WBSs (Work Breakdown S
tructure) The WBSs are created representing stages of the life cycle of the proj
ect: WBS Code INI PLAN CONS SIMU IMP POSIM ATVP Name Start Planning WBS Construc
tion Simulation Deployment Post-Deployment Activities Periodicals Reports Report
s to PMO Extracted Extracted for the PMO reports to the PMO Extracted Reports Re
ports to PMO Extracted Extracted from the PMO to PMO's Reports -
If you changed the WBS Code of WBSs to be drawn to the reports of the PMO system
can not locate them and point the project as Out of Template.
Activity Implementation
Deployment activity is of type Finish Milestone, that is, it must represent the
end of all deployments of the project. His identification (Activity ID) shall be
equal to MIL100 thus the extraction system will recognize this activity and rep
orts to the PMO.
Activities Mandatory and Non Mandatory
All the activities of the templates have a code (Activity Code) named Requiremen
t for Activity and can have values 'Mandatory' and 'Not Required'. This classifi
cation serves to guide users of templates than the minimum required by the proce
ss of Integrated Projects.
II - Project Properties
Calculations
Once created the project in the spring make sure the vision Projects - detail fo
lder Calculations - Field Default Price / Unit Activities for resource without P
rice / Units If the value is nonzero. The value in this field must be at least e
qual to $ 1.00 / h. With this information the spring may perform field calculati
ons of progress that comes from equating Length x Effort x Cost (Earned Value.)
Figure 3 - Setting the default value for resources registered at no cost
III - Schedule of Activities and Resource Allocation
After the project properties set, perform the planning activities and allocate h
uman resources who will work on your project. The complete and correct allocatio
n of resources is important to allow better monitoring of the progress of your p
roject. Progress, according to the concepts of the PMO, will always be calculate
d as a function of time and the distribution of effort in each activity. The all
ocation is incomplete or incorrect, therefore, can distort the indicators for ev
aluating projects of the PMO.
IV - Definition of Risks and Issues
After the planned activities and resources allocated / planned, we recommend the
preparation of the Plan of Project risks, as well as the record of any issues a
lready identified.
Risks
General folder in detail the risks, should - if state: Title of
the risk (Risk Name) Which WBS it applies (Applies to WBS) If it applies to some
specific feature (Applies to Resource) Who is responsible for this risk (Respon
sible Manager) type of risk (risk type) What is your status (Status) Your priori
ty (Priority) And when it was identified (Date Identified)
In particular folder Impact of risk, you should tell what percentage of probabil
ity of risk (Probability) and date of possible impact of this risk (Impact Date)
.
With this information the spring which calculates the potential impact in terms
of effort that your project will have and how many activities could be impacted
if the risk actually occur.
Control folder in detail the risks, which must be described Control Plan for thi
s risk, that is, mitigating actions and contingency.
Issues
In particular the General folder of the issues, inform you: Title of t
he issue (Issue Name) Who is responsible for this risk (Responsible Manager) Wha
t is your status (Status) Your priority (Priority) Date of resolution ( Resoluti
on Date) If the issue is open, this date represents the anticipated resolution.
If the issue is closed to date represents the day of his resolution.
Notes folder in the detail record what actions will be implemented to end this p
roblem.
MONITORING
Figure 4 - Steps to Follow in the basic standards required
I - Baseline Monitoring
It is recommended that before upgrading activities, a baseline is saved as guida
nce for your upgrade. Once saved this 'baseline update', defines it as primary (
primary baseline) and use the Schedule% Complete field to give the information o
f where you should be in your project for the last update.
The field 'Schedule% Complete' present value only if your project has allocated
resources and at least a minimum value for each resource.
It is advisable to use the Baseline Target because it represents the agreed upon
with the Customer.
II - Upgrading Activities and evaluating the impact on the Baseline Target
Once saved the baseline starts - if the update process of changing fields such a
ctivities Duration Remaining Duration% Complete or allocated by the resources an
d effort (and Actual Units Remaining Units)
If you need to compare the durations have the following alternatives: Select t
he desired baseline to baseline primary a. Display the Finish Variance field Dat
e (the date change order the project, comparing the current plan with selected b
aseline). AND / OR b. View the Duration field BL Budget that will represent thei
r original length when the baseline was saved. AND / OR c. Visualize the field V
ariance - Duration. After updating the project found the impact on the baseline
and is no need to renegotiate with the Client. If this alternative applies: Sa
ve a new baseline, Rate this as a Baseline Meta Replace the baseline summari
zation (Planning, item IV)
Do not forget to always summarize your project after an update.
GENERAL RECOMMENDATIONS
R - Base Access
Only projects created on the basis of DBWG0003 spring will be drawn to the repor
ts of the PMO.
II - Accent
We recommend not to use accents, because we have problems with strange character
s in the data extraction. This matter is already being studied by the supplier f
or possible improvements.
III - Synchronization WRC
The WRC (Web Resource Control) software is the control of resources allocated to
projects with direct integration with Spring. Do not forget to always check whe
ther the Project Codes for synchronization of the WRC are associated with your p
roject. WRC Project Code
PROJECT MANAGER
Code Value WRC Functional Project Manager
If the list of Code Values PROJECT MANAGER not contain the desired functional, p
lease ask your creation to the area of support spring.
Interfacing with Primavera, WRC search therein identification information on res
ources, projects and activities. Transforms the user resources and activities av
ailable so that resources can make entries in demand. The releases are made avai
lable to project managers or functional managers for approval. Once approved it
is launching a condensed with other releases of the same resource in the same ac
tivity and updates the spring.€Managers and directors can have detailed informat
ion on reports of launches. This book was created so that your users have a lear
ning how to work with the features of the WRC aiming mainly at the needs of Orbi
tall.
NOTE: The procedures for using the tool directly depends on the project scope, w
e may or may not have the need to use management tools. If you do not make neces
sary to use this resource, we use the physical structure of the architecture of
the company, whose processes are described in the following pages.
The area of Architecture Responsible for receiving the demands on infrastructure
, and to inform the needs for all areas to be involved in the projects Small Ste
ps: 1.it FLOW EXTERNAL DEMAND, with necessary documents. 2.Descrever document ne
eds INTERNAL Infrastructure. 3.SUGERIR flow Answering DEMAND "SERVICE" and check
the possibility to inform the process with new products and / or other Executiv
e Officer.
Structure of Request for Involvement in Infrastructure Project
Areas (Business)
From The bre ma nda Projetosno
N humerus SIG Action (AC)
D efi ni BR
BR
Soli quotes Anal ise Imp act
The prob P ropo sta ecni T
Ap ROV to Cu sto
A p r o v a T Notes I nfo rm Inic io
Ap ro va ça Calls an M ud ing
Area Architecture Infrastructure
And nvol area s E ve spe cial
Vali Ana lysis I mp
And lab now the P rop ost
P T
Closes tion / validation will Mudan ça
C om pa nh An And will there sa Pr oj Im et pl an ta's
F P
Co nst gnaws
Special Areas stas
EPE lab now and spe CIFI hunt s
Provider
Sun IICA rop P ost T in the ECN ica
E xec uta Test Solu tion s of P ropo sta
So LICI ta tion an M ud Calls Mudan ça
ça
Impl anta M uda nca
Cion solutions to the P P Robl ema s in P rodu tion
Planejament the initialization will
Construction Simulation
Project Tracking
Implantation will
Pósimplantaçã the
Documents used for demand control
EP (Implementation Plan) and internal documents of INFRASTRUCTURE, where any spe
cial area of INFRA, you can fill, provided they have been IMPACT ANALYSIS via GI
S, or request FORMAL area of Technology & ARCHITECTURE INTERFACE, because it mus
t meet a project that uses GIS tools, Spring and WRC. PT (Technical Proposal) an
d internal documents of INFRASTRUCTURE fill the Technological Architecture & EXC
LUSIVE INTERFACE, they have received via GIS IMPACT ASSESSMENT, because it must
meet a PROJECT, which uses GIS tools, Spring and WRC. This document also can be
created only with the existence of at least one EP (Implementation Plan).
Internal Process Work Area where
After receiving the documents control demands, we treat the project activities a
s always. The internal process of the area, states that we should open a project
built for any application where through the project team members have the abili
ty to see problems after the project implementation. Monitoring by the area mana
ger is done through the logs we generate when we ask for approval and updates th
e database of the area.
INCLUDE PART OF ISMAEL CASE 1 CASE Without Project Management Project Management
With two used the tool to Uniwiki projetos.O depository of software used is Mid
iaWiki, the second a free software GNU Genreal Public License. For each project
you create a código.O Project Lead may inform the users that access ings and dis
cussed the documentation.
The area has created a methodology for managing five projetos.São the following:
1. Requirements Definition Project This document aims to identify, analyze, def
ine and detail the main features of business involved in the project, as reporte
d by users of the needs and concerns. Provides an effective means of information
sharing among the development team and internal and external customer for valid
ation and acceptance of its contents, making sure that the features to be built
/ modified to meet customer expectations. The revision of this document is held
by all professionals involved in the project, with varied profiles (analysts, us
ers, etc.), therefore, should provide sufficient information for understanding t
he project in a clear and consistent, avoiding technical terms used to implement
. This document can be developed through successive refinements, ie at first ma
y submit summary information that will be detailed during the course of the proj
ect as needed. This document presents the following: project objectives, project
scope, expected benefits, project users,Current Situation and Status Proposal,
Requirements for Business Functionality. For each business functionality are des
cribed the following items: 1. Business Rules; Describe the features and functio
nality of all the business rules that must be considered to generate the results
expected by the user. Identify the inputs required and the products to be gener
ated. There may be involvement of other areas to carry out the detailed business
rules. Can be described in free text or outline. The functionality of business
can be described by successive refinements, ie at first can be summed up and ove
r the course of the project, can be detailed as needed.] 2. Legal and Technical
Requirements; Identify the technical requirements needed to run the application
in terms of hardware, software platforms and operating systems, configurations,
communication, storage and retrieval. Identify legal requirements that must be c
onsidered, such as regulations, decrees and regulations. 3. Restrictions Impleme
ntation; Identify all design constraints, such as people, deadlines, dates, proc
edures, rules and constraints, among others. 4. Level of Service;
Define the performance requirements, including communication skills and processi
ng (quantity, timing, frequency), availability and accuracy and response time fo
r different conditions. 5. Volumetry (Expected Volumes / Frequency / Period / Pe
ak) Set volume estimates of transactions per period, and capacity needed for sto
rage, average and peak processing. 6. Contingency / Exceptions; Define procedure
s for business continuity in times of unavailability of solução.Defina procedure
s when exceptions occur in the processing solution. 7. Security; Describe safety
procedures, ensuring integrity, confidentiality and accessibility to be observe
d for the solution. 8. Audit; Describe the procedures for tracking operations fo
r audit information to be observed for the solution. 9. Retention / Purge Data.
Describe procedures for retention and purging of data to be observed for the sol
ution. Prototype: Displays the file specification of prototypes of functionality
(can be made in the form of a hyperlink.). Strategic Implementation Identify al
ternatives available to implement the solution and develop strategies for each o
ption through scenarios with estimates of time and costs. 2. Diagram Interfaces
between systems represent the involvement of systems and define the responsibili
ties of the areas in implementing a business functionality. Diagram of interface
s between systems should be produced by business functionality - described in th
e Requirements Definition Project. The preparation of a census of more than one
business functionality (by design) should be carefully evaluated for the design
complexity and clarity of representation. This diagram graphically depicts the i
nvolvement of different systems into one solution and its interfaces in order to
generate the expected result of a specific business functionality. Not have the
purpose of representing
functions performed in a hospital system or sequence of execution, his focus is
communication between the systems involved. This diagram should be generated in
a project room (meeting with representatives of all the systems involved), where
they discussed the responsibilities of each system in the solution. For each in
terface should be defined that information is received and returned the system r
esponsibly. After drawing up the diagram, fill in list interfaces between system
s. This document should be sent to all departments involved, it is the responsib
ility of each in the solution. The following items are described in this documen
t: • Description Briefly describe the involvement of the systems in the solution
. • Description of Amendment (Maintenance Only) where maintenance of functionali
ty of existing business, briefly describe the changes made. • List of Interfaces
Between Systems List of interfaces between systems involved in a solution set b
ased on the diagram of interfaces between systems. Determines the responsibility
of each system in the solution. For each interface, define the identifier name
of the interface, concise description of its purpose, the system responsible for
implementation and information will be sent (input) and returned (output). Each
interface represents a system function.€Only new or changed interfaces require
specification of function in the document FUS - systems functions. Column S (Sit
uation) identifies the new interfaces (N) and altered (A). The FUS Number field
must be updated after the specification of the function (FUS), to create traceab
ility between documents. 3. Functions Systems This paper aims to describe the sp
ecification of a logic function of a system. The system functions are identified
during the technical analysis of business functionality and its structure in te
rms of involvement of systems, namely the definition of how the business functio
nality will be implemented by systems (DIS - Diagram of interfaces between syste
ms). In some maintenance projects, the system function to be altered is already
known, so the analyst should evaluate the need for development of DIS. FUS A doc
ument can contain more than one system function if they are related. Functions i
n different contexts require separate documents, so to better organize and retri
eve the documentation of a system. The specification shall contain a logical seq
uence and the implementing rules, calculations, and access to logical entities.
This document sets out the guidelines for construction / modification of a syste
m function. Represents a guide to the work of suppliers (Physical Design and Dev
elopment) and is an indispensable part of
system documentation. Therefore, it should provide enough information not only f
or the understanding and development of systems by the supplier, but also for an
alysts who need to understand the workings of a system. The following items are
described in this document: • System Function Diagram This diagram graphically r
epresents the execution sequence of actions necessary to implement the system fu
nction. Represents the input and output of function (through interaction with ex
ternal entities or systems), the following sub-functions performed, access to da
ta entities and the interaction with the function of other systems. Use abbrevia
tions of the systems involved. • Interfaces the Civil List (With other systems)
List of interfaces between the function and other systems involved. For each int
erface, define the function name, a brief description of its purpose, the system
responsible for implementation, the attributes that will be sent (input) and re
turned (output), the physical name of the function, if known, and technical cons
traints, when necessary. Only new or changed functions require amendment of the
specification of function in the document FUS - systems functions. Column S (Sit
uation) identifies the new features (N) and altered (A). The FUS Number field mu
st be updated after the specification of the function (FUS), to create traceabil
ity between documents. The name of the physical features may be updated after th
e preparation of the physical design phase, which is defined as the physical imp
lementation of the function. • Textual Specification The specification should de
scribe the logical sequence and the implementing rules, calculations, and access
to logical entities, detailing what was represented in Diagram Function System.
The textual specification details the guidelines for construction / modificatio
n of a system function. Should be written clearly and consistently, using techni
cal terms and acronyms systems where necessary. Should provide sufficient inform
ation not only for the understanding and development of systems by the supplier,
but also for analysts who need to understand the workings of a system. It is re
commended that you use a structured specification, with a minimum standard of wo
rds mixed with free text. Use comments throughout the specification, for easier
understanding. On maintenance projects, it is not necessary to specify the whole
system function. The specification must specify only the context and change. Ch
anges to existing specifications, shall be marked with the words "@ @ @ HOME - D
escription" and "@ @ @ END" 4. Specification of Prototypes Drafting the prototyp
es of the functions of business involved in the project, aiming at next year's b
udget.
The specification of prototypes should be developed for functionality of busines
s - defined in REP. This document aims to identify and detail the operation of p
rototypes (screens, reports and layout of input files and output) of a feature o
f business involved in the project. This document is shared between the developm
ent team and internal customer for validation and acceptance of its contents, ma
king sure that the prototypes to be built / modified to meet customer expectatio
ns.€This document is also shared between the development team and the supplier f
or the construction of prototypes, as specified operation. The revision of this
document is held by all professionals involved in the project, with varied profi
les (analysts, users, suppliers, etc.), therefore, should provide sufficient inf
ormation for understanding the project in a clear and consistent, avoiding techn
ical terms used implementation. This document can be developed through successiv
e refinements, ie at first may submit summary information that will be detailed
during the course of the project as needed. The following items are described in
this document: • • • • Screen / Report Represent an outline of the screen or re
port to be constructed / altered. Purpose Describe the purpose of the prototype
represented. Fields Identify and describe the fields on the screen or report, in
dicating those that were included, changed or deleted. Operation Describe in det
ail the operation of the prototype above represented a clear and consistent. It
is noteworthy that this document is used for both understanding and validation o
f the internal customer as to the construction of prototypes by the supplier. Pr
esent observations remarks relevant. Navigation flow represents the flow of navi
gation screens business functionality.
• •
5. Roadmap Test Plan and define the conditions for testing business (approval) f
or business functionality. Project Phases
•
Initial Project
Define the Project Scope and Features of Business involved. Describe the busines
s rules in summary form with necessary information to estimate the budget foreca
st. The objective of this phase is to identify the needs and expectations of int
ernal or external clients in relation to demand and describe the conditions nece
ssary to achieve the project objectives. At this stage, an analysis is made of t
he existing process in order, if necessary, suggest and support the restructurin
g of the methods for the optimization and organization. With knowledge of the pr
ocesses is done raising all the necessary requirements for the development and d
eployment of the system (business requirements, architecture, development, infra
structure, capacity, security and telecommunications). It formalized the opening
of the project and prepared the documentation of the features using the documen
ts and graphics (context diagrams, flowcharts and organization charts) suggested
. In this stage, the internal or external customer to receive the Draft Assessme
nt, containing features to be included / changed its forecast of budget and dead
line for deployment. If you agree with the Draft, Customer must formally accepte
d.
•
Logical Design and Technical
At this stage, the business requirements are detailed in order to fully reflect
the business functionality that will be built or altered to suit the needs and e
xpectations of internal or external customers. Engagements are performed in the
various areas impacted by the demand specification and logic functions of the sy
stems is developed and stored. Planning and Budget (Grade A) at the time and cos
t are refined and vendors that develop the application are selected. The documen
tation generated during the Logical Design and Technical must be approved by int
ernal or external customers. Consolidate Plan and Budget for Project (Grade A) s
upporting the estimated values on a budget for implementing the project. The Pro
ject Leader: Consolidates the estimated values for development, infrastructure,
capacity and telecom on a budget (Grade A). Revises the estimated time for proje
ct implementation. Review the Plan of Implementation of the project.
•
Physical Design and Development
At this stage we formalize the transition from development project to the vendor
. The supplier prepares the physical documentation of the project (books, progra
ms, etc ...) and the deployment plan, return and contingencies. IT validates thi
s documentation before construction starts provider of programs and test the sys
tems. This phase ends with the delivery of the systems tested by the supplier of
the Environment approval and storage of the documentation produced by the suppl
ier.
•
Testing and Certification
At this stage, the systems involved in the project are tested by IT and approved
by internal or external clients in the environment of Approval (system testing
and testing business). Upon approval, the internal or external customer authoriz
es the deployment of systems.
•
Implantation
At this stage, the systems involved in the project are deployed in production.€I
f problems occur, the analyst will evaluate the need to implement the plan to re
turn and register problems (RDP). This phase ends with the closing of the projec
t and updating of project documentation, and business systems.
Environment where there is a project management CASE Without Project Management
In the CBD, specifically for the IT area, the company has a department of projec
t management in the company directly. Eventually, when there are projects to upg
rade technology parks, hardware, software updates, they are designed and impleme
nted indirectly through a service provider company, currently Itautec. Managemen
t of projects in the CBD following the model of balanced matrix organization. Th
e authority of the Project Manager is moderate, because the service is outsource
d, most decisions, including the continuity and monitoring of the project are ma
naged by the operations management of the CBD, not outsource the coordination co
re / media projects. The Board approves the IT budget, requests for updates and
proposed technological changes. Processes are functional and necessary for syste
ms maintenance, monitoring competition, reporting, and competitive advantages. F
irst the project is requested by the Board to management of IT operations, which
forwards the request to the company providing the service. The company takes ca
re of the schedule, budget the required assets, the teams involved, resources an
d technologies needed. Approved budget, the coordinator of the operations of the
company sought to meet with the head of operation of the Sellers for the creati
on of a simple implementation schedule of services.
I believe that this process several steps could be normalized and standardized s
o that we can reduce costs and generate greater productivity in the workplace as
: Better definition of the scope, control routines and processes to document eac
h step of the project, weekly meetings with stakeholders of the Project : Delive
ry of the project report (documentation);
Currently, the problem so we are many: Failures in planning the schedule and sco
pe of the project; Some routine upgrades take about three months, when the proje
ct would be 1 month. For example, when the mainframe emulator Attatchmate licens
e had expired, and the solution Mocha software would be deployed, some stores wh
ere they had terminals which were not logon to the network remained with the old
software, and we had to direct a team of technicians for Merchants where our au
dit found that still had the old software. Solution: If there were phases of pla
nning, the orientation of Sellers with respect to update, network security that
inhibits the access to applications without the proper access rights, this would
be resolved within the time specified. Failures in auditing / Implementation; I
n some stores, we had to adapt IT assets to standardization. After some time, ho
wever, precebemos they had more machines than the standard porposto. Cause: Some
time later, we realized that the company that made the removal of equipment doe
s not contemplate a series of equipment present in the Lodge, which has caused u
s to end up re-apply the current situation of the Lodge for refizéssemos steps.
Finally, there were shops that had nearly twice as many workstations as a common
store. Quality: The Sellers are reported in the last resort procedures. The ear
liest dates are from 05 days prior to deployment. You lose quality in the projec
t's effectiveness, since the test phase is done in only one of the stores to be
applied and the operators of the software or equipment do not have time to be in
timate with the product. CASE 2 Without Project Management for control and manag
ement of new projects developed internally use a control called Funnel Business.
The Business Funnel is updated weekly by the Commercial Department / Projects,
where we have the definition of priority and responsibility of each department r
elated to the projects. We have three types of requests being proposed, and PRE-
SALE SERVICE. MOTION - Definition of resources required as hours worked and inve
stment in infrastructure. PRE-SALE - Home-related tasks schedule Funnel Business
. MAINTENANCE - Definition of resources required as hours worked and investment
in infrastructure for development of the proposal. In all situations are execute
d planning meetings with all involved and only runs after running the tasks bein
g described in the funnel Business
Customer PROPOSAL
Commercial / Projects
Direction
Produ 鈬 the development of information products 鈬 Customer Service
Planning
PR-ノ Customer SALE
Commercial / Projects
Direction
Approved Development Planning Produ 鈬 the products informs the 鈬 Service