Business Requirements: Delivering Unspoken Requirements

If you've read one of my previous posts about Fuzzy Logic, then you'll know that I was thinking about moving house earlier this year. Without boring you too much about my personal life, we're not going down that route anymore, instead we've been talking to architects and looking at doing a home extension. We live in a Victorian house full of original features (I sound like an estate agent !) and as a result we have a downstairs bathroom. One of our requirements is to achieve an upstairs bathroom. According to the beenster, an en-suite bathroom is one of the top 5 requirements requested by home buyers. Our architect, in trying to maximise re-sale value, is suggesting that we create a bathroom with two doors, one opening onto the landing and one opening into the master bedroom. This is called a Jack and Jill arrangement. Technically this means we'll have an en-suite, a tick in the box when selling a house.

Now I know the architect is trying to do us a favour, but I can't help but feel that whilst this technically meets the description of an en-suite, it doesn't meet the 'spirit' of an en-suite. (ie it's not an en-suite)

I can draw parallels with my job in IT. We often have critical success factors on projects that are hard to articulate. In my experience sometimes these can go unspoken, but everyone understands what they are. 'Look like this', 'behave like this', 'be better than that', 'delight me'. These are just a couple of examples in my head at the time of writing this. We often try to capture these and call them non-functional requirements. Sometimes we capture them well, other times less so and sometimes we don't capture them at all (I like to call this flexibility). Even when we capture them, we can fail to deliver on them, and when we don't, we can try and justify ourselves by claiming we've met the 'letter' of the requirement, when we know we haven't delivered in the 'spirit' of the requirement.

'If people don't use the system it's there own issue, it does everything they asked for....'

I've had a recent experience of this in a project where time was the most critical factor, ahead of cost and quality/scope. We had the ability to flex the scope in order to meet the date, but this soon got to the point where we knew we'd compromised the 'spirit' of the requirements, but we were trying to kid ourselves that we'd met the 'letter' of the requirements, so it was alright.

When I was a younger, less experienced project manager / business analyst, I would have carried on regardless, feeling like being unable to deliver the 'spirit' of the requirements was a personal failure and something to be covered up and ignored. Having been burnt several times by this approach ( I got away with it a couple of times too), I now know that raising these project issues early always leads to a better outcome in the long run. It can of course mean some short term pain from management and stakeholders as they realise they're expectations aren't going to be met fully, but the benefit of raising this early is two fold

• Stakeholders get a chance to be involved in a resolution plan, so you get good stakeholder involvement and buy-in to the resolution. (When issues are raised late, your usually very limited on the resolution.)
• Stakeholders expectations get managed gradually, so each incremental change is less painful than a big realisation at the end of a project

So with the issue over requirements raised, I'm probably in for a period of short term pain. I've learnt it's better this way though than to carry on regardless...