CAD Manager's Newsletter #82 (Apr. 3, 2003)3 Apr, 2003 By: Robert Green
In the last issue of the CAD Manager's Newsletter, I began the discussion of preparing for software upgrades by advising you to consider the needs, problems, budget restrictions, and personnel issues that make your company unique in order to compile some inventory lists.
In this issue, I'll pass along some hints and strategies to help you plan for the actual upgrade based on budgeting and staff parameters. I've developed these recommendations over years of work with my private clients. Please consider these as general recommendations and understand that they may not all apply to your specific situation.
Distill All Costs and Benefits
In the last issue, I encouraged you to list the needs, gripe items, and desired software features that might compel you to upgrade. You should now have a solid idea of whether or not a new software upgrade contains enough substance to persuade you to upgrade. For the purposes of our discussion in this issue, I'll assume that you've already made the decision to pursue upgrading.
Your task will now be to determine whether the software upgrade will provide enough time savings to pay for itself over a reasonable period by performing return on investment (ROI) calculations. For a quick overview of ROI computations please see issues 68, 69, and 70 of the CAD Manager's Newsletter as outlined in the Relevant Links section at the end of this newsletter.
You must present your ROI findings to your senior managers and obtain their approval before proceeding with your upgrade plans. Even if your management isn't necessarily asking for an ROI computation from you, I recommend that you undertake the task anyway, for the following reasons:
- By doing your ROI homework you will protect yourself from future questions such as "Was this upgrade worth it?" or "Why did we spend money on this new upgrade?" You'll have your ROI calculations and management approval to show why the upgrade was undertaken.
- ROI computations show you are serious about using the company's money wisely. After all, if a software upgrade can't produce a decent rate of return, maybe it isn't the best use of the company's money, right?
Should your management scuttle a software upgrade due to a low ROI value, do not take it personally. Understand that in a tight economy companies will not simply upgrade because there are neat new features, or even because you can save marginal amounts of user time. There must be a compelling financial incentive in order to upgrade.
Analyze Budget, Assess Skills, and Adjust Accordingly
If you have analyzed your software upgrade and found it to be technically and financially sound, you will now have to face the budgeting and staff assessment impact of the upgrade. In the last issue, I advised you to examine what you could realistically budget for any upgrade process and whether your staff could handle it. For our discussion, I'll assume that you were able to obtain a reasonably high budget from your upper management.
I'll now illustrate how to "analyze and adjust" by listing some budgeting/staffing case examples, and how I would make adjustments in those circumstances. I've tried to design these case studies so that an "upgrade rule" will be illustrated in each case. As you read through these cases, try to apply them to your specific staffing and budgeting guidelines.
Case 1: You want to upgrade your department of 20 proficient users from AutoCAD 2000i to AutoCAD 2004. You estimate that software costs alone for your upgrade will be $20,000 (round numbers based on current retail pricing) but your management doesn't want total expenditures for upgrading to go above $25,000.
Problem: The software consumes so much of your budget that you'll barely be able to afford any training, services, or down time.
Adjustments: There are no easy answers in this case. You either need a higher budget for the upgrade, or you must postpone the implementation. I would not proceed with an upgrade under these circumstances unless you simply want to purchase the software and put it on the shelf until you can afford to implement it. I've seen too many companies try to upgrade their software without adequate training and support budgets, and they've all floundered miserably.
Upgrade Rule 1: Upgrading a software platform (in this case, from one AutoCAD version to another) typically requires a 2.5 to 1 expense ratio where the software cost is the basis. So for a 20-user upgrade that will cost $20,000 in software, I'd forecast a total upgrade cost of $50,000 in round numbers. You may think these costs sound high but I've found it to be remarkably accurate over the years. My 2.5 to 1 rule takes into account installation, configuration and debugging, training, loss of productivity, and all the little miscellaneous costs that go with a conventional upgrade.
Case 2: You want to convert your AutoCAD R14 2D-driven department of 10 mechanical designers and engineers to SolidWorks, thus changing your work methodology to 3D design. Your users are smart and ready for the upgrade, but are way behind the learning curve because they're using old software. Your management understands all these factors and is prepared to spend $200,000 for this effort but, due to tight project deadlines, they are not willing to miss any deadline due to productivity loss in the process.
Problem: At first glance the math looks good here because software can be purchased for roughly $60,000 and that leaves plenty of money for training and services to get 10 seats installed, right? Further, your staff is sharp and is chomping at the bits to move to a more advanced software platform, so you don't anticipate learning problems. The alert in this case is management expects that spending a lot of money will mean no down time! Anyone who's ever tried to switch a department from 2D to 3D can tell you that the process does not happen quickly or without problems--no matter how smart the users are or how well-funded the effort is.
Adjustments: You'll need to adjust your management's expectations because such a huge shift in design methodology simply can't happen without severe disruption of work routines. Possible adjustments may be to introduce the new software to a few users at a time to spread out the learning curve or to employ part time staffing to make up for lost productivity as the migration is undertaken. Either way, you need to put management on notice that you can't switch software platforms so radically without a reasonable period of time for learning and ramp up.
Upgrade Rule 2: Even seemingly well-funded upgrades can go terribly wrong if management expectations regarding timing are unrealistic. I would rather perform an upgrade on a tight budget within reasonable timing than be committed to a well-financed project with an unrealistically tight time frame.
A Few General Conclusions
The two sample cases above use the key variables of time and money to illustrate that some upgrade scenarios are simply unrealistic. In both cases the key responsibilities for the CAD manager are
- knowing what your staff can and can't handle in a given time frame;
- knowing what budget limitations you must work under;
- adjusting any unrealistic expectations--regarding budget or time--and reacting to them;
- being willing to stop the upgrade if the time/budget required for success simply aren't present.
Please note that these key responsibilities are much more managerial than technical and require good communication with senior management. So before you get ready to embark on an upgrade on purely technical grounds, be sure to do your management homework to ensure your eventual success.
I hope these case studies give you a real-world perspective on how to adjust your upgrade strategy based on your company's unique parameters. If you'd like to share your experiences, or if you have a specific question you'd like addressed, please email me at email@example.com with your comments.
In the next issue of the CAD Manager's Newsletter I'll provide some hints for completing the upgrade process once you pull the upgrade switch and provide some reader feedback.