Web Project Management

WEB Project Management

Dr. Nicola Mezzetti
So!ware Architect, Team Leader

venerdì 12 febbraio 2010 1

Agenda
• The software development process

• Project Management

• Project Management Tools

• Traditional Project Management Methodologies

• Agile Project Management

– Extreme Project Management

– SCRUM


The Software Development
Process


Planning
• The general requirements for the product are collected

– Customers typically have an abstract idea of what they want

• Incorrect requirements could be produced at this point; the risk is reduced by

– Having a solid knowledge of the speciﬁc enterprise processes

– Frequently demonstrating live code

• An analysis of the scope of the development is formalized

– The set of requirements the product will meet is clearly stated

• Some requirements may be excluded because of cost or of unclear requirements

• If the development is outsourced, this document can be a legal document


Design
• Domain analysis is often the first step in designing the product to be
delivered

– In case the analysts or the developers are not sufficiently knowledgeable
in the enterprise processes covered by the product, the first task is to
investigate the so-called “domain” of the software

• The more knowledgeable they are about the domain already, the less
work required

• to make the analysts, who will later gather the requirements from
the enterprise process experts, speak with them in the domain's own
terminology, facilitating a better understanding of what is being said
by these experts


Design: Specification
• Specification is the task of precisely describing the software to be
written, possibly in a rigorous way

– most successful specifications are written to understand and fine-tune
applications that were already well-developed

– safety-critical software systems are often carefully specified prior to
application development

• Specifications are most important for external interfaces that must
remain stable

• A good way to determine whether the specifications are sufficiently
precise is to have a third party review the documents making sure that
the requirements and Use Cases are logically sound


Design: Architecture

• The architecture of a software system (software architecture)
refers to an abstract representation of that system

– Architecture is concerned with making sure the software system will meet
the requirements of the product, as well as ensuring that future
requirements can be addressed

– The architecture step also addresses interfaces between the software
system and other software products, as well as the underlying hardware or
the host operating system


Implementation, Testing and
Documenting
• Implementation is the part of the process where software engineers
actually program the code for the project

• Software testing is an integral and important part of the software
development process.

– This part of the process ensures that bugs are recognized as early as
possible

• Documenting the internal design of software for the purpose of
future maintenance and enhancement is done throughout
development.


Deployment

• Deployment starts after the code is appropriately tested, is
approved for release and sold or otherwise distributed into a
production environment

• Software Training and Support is important

– many projects fail because the technicians fail to realize that the value
of a product is the one perceived by the customer

– users are resistant to software changes, so as a part of the deployment
phase, it is very important to have training classes


Maintenance
• Maintenance and enhancements can take far more time than the
initial development of the software

– Customer reports problems

• It is assessed whether tests have been extensive enough to uncover
the problems before customer do

• If the cost of the maintenance phase exceeds 25% of the prior
phases' cost then the overall quality of at least one prior phase is
poor

• Bug tracking system tools are often deployed at this stage of the
process to interface development teams with customer/ﬁeld teams.


Project Management


What is a Project?
• The word “project”:
– comes from the latin word projectum that actually meant “something
that comes before anything else happens”

– When the modern languages initially adopted the word, it referred to
a plan of something, not to the act of actually carrying this plan out.

• Something performed in accordance with a project is known as
“object”.

– In the 1950s, with the development of project management
techniques, its meaning changed in order to cover both projects and
objects.

• In project management, it means a temporary endeavor undertaken to
create a unique product, service or result.


“You know what you have to do, do it, once, and that's
a project.”
• A project, by definition, is a temporary activity with
– a starting date and a defined end date;

– specific goals and conditions;

– defined responsibilities;

– a budget;

– a planning;

– multiple parties involved.

• A complex venture, unique and having a well defined duration, aiming at
pursuing a clear and predefined goal through a continuous process of
planning and control of resources


What is Project Management?

• The continuous planning and control of people and
resources, temporarily joint in order to achieve a unique
goal, meeting requirements of time, budget, quality, and
resources

• Project Management is the discipline of planning,
organizing, and managing resources to bring about the
successful completion of speciﬁc project goals and
objectives


The three dimensions of a
project
Each project success is assessed according to three dimensions:

• Time:

– The total duration of the activities;

• Budget:

– The total amount of money required for maintaining the whole set of
resources that will have a part within the project;

• Quality:

– The meeting of the customer requirements and the respect of the
market standards. The quality can refer both to the quality of the
result and to the quality of the whole process of project management.


The processes of a project

• Managing a project requires the management of processes that
can be classiﬁed as:

– Management processes:

• The processes regarding the deﬁnition and the organization of
the project before its beginning and for its whole duration;

– Implementation processes:

• The processes regarding the design and the implementation of
the project object.


Project Management Life Cycle
• Given any project management approach, the project development
process will have the same major stages

– Initiation

– Planning

• Risk Analysis

– Execution

– Control and validation

• Maintenance

– Closeout and evaluation


Project Initiation
• The initiation stage determines the nature and scope of the project
• Describe and develop the business case (problem/opportunity)

• Study the feasibility describing each possible solution to the business case

• Establish the project charter outlining the purpose of the project, the way
it will be structured and implemented

• Appoint the project team describing objectives and responsibilities of
each role

• Set up the project oﬃce deﬁning the cooperation and communication
model

• Perform a phase review assessing whether the team can proceed to the
next phase


Project Charter
• The project charter is a cohesive plan encompassing:

– Study analyzing the business requirements in measurable goals

– Review of the current operations

– Conceptual design of the operation of the ﬁnal product

– Contracting requirements, including an assessment of long lead time
items

– Financial analysis of the costs and beneﬁts including a budget

– Stakeholder analysis, including users, and support personnel for the
project

– Project charter including costs, tasks, deliverables, and schedule


Planning: SMART Goals
• Project goals are the key factors enabling the project to have success

• Goals should be SMART

– Specific: well defined and clear to anyone having basic project
knowledge

– Measurable: know if the goal is achievable, how far away completion is,
and when it has been achieved

– Agreed upon: agreement with the stakeholders what the goals should be

– Realistic: Within the availability of resources, knowledge and time

– Time based: enough time t achieve the goal, but not too much (that will
affect project performance)

Project Planning (1/2)
• The project plan should track down the following issues

• Deﬁnition of the project goals

– A project is successful when the needs of the stakeholders have been
met

• Deﬁnition of the project deliverables

– Determine the artifacts the project will produce during its life cycle

• Determine the things the project goals require to be delivered

• Specify when and how each item must be delivered


Project Planning (2/2)
• Project Schedule

– For each planned deliverable, create a list of tasks to be performed

– For each task determine the resource who will carry it out and the amount of
eﬀort required to complete the task

– Workout the eﬀort required for each deliverable and an accurate delivery date

– Problem: What if the project has an imposed delivery deadline that is not
realistic based on your estimates?

• Renegotiate either deadline or resources or the scope of the project with
the sponsor

• Supporting plans: human resource plan, communications plan, risk
management plan


Planning: Risk Analysis
• Risk analysis is a technique to identify and assess factors that may
jeopardize the success of a project or achieving a goal.

– For instance: “Reorganization may result in key people being reassigned”

• Analyzing possible risks is useful for

– defining preventive measures to reduce the probability of these factors
from occurring

– Identifying countermeasures to successfully deal with these constraints
when they develop to avert possible negative effects on the project
execution

• One of the more popular methods to perform a risk analysis in the
computer field is called Facilitated Risk Analysis Process (FRAP).


Planning: what not to do
– Not planning at all;

– Failing to account for all project activities;

– Failure to plan for risk;

– Using the same plan for every project;

– Allowing a plan to diverge from project reality;

– Planning in too much detail too soon;

– Planning to catch up later;

– Not learning from past planning sins.


Execution
• Executing consists of the processes used to complete the work
deﬁned in the project management plan to accomplish the project's
requirements

– The physical project deliverables are built and presented to the
customer

– This is usually the longest phase in the project life cycle and it typically
consumes the most energy and the most resources

• Execution process involves

– coordinating people and resources

– integrating and performing the activities of the project in accordance
with the project management plan


Monitoring and Controlling
• Those processes performed to observe project execution
– Measuring the ongoing project activities, the project variables (cost, eﬀort,
scope) against the project management plan and the project performance
baseline

– Identifying corrective actions to address issues and risks properly

– Beneﬁts:

• Timely identifying potential problems;

• Taking corrective actions, when necessary, to control project execution;

• Timely identifying variances from the project management plan;

• Providing feedback between project phases, to maintain the project
into compliance with the project management plan.


Monitoring and Controlling Steps
• Monitoring and Controlling means performing the following tasks

– Time Management: recording the time spent by people on a project

– Cost Management: reporting costs or expenses of the activities so far

– Quality Assessment: measuring and reporting the quality of produced
deliverables

– Change Management: procedures helping teams to react to changes

– Unclear or incorrect requirements are discovered or new
requirements are added or a risk occurred in the previous execution

– Risk Management: identify risks, evaluate them, take actions to
prevent them from occurring and to reduce the impact should them
eventuate

Monitoring and Controlling Steps
• Monitoring and Controlling means performing the following tasks

– Issue Management: identifying issues and triggering changes accordingly

• Lack of funding, insuﬃcient resources or tight deadlines

– Procurement Management

• Managing relationships with third party suppliers

• Managing the ordering, receipt, review and approval of items from
suppliers

– Acceptance Management: user acceptance testing with the customer

– Communication Management: communicating towards stakeholders

– Phase Review: assessment of whether the phase objectives have been
achieved


Project Maintenance (1/2)
• Project Maintenance is an ongoing process, and it includes:

– Continuing support of end users

– Correction of errors

– Updates of the software over time

– Monitoring and Controlling cycle

– Auditors should pay attention to how eﬀectively and quickly user problems are
resolved

• Change in the project scope is a normal and expected part of the
construction process. Changes can be, for instance, the result of:

– necessary design modiﬁcations, contractor-requested changes, or impacts from
third parties


Project Maintenance (2/2)
• Beyond executing the change, it normally needs to be documented to show
what was actually constructed

– The stakeholder usually requires a ﬁnal record to show any change modifying a any
tangible portion of the end product; this record is made on the contract document;

– The requirement for providing them is usually a norm in construction contracts;

– This is referred to as Change Management.

• When changes are introduced to the project, the viability of the project has to
be assessed again

– It is important not to lose sight of the initial goals of the projects

– When the changes accumulate, the forecasted result may not justify the proposed
investment


Project Closure
• Closing includes formal acceptance of the project and its ending

• Administrative activities include the archiving of the ﬁles and
documenting lessons learned.

• This phase consists of:

– Project closure: Finalize all activities across all of the process groups to
formally close the project or a project phase

– Contract closure: Complete and settle each contract (including the
resolution of any open items) and close each contract applicable to the
project or project phase


Project management Tools


Statement Of Work
• SOW is a document that captures and agrees the work activities,
deliverables and timeline that a vendor will execute against in
performance of work for a customer

– Detailed requirements and pricing are usually speciﬁed in a Statement Of
Work, along with many other terms and conditions

• Areas Addressed:

– Scope of work

– Period of performance

– Deliverable schedule

– Applicable standards

– Acceptance criteria

Work Breakdown Structure
• A complete, tree structured, classification of the project scope

– Shows a subdivision of effort required to achieve an objective

• starting with the end objective and

• recursively subdividing it into manageable components in terms of
size, duration, and responsibility (e.g., systems, subsystems,
components, tasks, subtasks, and work packages)

• Provides a common framework for the natural development of the
overall planning and control of a project

• Basis for dividing work into definable increments from which the
statement of work can be developed and technical, schedule, cost, and
labor hour reporting can be established

WBS design principles
• The 100% rule

– the WBS includes 100% of the work deﬁned by the project scope and
captures all deliverables in terms of the work to be completed, including
project management

• Mutually exclusive elements

– Any two distinct elements of a WBS have not to overlap in scope

• Planned outcomes, no planned actions

– Deﬁnition of the WBS elements in terms of outcomes or results

• Is not overly prescriptive of methods and creativity

• Guarantees to capture exactly 100% of the project scope


• Level of detail: When to stop dividing work into smaller elements ?

– Heuristics for determining the duration of a group of activities to produce
a deliverable

• “80 hour” rule: the activities should require at most 80 hours of eﬀort

• the activities should require at most a single reporting period

• “if it makes sense” rule: apply “common sense”


• Level of detail: When to stop dividing work into smaller elements ?

– A work package at the activity level is a task that:

• can be realistically and conﬁdently estimated

• makes no sense practically to break down any further

• can be completed in accordance with one of the heuristics deﬁned
above

• produces a deliverable which is measurable

• forms a unique package of work which can be outsourced or
contracted out


• WBS coding scheme

– It is common for Work Breakdown Structure elements to be numbered sequentially to
reveal the hierarchical structure.

• For instance 1.3.2 Rear Wheel identiﬁes this item as a Level 3 WBS element,
since there are three numbers separated by a decimal point.

• Terminal element

– the items that are

• estimated in terms of resource requirements, budget and duration

• linked by dependencies

• and scheduled.

– A terminal element is sometimes called a work package, although the two terms are
not synonymous


Gantt Diagrams
• Is a type of bar chart that illustrates a project schedule

• Illustrates the start and ﬁnish dates of the terminal elements and
summary elements of a project

• Can show the dependency relationships between activities

• Can show current schedule status using percent-complete shadings and
the current time

• Recommendations
– They do not substitute WBSs, they are only a manner of representing them

– They become quite unwieldy for projects with more than about 30
activities

– Do not represent the size of a project or the relative size of work elements

Example: Gantt Diagram


Traditional
Project management
methodologies


Project Management
Methodologies
• Each project management methodology has its own strengths and weaknesses

– Regardless of the approach employed, careful consideration needs to be given to
clarify project objectives and the roles and responsibilities of all participants and
stakeholders

• Project Management Methodologies:

– Traditional Approach (Waterfall model)

– Critical Chain Project Management

– Extreme Project Management

– Event Chain Methodology

– PRINCE2


The Traditional Approach
• Assumes that events affecting the project are predictable and activities
are well understood

• Aims at producing, since after the project initiation, the complete
requirement analysis and the detailed project design

• Inherits all the phases of the project management life cycle

• Not all the projects will visit every stage

• Once a phase is complete, it is assumed it will not be revisited

• In software development, this approach is often known as the waterfall
model (one series of tasks after another in linear sequence)

– In software development many organizations have adapted the Rational
Unified Process (RUP) to fit this methodology


Cons of the Traditional
Approach
• This methodology can work for small tightly-defined projects

• For larger projects, of undefined or unknowable scope, it is less suited

– the planning made on the initial phase of the project suffers from a high
degree of uncertainty

– this becomes especially true as software development is often the
realization of a new or novel product

• requirements are largely unknowable up front and susceptible to change

• Statistics say that, employing traditional project management methods,
30% of the lost time and resources are typically consumed by wasteful
techniques such as bad multi-tasking, student syndrome, in-box delays,
and lack of prioritization


Critical Chain PM: Rationale
• All tasks in the project are subject to some degree of uncertainty

• In general, task durations are overestimated

– When estimating the duration of a task, the task owner adds a safety
margin in order to improve the chance of completing the task on time

• In most cases, the task will not require the entire amount of safety
margin and should be completed sooner than scheduled

• Safety margin is internal to the task; if it is not needed, it is wasted

– When it becomes obvious that the safety margin is unnecessary, the task
owner will use that time anyway

– Any delay in the completion of a task propagate to the successor tasks


Critical Chain Project
Management
• Based on statistics and theory of constraints

– Every system has a constraint, and system performance can only be improved
by enhancing the performance of the constraining resource

• It is unlikely that all the critical chain tasks will exceed their 50%
likelihood duration estimates

• Under the assumption of statistical independence, about half the tasks
will exceed the 50% mark, while the other half will be completed at less
than 50%

• By pooling together the safety margins of the individual tasks, the
protection against uncertainty is improved

– There is pressure on the resources to complete critical chain tasks as quickly
as possible


CCPM: Planning (1/2)
• Starting point: list of tasks along with their duration estimates and
dependencies

• First step: developing an initial schedule for project tasks

– Compatibly with dependencies among tasks and resource availability

• Schedule is worked backward from a completion date with each task
starting as late as possible; each task is assigned

• "best guess“ duration: time to complete the task with 50% likelihood

• "safe" duration: task owner estimates (time to complete the task with
90-95% likelihood)

– The diﬀerence between the two values is called the project buﬀer and
should be considered a separate task


CCPM: Planning (2/2)
• Resources are assigned to each task and the plan is resource leveled
using the 50% estimates

– The longest sequence of resource-leveled tasks that lead from beginning to
end of the project is the critical chain

• "buffers" are used to establish dates for monitoring project schedule

– The "extra" duration of each task on the critical chain is gathered together
in the feeding buffer

• The feeding buffer provides the extent of the critical chain's protection
against the uncertainty in the feeding noncritical chains

• If there is still some slack on the feeding chain, CCPM prescribes that
the task be scheduled as late as possible.

• Finally, a baseline is established to enable monitoring of the project


CCPM: Execution
• When the plan is complete, the project network is fixed and the
buffers size is "locked"

• Resources working on critical chain tasks are expected to work
continuously on a single task at a time

– They do not work on several tasks in parallel or suspend their critical
tasks to do other work

– Resources are to complete the task assigned as soon as possible,
regardless of scheduled dates

• If the task is completed ahead of schedule, work on its successor is to
begin immediately

• If the task is completed past its planned completion date, as shown on
the CCPM schedule, this is no reason for immediate concern, as the
buffer will absorb the delay

CCPM: Monitoring
• Because individual tasks will vary in duration from the 50% estimate,
there is no point in trying to force every task to complete "on time“

• As progress is reported, the CCPM schedule is recalculated, keeping
the final due date of the project constant by adjusting buffer sizes

• Project control focuses on consumption of the buffer

– If the rate of buffer consumption is low, the project is on target

– If the rate of consumption is such that there is likely to be little or no
buffer at the end of the project, then corrective actions or recovery plans
must be developed to recover the loss

• When the buffer consumption rate exceeds some critical value, then
those alternative plans need to be implemented


CCPM: Cons (1/2)
• Though this method rationale is plausible, this method misses any
supporting scientific evidence

– task owners overestimate task duration by a certain safety factor

– the duration of the actual execution of each task will expand to fill the time
allotted

• Not all people overestimate by the same amount

– how does the project manager determine the safety factor that the task owner
presumably built into the duration estimate?

• Will they agree to shorten their duration estimates and merge their
individual safety factors into the project and feeding buffers?

– the knowledge that their estimates will be reduced will encourage task owners
to add larger margins


CCPM: Cons (2/2)
• This network structure is applicable to projects that consist of
construction, assembly, and integration tasks, which are common in
manufacturing environments

– many projects begin with a small core of central activities, i.e., design and
analysis, which split into parallel tracks that merge at various
intermediate review points before producing the various project
deliverables.

• This leads to more complex network ﬂows where a given task may
have both predecessors and successors from several chains; in such
cases, it is not clear how much of a feeding buﬀer should be allotted
to each merging task

• The more the number of concurrent chains, the more the likelihood
that that projects will always be late-relative


Event Chain Methodology
• Event chain methodology

– Is an uncertainty modeling and schedule network analysis technique focused
on identifying and managing events and event chains that affect project
schedules

– comes from the notion that regardless of how well project schedules are
developed, some events may occur that will alter it

• Identifying and managing these events or event chains (when one event
causes another event) enables one to perform more accurate analysis

– helps to mitigate effect motivational and cognitive biases in estimating and
scheduling

– simplifies the process of defining risks and uncertainties in project schedules,
by improving the ability to provide reality checks and to visualize multiple
events


ECM: Principles (1/2)
• Moment of risk and excitation state

– Activities are affected by external events transforming them from one state to
another

– An event’s important property is the moment when it occurs during the course
of an activity; this moment can be defined using a statistical distribution

• Event Chains

– Events can cause other events, creating event chains that can significantly
affect the course of the project. For instance:

– Requirement changes can cause an activity to be delayed.

– To accelerate the activity, the project manager allocates a resource
from another activity, which then leads to a missed deadline.

– Eventually, this can lead to the failure of the project.


ECM: Principles (2/2)
• Critical events, Critical event chains

– The single events, or the event chains, having the most potential to aﬀect the project

– By identifying them, negative eﬀects can be mitigated

• Analyzing correlations between project parameters (duration, cost) and event chains

• Performance tracking with event chains

– probability and time of the events can be recomputed based on data obtained by
monitoring the project tasks execution

• Main issue: forecasting an activity’s duration and cost if an activity is partially
completed and certain events happen

• Event Chain diagrams

– Gantt-Like diagrams showing the relationships between events and tasks


ECM: Planning
• Create a project schedule model using best-case scenario estimates of duration,
cost, and other parameters

• Define a list of events and event chains with their probabilities and impacts on
activities, resources, lags, and calendars

– The list of events can be described in the form of a RBS

– These events should be identified separately from the schedule model

• Quantitative analysis using Monte Carlo simulations

– The results are statistical distributions of the main project parameters, as well as
similar parameters associated with particular activities

• Sensitivity analysis

– Reality checks may be used to validate whether the probability of the events are
defined properly


ECM: Monitoring

• Repeat the analysis on a regular basis during the
course of a project

– The probability and impact of risks can be reassessed
based on actual project performance measurement

– It helps to provide up to date forecasts of project
duration, cost, or other parameters


ECM: Phenomena
• Repeated Activities

– Sometimes events can cause the start of an activity that has already been
completed

• Mitigation plan

– Mitigation plans are an activity or group of activities (small schedule) that
augment the project schedule if a certain event occurs.

• Resource Allocation Based on Events

– One potential event is the reassignment of a resource from one activity to
another, which can occur under certain conditions.

• Events can be used to model diﬀerent situations with resources, e.g.
temporary leave, illness, vacations, etc.


ECM: Cons
• Since this project relies on the traditional method planning stage, it
suffers the same problems of that method

• Additionally, the project manages is responsible of describing with
the same level of detail the possible risks that may affect the project

• This method works well for project settings with low uncertainty,
where the probability that an event will happen during the execution
of a given task

– For each risk, the manager defines the chance the risk will occur, the
risk’s impact (delay, increase cost, trigger other risks, cancel task, etc.),
and when will the risk occur during the course of activity


The Agile Methodologies


Agile Methodologies
Rationale
• Traditional PM techniques fail on projects with undefined or
unknowable scope

– Planning made on the initial phase of the project suffers from a high degree
of uncertainty

• 30% of projects fail, 49% of project fail to meet all the requirements

• Underestimation of the stakeholders efforts,

• undefined quality or scope requirements,

• underestimation of the risks,

• missing to perform important tasks

• Poor analysis experience


Agile Methodologies
• The project team and the stakeholders actively work together to
understand the domain, identify the needs to be built, and prioritize
functionality

• Agile methods are used when

– Project value is clear

– The customers actively participate throughout the project

– The customer, designers, and developers are co-located

– Incremental feature-driven development is possible

• The Agile approach consists of many rapid iterative planning and
development cycles, allowing a project team to constantly evaluate the
product and obtain immediate feedback from users and stakeholders

The Agile Manifesto

• The Agile Manifesto has been written in 2001

– Individuals and interactions over processes and tools

– Working software over comprehensive documentation

– Customer collaboration over contract negotiation

– Responding to change over following a plan


Individuals and interactions
over processes and tools
• Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.

• Business people and developers must work together daily throughout the
project.

– Continuous attention to technical excellence and good design enhances
agility.

– Simplicity--the art of maximizing the amount of work not done--is essential.

• The most eﬃcient and eﬀective method of conveying information to and
within a development team is face-to-face conversation.


Working software over
comprehensive documentation

• Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software

• Working software is the primary measure of progress

• Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale


Customer collaboration over
contract negotiation

• Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
maintain a constant pace indeﬁnitely


Responding to change over
following a plan

• At regular intervals, the team reﬂects on how to
become more eﬀective, then tunes and adjusts its
behavior accordingly.

• The best architectures, requirements, and designs
emerge from self-organizing teams.

• Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.


Declaration of
interdependence
• We increase return on investment by making continuous flow of value our focus

• We deliver reliable results by engaging customers in frequent interactions and
shared ownership

• We expect uncertainty and manage for it through iterations, anticipation, and
adaptation

• We unleash creativity and innovation by recognizing that individuals are the
ultimate source of value, and creating an environment where they can make a
difference

• We boost performance through group accountability for results and shared
responsibility for team effectiveness

• We improve effectiveness and reliability through situationally specific strategies,
processes and practices


On the Declaration of
Interdependence
• Project team members are part of an interdependent whole and not a group of
unconnected individuals

• Project teams, customers, and stakeholders are also interdependent

• The six form a system of values that provides a modern view of managing projects:

– Value

– Customers

– Uncertainty

– Individuals

– Teams

– context (situationally speciﬁc)


Agile Project Management
• Developments conducted collaboratively with a small co-located team

• Core teams usually consisting of

– Two developers writing code in pairs, for quality control

– The customer

– An IT architect

– A business analyst

– A project manager

• The work is accomplished through a series of sessions where the team writes
code, then tests working modules of the system and repeats the process

• There is minimal documentation as the team relies almost exclusively on
informal internal communication


Agile Management
Components
• Visual Control

– “cards on the wall” ensures that team members have the same view on the project

• Co-located hi-performance teams

– Co-located team members, possibly including the customer, in a work room

– Improvement of the quality of communication and coordination

• Test-driven development

– The test cases are developed ﬁrst, then the team is backed into the requirement

• Test cases are developed at the same time the requirements are deﬁned

• If a requirement is not testable, then it is not yet fully developed


Agile Management
• Adaptive control
Components
– Team dynamically adapted to changes and to lessons learned from previous iterations

– The project manager needs to be seen as a leader, not as a taskmaster

• facilitating the team in establishing working relationships, setting ground rules,
and fostering collaboration

• Collaborative development: all the team members collaborate to delivery the
results

– The project manager completes the initial planning

– The business analyst deﬁnes and prioritizes the solution features with the customer
and the technology representatives

– Then, the agile project team collaborate on the design, development, testing and
reworking of each incremental build


Agile Management
•
Components
Feature driven development

– The team focuses on one and only one feature at a time

– The business analyst and the project manager ensure that the next feature is the
next priority, based on business value and risk

• Leadership and collaboration rather than command and control

– The principles of APM facilitate leadership more than traditional management

• Move cost to revenue

– Features are prioritized based on value, such as increased revenue or market share

• Lessons learned

– After each cycle, the team holds more knowledge, to be employed in
understanding what they can do better on the next iteration


Extreme project management


Extreme Projects
• “An extreme project is a complex, high speed, self-correcting venture
in search of a desirable result under conditions of high uncertainty,
high change and high stress.” (Doug DeCarlo)

– High uncertainty

– Short deadlines

– Customer driven

– Open, high stressed, environments

– Frequent changes

– Stability is an exception


Extreme Project Management
(1/2)
• Based on a successful software delivery process called Extreme Programming

– developed to solve problems of other sw development processes

– Team-oriented and customer-focused

• Teams range in size from small to medium; customer as integral part of the team

• Help the team in determining and delivering exactly what the customer wants,
even if the requirements change over time

• XP values: simplicity, communication, feedback, and courage

• XPM practices

– planning practices: the Release Plan and the Weekly Plan

– quality control practices are used daily


Extreme Project Management
(2/2)
• Properties of Extreme Project Management

– The main focus is on the human side of project management

– The project manager handles business aspects leaving the other issues
to technical managers

– It is based on strongly motivated and responsible teams

– Lightweight leadership

– Simpliﬁed practices from TPM


XPM: Essentials
• 4 Accelerators

– keeping the project moving and the team committed and creative

• 10 Shared values

– fostering a strongly held belief among project stakeholders that by working
together they can succeed, even in the face of volatility and adversity

• 4 Business questions

– a reminder that the project is a business venture, that the goal is to deliver value
each step of the way, as well as after the ﬁnal project output has been produced

• 5 Critical success factors

– How to employ accelerators, shared values and business questions in the project

– skills, methods and practices that are essential to lead, plan, manage and track
the project from start to ﬁnish and to assimilate change along the way

XPM: Accelerators
• “Change is your friend”

– not only responding to change, but also proactively creating change

• “People want to make a diﬀerence”

– people have to see their project not so much as a project but as a cause

• “People support what they create”

– I may feel good about being part of an important project, but if it is a
risky venture, I will want to have a voice in shaping the project

• “Simplicity wins”

– “Less is more”: the smaller the set of aspects to be managed, the simpler
the management


XPM: Shared Values (1/2)
• Client Collaboration: interaction and feedback with the customer
throughout the venture

• People First: eliminating barriers so that people can do quality
work

• Clarity of Purpose: understanding not only the goals of the
project, but the bigger picture as well

• Honest Communication: acting with integrity and speaking the
truth about the good, the bad and the ugly without fear of reprisal

• Results Orientation: focusing on the completion of deliverables
rather than on tracking tasks


XPM: Shared Values (2/2)
• Fast Failures: ﬁnding the quickest path to failure by tackling the
most diﬃcult, risky or important work very early on

• Early Value: giving customers something they can put to use as soon
as possible

• Visibility: keeping everything out in the open for all to see: plans,
progress, work products, issues, who's accountable for what

• Quality of Life: ensuring that the project strikes a satisfying balance
of work life and personal life

• Courage: having the fear and doing it anyway; doing it scared because
it's the right thing to do


XPM: Business Questions

• Continually updating the business case to reﬂect the latest
expectations and projections

– Who needs what and why?

– What will it take to do it?

– Can we get what it takes?

– Is it worth it?


XPM: Critical Success Factors
(1/2)
• Self-Mastery: the on-going practice of leading oneself

– without it, the project manager will realize that he lost control of the project

• Leadership by Commitment: gain and sustain the commitment of others

– The successful project manager is able to unleash motivation and innovation,
establish the trust and conﬁdence to succeed, ensure the customer receives
value each step of the way and maintain control in the face of volatility.

• Flexible Project Model: 5 cycles that span project startup to project ﬁnish

– Initiate, Speculate, Innovate, Re-evaluate and Celebrate

– Provide just enough discipline to allow people the freedom to innovate and
to get work done


XPM: Critical Success Factors
(2/2)
• Real-Time Communication

– Ensure that information is available anytime to anyone who needs it, to speed the
ﬂow of thoughts and ultimately decisions

• Agile Organization

– Put in place a change tolerant, project-friendly culture; one that recognizes and
supports the special needs of diﬀerent projects

– The goal is not to ensure projects are delivered on time, on scope or on budget,
but rather to ensure that the project delivers the intended business outcome


XPM: Project Model

• Initiate

– A business problem is presented.

– Face-to-face sessions between the client and the producer are held in
which both parties come to a shared vision and clear understanding of
what is going to be done

• This is documented and agreed to by both parties

• The caveat is that this is an initial deﬁnition and is expected to
change as project work commences


XPM: Project Model

• Speculate

– A brief project description (Project Skinny) is presented along with a
prioritized list of requirements that the client and the producer believe
are needed in order to solve the business problem

• Some high-level planning is done very quickly to sequence the
functionality into a number of development cycles

• This is documented and agreed to by both parties - along with the
expectation that it will change as project work commences


XPM: Project Model

• Innovate

– Detailed planning for producing the functionality assigned to this cycle is
prepared

– The cycle work begins, is monitored throughout the cycle and adjustments
made as necessary

– The cycle ends when its time-box has expired


XPM: Project Model
• Re-evaluate

– The client and project team perform a quality review of the functionality
produced in the just competed cycle

– It is compared against the overall goal of maximum business value and
adjustments made to the high-level plan and next cycle work as appropriate

The sequence Speculate-Innovate-Re-evaluate is repeated until the time and budget have
been expended or the desired result has been achieved

• Celebrate

– Recognizing and rewarding success throughout the project keeps the energy
positive and helps keep the project in a good mood


SCRUM


SCRUM
• Conceived for the management, enhancement and maintenance
methodology for an existing system or production prototype

• Enhancement of the iterative and incremental approach to delivering
object-oriented software

• It guarantees the maximum ﬂexibility and appropriate control since
the system development process is complicated and complex

• It assumes that the analysis, design, and development processes in the
Sprint phase are unpredictable

– A control mechanism is used to manage unpredictability and control risk

• Very easy to learn and requires little eﬀort to start using


Roles of SCRUM
• Pigs

– ScrumMaster:

• Acts as a facilitator in order for the team to deliver the sprint goal

• Keeps the team focused on the tasks in hand, ensuring that the
SCRUM process is used as intended

– Product Owner: represents the stakeholders and ensures that the Scrum
Team works with the "right things" from a business perspective

– Team: a self-organizing and cross-functional group of about 7 people who
do the actual analysis, design, implementation, testing, etc.

• Chickens

– Stakeholders and Managers


SCRUM Principles
• SCRUM enables the creation of self-organizing teams by encouraging

– co-location of all team members, and verbal communication across all
team members and disciplines in the project

• SCRUM recognizes that during a project the customers can change
their minds about what they want and need

– Scrum adopts an empirical approach, focusing instead on maximizing the
team's ability to deliver quickly and to respond to emerging requirements

• Sprint: empirical process during which the team creates a potentially
shippable product increment


SCRUM Phases: Pre-game
• Planning

– Deﬁnition of a new release based on currently known backlog, along with
an estimate of its schedule and cost

– If a new system is being developed, this phase consists of both
conceptualization and analysis

– If an existing system is enhanced, this phase consists of limited analysis

• Architecture

– Design how the backlog items will be implemented

– This phase includes system architecture modiﬁcation and high level design


Product Backlog

• It is a high-level document for the entire project

– It contains broad descriptions of all required features, wish-list items,
etc. prioritized by business value

– It is open and editable by anyone and contains rough estimates of both
business value and development eﬀort

– The product backlog is property of the Product Owner

– Business value is set by the Product Owner

– Development eﬀort is set by the Team


SCRUM Phases: Game

• Development Sprints:

– Development of new release functionality, with constant respect to the
variables of time, requirements, quality, cost, and competition

– Interaction with these variables deﬁnes the end of this phase

– There are multiple, iterative development sprints, or cycles, that are used
to evolve the system


Sprint
• A sprint is a two to four weeks period used to evolve the final product

• The set of features that go into a sprint come from the product
"backlog“, a prioritized set of high level requirements of work to be done

• During a sprint, no one is allowed to change the sprint backlog

• A sprint is empirical, non-linear and flexible

– Where available, explicit process knowledge is used; otherwise tacit
knowledge and trial and error is used to build process knowledge..

• Controls, including risk management, are put on each iteration of the
Sprint phase to avoid chaos while maximizing flexibility

• After a sprint is completed, the team demonstrates the software


Sprint Backlog
• It is a document containing information about how the team is going to
implement the features for the upcoming sprint.

• Features are broken down into tasks

– tasks are normally estimated between four and sixteen hours of work

• Team understands exactly what to do; anyone can pick a task from the list

– Tasks on the sprint backlog are never assigned

• Signed up by the team members as needed, according to priority and
skills

• The sprint backlog is property of the Team

• Estimations are set by the Team


Burn Down Chart
• It is a publicly displayed chart showing remaining work in the sprint
backlog

– Updated every day, it gives a simple view of the sprint progress

– There are also other types of burndown

• the Release Burndown Chart shows the amount of work left to
complete the target commitment for a Product Release (normally
spanning through multiple iterations)

• The Alternative Release Burndown Chart which does the same and,
in addition, shows clearly scope changes into a Release Content


Meetings
• Daily:

– Daily Scrum

– Scrum of Scrums

• At the beginning of each Sprint:

– Sprint Planning Meeting

• At the end of each Sprint:

– Sprint Review Meeting

– Sprint Retrospective


Daily Scrum
• This meeting has speciﬁc guidelines:

– The meeting starts precisely on time

• Often there are team-decided punishments for tardiness

• All are welcome, but only "pigs" may speak

• The meeting is time-boxed to 15 minutes

• The meeting should happen at the same location and same time every day

• Each team member answers three questions:

– What have you done since yesterday?

– What are you planning to do today?

– Do you have any problems preventing you from accomplishing your goal?

Scrum of Scrums
• Each day normally after the daily scrum

– These meetings allow clusters of teams to discuss their work, focusing
especially on areas of overlap and integration

– A designated person from each team attends

• The agenda will be the same as the Daily Scrum, plus the following
four questions:

– What has your team done since we last met?

– What will your team do before we meet again?

– Is anything slowing your team down or getting in their way?

– Are you about to put something in another team’s way?


Sprint Planning Meeting

• At the beginning of the sprint cycle (every 15–30 days)

– Select what work is to be done

– Prepare the Sprint Backlog that details the time it will take to do that
work, with the entire team

– Identify and communicate how much of the work is likely to be done
during the current sprint

– Eight hour limit


Sprint Review Meeting

• At the end of a sprint cycle

– Review the work that was completed and not completed

– Present the completed work to the stakeholders (a.k.a. "the demo")

– Incomplete work cannot be demonstrated

– Four hour time limit


Sprint Retrospective

• At the end of a sprint cycle

– All team members reﬂect on the past sprint.

– Make continuous process improvement.

– Two main questions are asked in the sprint retrospective:

• What went well during the sprint?

• What could be improved in the next sprint?

– Three hour time limit


SCRUM Phases: Postgame

• Closure

– Preparation for release, including ﬁnal documentation, pre-
release staged testing, and release


Deliverables

• The project is open to the environment until the Closure phase

• The deliverable can be changed at any time during the Planning
and Sprint phases of the project

– The project remains open to environmental complexity, including
competitive, time, quality, and ﬁnancial pressures, throughout these
phases


SCRUM Practices

• Customers become a part of the development team

• Scrum has frequent intermediate deliveries with working functionality,
like all other forms of agile software processes.

– This enables the customer to get working software earlier and enables the
project to change its requirements according to changing needs.

• Risk mitigation, monitoring and management (risk analysis) occurs at
every stage and with commitment.


SCRUM Practices

• Let everyone know who is accountable for what and by when

• Frequent stakeholder meetings to monitor progress

• There should be an advance warning mechanism

• No one is penalized for recognizing or describing any unforeseen
problem.

• Workplaces and working hours must be energized


Web Project Management

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Web Project Management (20)

More from Nicola Mezzetti (20)

Recently uploaded (20)

Web Project Management