Even though it was a long time ago, I can still vividly remember passing my driving test and earning my licence. I can recall driving back to the test centre, parking up, and receiving the good news. I can still remember the examiner’s name, the fact that it was a sunny day, and I can even remember which parking bay I pulled into. It was a significant day for me– especially since I didn’t pass the first (or even second) time, and I’m embarrassed to admit that I had what seemed like hundreds of hours of tuition before I finally passed.
Although my memory of each individual driving lesson has faded, I can still vividly remember my driving instructor drumming into me the importance of checking your blind spot before making a manoeuvre. A quick glance out of the side window, followed by a glance over your shoulder helps avoid accidents. Every driver and every car has ‘blind spots’ and if you rely on looking in mirrors and the windscreen alone, you might end up ruining the paint job on your car, or worse….
This idea of ‘blind spots’ can be applied to other areas of life too. Incidentally, I’m told that fashion is one of my personal ‘blind spots’ – apparently the Hawaiian shirts that I wear on the weekend are so last millennium (who would have known?!) More importantly, these blind spots can cause real problems in projects and in purchasing decisions.
A common project ‘blind spot’: Full Function Focus
When working to implement projects that have a technology component, we may find that there is an implicit and almost laser-like focus on the functionality that the solution needs to deliver. People will talk about what they want to see, how they want to interact with the system, and the goals that they wish to achieve. This is understandable, and naturally, functionality needs to be a key and important discussion point. After all, the features and functions are almost certainly a key driver of the benefit to the business and the users.
Yet, if we over-focus on the functionality, we may find conversations about the non-functional aspects of the solution fall into the shadows. It is almost like they have descended into a blind spot. Extending on my earlier metaphor, we may need to check our mirrors, look over our shoulders, and ask questions relating to the:
- Level and type of security that are needed
- Sensitivity of the data that is being stored
- Performance and availability that is needed
- Error and exception handling
- Archiving and data storage concerns
- Backup and disaster recovery requirements
- Level of saleability/extensibility required
- And so on…
The list could go on and on. Asking these types of questions is a significant way that we can help ensure we deliver better business outcomes for our businesses, customers and stakeholders. As an example: While a stakeholder or customer might immediately gravitate towards a particular ‘cloud-based solution’ (and there may be many good reasons for this), it is important that we consider the business problem they are actually trying to solve, the type of application that they are considering alongside the full range of non-functional concerns. It’s crucial that we ensure the core requirements can be met, and that the solution will deliver the value that the business wants and expects.
These aren’t always easy conversations. If a CEO has decided that a particular software package is ‘flavour of the moment’, we might make ourselves unpopular—in the short term—by enquiring about these types of issues. Yet in the longer term, these difficult but essential conversations ensure that we deliver a solution that works, delivers value and meets regulations. These conversations require trust, rapport and the confidence to be open, honest and blunt. They also require us to think beyond the current engagement. It’s undoubtedly easier to nod and avoid these difficult conversations. Yet it is far better to have the open debate, iron out problems and build a sustained reputation for the delivery of value.
So, in summary: We ignore our blind spots at our peril. Open and honest debate and dialogue ensures a better outcome!
How do you avoid certain topics and discussions falling in a ‘blind spot’? Do you have any tips or tricks to share? I’d love to hear from you. Please feel free to add a comment below.
If you’ve enjoyed this article don’t forget to subscribe.
This post was brought to you by IBM for Midsize Business and opinions are my own. To read more on this topic, visit IBM’s Midsize Insider. Dedicated to providing businesses with expertise, solutions and tools that are specific to small and midsized companies, the Midsize Business program provides businesses with the materials and knowledge they need to become engines of a smarter planet.
i think that , using a sheet that have all the aspects (non-functional REQ.) that we may miss , in this way we should not ignore or Condones them , because i believe implementing perfect system must consider all the aspects that even may affect it .
Great post Adrian, very relevant. I think non-functional requirements are often overlooked and can have a large impact if not understood. A recent example that I had was a solution being built at a client where they are restricted in the use of their browsers. As you mentioned we go right into the functional requirements and look at what the solution should do. Luckily I looked at the browser issues and requested stats to find out what browsers were being used. Internet Explorer 7 and 8 made up 90% of the browser versions. From a technical perspective these two browser version battle supporting the newer design technologies like HTML5 which means that we needed to use a more suitable method. Some of the standard components that were normally used in this type of project were also not compatible. Had this not been identified upfront there might have been issues as the solution was developed offsite on a different environment. Going forward I make sure to look at compatibility as a non-functional requirement noting OS versions, Browser Support or any other requirements around compatibility.