As we planned our relocation, we started to search for houses using a set of “features and functions” that closely matched our current house. They were all pretty typical specs: bedrooms, baths, square feet, lot size, schools, age of house, etc.
This approach was useful when narrowing neighborhoods, but they didn’t surface the house we ended up choosing here in Evansville. The house we chose fulfilled the capabilities we wanted from our new house, even though it didn’t exactly match the specs we used to benchmark houses.
For example, our new house’s lot is about half the size of our old lot. However, it does give us the “lot-driven” capabilities that we require — privacy (house faces into a small cul de sac and has nice mature trees around it) and a large, fenced yard space — even though it didn’t match some key yard requirements we thought we had.
For me, it was a useful reminder not to confuse the capabilities one expects from a project with product/solution specifications. In this case, what appeared to be a clear-cut, “must have” requirement of “lot must be over x square feet” would have been better expressed as “lot must be private and have a large, dog-friendly fenced area.”
More importantly, the square footage specification was just that, a specification, not the requirement or capability itself. Specs must serve the capability, not vice versa.
Filed under: Requirements Management, Scope Management | Tagged: capabilities, house hunting, relocation, requirements, specifications
Paul,
You’ve got the essesnce of Capabilities Based Planning and the Concept of Operations used in the defense business.
1st define the capabilities.
Then define the requirements needed to fulfill those capabilities
Hi Glen,
Good to see someone is still reading…
Yup, sometimes we forget that the thing we’re buying or building is supposed to accomplish something, not just look pretty on the RFP.
Good idea wrapped in a “easy to be sold” wrap.