This is not the document you are looking for? Use the search form below to find more!

Report home > Education

gestion de proyecto

0.00 (0 votes)
Document Description
pdf de gestion de proyecto
File Details
  • Added: June, 07th 2010
  • Reads: 339
  • Downloads: 3
  • File size: 804.52kb
  • Pages: 25
  • Tags: gestion, proyecto, pdf
  • content preview
Submitter
  • Name: julio
Embed Code:

Add New Comment




Related Documents

Gestion de la relation client

by: jawadzik, 489 pages

Gestion, relation, client, Gestion de la relation client

Expertos en posicionamiento web y gestion de redes sociales

by: slavetwist20, 2 pages

Una buena manera de conseguir que su sitiotenga un mejor ranking a través de la optimización de mot...

Expertos en posicionamiento web y gestion de redes sociales

by: calf8heart, 2 pages

En Fusionarte Comunicación agencia de publicidad, marketing y social media, asignamos un community m...

Modelo de Proyecto

by: tegan, 54 pages

Modelo de Proyecto

This Is A Swift ESTUDIO Tener Éxito Con Junto Con posicionamiento web en madrid y la gestion de redes sociales ( social media marketing)

by: couchplain9, 2 pages

La última novedad para llegar a la primera página de Google Más allá de todas las acciones conocid...

This Is The Swift ESTUDIO Tener Éxito Con Along With posicionamiento web en madrid y la gestion de redes sociales ( social media marketing)

by: couchplain9, 2 pages

Los 5 factores más importantes de SEO para Bloggers Bloggers no voy a hablar entrar en comparar pla...

This Is A Speedy Técnica Para Éxito Along With posicionamiento web en madrid y la gestion de redes sociales ( social media marketing)

by: couchplain9, 2 pages

Como hacer posicionamiento web y no morir en el intento Es muy facil canibalizase co una empresa se...

Proyecto De Vida

by: alide, 30 pages

PROYECTO DE VIDA VERONICA ROARO AUTOCONOCIMIENTO Capacidades y limitaciones Rasgos de personalidad Gustos y preferencias ...

Mi proyecto De Vida

by: juhana, 22 pages

Mi proyecto de vida Visión ¿Qué deseo Lograr? Visualícese en 5 años: ¿Cómo se ve? ¿Cómo se ...

Gestión de contenidos

by: inigo, 50 pages

Apuntes de Gestión de Contenidos

Content Preview

Objective Based Planning
Whitepaper
Version: 2.4

Objective Based Planning

Whitepaper
Disclaimer and Trademarks
© Select Business Solutions, Inc. 2003. All Rights Reserved.
Information in this document is subject to change without notice and does not represent a commitment
on the part of Select Business Solutions, Inc. to provide or continue providing said functionality. This
document may not, in whole or part, be copied, photocopied, reproduced, translated or reduced to any
electronic medium or machine-readable form without prior written consent of Select Business
Solutions, Inc. Company names, data and other information appearing in examples are fictitious in
nature unless otherwise designated.
The software described in this document is furnished under license or non-disclosure agreement and
may be used or copied only in accordance with the terms and conditions of that agreement. It is
against the law to copy the software on any medium except as specifically allowed in the license or
non-disclosure agreement.
Select Enterprise is a Registered Trademark of Select Business Solutions, Inc., and Select Component
Factory, Select Component Architect, Select Component Manager, Select Component Portal, Select
JSync, Select CSync, Select C#Sync, Select ForteSync, Select VBSync, Select DBSync, Select
XMLSync, Select ORSync, Select Document Generator, Select Object Animator, Reviewer for Select
Component Architect, Reviewer for Select Enterprise, Reviewer for Rose, Select Process Director,
Select Process Director Plus, Select UDDIServer, Select Application Composer, Select Scope
Manager, Select Perspective, Select SE, Select SSADM, Select Yourdon are all Trademarks of Select
Business Solutions, Inc.
Because of the nature of the material, numerous hardware and software products are mentioned by
their trade names in the publication. In most, if not all, cases these designations are claimed as
trademarks by their respective companies. It is not the publisher's intent to use any of these names
generically, and the reader is cautioned to investigate all claimed trademark rights before using any of
these names other than to refer to the product described.
For more information about Select Business Solutions Inc., or to download an electronic copy of this
document please visit the Select Website: http://www.selectbs.com/
© Select Business Solutions, Inc. 2003
Page: 1


Objective Based Planning

Whitepaper
Table of Contents
Introduction ......................................................................................................3
This Document ..................................................................................................................... 3
Monolithic Processes ........................................................................................................... 3
Agile Processes.................................................................................................................... 4
About Select Business Solutions.......................................................................................... 4
Managing Projects Using Monolithic Methods..................................................5
Reality Check ....................................................................................................................... 5
Team Impact......................................................................................................................... 6
Surely There Must Be A Better Way… .................................................................................. 6
Revolutionary Processes and Project Management.........................................7
Reality Check ....................................................................................................................... 8
Team Impact......................................................................................................................... 8
Surely There Must Be A Better Way… .................................................................................. 8
Squaring the Circle ........................................................................................10
Select Perspective.............................................................................................................. 10
Foundations of Agile Planning........................................................................12
Time-Boxed Increments ..................................................................................................... 12
Increments and Select Perspective.................................................................................... 13
Products Re-Defined .......................................................................................................... 14
Planning With Scope and State.......................................................................................... 15
Objective-Based Planning..............................................................................16
Increment Objectives.......................................................................................................... 17
Impact of Supply-Manage-Consume.................................................................................. 18
Objectives and Product States ........................................................................................... 19
Product States and Processes ........................................................................................... 19
Supply-Side Economics ..................................................................................................... 20
Planning is Iterative, Too .................................................................................................... 21
Agile Project Management .............................................................................22
Agile By Alternative ............................................................................................................ 22
Agile By Addition ................................................................................................................ 22
Agile By Adaptation ............................................................................................................ 22
Agile By Automation ........................................................................................................... 23
Conclusions ...................................................................................................24

© Select Business Solutions, Inc. 2003
Page: 2


Objective Based Planning

Whitepaper
Introduction
Project Management has traditionally been and remains a problem area for the IT industry. According
to many research papers, the majority of projects fail to deliver their critical success factors – time, cost
and scope.
This Document
This document reviews the issues and problems surrounding the planning, management and control of
projects in both monolithic and agile environments. It discusses how these problems can be addressed
and overcome using the principles embodied in Select Perspective. The result is a new and more
effective approach to project management. Lastly, the issue of project management skills is addressed,
showing how effective tool support can speed the production of effective, consistent and reliable
project plans, reducing reliance on increased project management skills.
The audiences for this document are the IT and Project managers who every day face the problem of
ensuring that projects deliver. Deliver on time, on cost and on scope.
Monolithic Processes
Traditional, monolithic processes sought to address these issues by laying everything down in stone –
the flow of activity in the process, the deliverables to be created, the meetings to be held. Not
surprisingly, these methods are viewed as overkill by many in the industry and are seen to stifle the
individual creativity of team members. These monolithic processes are based on the view of software
development as pure engineering. Recent work indicates that whilst elements of software development
are akin to engineering, the balance between creative and constructive work is very different to that
found in most engineering practices.
Failure of monolithic processes is normally attributed to two faults – the process is abused (witness the
cherry-picking that takes place in the typical SSADM project) or the project manager fails to estimate
and plan the work sufficiently well. However, to plan “well enough” requires almost perfect
knowledge of the problem domain before the project even starts. Even alleged scientific methods of
estimation, such as function point counting, assume that all projects will proceed identically –
essentially an engineering viewpoint.
Several times in the history of the IT industry, revolts have developed in an attempt to overthrow the
tyranny of the monolithic process. The RAD revolution of the late 1980’s has been followed in the
new millennium by the Agile revolution. These revolutions are based on apparent common sense –
why apply rigorous, heavyweight processes to activities that can be planned easily and adjusted in the
light of experience as the project proceeds. Or, with even more common sense, why continue using
techniques that manifestly do not work well.
In many ways, this common sense view is a fallacious as the engineering view. There may be many
projects that can be executed in an “agile” way, but the approach is insufficiently disciplined to support
large-scale development work where the majority of IT effort is spent. What is needed is an approach
that balances the ability to plan, monitor and control with the ability to be flexible and responsive to
change. What is more, these abilities must be balanced differently depending on the scale and other
characteristics of the project.
Revisionist tendencies quickly appear in even the best revolutions. In the RAD revolution, the DSDM
consortium advocated the importance of architecture to underpin and give direction to the iterative
prototyping activity – coining the acronym RAAD or “RAD with Architecture”. Select Perspective – a
leading light in the DSDM consortium – espoused a practical balance between modeling to explore
architecture and prototyping to explore requirements.
In the Agile revolution, concepts such as Agile Modeling are beginning to impose structure, direction
and predictability – in-short a (light-weight) process – on agile teams. Again, Select Perspective is
leading the way, advocating an agile approach within a framework that enables planning, predictability
and control.
© Select Business Solutions, Inc. 2003
Page: 3


Objective Based Planning

Whitepaper
Agile Processes
Best project practice is adopting many of the ideas advocated by the agile school of thought. Every
project is different and this must be taken into account when planning the project. No rigid, non-
adaptive process can match the complexities of the different styles of project that can arise in a single
organization, let alone across all the organizations that it would have to support.
Modern development processes, such as Select Perspective, spurn the idea of a fixed sequence of tasks
that must be executed in every project. Rigidity is replaced with a series of process maps, each
showing the best routes from objective to objective, avoiding the pitfalls and disasters that can
otherwise occur. Even with a map, different routes will suit different projects – by taking into account
the characteristics of the project and the risks that are likely to occur, the route over the terrain can be
fine-tuned helping to maximize the chances of a successful completion.
Such an approach, though, requires greater levels of expertise than project managers typically possess.
No longer can the project manager base their plans on fixed sequences of tasks that do not vary from
project to project. No longer can the project manager assume the plan will remain (largely) unchanged
from inception to completion. No longer can the project manager remain ignorant of the basic
techniques and products created by the team.
About Select Business Solutions
For more than 10 years, Select Business Solutions has created a successful track record with tools and
process solutions and is generally recognized as being one of the early adapters of Service and
Component Based Development (CBD) worldwide. The technology behind the Select tools is
continually recognized as being innovative, ensuring that customers’ demands are met to the fullest
satisfaction. It is this three-way focus on development, customers and emerging markets that makes
Select Business Solutions a leader in its field.
The ADT division of Select Business Solutions provides a comprehensive suite (named Select
Component Factory™) of business software development solutions comprised of Select Component
Architect™, Select Component Manager™, Select Component Portal™, Select UDDI Server™,
Select Process Director™, Select Reviewer™, Select JSync™, Select VBSync™ Select C#Sync and
C++Sync™. These tools are supported by a full complement of professional services (support,
training, consultancy/mentoring) in addition to the development method, Select Perspective™.
Select Perspective is delivered through Select Process Director, which enables users to amend and
maintain the definition of the process to suit their organizations’ culture and working practices.
Adding further value, Select Process Director delivers the process in a practical way, helping project
managers to focus on the optimal planning of their projects and encouraging team members to play an
active role in following the process and feeding back suggestions for process improvement.
© Select Business Solutions, Inc. 2003
Page: 4


Objective Based Planning

Whitepaper
Managing Projects Using Monolithic Methods
An examination of the historical and current issues facing projects that use monolithic methods defines
the context in which new
Agile methods have arisen.
Monolithic methods attempt to impose certainty on project planning and estimation by establishing a
fixed roadmap of processes, tasks, techniques, organization and products that must be created during a
project. Theoretically, project planning and estimation then becomes a relatively simple task of taking
size and complexity into account and scaling the effort assigned to each activity accordingly.
Monolithic methods fail to provide effective mechanisms for responding to changing circumstances.
Project managers who recognize the very real differences that exist between projects then have to
cherry-pick from the processes and products that comprise the method in order to ensure that their
project can deliver with a reasonable degree of efficiency. Choices to omit tasks are often obvious – at
least at first glance. However the choices made can have unexpected side effects which significantly
raise the risk profile of the project, and there is no way to ensure that the delivery plan is consistent in
terms of the chain of products created.
Even worse, the additional risks will not be monitored, nor will effective mitigation strategies be in
place. The increase in risk that results from mix and match planning is unknown, unexpected and
unplanned for.
Requir
Re
ement
quir
s
ement
Design
Code
Co
Integrate, Test Fix
Moving ta
Moving r
ta get
Take
Ta ai
a m
Figure 2 - Monolithic process cannot change - aim, fire and miss
Change is seen as a significant threat to these projects, yet real experience suggests that change is the
only constant that can be relied on. To ensure that the delivered solutions remain aligned to the
underlying business need, it is essential that the set of requirements be allowed to evolve over the life
of the project. The project plan must be sufficiently robust and flexible to take into account the rate
and degree of change likely to be experienced. Change to scope and content can be managed as it
occurs rather than having a significant and surprising effect at the end of the project. Managing
change continuously avoids the Sword of Damocles that huge accumulated change often represents to
a project.
Since change is perceived as a threat, monolithic methods try to limit the impact of change by stifling it
with over-bearing change control procedures. The team is unable to respond effectively to requests
from the user community resulting in frustration on both sides. The project is unable to respond
adequately to the requested changes so that the delivered solution fails to live-up to the users’
expectations and the project is perceived as a partial failure at the very least.
Reality Check
No one is perfectly prescient; it is inevitable that the initial project plan will fail to take into account all
the incidents that will impact the project as it proceeds. Indeed real-life is so complex that no plan can
take into account all the possible combinations of factors that will impact the project – even if it could,
the resulting plan would be so complex that it would be impossible to follow.
© Select Business Solutions, Inc. 2003
Page: 5


Objective Based Planning

Whitepaper
Incident follows incident in the project, creating a cumulative impact; the project plan becomes
increasingly inaccurate. At some point in the project, the manager is faced with unpalatable
alternatives. Abandon the project plan, sound the alarms and get the team into a coding frenzy –
typically symptomatic of the “death-march” project. Alternatively, abandon the project plan - and
replace it with a new one.
Whatever, the plan has been abandoned. Re-planning is the more responsible choice, but it means
facing the political realities of having to reset the users’ expectations. Worse still, it probably entails
changing the project timescales and budgets.
Many project managers – often for the best of motives – resort to the coding frenzy approach. They
believe that delivering the project at all costs is the more effective choice. However, the delivery, if
made at all, will usually be of poor quality, lack key required functionality and will require extensive
remediation after deployment. In other words, the project is still late and over budget and because the
project manager did not get agreement for these changes, the users have lost effective control over the
costs and timescales. The best of motives has led to the worst possible outcome.
So, there goes another project failure; too late, too expensive and too little functionality. Collateral
political damage will be immense and the relationship between the users and IT irreparable. Of course,
corporate politics being what it is, the project will be presented as a success – after all, it met the
budget, timescale and scope (4th revision).
Team Impact
The efficiency of a monolithic process is also open to question, even if the project is blessed with a
highly skilled project manager - capable of pruning redundant steps and products from the process, and
creating a productive and effective project process. How productive will the project be? The answer
is dependant on the productivity of the team members. Much of the work involved in systems
development is creative – certainly teams free to exercise a degree of creativity in the way they work
build the best solutions.
Monolithic processes by their very nature are rigid and inflexible; they impose constraints on the way
the team can work and on the techniques and products to be created. At best, the team will end up
creating products that it perceives as wasting time. At worst, inflexibility of this sort can serve to
reduce the motivation of the team – “another day in the factory”.
Even if the project manager can maintain motivation, productivity will still be reduced by the inability
to work in ways best suited to the team and by the overheads imposed by the rigidity of the process.
Monolithic methods can only change in the longer term, as lessons are learnt by the organization
executing projects. Unfortunately this rate of change is too slow, since the organization itself and the
technology it uses are changing more rapidly.
Surely There Must Be A Better Way…
Faced with these intractable problems:

“One size fits all” methods;

Inability to adapt;

Inability to change quickly enough;

Regular and predictable project failures.
Most project managers and users are demanding better ways to manage their projects. Defined
processes give way to ad-hoc approaches, cherry-picking results in projects with unquantified levels of
risk.
Guerilla war has been waged by IT practitioners – has this war helped or hindered the search for better
methods and management?
© Select Business Solutions, Inc. 2003
Page: 6


Objective Based Planning

Whitepaper
Revolutionary Processes and Project Management
Not surprisingly, from the wreckage of failed monolithic projects, revolution arises. Advocating
extremely lightweight noninvasive process, planning, management and control, the revolutionaries
rapidly garner support from the exploited masses of analysts and developers. In consequence, the
revolutionary movements are perceived to be very successful – in terms of the heat and noise
generated, this is undoubtedly true, but what about real project experience? Has the process baby been
thrown out with the monolithic bathwater?
Revolutionaries often fail because they ascribe their own positive attributes to everyone else. The fact
that I can work in a disciplined and focused manner and make high quality, fully functional deliveries
against the loosest of framework plans does not mean that the average developer can too. To succeed
in the revolution you have to be beyond the ordinary.
The RAD revolution was a brilliant conception answering many of the concerns about monolithic
processes – key to its success was the need to involve users at every stage of development and
deployment. Even so, RAD projects failed very often – the teams lacked the experience and ability to
spot the risks, inherent in iterative prototyping, as they occurred. Key risks include scope-creep, re-
inventing the wheel, consensus failure, code entropy, and prototyping paralysis.
Identifying these key risks, the revisionists of the DSDM consortium sought to impose a degree of
Moving tar
Moving ta ge
g ts
Figure 3 - RAD projects have multiple, unknown targets - aim, file, miss them all!
controllability on RAD-style projects by adding architecture to the equation – Rapid Architected
Application Development or RAAD. Scope-creep can only be avoided (or at least managed) if the
scope is defined in some way. Re-inventing the wheel can be avoided if the business architecture is
modeled and documented effectively. Consensus failure is mitigated by the clear and constant
involvement of the user community throughout the project. Code entropy is avoided by retaining
intellectual property in designs as well as code, allowing a more architectural view of the solution to be
taken. Prototyping paralysis is avoided by defining a clear scope and business architecture, so that the
alignment of the prototype to the documented business need can be monitored.
DSDM combines the use of modeling to capture intellectual property with the use of prototyping to
drive the design forward as quickly as possible. It also formalized the ideas of incremental delivery
and iterative working to address many of the issues that arise in managing RAD projects.
More recently, the xP world is littered with as many failures as success stories. Again, the key to
success with xP is a regimen of skill and discipline that the project team must adhere to as if it were its
second nature. Lacking these high standards, the less-skilled, less-disciplined xP project is doomed to
failure simply because there is no clear process laid down.
© Select Business Solutions, Inc. 2003
Page: 7


Objective Based Planning

Whitepaper
Without the experience, skill and discipline, xP teams are unable to spot risks as they arise until the
impact of those risks bites back – typically during system test or deployment. Now it is too late.
Lacking well-documented design, the intellectual property has been lost. Tracking down and
rectifying the problems simply from the code base is at best extremely time-consuming, at worst an
impossible task. In many xP projects, elements of analysis and design documentation are encouraged.
Even if the documentation has been kept up to date, it may be insufficient to support full-scale re-
factoring of the design.
Counter-revolutionaries are now infiltrating the agile process world. Advocating ideas such as “agile-
modeling” or lightweight but relatively well-defined processes that can be followed without imposing
the weight of control associated with monolithic processes. Agile processes are now gaining grudging
acceptance amongst the xP community as a necessary evil.
Reality Check
Only the smallest IT shops are made-up entirely of high-skilled individuals – those who are likely to
have experience, skill and expertise to be able to make a real success of xP. Indeed, in many shops the
opposite situation exists – the skills base is so small that even maintaining existing systems within the
constraints of a heavyweight, monolithic process is a real management issue. Nor is this situation
likely to improve – the signs of increasing skills shortages in the IT world are ubiquitous.
Even if sufficient skills are present in the IT shop to make xP a practical reality – at least on some
projects – how are the delivered business solutions to be maintained in the longer term? Reducing
capture of intellectual property may be the key to the rapid delivery of solutions (the argument lies in
how far the reduction can be taken, of course). But without the intellectual property, maintenance
becomes a real headache. Maintenance-mode is the reality that faces many IT solutions, even if they
are relatively recent – stories of the short-term tactical fix still in operation years later are apocryphal in
the industry.
Many xP practitioners would argue there is a process in the xP world. The problem is, of course, that
it is not written down. Nor is there any consensus about what the process is or should be. How can a
project be planned from a process that is not written down? Even if a plan is created, how does the
project manager argue against the “I did it my way” syndrome and effectively measure progress
against the original plan?
Team Impact
The positive element of revolutionary processes is their empowerment of the teams that use them. This
after all is why they were created – power to the developers! With power goes responsibility and
responsibility calls for knowledge and skill.
Empowered teams are likely to have good morale and to be very productive. Notice, however, this is
likely to be true of skilled and knowledgeable practitioners anyway. Such people are often very
motivated and focused on success. How much of the benefit of xP derives from the empowerment of
the team and how much from the sheer intellectual power of the combined capability of a highly
skilled group? All that can be said with certainty is that xP certainly does not crush the creative skills
of such a group. Unfortunately it does not offer much in the way of support for an inexperienced or
unskilled team, either.
Surely There Must Be A Better Way…
Many of the revolutionaries want to throw away the concept of process altogether, losing sight of the
benefits that process can bring:
© Select Business Solutions, Inc. 2003
Page: 8


Objective Based Planning

Whitepaper

Scalability – work on projects of many different sizes and complexity;

Skills Transfer – ability to mix skill levels and educate within a project;

Planning – know in advance what is to be done in each period of work;

Risk Management – understand risk and take action to mitigate it;

Agility – understand problems as they arise and respond appropriately;

Measurability – knowing where the project is and how much work is left.

Is there a middle way featuring the benefits of process and of agility?
© Select Business Solutions, Inc. 2003
Page: 9


Document Outline

  • Introduction
    • This Document
    • Monolithic Processes
    • Agile Processes
    • About Select Business Solutions
  • Managing Projects Using Monolithic Methods
    • Reality Check
    • Team Impact
  • Revolutionary Processes and Project Management
    • Reality Check
    • Team Impact
    • ÿ
  • Squaring the Circle
          • Documented
    • Select Perspective
          • Documented
  • Foundations of Agile Planning
              • Agility = Capability + Applicability
    • Time-Boxed Increments
    • Increments and Select Perspective
          • A short period of time with fixed start and end dates, dedicated to the creation of selected project products and which consumes all of the resources of the project.
    • Products Re-Defined
    • Planning With Scope and State
  • Objective-Based Planning
    • Increment Objectives
                • Increment
    • Impact of Supply-Manage-Consume
    • Objectives and Product States
    • Product States and Processes
                  • Product
    • Supply-Side Economics
    • Planning is Iterative, Too
  • Agile Project Management
    • Agile By Alternative
    • Agile By Addition
    • Agile By Adaptation
    • Agile By Automation
  • Conclusions

Download
gestion de proyecto

 

 

Your download will begin in a moment.
If it doesn't, click here to try again.

Share gestion de proyecto to:

Insert your wordpress URL:

example:

http://myblog.wordpress.com/
or
http://myblog.com/

Share gestion de proyecto as:

From:

To:

Share gestion de proyecto.

Enter two words as shown below. If you cannot read the words, click the refresh icon.

loading

Share gestion de proyecto as:

Copy html code above and paste to your web page.

loading