iterative project management chapter 3 - controlling an iterative project modified considerably by...

Iterative Project Management

Chapter 3 - Controlling an Iterative Project Modified considerably by Instructor

Two Classes

2Iterative Project Management / 02 - Controlling an Iterative Project© 2005 Ivar Jacobson International

Objectives – Major sections:

• Introductory Remarks• Variables that Shape Projects

– Scope; time; cost; quality

• Stakeholders – the Real Drivers of project success• Controlling the Project as a Whole• The Unified Process Phases


0. Introductory Remarks

• Big point behind iterative development is this approach provides for – enabling stakeholders to evaluate progress, replan, if necessary, and – empowering management to take full control over projects

maximizing the chances of success.

• Managing iterative projects is challenging because all of the disciplines: project management, requirements, analysis, design, implementation, and test are interleaved such that there are no real clear cut boundaries from one to the other.– Very different from methodologies from the past that are still in large

part subscribed to…– This perceived inability to plan in accustomed ways can cause some to

‘retreat’ to waterfall style while citing this as proof that iterative approaches do not work

• Just like any other approach, we need training and practice.


Introductory remarks – 2

• Again, dividing a project into iterations – provides much greater control over the project because it allows

us to:• explicitly manage risk within each iteration, and • force each iteration to produce something tangible that can

be tracked, quantified, and reported to senior management.

– Each iteration removes different risks in a planned manner and not haphazardly.

– The key is: knowing exactly what to do and when to do it, and how much of each discipline we need to employ in an iteration, and how to assess progress.

• Lets look at essential variables crucial to planning these iterations.


I. Variables that Shape Projects:

• Key variables presented in most management books include:– Scope, cost, and time, or– Quality, cost, and time

• Our approach is to employ all four in a not-so-rigid ‘square.’

• First: look at the metrics (parameters) scope, quality, cost and time.


Key variables – scope, quality, cost, and time• Scope:

– All develop efforts have lists of requirements or features that need to be cranked into the application (new or redesigned into…)

– Generally speaking, this is the number of requirements (usually in terms of features or functions) that the software must accommodate.

– These can be captured in may ways some of which we have discussed. (More ahead on this)

– Every project has scope.

• Quality:– Usually quantified in terms like MTBF, MTTRMTTR – as used in real-time

systems and other engineering / manufacturing / similar systems.• Not used very much for information systems…

– A sometimes used metric is defects/thousand lines of code• Can be very misleading…• Just because there is a small number of defects does NOT mean

that the code is of high quality: – Better: fitness for purpose – measured in terms of the relative

priority of the implemented features and the number of them that were actually required.

– Sometimes number of ‘incident reports’ or ‘deficiency reports…’


Key variables – scope, quality, cost, and time

• Cost:– Usually termed, ‘resources.’ – Single most significant aspect of a software development’s

project cost.– People, equipment, training, customer service, travel,

development / management support…

• Time:– Time taken to complete the project – usually stated in terms

of some market driven goal of having the solution to market by some specific day

– Often measure in man-hours/ man-days / man-years…– Remember, people and time are NOT interchangeable!!


Additional comments:

• Important to note variables are not mutually independent• They form the basis of visuals or other ‘mechanisms’ such

as time box, scope box and others to be discussed.

• Changes in time may well affect other parameters; certainly changes in scope may well do the same.

• Changes in one of these parameters must be compatible with the others – and may well not be.

• These four parameters must be compatible, attainable, and supported by stakeholder’s ‘shared’ understanding of the project’s success.

• (Remember, ‘Take no small slip!’ – Frederick Brooks, The Mythical Man Month.


II Stakeholders: the real drivers of project success

• Must realize the stakeholders that drive the project.– But there are several categories of ‘stakeholders.’

• They are the primary sources of requirements, constraints, and risks, funding and much of and often ultimate decision making.

• May ‘classify’ stakeholders by ‘domain:’– The Problem – those affected by the problem(s) the project will solve.

• They are the primary sources of requirements; • They will ‘confirm’ when problem solved and accept solution.

– The Solution – those affected by solution because they must support the operation or change their jobs.

• Might not directly benefit from the solution.– The Project – group responsible for delivering the solution to other

stakeholders


• We constantly need to prove to these stakeholders that real progress is being made.

• GREAT QUESTION: • HOW DO WE DO THIS?• HOW DO WE ASSUAGE THEIR FEARS?• HOW DO WE INSTILL CONFIDENCE IN THE PROCESS?

• All we do is directed toward these ends.


III Controlling Individual Iterations – Key Parameters

• All iterations have – a beginning, middle, and end along with – goals and success criteria used to assess performance.

• First and foremost, we must control the iterations in order to control the overall project.

• Our approach: ‘fix’ two of the classic control variables and vary the other two

• We will fix time – by creating a ‘time box’ and• We will fix scope – by defining exactly what will be

delivered in the iteration.• We will then consider controlling iterations using a time

box or a scope box and discuss the relative merits (or demerits) of each.


Time Boxing

• Idea here is to divide project into a series of equal length time boxes.

• Except for some initial time boxes, which may require a little learning to lock in a good ‘period,’ these should be fixed and remain fixed at all costs!

• Time boxes are the sacred cow of an iterative process.– are the building blocks / framework of successful iterations!– provide for a pause, synchronization point for progress of all kinds

• Time is fixed and scope becomes the control variable– Cost varies with time and scope– Quality is considered as a secondary control variable.

• For a specific iteration, we identify the requirements (scope – in terms of scenarios) whose implementation may be used to determine success.– We set a quality level desired and costs are usually controlled by

number of people working during this iteration.


Iterations: Time Boxes or Scope Boxes

Scope

Resources Time

Quality

Scope

Resources Time

Quality

• Scope Box – A fixed set of requirements delivered in the time needed to realise them to an agreed level of quality.

• Time Box – As many requirements as can be realized in a fixed amount of time with a given amount of resources. (the desired amount of quality factors in…)

Time is the fixed component of the project plan; functionality becomes the variable.Time boxingTime boxing is recommended approach for controlled iterative and incremental development.


Recommendation: Time Box The Iterations

Time

Start Deliver

Iteration 2

Start Deliver

Iteration 1

Resources

Start Deliver

Iteration 3

The start and end points of each iteration are fixed.Effort available is governed by the size and skill of the team.

Note: Time is fixed, resources may vary. But the resources are normally fixed for an iteration: An appropriate amount of work - based on priorities of requirements / effort - is determined.


We map an appropriate amount of work onto the time box (iteration).Scope is thus established by selecting requirements, changes, defects, starting with highest priority items and working down to lesser ones.Ideally, they are of approximately equal effort.This approach greatly simplifies the planning process. (Much more later…)

Fitting the Work (Scope) Into the Time Box

Requirement 1

Requirement 2

Overhead


Adjust The Plans (not time boxes) Based On Project Results• Each iteration is assessed and the feedback generated used to

adjust the project plan. May be shortfalls moved to later iterations.

• Do not change the length of the time box!

• Since we address most significant items first (risk, functionality) If we come up short, it should be for those ‘lesser’ items.

• Can always move items from later iterations to current one, if...

ThisTime Box

LastTime Box

Future plans are adjusted in the light of lessons learned from the current iteration.Feedback used to adjust the project plan


Caution on Roll Back…

• It is important that the impact of moving work back is assessed for the project as a whole, and that the project does not succumb to the snow-plow effect.

• This may occur when all the work gets pushed back, iteration by iteration, and we end up in the situation where the last iteration is expected to deliver its originally planned functionality plus all of the left over work from the preceding iterations.


Adjusting time boxes if we come up short???

• Seems like this is reasonable, but…if we do:• Box boundaries become meaningless• Once we slip, we will likely slip more rather than catch up.• Must ‘close out’ the iteration and learn. Domino effect….• Time boxes establish a sense of urgency; a rhythm; pulse.

– We are aware of project constraints and we need to be!

• As a heuristic, develop the most important requirements first – so that if you come up short, lesser requirements drop out.

• It is indeed tempting to stretch the iteration just a wee bit. But:– Extending implies all is going well – must be realistic and honest!– It is not disruptive to stop and pause and adjust the next iteration.– Don’t want to appear we are failing to achieve objectives.

• Perhaps original objectives were too aggressive. Recognize these.


Treat The Time Box As Sacred

Rather than change the current time box, work is moved around between the iterations.

If there is too much work move some to the next iteration rather

than extend the time box.

If all the work is done move some forward from the next

iteration rather than shrink the time box.


Beware of Slipping!!!!

• The authors cite that they can all think of circumstances where it might be beneficial to extend an iteration’s time box to allow the team to successfully fulfill the iteration’s objectives

• But, as a general ‘rule-of-thumb’ this should be avoided.• An extension should only be considered as an appropriate

action once the iteration has been concluded at the end of the original time box. – This may be one form of adjusting the project plans.

• They cite clearly that once things start to slip they are more likely to slip some more rather than conclude the iteration, especially if we do not take the time to – close out the iteration and – learn the lessons from its execution.


Heuristics for controlling iterative projects w/time boxes:

• Estimate and prioritize work to be done• Address highest priority items first• Assess iterations and act upon lessons learned• Measure performance and progress in each iteration• Adjust priorities and scope based on results.

• Time boxing, remember, is (among other things) used – as a management tool used to gauge project progress.– To provide regular inputs to stakeholders as to the progress of the

project.– To facilitate predictability resulting from successful iterations helps in

the planning and understanding of stakeholder involvement. – To assure all stakeholders that the project is on track.


Second Night on this set of Slides


Scope Boxing

• Here: we have specific sets of requirements /iteration. • ‘Scope’ drives the iteration

– (the more functionality we include in the scope box, the more must be completed to meet the objectives of the iteration).

• D1: Scoping gives rise to iterations of unequal duration.• D2: This stops fixed periods of evaluation and • D3: This stops the use of time as a control mechanism.• Many have adopted this approach but it is not truly

iterative and incremental and does not really control project scope, schedule, and effort. Why NOT???– Without regard to fixed time limits, this can be very dangerous.– Requirements are not moved, instead iteration length is extended– Absence of hard time constraints may obviate the sense of

urgency for getting work done.– Lack of deadlines hurts keeping project on track.


Scope Boxing

• Additional problems – When do you adjust project plan as a result of learning in a scope box?– What do you do if the scope box is overrunning?– What do you use as intermediate milestones?– Under what circumstances can you draw the scope box to a close

before it is completed?– When do you pause and learn from lessons learned from scoping?

• Progress is now irregular and unpredictable – How so?• No opportunity for feedback before work is ‘done’ Agree?• Fewer opportunities of some stakeholders to provide early

inputs – Agree? How so?• Can be a lack of motivation and hence a lack of direction.


Authors’ recommendations (1 of 2):

• Guidelines for controlling iterations:• 1 Every iteration should be treated as a discrete time box

• 2; Iterations should be defined by their intended results and the evaluation criteria for these results

• 3. Every iteration should actively address and reduce project risk

• 4. During an iteration, the project team members should focus on meeting the objectives of the iteration alone and doing whatever they can to ensure the iteration’s success and no more.

•


Authors’ recommendations (2 of 2):

• 5. Every iteration should produce an executable release. The release should fulfill more the the project’s requirements than the previous release (from the previous iterations) (incremental advancement of business value!)

• 6 Every iteration should end on time Don’t change date/time

• 7. At the end of the iteration, its results should be objectively assessed; the team should be prepared to rework the solution and project plan as required.

We still do not have enough detail here to plan iterations. Need more to be able to discuss how to decide what project risks should be addressed first and what requirements should be implemented in which iteration.


IV Controlling the Project as a Whole

• We clearly need some kind of overarching control framework within which the project can iterate

• Cannot simply have a set of iterations….– Time boxed or otherwise….

• Need a framework to address certain risks / functionalities first.

• Need some kind of lifecycle ‘anchors’ or ‘milestones’ through which we can check out the ‘state’ of the project.


Lifecycle Anchor Points – Technical Milestones• Look to three anchor points between project start-up and close-down

– Lifecycle Objectives (LCO)• Project Viability Agreed; Conclusive proof; • Technical and Financial feasibility.

– Understand scope and risks that threatened completion

– Have a credible plan and architecture in place.

– Lifecycle Architecture (LCA)• Selected technical approach - proven and stable.• Architectural model solid; agreed to; workable.• Execute a partial solution indicating solution works…

• LCO and LCA measure the state of the project as a whole.– Focus is not on requirements snapshots or architecture-point solutions.– Rather, focus is on requirements and architectural specifications

which anticipate and accommodate systems evolution.

• Hence: ‘Lifecycle Objectives and Architectural Milestones.’

• Do these look familiar???


Lifecycle Anchor Points – Technical Milestones - more

According to your authors:• Stakeholder concurrence on the milestone elements is essential.

– Establishes mutual stakeholder buy-in to the plans and specifications;

– Enables a collaborative team approach to unanticipated setbacks rather than an adversarial approach as in most contract models.

• Consideration of the business case at these milestones (anchor points) is an essential rather than an optional add-in

• As Barry Boehm likes to say “The LCO milestone is the equivalent of getting engaged, the LCA of getting married. As in life, if you marry your architecture in haste, you and your stakeholders will repent at leisure. The third anchor point milestone, the initial operational capability (IOC) represents an even bigger commitment: It is the equivalent of having your first child.”

• So, on to the Initial Operational Capability:


Initial Operational Capability (IOC)

• Usable Solution Available to user community in prerelease form

• Here, we must have a working product that users are prepared to receive

• Look familiar? When does this occur?– Is application ready for deployment?– Has it been beta tested? Acceptance tested? Etc.????

• A number of pioneers has established such a framework – notably Jacobson, Booch, Rumbaugh, Krutchen, and Walker Royce.

• OK. Here we go:


The Unified Process as a Management Framework

Each phase in the software development life cycle (sequential) ends in the achievement of a major milestone for planning and control.

Business ModelingConfiguration and Control


The Need For Milestones (from book…)

• Phases provide way to focus on specific kinds of risk. • Each phase addresses critical risks that must be

mitigated.• Must have mitigated risk at end of each phase to move on.• Two types of milestones to be addressed in these phases:

– Business Milestones• Anchor the project with business commitments

– What does this mean to you? DISCUSS!

• The project must be synchronized, and in-line with the business

– Technical Milestones• Anchor the project against the overall system lifecycle

• Provide a framework for directing the iterations and their plans.


Phases and their Purpose

Phase Focus

Inception Confirm the scope and objectives of the project and bring the business risks under control

Risks addressed: business risks

Elaboration Stabilize the product plans and bring the architectural and technical risks under controlRisks addressed: architectural / technical risks

Construction Build the product and bring the logistical, project execution risks under controlRisks addressed: Logistical risks

Transition Deliver the product and bring the roll-out risks under control

Risks addressed: solution roll-out (delivery) risks.

The phases define a risk-driven lifecycleWe will discuss these risks in much more detail ahead.But, you should recognize the risks in focus for each of the phases!

Phases: an objective measure of the ‘state’ of the project.


Why do we have these Phases and Milestones?

• These periods are very important.• Can focus on the project as a whole and one might be able

to simply say that the project is now is x phase.• Milestone ‘gates’ serve many purposes:

– Provide concrete evidence of progress for the decision makers– Can monitor project at key points– We resynchronize stakeholder expectations, and decisions

made/not made to continue.

• Milestones in the UP used to measure state of the project as a whole!– Looking at risk reduction and on establishing key principles that

anticipate and accommodate systems evolution. – Stakeholder buy-in with each milestone is essential!

So, in summary, the UP milestones serve as: – Commitment points and progress checkpoints– System-wide events that synchronize the whole team, and– Measure of the state of the project.


Phases versus Iterations

• “Phases and process milestones [in the UP] are defined by the process and are common to all projects.

• “The number and size of the iterations and their specific objectives are at discretion of the project manager and development team.

• End of phase milestones represent ‘toll gates” that cannot be passed without achieving specific results.

• Phases are not time boxes in the same way iterations are. Iterations are concluded when the time runs out; Phases are only concluded when their objectives have

been met.”

• Phases consist of one or more iterations the completion of which is a minor milestone.

• Phases end with a go / no-go decision. Major Milestones.

iterative project management chapter 3 - controlling an iterative project modified considerably by...

Documents

iterative projects

iterative development

iterative approaches

management books

empowering management

senior management

time scope

ivar jacobson international