They hook something to your car to make sure you pass the minimum requirements for not polluting the environment. It costs about $35-40 and I'm glad they require it because I hate seeing black smoke billow out of cars and into the air we all breathe. I think of it as an extra check to make sure that not only are we complying with the requirements of funding road maintenance, etc. with the annual registration fee, we are also ensuring that we are meeting or exceeding the regular performance requirements.
Tackling the performance issue
This one made me think in terms of the projects we manage. I have almost exclusively managed IT or technical type projects and implementations so performance would or could understandably be a requirement of the system or software being deployed each and every time. However, rarely has that been the case. There have been a couple of times where a certain performance measure was built into the requirements…such as “this process must be completed in a certain amount of time” or “these records must be searchable and retrievable within a certain acceptable timeframe.”
But on IT/technical projects, I think we should be examining things like this more closely. Because I know on several projects, my team and I have been called back in post-deployment to reconfigure the database or tweak the system to meet some processing criteria that the customer hadn’t previously considered or to speed up performance that was deemed unbearably slow after running massive ‘live’ data through the solution rather than the smaller test case files that were used during user acceptance testing (UAT).
That’s fine…and from a delivery organization standpoint it was actually a moneymaker because those instances of going back in after deployment and tweaking the system were either change orders to the completed project or they were mini-projects on their own. The negative part of all that is it left the customer with a bad taste in their mouth. They thought they were also getting performance even though that wasn’t spelled out. What they got was a workable, but slow solution that needed tuning in order to meet their ‘real’ performance standards and needs that they were already expecting with a ‘new’ solution. That’s unfortunate.
A proactive approach
The solution, of course, is to ask this as a question – several times if you have to – during the requirements definition phase. It is likely that there will be several instances in the system design and development were a performance feature or issue could come into play. Ask the customer:
- What are your current performance issues or needs based on the current business process?
- What do you want – within a reasonable range – the performance to be?
- What tradeoffs – if any – are you willing to make if that becomes necessary in order to meet your performance needs? (Meaning, what functionality can you do away with in order to speed up performance as per this requirement?).
Don’t be afraid to address these issues. And performance may not be a critical issue with the customer. But by bringing it to the forefront during requirements you’re going to show the customer you care, you will gain customer confidence and satisfaction, and you may save yourself and your team rework later on that you may have to perform to keep that customer happy as they realize that what you’re developing isn’t meeting their performance expectations.