Success and failure: are they really two separate paths?
Most of us have heard the rumor that failure is being redefined. Failure might not be bad. It’s even possible, maybe probable, that failure might teach us valuable lessons. If we learn those lessons quickly, failure might translate to success.
Seems logical, right? It’s natural law–survival of the fittest–evolve or die. But what does this cycle of try-fail-adapt-succeed mean for you and your project team?
Is your organization traditional or a bleeding-edge innovative company? Is your BA background in innovative or traditional environments? What is your definition of success as a BA? What’s your organization’s definition of success?
Many traditional organizations measure “rework” (aka – requirements defects) as an indicator of project success or failure:
little rework = lots of success
lots of rework = failure
But here’s a question to ponder…Do those formulas inspire innovation? Are you in an innovative organization, but letting rework and defects label your projects “FAILURE”? Or does rework help you learn and innovate faster?
In many innovative environments, we don’t know what our customers want so we put something out there to get feedback. In this case, rework and defects are a good thing. They provide meaningful information which helps the solution or product evolve.
Take a minute to think about your environment:
- Is perfection expected?
- How are you measuring rework?
- Is failure an opportunity to learn and evolve the product or solution?
- How are your leaders looking at it?
- What is your goal? Do you want to launch a product or solution quickly to see how the users respond? Requirements generated for that purpose would look very different from requirements generated for something well-understood or strategically planned.
- Based on the project goal, what do “good enough” requirements look like?
In an innovative environment, rework will be the norm, not the exception:
- You can’t do a successful market analysis when you are designing products consumers don’t even know they need. Meaningful feedback and rework are necessary.
- You can’t create a clear business case when you are operating on the hunches and assumptions of invention.
- Gaps in requirements will be commonplace when your SMEs are your consumers and you are learning together in a complex world.
- Prototypes go directly to the marketplace to get user feedback. Without meaningful feedback the prototype fails.
Think about your role. Your goal is to add value to the business. Sometimes that means rework and failure. Those lessons help you understand your customers. Then you adapt and refine your solution and try again. This cycle becomes visible when working on complex efforts, innovative efforts and efforts where you don’t know what you don’t know. Are you ready to embrace innovation?
What do you think?
Do you celebrate failure? Does success make you lazy? How would redefining success and failure impact your project team? Mention @WickAng on Twitter with your thoughts.
“Success is going from failure to failure with great enthusiasm.”– Mark Twain