When building any large system (i.e. > £100k) then spend a couple of hours mapping it, split it into small components and use appropriate methods ... 
... do NOT try and use a single method across all the components (whether agile or six sigma)
... do NOT try and use large contracts or LOTs that span multiple boundaries (i.e. mix in genesis with commodity)
... most importantly, spend a few hours producing the map, have a pre-mortem (i.e. a challenge on the map before you build it) and a post mortem using the map after.
That way, you will learn.
That way, you will learn.
From experience, a vast number of major project failures and cost overruns can be determined before anyone has even started building the project by simply looking at the map and contract structure. Many projects are doomed before they have even started ...
and from experience, the one statement that signals a company that has institutionalised failure is ... the statement after a project failure that "next time we need to specify it better" aka the desire to specify the unknown rather than build capabilities to cope with it.
Sorry to sound like a stuck record, gosh I've been doing this for 15 years now .... but I'm always amazed at how people mess up projects in contract structure i.e. the project is doomed to failure and cost overrun before it has even started.
Despite mapping a project and showing why it will fail, you wouldn't believe how many people go on and do it anyway ... and fail / have cost overruns at exactly the point they were told.
The problem is when "I" map which is why I don't map for others, I get them to map ...
The problem is when "I" map which is why I don't map for others, I get them to map ...
... if someone is sold into a story (and all the politics that comes with it) then a map can help them out of troublesome spot but it requires them to create the map, to challenge their own story.
