Home

Manifesto

Values and Principles

About Us

The People

Whitepapers

Risk management

Contact

Links

Forums

Resources

Muse Cases

 

RiskToPatternTable

 


In the course of researching for this work, I came to the realization that what is a problem for one person or project is not a problem for others.  A solution to one problem can cause other problems.  Few if any of the solutions are appropriate for every case. 

 

Each of the risks listed in the table has a discussion section to indicate which approaches may be most appropriate.  The table gives quick links to patterns that may be appropriate, for use as an aide-memoir.

 

This is a work in progress – the first pass is nearly complete, but we expect continual additions and improvements – YOUR FEEDBACK is welcome. The update cycle is approximately fortnightly.

 

This work is heavily indebted to several particular sources, the Organisational Patterns to which many of the ‘solutions’ links lead, Capers Jones’ book "Assessment and Control of Software Risks", the C2 Wiki…


HowToUseIt     ContributorList         FeedBack       Home

 


 

 

Risk

Relevant Pattern

Description

ApproachesToRisk

 

Overview

ArchitecturalDegeneration

CodeOwnership OwnerPerDeliverable SystemMetaphor ConstantRefactoring

The initial Vision of the architecture degenerates toward chaos

BadFitToSchedule

CompletionHeadroom TakeNoSmallSlips WorkSplit PlanningGame

You have a schedule but find it is unreasonable

BarriersToProgress

PatronRole CustomerInterface

Something outside project control is holding up progress

BurnedOutWorkers

SizeTheSchedule DistributeWorkEvenly ThreeToSevenHelpersPerRole SustainablePace

The workers are not performing as well as they might if put under less pressure

ChangingPriority

WorkQueue IterativeDevelopment PlanningGame BackLog

A fixed schedule is not responsive to changed priorities

ChangingRequirements

IterativeDevelopment ModelTheDomain SessionFacade CustomerOnSite SimpleDesign YouAren'tGoingToNeedIt ConstantRefactoring

Requirements change

CodeBaseInstability

PrivateVersioning PrivateWorld NamedStableBases ContinuousIntegration

Workers waste time responding to errors and frequent changes in the work of others, or are unable to maintain a stable situation

CommonModeError

ApplicationDesignIsBoundedByTestDesign IntentStatement

Independence assures no common mode error, dependence allows it to happen

ComplacentWorkers

SizeTheSchedule DistributeWorkEvenly ThreeToSevenHelpersPerRole SustainablePace

The workers are not performing as well as they might if put under more pressure

ConflictingRequirements

OrganizationFollowsMarket ProductChampion JointApplicationDesign

Different people want different things, or the same person wants two things mutually incompatible

CostOfCommunication

DeployAlongTheGrain FewRoles DomainExpertiseInRoles GateKeeper WorkFlowsInward HolisticDiversity CouplingDecreasesLatency MoveResponsibilities ProducerRoles ResponsibilitiesEngage CustomerOnSite DevelopingInPairs GeneralizingSpecialist

Communication of Information costs more than necessary; see also DifficultyInCommunication, LackOfCommunication (this topic is split and considered as too much comms needed, and expensive means of comms used).

CostOfInnovation

SkunkWorks

Innovation is risky. It may cost more than it is worth.

CriticalPathProblems

InterruptsUnjamBlocking DontInterruptAnInterrupt SomeoneAlwaysMakesProgress

Work progresses but critical path work doesn't

DecisionsNotEasy

ProgrammingEpisode ArchitectureTeam

It is difficult to make decisions owing to e.g. the size of the problem etc.

DecisionsNotForthcoming

PatronRole InterruptsUnjamBlocking CustomerInterface CustomerOnSite

It is difficult to get decisions made

DifficultyInCommunication

ScenariosDefineProblem SubsystemBySkill HandlersToConnectSystems FaceToFaceBeforeWorkingRemotely GeneralizingSpecialist DevelopingInPairs CustomerOnSite

It will be difficult to represent information in a way that it means the same to the writer (speaker) and reader (listener); see also CostOfCommunication, LackOfCommunication

DysfunctionalTeam

SelfSelectingTeam DistributeWorkEvenly HolisticDiversity DiverseGroups MatronRole

The team doesn't work well together as a team (includes being too single minded)

FeatureCreep

 

The scope of a project keeps expanding as new features are added

GeographicalDistribution

OrganizationFollowsLocation LooseInterfaces FaceToFaceBeforeWorkingRemotely

The project is being performed on more than one site. This will also impact on CostOfCommunication.

GrowingPains

PhasingItIn ApprenticeShip DayCare

The need to grow the project is not handled in the best way

HighLevelOfCoupling

HandlersToConnectSystems LooseInterfaces DesignPattern

The amount of coupling between components etc. will be higher than necessary (NB chiefly design rather than process?)

HighRateOfChange

StandUpMeeting OpenWorkspace

The rate of change of information is too fast for the project to cope

ImpracticalVision

ArchitectAlsoImplements DevelopingInPairs

The Architectural Vision will be impractical

InaccurateRiskPerception

 

The perceived risks won't reflect the real risks

InappropriateArchitecture

ConwaysLaw ArchitectureTeam LockEmUpTogether YouArentGoingToNeedIt

The vision and / or architecture are not the best possible

InappropriateCrisisResponse

RecommitmentMeeting

Trouble happens. The response to it is not handled in the best way

InappropriateOrganisation

ConwaysLaw OrganizationFollowsLocation OrganizationFollowsMarket CouplingDecreasesLatency DeveloperControlsProcess DivideAndConquer ArchitectureTeam HolisticDiversity HubSpokeAndRim UpsideDownMatrixManagement ThreeToSevenHelpersPerRole ProducerRoles ResponsibilitiesEngage

The enterprise and / or team organization are not the best possible for the project

InappropriateRegimentation

InformalLaborPlan

Too much fine control can decrease efficiency compared to self-organization

InappropriateSpecialisation

DevelopmentEpisode DomainExpertiseInRoles BuildPrototypes GeneralizingSpecialist

The team members will have too much or too little specialization

InappropriateTasks

WorkFlowsInward GenericsAndSpecifics ArchitectControlsProduct DayCare HubSpokeAndRim MoveResponsibilities ProducerRoles ResponsibilitiesEngage

The distribution of work will not be as good as it could

IncompleteRequirements

JustDoIt BuildPrototypes EngageCustomers CustomerInterface EarlyAndRegularDelivery ImpliedRequirements UserStory CustomerOnSite

Not all requirements are known

InefficientSkillsTransfer

DayCare DevelopingInPairs DevelopmentEpisode

Transfer of skills costs too much or happens too slowly

InflexibleProcess

 

The process will not adapt to changing risks or opportunities

LackOfAccountability

OwnerPerDeliverable FunctionOwnerAndComponentOwner

Some aspects have many contributors, some none, don't know who is responsible for these

LackOfCommitment

 

 

LackOfCommunication

GateKeeper OrganizationFollowsLocation SelfSelectingTeam HallwayChatter FaceToFaceBeforeWorkingRemotely ShapingCirculationRealms ThreeToSevenHelpersPerRole

The project will suffer through shortage or lack of communication of information and ideas; see also CostOfCommunication, DifficultyInCommunication

LackOfConsensus

SmokeFilledRoom

Different folk have different ideas and will not compromise, so agreement cannot be reached

LackOfDirection

UnityOfPurpose LockEmUpTogether

Workers have no direction, or are pulling in different directions

LackOfExpertise

DomainExpertiseInRoles ApprenticeShip DevelopingInPairs HolisticDiversity DayCare DeCoupleStages LegendRole GenericsAndSpecifics SubsystemBySkill

The required expertise is not available

LackOfFlexibility

AskFiveTimesWhy ModelTheDomain ResponsibilitiesInTheRightPlace VariationBehindInterface ParserBuilder

The system is not flexible with respect to changes

LackOfProgress

DontInterruptAnInterrupt

Workers slack (see SlackResources) or thrashing

LackOfVision

ArchitectControlsProduct UnityOfPurpose

There will be no coherent vision

LateFeedback

BuildPrototypes EngageQualityAssurance IncrementalIntegration EarlyAndRegularDelivery

Feedback would have saved much more if it had arrived earlier

LocatingExpertise

FormFollowsFunction PublicCharacter ShapingCirculationRealms

The expertise is available but people don't know where (see also CostOfCommunication)

LossOfEssentialExpertise

ModerateTruckNumber LegendRole

Expertise concentrated in a single irreplaceable person is vulnerable to loss

LostFeedback

DeployAlongTheGrain RecipientAlsoReviews PeerReview

Feedback from later development is lost rather than fed back in

LostOpportunityForReUse

ModelTheDomain OrganizationFollowsMarket

Parts of the system could have been re-used, but the chance will be missed or unrecognized

LostOpportunityToAutomate

DeCoupleStages

Parts of the process could be automated and save effort, but the chance will be missed or unrecognized

LostWork

PrivateVersioning

Good work is lost, or needs to be thrown away with bad during rollback

PoorDocumentationSkills

MercenaryAnalyst

The folk with the skills to do the work aren't those with the skills to write it up

PoorEstimating

 

 

PoorMaintainability

SizeTheSchedule ArchitectControlsProduct

The product is not as easy to maintain as it should be

PoorPerformance

ArchitectAlsoImplements

The chosen architecture doesn't give the required performance

PoorQuality

SizeTheSchedule EngageQualityAssurance GroupValidation

The quality of the product is not as good as desired

ProcessDoesNotScaleUp

DivideAndConquer

The process works while the enterprise is small or only small projects are undertaken, but fails to cope with increase in scale

ProductiveDistractions

TeamPerTask SacrificeOnePerson SomeoneAlwaysMakesProgress StableRoles

The workers will be distracted from their work by issues that somebody must deal with or productivity will be affected

RippleEffect

VariationBehindInterface LooseInterfaces

Changes ripple out to affect everything

SlackResources

JustDoIt InterruptsUnjamBlocking EarlyAndRegularDelivery

Having people doing nothing productive

SlowDevelopment

CouplingDecreasesLatency FewRoles SizeTheOrganization InterruptsUnjamBlocking LooseInterfaces DontInterruptAnInterrupt DayCare

Time to completion is too great and needs to be reduced

SolutionRequirements

AskFiveTimesWhy

The requirements describe the solution not the problem

UnclearRequirements

 

 

UndefinedScope

ScenariosDefineProblem

The scope of a system is poorly defined or undefined

UnknownFitToSchedule

ComparableWork

You have a schedule but don't know whether it's reasonable

UnknownProcess

DevelopingInPairs EarlyAndRegularDelivery MicroCosm

The process to be used is unfamiliar

UnknownTechnology

BuildPrototypes MicroCosm

The technology to be used is unfamiliar and may have quirks or be unsuitable (consider technology we don’t know about at all – where do the new approaches come from to be considered?)

UnmotivatedWorkers

CompensateSuccess PatronRole FailedProjectWake

The workers are unmotivated or demoralized

UnproductiveDistractions

FireWalls GateKeeper MercenaryAnalyst

The workers will be distracted from their work by interruptions that do not pay back in better productivity (see also InappropriateCrisisResponse)

 

 

 

 

 

 

 

 

 

 

 

 

Copyright 2002, Appropriate Process Movement