Implementing Agile Iterative Project Delivery Approach and Achieving Business Responsiveness

8/9/2019 Implementing Agile Iterative Project Delivery Approach and Achieving Business Responsiveness

1/148

Implementing Agile IterativeProject Delivery Approachand Achieving Business

Responsiveness

Alan McSweeney


2/148

August 16, 2010 2

Objectives

To describe a generalised agile and iterative approach toinformation technology projects and the use of the agileapproach within organisations


3/148

August 16, 2010 3

Agenda

Introduction

Agile Iterative Approach to ProjectsUsing Agile Effectively and Productively

Control Components of Agile Process

Agile Tools and Techniques

Iterative Agile Framework and Phases

Using Agile Iterative Approach for Specific Projects

Introducing Agile Iterative Approach into an Organisation


4/148

August 16, 2010 4

Introduction


5/148

August 16, 2010 5

Projects

Projects are about change New or changes to existing processes, systems, applications, structures

Organisations need to be good at two sets of skills

Running the Business (RTB) business as usual operations

Change the Business (CTB) changing existing operations to survive or compete

Projects are the way of introducing change into organisations

Projects tend to be multidisciplinary, involving some or all of: Requirements gathering

Solution design

Hardware installation Product selection Software development or modification Testing Process change Organisation change

Data conversion Implementation Parallel operation

Organisations need to be good at projects in order to deliver change


6/148

August 16, 2010 6

Dimensions of Being Good At Organisational Change

To be good at change, threedimensions must cometogether within the

organisation: A clear vision for the

organisation and the set ofprojects needed to deliver onthe vision

A proven capability to deliverprojects quickly andeffectively

Focus on the realisation ofexpected business benefitsand business value associated

with the implementation ofinformation technologyinvestments

Agile approach to projects isone way of being good atchange

Ability toExecute Projects

Completeness ofOrganisational

Vision

Effective and ProvenBenefits Realisation

Approach


7/148

August 16, 2010 7

Projects Fail

Yes projects fail its no surprise

Fail occurs largely because of people rather than technology issues

Project success means the project delivered on time, on budget, to agreedspecification and delivering the agreed business benefits

Different types and scales of project failure Delivered solution fails to meet the business requirements for which it was

implemented and its use is abandoned or expensive adjustments are made

There are performance problems in the delivered solution which means it is insufficientto meet the needs of users and its use is abandoned or expensive adjustments aremade

After implementation errors and gaps appear in the delivered solution causingunexpected problem and its use is abandoned or expensive adjustments are made

Users reject, bypass or circumvent the delivered solution because of lack ofconsultation, involvement, commitment, agreement or other reasons

Delivered solution is used but over gradually become to expensive or complex tomaintain and falls into disuse

Project is late and/or over budget

Project does not deliver the business benefits


8/148

August 16, 2010 8

Spectrum of Project Failures

CompleteSuccess

CompleteFailure

Complete Project

Success:On-time, On-budget

Complete ProjectFailure: Cancelled,

Unused, Rejected

SpecifiedBusiness Benefits

and Savings NotDeliveredProject Late

and/or OverBudget

SignificantRework

Required

SolutionLargely Unused

Functionality DeliveredDoes not Meet Business

Requirements

Performance and/orOperationalProblems

More Expensiveto Operate Than

Planned


9/148

August 16, 2010 9

Balancing Solution Functionality and

Implementation Project Cost/Resources and Time

Traditional view ofprojects is that they are

a balance betweenmeeting requirements(solution functionality),implementation project

resources (and thuscost) and project time

Functionality(requirements) is fixed

and cost and time mustvary


10/148

August 16, 2010 10

Balancing Solution Functionality and

Implementation Project Cost/Resources and

Resources are constrained soproject time must increase

Time is constrained soresources must increase


11/148

August 16, 2010 11

Project Risk/Quality Factor

Reality is that allprojects have a risk

dimension projectsfail all too frequently

Risk and quality areinterrelated

Risk increases withproject duration, size ofproject team and

complexity of solutionbeing implemented


12/148

August 16, 2010 12

Projects and Changes

Organisations need to deliver projects to business in shorter timescales inresponse to internal and external

Project processes need to be flexible, responsive and agile in order to deliver whatthe organisation needs when it needs it

Traditionally projects are delivered in a series of sequential phases designed tocreate certainty around the solution being delivered Gather requirements Design solution

Technical and detailed design

Development/modification Testing Implementation Operation

Sequential approach has disadvantages Not sufficiently flexible to accommodate changes in requirements Resources are wasted building features that nobody needs Opportunity to provide feedback limited until a large part of the solution is delivered Solution stability and operability not certain until late in the project


13/148

August 16, 2010 13

What Makes Projects Succeed

User involvement and commitment

Executive management sponsorship

Defined and certain business objectives

Defined and agreed requirements

Defined scope

Flexible and reactive delivery process

Project management skill and experience

Good control of project costs

Skilled and experienced project team

Project delivery methodology

Proven technology


14/148

August 16, 2010 14

What Makes Projects Fail

Lack of or changing executivemanagement commitment

Unclear of scope, objectives andrequirements

Lack of user commitment andinvolvement

Changing scope and objectives and

poor change control Poor planning and estimation

Poor project management

Failure to manage end-user

expectations Lack of agreement between

stakeholders

Lack of skills and experience in theproject team

Unclear definition of roles andresponsibilities

Artificial and unrealistic deadlines Specifications not agreed

New or radically redesignedunderlying business processes

Use of new technology Poor project control against targets

Large number of organisational unitsinvolved

Lack of effective projectmethodologies

High project staff turnover


15/148

August 16, 2010 15

Flexible, Responsive, Agile Project Approach

An agile approach to project delivery seeks to reduce risksassociated with sequential solution delivery approach

Multiple iterations/releases

Sets of smaller deliveries

Prioritised requirements

Greater user involvement

Lower overall cost

Agile approach tends to be good for projects with inherentuncertainty and volatility

Transformation and organisational change projects

Support and maintenance

Research and development

Information technology


16/148

August 16, 2010 16

Applying Agile Approach to Projects

Agile approach tends to be associated with softwaredevelopment projects

More general approach and can and should be appliedmore widely to other projects (that may have adevelopment component)


17/148

August 16, 2010 17

Classification of Projects

Project Technology

ProjectRe

quirements

Well

Proven

Highly

Uncertain

WellDefined/Agreed

HighlyUndefined

and Far fromAgreement

Simple

Here beDragons

Highly

Complex

Complicated

Difficult


18/148

August 16, 2010 18

Solution Functionality Used

Most of the functionality ofdelivered solutions is never

or seldom used Not surprising think of all the

features in applications such asMicrosoft Office

How much do you use? Represents a significant cost

Tendency is always to delivercomplex feature-rich

solutions

Simplicity is not seen as good


19/148

August 16, 2010 19

Agile Iterative Approach to Projects

Time is fixed for the life of aproject and resources arefixed as far as possible

Requirements that will besatisfied are allowed tochange

Flexibility of requirements tobe satisfied has significantimpact on the developmentprocesses and controls, andon acceptance of the system

Iterative approach reducesrisk by continuouslyreaffirming and validating thesolution being implemented


20/148

August 16, 2010 20

Agile Iterative Approach to Projects


21/148

August 16, 2010 21

What is Meant by Agility

Driven by user descriptions/scenarios of what is requiredof the solution

Seeks constant user feedback

Recognises that plans are short-lived

Develops solution iteratively with a emphasis ondevelopment activities

Delivers multiple working solution increments

Adapts as changes occur


22/148

August 16, 2010 22

What Are the Potential Issues With Agile Approach

May not apply to large and complex projects

May not be suitable to all organisations and people Delivered solutions may not be scalable to large volumes

of users/transactions/workload/data

Delivered solutions may not be adaptable to meet futurebusiness needs


23/148

August 16, 2010 23

Agile and People

People are at the core of an agile process

The process adapts to the needs of the team needs ratherthan imposing a structure on the team as withconventional sequential processes

An effective agile team should be:

Competent

Working towards a common goal

Collaborative

Able to make decisions

Good at solving problems

Trust and respect one another

Self-organising with respect to workload, schedule and projectprocesses


24/148

August 16, 2010 24

Iterative Agile Approach to Projects

Fundamental assumption of agile approach to projects is thatnothing is built perfectly first time

80% of the solution can be implemented in 20% of the time that itwould take to produce the total solution

All deliverables from previous project steps can potentially be

revisited as part of the iterative approach Only enough of the current step need be completed to move to the

next step

Designed to address the current and immediate needs of thebusiness

Deliver simpler solutions more quickly that are fit for purpose andeasier to maintain and modify after their initial implementation


25/148

August 16, 2010 25

Agile Approach to Ensuring Project Success

Satisfies the real requirements of the organisationprioritised by importance

Supports the way the organisation needs to work

Aims to deliver quality solution on time and within budget

Aims to deliver quickly and effectivelyRequired functionality, performance, security, operability and

maintainability


26/148

August 16, 2010 26

Using Agile Iterative Approach

All too frequently seen as a panacea to project problems

It is not

Agile is hard

Agile has become fashionable without an understanding ofthe effort involved

Agile requires commitment, involvement and can beintense and demanding

If you have current project problems, agile is probably notthe solution

You need to fix the underlying organisational issues first


27/148

August 16, 2010 27

Agile Approaches

Lots of different agile approaches Adaptive Software Development (ASD) Agile Unified Process (AUP) Crystal Clear

DSDM (Dynamic Systems Development Method) Essential Unified Process (EssUP) FDD (Feature Driven Development) Incremental SDLC Open Unified Process (OpenUP) RAD (Rapid Application Development)

Scrum

Spiral SDLC TDD (Test-driven development) XP (Extreme programming)

Common features Teamwork, collaboration, and process flexibility adaptability throughout the project lifecycle

Divide tasks into smaller increments with accelerated planning

Multiple small iterations

Many agile processes are focussed on software development projects

Need a more generalised agile approach that can be applied to all information technologyprojects


28/148

August 16, 2010 28

Benefits of Iterative Agile Approach to Solution

Delivery

Users are more likely to be committed to the solution

Risk of building the wrong solution is substantially reduced Final system is more likely to meet the real needs of the

organisation

Implementation is more likely to be easier because of theinvolvement of all parties concerned throughout theproject


29/148

August 16, 2010 29

Agile Iterative Approach StructureGeneralised Approach to

Agile Iterative Projects

Project Selection andValidation

Control Components ofAgile Process

Agile Tools andTechniques

Agile ApproachSuitability Checklist

Solutions and ProjectsWhen to Use Agile

Agile Project CriticalSuccess Factors

Key Principles ofIterative Agile Approach

Timeboxing

MoSCoW Prioritisationof Requirements

Estimation

Project Managementand Project Planning

Risk Management

Quality Management

Measurement

Workshops

Models and Modelling

Prototypes

Testing

ConfigurationManagement

Agile Phases

Pre-Project

Feasibility Analysis andStudy

Business Analysis andStudy

Functional ModelIteration

Design and BuildIteration

Implementation

Post-Project


30/148

August 16, 2010 30

Using Agile Effectively and Productively

Agile Approach

SuitabilityChecklist

Solutions and

Projects Whento Use Agile

Agile ProjectCritical Success

Factors

Key Principlesof Iterative

Agile Approach


31/148

August 16, 2010 31

Checklist of Suitability of Projects for Agile Iterative

Approach Do the sponsor and management understand and accept the agile philosophy as their buy-in is

essential?

Will the team members be empowered to make decisions?

Is there senior user commitment to provide end user involvement? Can the organisation accommodate the frequent delivery of increments?

Will it be possible for the project team to have access to the users throughout the project?

Will the project team remain the same throughout the project as stability of the team including theuser representatives is important?

Will the project team have the appropriate skills including technical skills, knowledge of the business

area? Will the individual project teams consist of six people or less?

Will the project use technology suitable for prototyping?

Is there a highly demonstrable user interface?

Is there clear ownership?

Will the solution development be computationally non-complex as the more complex the developmentthe greater the risks involved?

Can the solution be implemented in increments if required?

Has the development a fixed timescale?

Can the requirements be prioritised with a mix of Must Haves, Should Haves, Could Haves and Want toHave but Won't Have This Time?

Are the requirements not too detailed and fixed so users can define requirements interactively?


32/148

August 16, 2010 32

Solutions and Projects When to Use Agile

Solution that is interactive, where the functionality is clearlydemonstrable at the user interface Agile is based on incremental prototyping with close user involvement

User must be able to assess the functionality easily through viewing andoperating working prototypes

Solution that has a clearly defined user group If the user group is not clearly defined, there may be a danger of driving the

solution from a wrong viewpoint or ignoring some important aspect of the

project entirely

Solution that is computationally complex, the complexity can bedecomposed or isolated If the internals of the solution are hard to understand via the user interface

then there is a risk

Level of computational complexity is often quite difficult to determine inadvance

Interactions between different components that can be difficult to identify upfront


33/148

August 16, 2010 33

Solutions and Projects When to Use Agile

Solution that is large, possesses the capability of being split into smaller functionalcomponents If the proposed solution is large it should be possible to break it down into small,

manageable chunks, each delivering some clear functionality

These can then be delivered sequentially or in parallel Each sub-project must be constantly aware of the overall system architecture

Solution that is time-constrained There should be a fixed end date by which the project must be completed If there is no real case for the end date to be fixed, it will be relatively easy to allow

schedules to slip and the fundamental benefits of agile approach will be lost Solution where requirements can be prioritised

Requirements should be able to be prioritised using the MoSCoW rules

Solution where requirements are unclear or subject to frequent change In periods of rapid change it may be difficult to specify the requirements in detail at the

outset of the project making traditional approaches unsuitable Agile approach is designed specifically to deal with requirements that change and

evolve during a project Applications that are difficult to specify in advance because the users do not know

exactly what is needed at the outset


34/148

August 16, 2010 34

Solutions and Projects When Not to Use Agile

Process control/real-time applications

Requirements that have to be fully specified before anyprograms are written

Safety-critical applications

Solutions aimed at delivering re-usable components


35/148

August 16, 2010 35

Agile Project Critical Success Factors

Acceptance of the agile approach before starting work

Delegation of decision-making to the business people and

developers in the development team Commitment of senior business management to provide significant

end-user involvement

Incremental delivery

Easy access by developers to end-users Stability of the team

Project team should be highly skilled people in terms of both thebusiness area as well as the technical environment

Size of the project team should be small in order to minimise theoverheads of management and communication

Solution technology that allows iterative development,demonstrable work products and control of versions


36/148

August 16, 2010 36

Key Principles of Iterative Agile Approach

Iterative agile approach requires acceptance of keyprinciples

1. Active user involvement is essential2. Collaborative and co-operative approach between all

stakeholders is essential

3. Agile project team must be allowed make decisions

4. Focus is on frequent delivery of products5. Fitness for business purpose is the essential measure for

acceptance of deliverables

6. Iterative and incremental development is necessary to converge

on an accurate business solution7. All changes during solution implementation are reversible

8. Requirements are baselined at a high level

9. Testing is integrated and performed throughout the lifecycle


37/148

August 16, 2010 37

Principle 1 - Active User Involvement is Essential

Agile is user-centered

If users are not closely involved throughout the projectlifecycle, delays will occur during decisions making

Users may feel that the final solution is imposed by theproject team and/or their own management

Users are not outside the project team acting as suppliersof information and reviewers of results but are activeparticipants in the project process

User and thus business commitment is fundamental tosuccess


38/148

August 16, 2010 38

Principle 2 - Collaborative and Co-operative

Approach Between All Stakeholders is Essential The nature of agile projects means that low-level detailed

requirements are not necessarily fixed when the team is assembled

to perform the work The short-term direction that a project takes must be quickly

decided without the use of restrictive change control procedures

The stakeholders include not only the business and developmentstaff within the project, but also other staff such as service deliveryand resource managers

When development is procured from an external supplier, both the

vendor and the purchaser organisations should aim for as efficient aprocess as possible while allowing for flexibility during both the pre-contract phase and when the contracted work is carried out

Can be difficult and needs substantial mutual trust


39/148

August 16, 2010 39

Principle 3 - Agile Project Team Must Be Allowed

Make Decisions

Project teams must be mixed and consist of both ITpersonnel and users

Project teams must be able to make decisions asrequirements are refined and possibly changed

Project teams must be able to agree that defined levels offunctionality, usability, etc. are acceptable withoutfrequent need to refer to higher-level management


40/148

August 16, 2010 40

Principle 4 - Focus is on Frequent Delivery of

Products

A product-based approach is more flexible than an activity-based one

Products include interim development products, not justdelivered solutions

Work of a project team is concentrated on products that

can be delivered in an agreed period of time Enables the team to select the best approach to achieving

the products required in the time available

By keeping each period of time short, the team can easilydecide which activities are necessary and sufficient toachieve the right products


41/148

August 16, 2010 41

Principle 5 - Fitness for Business Purpose is the

Essential Measure for Acceptance of Deliverables

Focus of agile is on delivering the necessary functionalityat the required time

Traditional project focus has been on satisfying thecontents of a requirements document and conforming toprevious deliverables, even though the requirements are

often inaccurate, the previous deliverables may be flawedand the business needs may have changed since the startof the project

Solution can be more rigorously engineered subsequentlyif such an approach is acceptable


42/148

August 16, 2010 42

Principle 6 - Iterative and Incremental Development is

Necessary to Converge on an Accurate Business Solution

Agile iterative approach allows systems to grow incrementally

Therefore the project team can make full use of feedback from the

users

Partial solutions can be delivered to satisfy immediate businessneeds

Agile approach uses iteration to continuously improve the solutionbeing implemented

When rework is not explicitly recognised in a project lifecycle, thereturn to previously "completed" work is surrounded by controlling

procedures that slow development down

Rework is built into the agile iterative approach process, the solutioncan proceed more quickly during iteration

P i i l 7 All Ch D i S l i


43/148

August 16, 2010 43

Principle 7 - All Changes During Solution

Implementation are Reversible

To control the evolution of all products (documents,software, test products, etc.), everything must be in a

known state at all times Configuration management must be all-pervasive

Backtracking is a feature of agile iterative approach

Sometimes it may be easier to reconstruct than to backtrackdepending on the nature of the change and the environment inwhich it was made


44/148

P i i l 9 T ti i I t t d d P f d


45/148

August 16, 2010 45

Principle 9 - Testing is Integrated and Performed

Throughout the Lifecycle Testing is not treated as a separate activity

As the solution is developed incrementally, it is also testedand reviewed by both the project team and usersincrementally

Ensures that the project is moving forward not only in the right

business direction but is also technically sound

Early in project lifecycle, the testing focus is on validationagainst the business needs and priorities

Towards the end of the project, the focus is on verifyingthat the whole system operates effectively system andintegration testing


46/148

August 16, 2010 46

Control Components of Agile Process

Since agile iterative projects are flexible in theirdevelopment activities all aspects of their management

need to be flexible while maintaining a level of control thatensures successful delivery of the required businesssolution

Key control techniques and components

Timeboxing

MoSCoW prioritisation of requirements

Estimation

Project management and project planningRisk management

Configuration management

Measurement


47/148

August 16, 2010 47

Timeboxing

Very important aspect of agile iterative process and projects

Process to reach defined objectives at a pre-determined and fixed date throughcontinuous prioritisation and flexing of requirements using the MoSCoW control

rule Timebox is a fixed interval of time - typically between two and six weeks in length

but the shorter the better

Without the control of timeboxing, project teams can lose their focus and run outof control

Used at various stages of project Project end-date is fixed and the overall business objectives to be achieved by that date

are defined End date for each increment within the project is fixed and the prioritised set of

business and technical requirements to be satisfied by that date are defined End date for phase level activities is fixed, e.g. for the Feasibility Study, and the

objectives for this project defined End date for part of the prototyping activity is fixed and the prototype is created,

reviewed and tested according to the objectives defined in the timebox schedulecontained in the Development Plan

End time for a workshop, meeting or review is fixed and the participants work to thepredefined and prioritised objectives


48/148

August 16, 2010 48

Timeboxing

A timebox must have an agreed scope and clear objectives based on a subset ofthe prioritised requirements list

With timeboxing control is not activity-based

Objective of a timebox is to make a product - produce something tangible in orderfor progress and quality to be assessed

How that product is put together will be decided by the people doing the work, aslong as the project's standards and procedures are followed

Team working in the timebox must agree the objectives and must themselvesestimate the time required

At the deadline, the users must be able to approve the delivery of the productscovered by the timebox

If it appears that deadlines could be missed, the deliverable should be de-scopeddropping the lower priority items

Detailed planning of a subsequent timebox containing dependent work cannot bestarted before the current timebox is complete


49/148

August 16, 2010 49

Timebox Plan

Plan for an individual timebox within Functional Model andDesign and Build Iteration phase

Purpose and objectives

Define the products of an individual timebox

Define key milestones, e.g. technical or user review dates,within a timebox

Agree the prioritisation of products and activities within a

timebox


50/148

August 16, 2010 50

Timeboxing and Daily Meetings

During each timebox, the team working on the timebox should meetdaily to review their progress and to raise issues

Provides the team with evidence regarding their progress and the problemsthey face

Highlight risks as they occur

Each daily meeting should be limited at 30 minutes and ideally lasts no longerthan 15 minutes

All team members attend

Agenda

What work has been completed for this timebox since the last daily meeting?

What (if anything) got in the way of completing the planned work? What work will be done between now and the next daily meeting?


51/148

August 16, 2010 51

Timebox Plan Questions and Checklist

Are the estimates of effort reasonable? Were they produced by thepeople doing the work?

Have acceptance criteria been agreed for the products of thetimebox? If they have not, is it clear when these will be available?

Is there a high degree of certainty that the Must Haves will becreated, developed and tested to the required standard?

Are the review dates agreed with all key personnel?

Have lessons learnt in previous timeboxes been applied?

Can the team commit to delivering at least the Must Haves by theagreed end date?


52/148

August 16, 2010 52

MoSCoW Prioritisation of Requirements

MoSCoWMust Have

Requirements that are fundamental to the system Without them the system will be unworkable and useless

Must Haves define the minimum usable subset

Agile project guarantees to satisfy all the minimum usable subset

Should Have Important requirements for which there is a workaround in the short term

and which would normally be classed as mandatory in less time-constraineddevelopment, but the system will be useful and usable without them

Could Have

Requirements that can more easily be left out of the increment underdevelopment

Want to Have but Won't Have This Time Requirements that can wait till later development takes place - the Waiting

List

f


53/148

August 16, 2010 53


Delivering on a guaranteed date means that what was originally envisaged for anindividual delivery may have to be left out

Important that essential work is done and that only less critical work is omitted

Means of ensuring that this is true is clear prioritisation of the requirements

Provides a basis on which decisions are made about what the project team will doover the whole project, within an increment of the project and during a timeboxwithin an increment

As new requirements arise or as existing requirements are defined in more detail,the decision must be made as to how critical they are to the success of the currentwork using the MoSCoW approach All priorities should be reviewed throughout the project to ensure that they are still

valid

Essential that not everything to be achieved within a project or a timebox is aMust Have Having lower level requirements that enable teams to deliver on time by dropping out

lower priority requirements when problems arise

M SC W P i i i i f R i


54/148

August 16, 2010 54


Solutionfunctionality is

prioritised anddelivered accordingto available timeand resources buttime and resourcesare fixed

E ti ti


55/148

August 16, 2010 55

Estimation

Estimation provides the information that is required fortwo main purposes:

Assess project feasibility by evaluating costs and benefits

Use in project planning, scheduling and control

Estimation in agile iterative projects

Estimates should be tight from the outset with frequentdeliverables

Not unacceptable for activity overrun and for long timescales for agreeingthe quality of products

Estimates that are based on outline business functions providethe closest match with the agile iterative process

Starting point for estimating should be the expected functionality of theend products rather than the activities used to deliver those products

E ti ti


56/148

August 16, 2010 56

Estimation

Estimation is a conditional forecast based on the information available at the time An extrapolation from past and current knowledge to the future

Cannot be done with complete certainty because the future is unknown, therefore the

actual effort or cost to deliver will almost always be different to the estimate Better the quality of the information available for estimating, the closer the estimate is

likely to be to the actual figures

Estimation must be based on a defined process so that it is rigorous andrepeatable

Whatever process is used the primary information required to estimate is:

Scope of what is to be delivered

Delivery capability

Contingency must be included in any estimate in order for it to be realistic estimates are conditional forecasts that will be affected by future events both internal

and external to the project Events cannot be known with certainty and the estimate must make reasonable

allowance for them

Solution development itself is not an exact science

The size of the contingency in an estimate must reflect the degree of uncertainty

Estimation


57/148

August 16, 2010 57

Estimation

Pre-project PhaseEstimation

Feasibility StudyPhase Estimation

Business StudyPhase Estimation

Before the project begins properly an estimate must be prepared for the work to be doneduring Feasibility Study phase

Estimate could be a timebox - a fixed team for a fixed period - or could be based on a scheduleof workshops and the associated effort to complete the products

First estimate for the whole project is prepared towards the end of Feasibility Study

Rough estimate, based on high level requirements - assist management to assess the value andpracticality of continuing with the project

Second estimate is produced at the end of the Business Study - scope of the project is decided,the necessary business functionality to be delivered is defined and prioritised, and the system

architecture is defined

Detailed estimate as it based on the likely major components of the delivered solutionidentified from the prioritised requirements

Estimate must reflect a level of risk and confidence that is acceptable to the relevantstakeholders

Purpose of this estimate is to plan and schedule the project and used to re-evaluate theBusiness Case to assess whether the project is still viable

Estimation


58/148

August 16, 2010 58

Estimation

Functional ModelIteration Phaseand Design andBuild Iteration

Phase Estimation

ImplementationPhase Estimation

Detailed estimate from Business Study provides the basis for the whole project, andthroughout the remainder of the project this estimate is frequently monitored and revised

Estimation is performed for each timebox to assess whether the timebox plan is achievable,and to evaluate the impact on the project if any revisions to the estimate are required

Before the start of each timebox an estimate for the expected work is carried out to ensurethat it remains achievable in light of project experience to date

If there is significant deviation from the estimates, the original estimates should be carefullyreviewed

Until the Implementation Plan is prepared during Functional Model Iteration, there are only

very high level estimates available for this phaseBefore the Implementation phase begins, the estimates must be reviewed to ensure they arestill reasonable

Estimation Techniques


59/148

August 16, 2010 59

Estimation Techniques

Top Down - estimating by comparison where the proposed project is compared tosimilar completed projects Based on the business requirements (rather than system components)

Give a figure for the project as a whole, which may be broken down into phases on apro rata basis

Fast to prepare

Can be derived from very high level requirements

Give a high level view of the project (its overall cost and timebox) which can be used inevaluating the feasibility of the project

Bottom Up - counting components and other implementation-related informationshown in a design and estimating the effort for each of those Based on tangible system components

Give detailed figures for low level components of the project which can be aggregatedto give higher level views

Take time to prepare

Need sufficiently detailed information to allow identification of system components

Provide a good basis for project planning, scheduling and management

Collaborative Estimation


60/148

August 16, 2010 60

Collaborative Estimation

Facilitated workshop can be an excellent approach togaining both sound estimates and buy-in to these

estimates from the team and the stakeholders Participants should, between them, have expertise in all

the main technical and business areas covered by the

project Project management and estimation participants

Estimation workshops require considerable preparation in

order to achieve their objectives

Estimation Guidelines


61/148

August 16, 2010 61

Estimation Guidelines

Use more than one technique to allow cross-checking, e.g. top-down and bottom-up

Produce estimates by workshops involving all stakeholders, rather than by individuals

Ensure the estimate includes sufficient effort for all timebox activities not just those directly

resulting in business functionality, including Project management, team leading, technical co-ordination User involvement Non-functional requirements and technical products Specialist roles, such as business and technical consultants, quality and test managers, security

specialists, etc. Specialist roles, such as business and technical consultants, quality and test managers, security

specialists, etc. Workshop preparation, attendance and follow up, including facilitation and scribing Completion of project documentation Quality reviews, inspections, walkthroughs, timebox planning and estimating Travel and meetings particularly if cross-site Mentoring if project and/or organisation is new to agile iterative projects

Specialist testing such as stress and performance, or operational acceptance. Ensure all areas of development are included: avoid focus on pure coding effort

Capture project metrics and feed back actuals vs. estimates into the estimating process

Ensure that anyone who estimates is trained, particularly for specialist techniques such asfunction point analysis

Project Management


62/148

August 16, 2010 62

Project Management

Aim of project management is to deliver the right solution on timeand on budget using the available resources wisely

Management of traditional projects is about control Preventing drift from the signed off specification, controlling resources, etc.

Managing an agile project is about enabling constant change whilecontinuously correcting the course of the project in order to

maintain its aim at the target - a fixed delivery date for a usablesystem

To be successful with agile iterative approach, the organisation may

have to change organisational, social and technical elements at thesame time

All impact on the management of the project

Project Management


63/148

August 16, 2010 63

Project Management

For tradition projects, the project manager has a detailed planagainst which to monitor and control activities

In an agile and iterative project, there are typically more activitiesgoing on in parallel

Project Manager has a number of distinctive responsibilities to ensure that theproject is under control in each phase

Speed of progress can pose some difficulties for managers from atraditional background in IT project management

If problems arise during a timebox then it is often tempting for the traditionalmanager to renegotiate the end date as that is what they would normally do

In an agile project, the timebox deadline is fixed usually because it is set by thebusiness need

Consequently, the approved approach is to renegotiate the content of thetimebox rather than its duration

Project Management


64/148

August 16, 2010 64

Project Management

In the agile iterative collaborative approach, there is a great deal ofinteraction between users and implementers in task completion

Important that communication is clear and concise if rapiddevelopment is to be achieved

Agile projects should have an informal but planned communicationprocess

As each timebox is completed, it is the responsibility of the ProjectManager to ensure that there is a clear understanding about what isto be delivered in the following timeboxes and to ensure that therelevant requirements are established in detail

Likely that the users will change their minds about priorities and requirements

Project Manger must be open to making such changes whilst ensuring that anyconsequences are fully understood by the users

Project Management


65/148

August 16, 2010 65

Project Management

Pre-project Phase

Feasibility StudyPhase

Business StudyPhase

Initial planning Verify suitability of profile for agile approach Agree project review and termination evaluation and decision factors Confirm user involvement Give training in agile approach for all people new to the method Schedule workshop facilitators

Set up the Feasibility Study team Attend all workshops Review/accept and get signoff for the Feasibility Report

Ensure that all key stakeholders have bought in to the Prioritised Requirements List andthe proposed timescales for (incremental) delivery for the project Create a high-level Business Case for the project Create the Outline Plan Schedule Business Study workshop

Manage production of the Business Study products

Attend all workshops Review and update project risks Create the Development Plan jointly with all relevant people Refine the Business Case and get it agreed by the relevant people Obtain agreement to proceed into development Ensure that all project Team Leaders are aware of the contents of the Business Case so

that they can use it as the basis for negotiation about what is important within theirtimeboxes

Project Management


66/148

August 16, 2010 66

Project Management

Functional ModelIteration Phase

Design and BuildIteration Phase

ImplementationPhase

Agree individual Timebox Plans with the Team Leaders Participate in timebox kick-off and closeout meetings Accept all timebox deliverables to the project at each timebox closeout meeting Monitor the team(s) Create the Implementation Plan jointly with all relevant people Publish the Implementation Plan and get it agreed by the relevant people before the end

of the last pass through the Functional Model Iteration

Agree individual Timebox Plans with the relevant Team Leader

Participate in Timebox kick-off and closeout meetings Accept all timebox deliverables to the project at each timebox closeout meeting Monitor the team(s)

Manage the migration of the system to the operational environment Ensure all necessary training takes place in a timely way Run the Increment Review workshop and produce the Increment Review Document Obtain sign-off of the increment from all relevant parties Plan the next increment if there is one For the last increment, set the date for the Post-Implementation Review

Project Management


67/148

August 16, 2010 67

j g

Post-project Phase Ensure all lessons learnt are made available to other projects Participate in the Post-Implementation Review

Project Planning


68/148

August 16, 2010 68

j g

The purpose of project planning is to ensure the success of the project

For agile projects planning is not just an activity that takes place at the beginningof the project - it continues throughout the lifecycle

Planning an agile project can be especially difficult for a project manager used totraditional methods

Agile project plans evolve with more and more detail as the project progresses, asrequirements are progressively refined and as lessons are learnt

Plan should address all products generated by, and activities undertaken in, theproject Includes the deliverable products (prototypes, models, documentation, etc.)

Project initiation

Configuration management

Change control

Product breakdown structure

Product descriptions

Risk management

Work instructions

Project Planning


69/148

August 16, 2010 69

j g

Traditional project planning Focus on agreeing a detailed "contract" with customers about the totality of

the system to be delivered along with the costs and timescales

Concerned with understanding the requirements in complete detail so that theright level of resources can be secured and an estimate of the completion timecan be made

Plan is created in a great detail and is ideally executed with minimal change

Agile project planning Focus on setting up a collaborative relationship with the customers, bringing

them fully into the make-up of the team

Concerned with agreeing with the users the process by which the businessrequirements will be met

Initial plans are created in sufficient detail to establish the main parameters ofthe project and with the firm expectation that the customers will change theplan during the course of the project as they gain a deeper understanding oftheir needs

Pre-project Phase Planning


70/148

August 16, 2010 70

p j g

Objective of pre-project planning is to provide the basis forcarrying out the project successfully

Understand the requirements just sufficiently to assess therisks and suitability of the project for an agile approach

Establish the right conditions for the project with the user

management Ensure that the managers from the business have agreed

to release their staff into the development team forsignificant periods of time (including full-time secondment

when the project requires it) Agree a definition of "fitness for business purpose" for the

system being developed with the business

Agile Project Plans


71/148

August 16, 2010 71

Feasibility StudyPhase

Business StudyPhase

Outline Plan

Means to define and agree the terms and conditions for a successful project andcontains as a detailed plan for the Business Study

Functional ModelIteration Phase and

Design and BuildIteration

Phase

ImplementationPhase

Development Plan

How the project will be carried out and in particular which prototypes will be builtand when

Timebox Plan at the start of each timebox

Refines the Development Plan where each Timebox Plan contains at least onecomplete cycle of the Functional Model Iteration or Design and Build Iteration forpart of the system

Implementation Plan

Defines how the successful implementation of the solution will be achieved

Agile Planning Success Factors


72/148

August 16, 2010 72

The contents of timeboxes are crucial

Plan for deliverables and not activities Consider the key questions "who, when what, where, how" when planning

Define quality criteria for each deliverable

Plan for frequent delivery of products Distinguish "delivery to the project" from "delivery to the end user population"

Focus of planning and control in agile projects is on sustaining a high rate of progress, agreeingpriorities, keeping relationships healthy, learning as the project progresses, and allowing plans toevolve based on experience gained

Make project planning work by focusing on principles, products, and people rather than methods and

techniques Manage expectations by planning appropriate briefings and training on agile approach, addressing

roles and responsibilities, and defining and agreeing products and acceptance criteria

Plan for the use of experienced mentors where there is insufficient experience in the team

Plan to do the work during normal working hours

Plan contingency only for prerequisites (software, hardware, setup, etc.) but not for time or resource

on the project itself Contingency in agile is managed through prioritisation of requirements

Plan for regular daily team meetings

Plan formal reviews at the end of each timebox and establish dates in diaries early

Plan early for testing interfaces, theoretical performance analysis, and performance prototyping


73/148

Risk Management


74/148

August 16, 2010 74

Ongoing process throughout the life of a project

Actively control all the risks facing a project or the

implementation of the solution it is delivering Identification of any and all risks that may threaten the project for

business, systems or technical reason

Assessment of the impact of those risks on the success of the

project should they arise and deciding on the likelihood of the riskoccurring and if it does on the severity of its impact on the project

Management of those risks through defining specificcountermeasures that are aimed at either avoiding the identifiedrisks or accepting them and minimising their detrimental effect onthe project

Applying the appropriate countermeasures when a riskmaterialises


75/148

Risk Log


76/148

August 16, 2010 76

Opened at the start of the project to assist management in deciding the future ofthe project Class of risk (business, systems or technical) Description of the risk - should be in sufficient detail to be understood by all interested

parties but short enough to enable a checklist approach to risk monitoring throughoutthe project Likelihood of the risk occurring (high, medium or low) Severity of impact on the project should the risk occur (high, medium or low) One or more proposed countermeasures, which will mitigate the risk either by

preventing it occurring or by containing when it arises

Countermeasures should include the dates beyond which they are no longer applicable The status of the risk (open or closed), open risks are still possible, closed risks have

either happened and have been dealt with or the time at which they were likely tohappen has passed

Owner of the risk (who is responsible for monitoring the risk and/or implementing anycountermeasures)

Checklist Are all the factors potentially affecting the success of the project discussed? Are risks sufficiently quantified for a decision to be made? Does each risk have at least one countermeasure identified?

Quality Management


77/148

August 16, 2010 77

Quality of an information technology solution often defined in termsof the way in which that system provides the capability and supportrequired by the user

Agile approach designed to ensure the quality of the project'sproducts Facilitated workshops ensure that the system's requirements are properly

considered at the outset

Continuous and focused user involvement helps to ensure that all partiesunderstand each others - needs and viewpoints

Reviews (whether of prototypes or of supporting documentation) serve toensure (and record) that the system continues to meet the needs of thebusiness - the quality criteria against which products should be reviewed areidentified the Product Descriptions

Thorough testing validates the delivered system against its requirements

Configuration Management and Change Control serve to ensure that quality,once built in to the system, is preserved

Quality Planning


78/148

August 16, 2010 78

Quality planning should be an integral part of the project planningactivity Identification of which products are to be produced and which of those

warrant specific quality-related activities

How the quality of each type of product is to be checked - for example byreview and/or by testing

When quality checks are to be performed; and whether they are they optionalor mandatory, whether or not all examples of a particular type of product mustbe checked or only a sample, and whether items are checked duringdevelopment or only on completion

Who is responsible for reviewing and testing each product, who has authorityto accept the product and what is to happen if such a review or test isunsuccessful

Which criteria are to be used to assess each product's quality - typically byreference to the quality criteria defined in each of the Product Descriptions

Which procedures are to be used to define quality-related processes

Which records are to be kept to document decisions and actions taken Which standards are to be applied to products (for example, coding standards

and user interface style guides)

Quality Audits


79/148

August 16, 2010 79

Audit projects from time to time in order to determine theircompliance with the organisation's procedures, practices andstandards

Very important in agile projects that such audits are not allowed toresult in unnecessary rework or ineffective effort expenditure

Greatest benefit obtained from audits is frequently in causingcorporate procedures, practices and standards to be revised in thelight of real experience

Agile-specific audit questions Is the user involvement there? Are the users empowered? Is the life-cycle being followed?

Are comments from prototype reviews being incorporated?

Is backtracking allowed when necessary? Are priorities being adhered to? Are timeboxes being respected?

Measurement


80/148

August 16, 2010 80

Measurement is necessary in order to: Establish a baseline for predicting what will happen in the future

Provide evidence that the process is successful and working

Investigate the process itself in order to highlight and quantify problems

Can provide the information to convince management that theintroduction of agile iterative approach can provide tangible benefitsto the organisation

Projects should keep careful records of defects classified by severityand type

Success of a project will be whether or not it achieved the statedobjectives so these should be described in precise measurable terms

Agile approach is focused on satisfying all of the "must haves" within a fixedelapsed time frame so any measurement of success needs to include all ofthese

Agile Tools and Techniques


81/148

August 16, 2010 81

Tools and techniques that are applied to agile projects

Workshops


Prototypes

Testing

Configuration Management

Workshops


82/148

August 16, 2010 82

Workshop is a structured approach to ensure that a group of people can reach a predeterminedobjective in a compressed timeframe supported by an impartial facilitator

Benefits Rapid, quality decision-making

Because all stakeholders are present at the same time, there is great confidence in the result

Group is focused on the objectives to be achieved in the session so that the information gathering and review cycle isperformed at a greater speed

Misunderstandings and disagreements can be worked out at the time Concerns should therefore have been raised and resolved or noted by the end of the workshop

Greater user buy-in Workshops, run effectively, lead to participants feeling more involved in the project and decisions being made Build and maintain enthusiasm

Building team spirit

Controlled way of building rapport as well as delivering Promotes understanding and co-operation between departments - important when a solution involves many groups

Process redesign by the user community If practices are reviewed as a result of a workshop, participants can gain a greater understanding of the inputs and implications

of their work Leads to improved efficiencies that are led by the participants themselves, giving greater buy-in and commitment Greater chance of successful implementation

Clarification of requirements when they are unclear

Business users can be led through their objectives and processes to define what they may require Participants can explore and model ideas Successful through a combination of structured discussion and the presence of knowledgeable participants


83/148



84/148

August 16, 2010 84

Modelling helps the project team gain a good understanding of a businessproblem, issue or process

Accurate models reflect the realities of the business world

Understanding can be gained by analysing the problem from different viewpoints Business View - uses a selection of techniques to understand and interpret the business

need and to model the business from a future perspective Processing View - models the system as a set of business processes, or activities, which

transform input data items to output data items Processes can be either combined to form higher level processes, which in turn can be

combined again to form yet higher level processes, or decomposed into their constituent sub-

processes Corresponds to the traditional "Why, What and How" type of questioning used during

requirements elicitation

Data View - models the business information as a set of objects, or entities, and therelationships that exist between these objects

Behavioural View - models the behavioural characteristics of the system in terms of a

set of events and states, where events cause changes in the states of the system. Eventsmay be generated within or external to the system User Interface View - models the interactions and interfaces between the system user

and the system itself

Prototypes


85/148

August 16, 2010 85

Prototypes provide the mechanism through which users can ensurethat the detail of the requirements is correct

Demonstration of a prototype broadens the users' awareness of thepossibilities for the new system and assists them in giving feedbackto the project team

Accelerates the development process and increases confidence thatthe right system is being built

Types of prototype Business - demonstrating the business processes being automated

Usability - investigating aspects of the user interface that do not affectfunctionality

Performance and Capacity - ensuring that the system will be able to handle fullworkloads successfully

Capability/Technique testing a particular design approach or proving aconcept

Testing


86/148

August 16, 2010 86

In agile projects testing takes place throughout the projectlifecycle

Validation - check that a system is fit for business purpose

Benefit-directed testing - testing the parts of the solution thatdeliver the key business benefits is the highest priority

Error-centric testing - objective of designing and running a test is

to find an error Testing throughout the lifecycle - performed on all products at all

stages of the project

Independent testing - a product should be tested by someoneother than its creator

Repeatable testing - tests must be repeatable

Testing


87/148

August 16, 2010 87

Testing activities must be prioritised based on the business goals

Overall business process performance (i.e. business processing cycle times)

Large processing volumes (i.e. very frequently occurring events)

Labour-intensive or complex business tasks

Human computer interface, particularly if the computer system will be visibleto customers

Efficient use of time available can be made through risk basedtesting

Identify the risk areas

Assess the impact of errors

Plan for risk based testing

Reduce the risk of errors

Configuration Management


88/148

August 16, 2010 88

Dynamic nature of ale projects means good configurationmanagement is required

Many activities are happening at once and products arebeing delivered at a very fast rate

Configuration management strategy must be decided and

documented in the Development/Implementation Planbefore leaving the Business Study phase

Iterative Agile Framework


89/148

August 16, 2010 89

Solution delivery lifecycle is iterative and incremental

Solution is not be delivered in one go, but in a series of

increments, which increase what it does each time

Urgent business needs are addressed early while lessimmediately important functionality is delivered

Users see work under construction, review and commenton it and request changes during the development of anincrement

Agile approach provides a generic framework for iterativesolution delivery

Overall Agile Iterative Process - Phases


90/148

August 16, 2010 90

1. Pre-Project

2. Feasibility Analysis and Study

3. Business Analysis and Study

4. Functional Model Iteration

5. Design and Build Iteration6. Implementation

7. Post-Project

Overall Agile Iterative Process

6


91/148

August 16, 2010 91

FeasibilityAnalysis and

Study

BusinessAnalysis and

Study

Post-ProjectFunctional

Model

Iteration

Implementation

Design andBuild

Iteration

Pre-Project

SequentialPhases

Iterated Phases

1

2

3

4

5

6

7

Iterated Phases


92/148

August 16, 2010 92

FunctionalModel

IterationImplementation

Design and

BuildIteration

IdentifyWhat IsTo Be

Produced

Agree Howand When To

Do It

CreateThe

Product

Check That It Has

Been ProducedCorrectly

IdentifyWhat IsTo Be

Produced


Do It

CreateThe

Product

Check That It Has

Been ProducedCorrectly

Identify

What IsTo Be

Produced


Do It

Create

TheProduct

Check That It HasBeen Produced

Correctly


93/148


94/148

Phase 2 - Feasibility Analysis and Study Phase


95/148

August 16, 2010 95

Assessment if iterative agile is the right approach for theproject

Feasibility Study should be short and should last no morethan a few weeks

Consider using workshop(s) to perform feasibility analysis

Feasibility Study outputs

Feasibility report

Outline plan for implementation

Feasibility prototype

Solution risk log

Feasibility Analysis and Study Report


96/148

August 16, 2010 96

Enables the project steering committee to decide not only which option to choose for theway forward and whether or not the project should proceed beyond the Feasibility Study

Objectives and purposes Outline the problem to be addressed by the new system

Define the scope of the project or set of projects Give a preliminary indication of any areas within the scope which may be desirable but not

essential State, at least in outline, the Business Case for the project(s) - including where possible expected

costs, benefits, assumptions and risks (whether quantifiable or not) Indicate what alternative solutions have been or could be considered Define the major products to be delivered by the project

Report on the suitability of an agile approach for use on the project, which may vary for eachsolution

Document the objectives of the project including process performance criteria Document high-level technical and business constraints, e.g. timescale, hardware and software

platforms Identify whether the system may be safety-related or if there may be any product liability issues Describe at a high level the business processes and data that are expected to be automated

Identify at a high level the interfaces necessary to existing data and applications

Identify which business processes and/or systems (whether automated or not) might be impactedby the new system and which might need to change in order to accommodate it

Define the expected life of the computer system and hence the requirements for maintainability

Feasibility Analysis and Study Report Questions andChecklist


97/148

August 16, 2010 97

Is the problem definition in line with the needs of senior business management?

Is the scope of the project sufficiently clear for it to be refined within the BusinessStudy?

Are the business objectives to be met by the development clearly defined? Is the solution to the problem, as laid out in the major products to be delivered

and in the objectives of the project, feasible in both technical and business terms?

Is the case for the project approach sound and are the risks acceptable?

Does management accept what has been included and excluded from the scope? Are all associated systems and their interfaces identified?

Is any impact on those systems acceptable?

Is the Business Case for the project to proceed valid?

Feasibility Prototype


98/148

August 16, 2010 98

Feasibility prototype may be produced as a proof ofconcept for the proposed solution

To prove one or more of the possible technical solutionscontained within the Feasibility Report

To demonstrate to the business the possible content of the userinterface and the look and feel

Prototype should only be produced if it will really assist thedecisions made in the Feasibility Report

Outline Plan for Implementation


99/148

August 16, 2010 99

First planning product within the project

Sets deadlines and milestones for various major phases of

work and key deliverables (particularly incrementaldelivery dates)

Deadlines become the major control points around which

the later, lower level plans will be developed Provides the detailed plan for how the Business Study

phase will be run

Outline Plan for Implementation


100/148

August 16, 2010 100


Provide management with ballpark estimates of the financial and resourceimplications (both project team and user) of the proposed project

Provide a basis for agreement of timescales for the proposed developmentactivities

Define the high-level acceptance criteria for the proposed deliverables such asthat the system will conform to all agreed requirements

Define and agree the approach to the Business Study phase Identify any particular facilities which the project team will require

Define the expected path through the agile framework for the project

Identify any currently known issues surrounding the implementation of thesystem and in particular aspects such as data take-on and user handover

Outline Plan for Implementation Questions andChecklist


101/148

August 16, 2010 101

Are the estimates for effort realistic in the light of the details within the FeasibilityReport?

Are the estimated timescales consistent with the business needs of the project?

have the business needs been addressed in terms of what is delivered and when?

Is business management able to commit to the level of business resourcesrequired for the Business Study and to ongoing user involvement for the proposedduration of the project?

Is development management able to commit to the level of developmentresources required for the Business Study and to ongoing involvement for the

proposed duration of the project? Will all necessary equipment and facilities be available as required?

Is it clear what the criteria for acceptance are and are they rigorous enough todefine the quality of deliverables while allowing the requirements to flex duringdevelopment?

Are all the currently identified standards and guidelines available and for thosethat are not yet available, are there sufficient resources to enable theirdevelopment or procurement?

Phase 3 - Business Study Phase


102/148

August 16, 2010 102

Only initiated if Feasibility Study and Report recommends to proceed with solutiondevelopment

Forms the basis for all subsequent work

Should be kept as short as possible (weeks rather than months) while achievingsufficient understanding of the business requirements and technical constraints tomove forward with safety

Focus is on the business processes affected by the solution and their informationneeds

Phase has to be very strongly collaborative using workshops attended byknowledgeable staff who can quickly pool their knowledge and gain consensus asto the priorities of the development

Key workshop output is the Business Area Definition which identifies the businessprocesses and associated information and the groups/types of users who will be

affected in any way by the introduction of the solution

Users who will participate in the solution development will be identified andagreement reached with their management regarding their involvement

Business Study Phase Outputs


103/148

August 16, 2010 103

Business Area Definition

Prioritised Requirements List

Development/Implementation Plan

System Architecture Definition

Updated Solution Risk Log



104/148

August 16, 2010 104

Contains a high-level view of the business processes,people and information to be supported by the proposed

solution Evolves into the Functional Model during Functional Model

Iteration(s)

Must be in enough detail to enable both the DevelopmentPlan and a realistic business case


P d Obj ti


105/148

August 16, 2010 105

Purpose and Objectives Identify the business needs that should be supported by the

proposed solution

Refine the Outline Business Case (documented in the FeasibilityReport) to include benefits, risks, costs and impact analyses

Outline the information requirements of the business processesthat will be supported

Identify the classes of users impacted by the development andintroduction of the proposed system

Identify the business processes and business scenarios that needto change

Clarify all interfaces with other systems (human or automated)

Verify that the proposed solution is still suitable for developmentusing an agile iterative approach

Business Area Definition Questions and Checklist

Are the business context business process and business objectives defined and agreed?


106/148

August 16, 2010 106

Are the business context, business process and business objectives defined and agreed?

Have all the currently identified requirements been prioritised (including non-functionalrequirements)?

Have all the priorities been assigned in collaboration with the users?

Have high-level acceptance criteria for the delivered solution been defined? Are the business areas clearly documented, including high-level information needs that are

affected by the system?

Is the envisaged boundary of the proposed new system realistic in the timescales?

Are all classes of users affected by the new system identified?

Are the information and processing requirements of the proposed system defined at leastin outline?

Is it still clear that the business needs are being addressed by the proposed new system?

Is the person responsible for each business process identified? Can they commit thenecessary resources and time?

Are all major business events (e.g. financial year-end, order received, new supplier takenon) identified?

Generating and Managing Requirements

All of the requirements identified during the Feasibility and Business


107/148

August 16, 2010 107

All of the requirements identified during the Feasibility and BusinessStudies have to be prioritised and recorded so that the mostimportant features will be developed in preference to less essential

parts that can be added later if required Prioritisation will mainly be led by business need but will also need

to take into account the technical constraints that may drive somerequirement to be satisfied first even though it may be lessimportant in business terms

Some non-functional (operational) requirements, such as securityand performance, may also affect the prioritisation

As parts of the solution will begin to be produced in the next phase

(the Functional Model Iteration), it is not only important tounderstand the functionality to be developed but also the systemarchitecture that will be used


Defines the plans and controls for the whole project or just for the


108/148

August 16, 2010 108

Defines the plans and controls for the whole project or just for thenext increment


Refine the Outline Plan to provide a more detailed plan for activities within theFunctional Model Iteration and Design and Build Iteration

Provide the development team with a strategy for development

Prioritise prototyping activities

Define the categories of prototypes that will be developed and when

Define the mechanisms for deciding when a particular prototyping activityshould terminate

Identify individuals who will take on the various roles and responsibilities onforthcoming phases of the project

Identify which items are to be subject to configuration management and tooutline how configuration control is to be applied

Define the approach to be taken to testing: what types of tests are to be run,how they are to be specified and recorded


First Development/Implementation Plan produced in a


109/148

August 16, 2010 109

First Development/Implementation Plan produced in aproject should cover the overall development approachand the plan for the Functional Model and Design andBuild Iterations for the first increment

As new increments are started, the controls should bechecked for their validity and possibly updated

Plan for the next increment is added to theDevelopment/Implem

Date post:	29-May-2018
Category:	Documents
Upload:	alan-mcsweeney
View:	217 times
Download:	0 times

Implementing Agile Iterative Project Delivery Approach and Achieving Business Responsiveness

Documents