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)