It has been conjectured that ...
What in the begining you thought you needed is never what you actually need
Fails to realize several critical success factors for project success...
- Without stating what capabilities we need from the project, we have no means to assess any value produced by the project are worth our investment. These capabilities aren't requirements - yet. They're the mechanisms to earn back the investment. Typical capabilities sound like...
- We need to process provider enrollment processes for $0.07 per transaction versus of current $0.12 per transaction.
-
I need the capability to move a brigade of 3,000 to 5,000 troops 100 miles up the coast in ten hours. — Gen Norman Schwarzkopf
Capabilities decipher the intent of the leader (Commander)
- Requirement always emerge. But capabilities should not, without rethinking why we're doing the project.
- If we're changing our needed capabilities, we don't likley know what Done looks like in any meaningful way and therefore are wasting out money exploring.
- Exploring in a research and development domain is mandated, but we should do that with the full knowledge and participation of the people paying for work.
- Agile is essential a process to buy knowledge about things we don't know about.
- Ask before spending our customer's money experimenting, can we gain this knowledge in other, cheaper
So if we're on a project that doesn't know what Done looks like, we've got to ask a serious question
Do we know what we're doing?
If the answer is No, we may want to rethink why we're here. Here's a process to answer that question.
And a framework to discover those answers
