On big systems, systems which involve changing core engineering processes, catalyzing adjustments in the way dozens of people work, it is natural that some opportunities to provide advanced or more subtle assistance in the software tools used gets shaken out. A good software vendor has a controlled mechanism for handling these requests.
Whilst deploying enterprise-class systems, if you fail to plan for some buggy code raising a problem now and then, and don’t have a get-out response ready, then you are brave to be taking on such risk. When you deploy large scale, there will be a few bugs and there will be some enhancement requests too. So you should anticipate this and think about how you are going to deal with the requests to optimize or improve what you are deploying.
What’s an enhancement? It is an improvement made to a software suite or module or object or an augmentation of functionality. It may be latent to the user (for example - a new index on a data table to allow efficient access to records for some new processing), or apparent through the user interface (continuing the example - a different on-screen search filtering opportunity which takes advantage of the new index). Most of the ones requested by customers are the latter type. They can be experienced directly in the user interface.
So how can things work out better if you are a customer requesting a Capital enhancement and what happens to the requests you make:
- Qualify: You should think carefully about the necessity for a new feature. What is the impact if the out-of-the box way of working is unchanged? Are the consequences all that bad? What exactly is the cost of inactivity? These are often uncomfortable questions, and people don’t like to change, will resist. Ask the questions anyway, assertively. Otherwise you might be just wasting your time.
- Quantify: Practically all professional software producers weight the enhancement requests they receive. They factor in to their judgment at what stage of a customer’s deployment the enhancement is, whether using the application in preparation for production use, or actually in the steady-state of production deployment and roll-out, whilst getting the return for investment. Provide context.
- Gather information about, document & communicate how perceived deficiencies in the functionality can retard the time to productivity, backed up with solid evidence is the ideal way to communicate with your software producers.
- This toughens up your statement of desire - if x then y.
- Objective: The Mentor Graphics technical representatives you deal with should be left without doubt in their mind of the benefit to you to add a new feature you are advocating.
- Talk & write in numbers
- Why? It is easier to manage what you can measure. Or to put it another way, if Capital delivers a new feature to satisfy your request and you haven’t benchmarked something, then how are you going to know whether that new functionality hits the sweet spot?
- This toughens up your statement of desire - if x then y.
Not all enhancements requests can be accommodated. Is that clear? Good. That understanding is going to help. There is never enough time available.
There are other causes of inactivity apart from the big one - finite resources. Sometimes it turns out a customer’s request directly competes with other customers’ wishes. For example - relax user permissions requirements and tighten same. Some “nice to have” things would be nice to see in the software but never reach the criticality the priority so that they get to the top of the list. Possible candidates for releases do not necessarily ever get to probable. This is quite normal with any large system development and redevelopment. Each new Capital release however has lots of new things in it. It has not been unusual for me in the last 3 years to alert a customer that more than 50 functional changes are worth looking at in a new release to consider adopting in their electrical design process. But there are always things which never make it, things which drop out. That’s why I call your attention to the end node on the flow-chart illustration which says “never.” Think carefully what would be the consequence if the enhancement request never got addressed.
But don’t feel singled out unfairly. My pet projects are the ones which always get dropped - not yours.
So let’s just loop back to the first piece of advice if you have in mind a red hot improvement to Capital you have sponsored which hasn’t been adopted : “qualify”….. and hopefully you haven’t wasted time.
I’m going to depart from the main theme now for a very good reason. Application extensibility can do the trick just as nicely to deliver functionality. One alternative to consider instead of “never” follows now. It exists despite Capital being an “off-the-shelf” solution. The Capital software package has a comprehensive, reassuringly powerful Application Programming Interface (API) so customers can fashion their own functionality extensions. In many cases setting this API to work is the right way to extend core functionality. The package is backed up too by experienced Mentor Graphics Consulting folks who are skilled at exceeding customer expectations in paid engagements and can operate the API on your behalf, or play an enabling role for your own staff to unleash the customization power. And Capital has Web Services integration too by the way.
I was today revisiting some statistics over the past two years for Capital customer support activity worldwide and analyzing it:
A greater ratio of issues ending in requests for enhancements to Capital to defects indicates that the off-the-shelf software does not fit quite as well with the customer? You might think that is the “common sense” deduction - the significance of the pink line lying over the blue line in some of the charts pictured below. The evidence from pattern tracing in this data is actually not directly supportive of this thesis. The distribution of the requests between customers I know are broadly happy with Capital did not match this expectation. Happy customers log enhancement requests too. I particularly looked at large deployments and saw seasonality in how the enhancement requests occurred.
- Spikes of enhancement requests coincided with new releases of Capital being adopted - as well as when new phases of system roll-out were being proven - in prior to production release.
- The larger the process and software tool approval staff at a customer the greater the number of requests. This is an interesting one; because of course the software isn’t any different at a place with a smaller staff. It is not any better or any worse, there are just more pairs of eyes looking at it and making judgments about what they like and don’t like so much about what they are seeing.
- More quantity of improvement suggestions does not correlate with greater urgency of those suggestions or a larger proportion of the enhancement requests being classified as urgent by the customer
- Earlier in a deployment there are more requests for enhancements logged than later. Over the two years I studied, you can quite distinctly see that trend.
So here’s what I conclude. I’m reminded of the maxim that the Doctor who gives you a clean bill of health hasn’t examined you properly. Software design is not a pure scientific enterprise, it is infused with that intangible “design” stuff, and a consequence is that everything produced by software developers can be subjected to a critique which will shake out some improvements as well as flushing out some bugs.
In the meantime, if you want something to be placed in the Capital software as an enhancement, qualify then quantify what you want to see.