Web Project Management

WEB Project Management

Dr. Nicola MezzettiSo!ware Architect, Team Leader

1venerdì 12 febbraio 2010

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 specific 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/field 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 specific 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 classified as:

– Management processes:

• The processes regarding the definition 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 office defining 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 final product

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

– Financial analysis of the costs and benefits 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

• Definition of the project goals

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

• Definition 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 effort required to complete the task

– Workout the effort 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

defined 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, effort, scope) against the project management plan and the project performance baseline

– Identifying corrective actions to address issues and risks properly

– Benefits:

• 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, insufficient 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 effectively 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 modifications, 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 final 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 files 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 specified 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 criteria33venerdì 12 febbraio 2010

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 defined 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

– Definition 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


WBS design principles

• 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 effort

• the activities should require at most a single reporting period

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


WBS design principles

• 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 confidently estimated

• makes no sense practically to break down any further

• can be completed in accordance with one of the heuristics defined above

• produces a deliverable which is measurable

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


WBS design principles• 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 identifies 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 finish 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 elements39venerdì 12 febbraio 2010

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 difference between the two values is called the project buffer 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 flows 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 buffer 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 affect the project

– By identifying them, negative effects 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 different 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 efficient and effective 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 indefinitely


Responding to change over following a plan

• At regular intervals, the team reflects on how to become more effective, 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 specific)


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 first, then the team is backed into the requirement

• Test cases are developed at the same time the requirements are defined

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



• Adaptive control

– 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 defines 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



• 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

– Simplified 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 final 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 finish 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 difference”

– 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: finding the quickest path to failure by tackling the most difficult, 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 reflect 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 confidence 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 finish

– 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 flow 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 different 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 definition 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 flexibility 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 effort 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

– Definition 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 modification 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 effort

– The product backlog is property of the Product Owner

– Business value is set by the Product Owner

– Development effort 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 defines 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 specific 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 reflect 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 final 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 financial 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


Leadership & Management

Web Project Management