The more time spent on words, the harder it gets to define. Yesterday I had a talk to a friend, about the problem in consultancy for measuring “success”. It gets complicated, are we talking about “a result comparison of the planned time and budget to the actual data” or “a comparison to what it should have achieved.”
If compared the actual time and cost to the planned one, sometimes not delivering a project has more benefits; it can be a good learning experience [not preferable one but since there is a phrase: success comes from experience and experience comes from failure]. Even cancellation can provide more advantage; a good risk analysis at the very beginning of the project can save many resources beforehand.
If compared to what it should have done something better, then the question “what were the alternatives and how could it have been achieved” raises. The expectation/understanding from success changes the further we go.
Then, confusion starts with “decision” word. “How would it be done in a better way”, “what were the expected results”? [I won’t continue now, but I am sure you get the idea]
Even if I start to make assumptions and select a path to reach a final understanding of a word success, it will be unique to my understanding/imagination/knowledge and experience. While you are reading, I am sure you have come up with lots of more questions for each confusion.
“Being aware of what you want” is challenging enough, and I won’t go further with asking “being sure about what you want.” Do you really want it? Have you done enough analysis? Are you confident enough? [Is confidence a good thing?] I don’t know.
As the scope gets bigger, the answer gets more unconclusive. I reckon, that’s where agile methodologies help us to have smaller, achieavable, forecastable projects. Being aware of the big picture, but relying on what you have in the smallest piece on your hands.