Every project team asks themselves, implicitly or explicitly, what are our criteria for success? Depending on the range of the stakeholders involved you’ll get answers from the superficial (e.g. “users of all skill level can use software”) to the goal oriented (e.g. “identify the safest and most viable customers who need car insurance”). It’s easy to talk about success – especially non-quantifiable success.
The Firebrand Architect philosophy encourages you take a step further and pose a question: “What are our criteria for failure?” In other words – when we look back a year from now how would we know for sure we have failed to achieve our objective? Depending on your relationship with the group of the stakeholders you may have to be diplomatic as to how you pose the question.
Let’s work through an example. A project aims at providing insight into the inventory stored in many warehouses. The goal is to keep the inventory as low as possible while providing quick response to product demand. This project has a budget of $2,000,000 and will require a purchase of expensive COTS software ($500,000). A team of stakeholders will let the technical team decide which of the vendors to select, but know that a mature COTS software package has solved a similar problem in other organizations.
A year goes by, hardware has been purchased, COTS software installed and linked to a data warehouse, insight for a few categories of inventory can be obtained. Is this project a success or a failure?
One may say that since the software has been installed and connected to a data source in the production environment it’s a success. If that’s the only claim to fame, then this project is a failure. It doesn’t produce the insight that a business needs.
Using the same example as above, if a project produces some level of insight, but not all what was envisioned was it a failure or success? This is a harder question. If the paradigm and the model of operation through which the limited insight has been developed can be naturally expanded to gain insight in all envisioned categories, then the project is a success despite not delivering everything what was planned. If the paradigm doesn’t scale to cover additional level of insight, then the project is a failure.
Knowing the definition of success is important. Knowing the definition of failure is paramount.
I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...
Great blog post by Agile Journeyman about Martin Fowler's Design Stamina Hypothesis & the Technical Debt Quadrant. Constantin K...
Agile processes give you an ability to do something faster. Often agile approaches give you an ability to deliver smaller chunks of software...
From the SEI podcast series: "We know from existing SEI work on attribute-driven design, Quality Attribute Workshops, and the Ar...