Add Up Your Software Project's IQ (Implementation Quotient)
Complete this test to determine if you're an idiot to continue, or should start declaring success now.
*This material is copyright protected by Expert Buying Systems Inc. and is reprinted with permission.
A ll application software projects involve risk. Even the simplest effort probably has only a 90% chance at total success-i.e., the project is on time, within budget, and attains all planned benefits. As projects increase in scope, the odds of achieving success diminish rapidly.
Implementation projects require companies to strike a balance between the desire to satisfy everyone's functionality requests and the need to keep things simple enough to ensure a success. If you implement a package with on procedural code changes, you are much more likely to succeed than if you make major software and structural operating adjustments.but at what cost? By doing this you may end up with a system that executes flawlessly, but doesn't support the business adequately.
Balance risk and results at a level comfortable for your company. The following information provides a quick, yet effective, vehicle for assessing the risks of failure, and can serve as a checklist of precautions that can be taken to reduce those risks.
Using the test
Although the approach taken is lighthearted, the impact of learning its lessons on your company can be very serious. All projects experience shortfalls. Many projects encounter serious problems and even projects with no major flaws can be brought down by a preponderance of little problems.
Throughout this test answer each statement to the best of your knowledge about your company. You must answer, so if you don't know the answer, guess! Your answers will reflect your biases, so it may do you well to get feedback from your peers. Of course, if you're at the top of the corporate food chain with no peers, your feelings and impressions are probably correct, and you should act accordingly.
This I.Q. test has been subjectively developed, will be subjectively completed, and may be subjectively reviewed. There are many points where your opinion is asked. It may differ from others within your company, but this test is a reading of your opinions, so proceed without fear. But, experts within your company first should review any and all recommendations. (With minor modifications this test and scorecard could be used to evaluate the risks of any large, complex, capital project.)
Implementing an enterprise wide integrated manufacturing or distribution system is much like growing a crop. If the field has not been well prepared, the crop either will fail, or its productivity will fall short of expectations. That's not good for the overall success of the venture. This test avoids many of the classical technical reasons for project failure, but instead deals primarily with the environment where the systems will be installed. No matter how strong or weak your project is from an internal, technical point of view, its fate may already have been decided by less obvious, but equally important environmental factors.
Does your corporate culture breed success?
A project is not executed in a vacuum, but once people get the idea that failure looms, it may feel like you're working in one. Projects actually are realized within the confines-both physical and psychological-of the company. The company culture can either increase the likelihood of success, or breed failure. The longer and more complex a project, the greater the impact the corporate culture will have on its chances for success.
The choice of project manager is an important one. The project manager must be a respected user, preferably with a high rank in the company. He or she must be willing to step on toes and capture the full attention of upper management.
A successful project is one that has used the corporate environment, both its weaknesses and strengths, to ensure success. When all involved feel that their success depends on the project's success, the likelihood of a timely, cost-effective implementation soars.
Possible points: -11 to 24
Rate your company environment by answering the following statements. Transfer all total scores to the scorecard at the end.
Managers cede predefined responsibilities to project manager (Yes 2; No -1) ____
Managers commit to approved goals (Yes 2, No -1) ____
When the going gets tough, all will pitch in to help (Yes 2, No 0) ____
Committees have complete authority within budget (Yes 2, No -1) ____
Committees will share responsibility for failure (Yes 2, No -1) ____
Project manager will control all program changes (Yes 2, No -1) ____
Committee can force acceptance by managers (Yes 2, No -1) ____
Management disagreements can be solved in less than a week (Yes 2, No -1) ____
Management/project team disagreement grievance policy can work (Yes 2, No -1) ____
If the project fails, heads will roll (Yes 2, No -1) ____
Project manager comes from Operations (2), Finance (0), MIS (-1) ____
Project manager trying to win popularity contest (Yes -1, No 0) ____
Project manager willing to be exiled by friends for successful implementation (Yes 2, No 0) ____
Too often, projects are begun based on management fiat. But when the going gets tough, these usually are the first projects to be shelved. If a project is justified financially, tough times only increase the pressure to implement. Financially justified projects are much less likely to be dropped due to changing market conditions or new management. These projects have a life of their own. Also, with financially justified projects, priorities based on relative contribution are established, ensuring that the most important decision-makers do in fact drive the project.
A sound justification is the first important step to implementation. While implementation may cause significant pain to your company, you should expect significant gain in the long run. Even companies currently in the throes of implementation can benefit from completing a justification based on what they've learned to date.
Possible points: -5 to 12
Rate your project's financial environment by answering Yes or No to the following:
Project is financially justified (Yes 2, No 0) ____
Project will be audited after the first year (Yes 2, No 0) ____
Project results are part of management business objective bonus calculation (Yes 5, No 3) ____
Management's definition of success based on personnel reduction (Yes -2, No 3) ____
Shakespeare is noted for coining the suggestion, 'First, let's kill all the lawyers.' Within many companies, MIS, with all its red tape and highfalutin jargon, is equivalent to the American Bar Association. But MIS need not be unapproachable. Successful projects recognize the proper place for the information technology experts, then properly circumscribes their involvement. In technical terms, MIS people do technical stuff; business managers do business stuff. Each is important to the success of the project, and each contributes most when they are doing what they know best. Remember that you are implementing a business system, not a computer system.
The scope and complexity of the project will impact its duration and possibilities of success. With every three months beyond a recommended maximum of nine months-the average attention span for most managers and workers--a project's likelihood of finishing on time and within budget is halved. If you think the project will take too long, find a way to do less.
The smaller the company, the greater the need for a stable, proven technology.these companies must stay off the 'bleeding' edge. Even for large companies, implementing too many leading-edge technologies can be disastrous!
Possible points: -9 to 12
Rate your project's MIS involvement by answering the following statements.
Operating systems, databases, and networks have been selected (Yes 1, No 0) ____
There is competent in-house technical expertise or support for all operating systems, databases, and networks (Yes 2, No -1) ____
Project will take ___ months to complete (score is nine minus your answer) ____
Likelihood of technical staff retention until project ends (High 1; Low 0) ____
Quality of current data (Good 2; Poor -1) ____
Data repair is a pre-implementation activity (Yes 1, No 0) ____
Software package can be customized easily to suit unique company needs (Yes 2, No -1) ____
MIS is the primary driver in making the final package selection (Yes -2, No 0) ____
Accurate data is the bedrock upon which any management system is built. It encourages confidence in the system from day one. Often, poor quality data is the result of an unresponsive system, and a new system will allow you to repair the low-quality data left over from the old system. However, you should schedule this data repair within the first three months of installation, otherwise the users will start to believe the new system is no better than the last.
Lessons learned: Quality assurance tasks for verifying and maintaining data accuracy suffer the 'Rodney Dangerfield Syndrome'-they get no respect! Such tasks are seen as boring, tedious work. They lack action and excitement of sampling newfound functionality in a software package. Auditing data quality is probably one step below mowing the lawn on the fun-o-meter. While it may not be a barrel of laughs, it certainly is essential.
A familiar adage states it's the little things that count. In the data quality area, it's the little things that will kill the project if not handled properly. Poor data quality is one of the leading causes of project failure, after all, most integrated systems are essentially planning simulators, and any simulation generated from a foundation of inaccurate data is usually as reliable as next week's weather forecast.
The parameters outlined above are not in any way all-inclusive. Low percentage completion of the master production schedule, however, is the single greatest bellwether of poor scheduling, excessive and inactive inventories, and poor customer performance. The master production schedule is the centerpiece of good or poor performance, and it should be tracked before and after the implementation.
Bill of materials is another area of concern. Mistakes in this key data produce shock waves felt throughout all manufacturing modules. If the bills are inaccurate and you are depending on the new systems' tools to help correct the data, make sure you apply the resources to repair the data during the first few weeks of installation. This can provide much-needed, early system credibility.
Possible points: -8 to 17
Rate your company's data quality by answering the following statements:
Reliability of current financial data (High 4, Low -2) ____
Reliability of customer service reporting/commitments (High 2, Low 0) ____
Bills of material accuracy (High 3, Low -1) ____
Reliability of inventory stock status (High 2, Low -1) ____
Percentage of master schedule built (greater than 90% 2, less than 90% 0) ____
Quantity of inactive and obsolete inventories (Low 1, High -1) ____
There is a plan for ongoing measurement of the accuracy of critical data (Yes 3, No -3) ____
It's true, vanilla software equals a successful implementation. But no system is a perfect fit, so decide how much change is acceptable. Almost all change carries some amount of risk-even tweaking already tested system option parameters can give wildly unpredictable results-so get the system that requires the least changes. Changes that never should be made include changing to a multi-currency system form a single currency system, changing to a multi-plant system from a single plant system, and adding lot control capabilities.
One way of measuring risk in software projects is to count the number of full-time equivalent programmers involved in logic changes (this does not include programming time dedicated to reporting and screen modifications). Generally, the number of newly introduced, unknown software bugs at the time of implementation can be calculated as a constant x times 2 raised to the power of the number of programmers: software bugs = x * 2#of programmers. These bugs are the result of communications, coordination, and testing complexities.
Many important computerized processes may need to be changed, especially in areas like order processing, which represents the face you present to the public. The percent of change is the cost of software development personnel (internal, consultant, and vendor) for changes to processes and logic (excluding reports) divided by the cost of the vanilla software.
Most packaged systems require changes, even to major logic, but in each case you must ask, 'Is this change necessary?' From a technical point of view, nothing will impact your likelihood of success, or failure more.
Possible points: -5 to 12
0 - 1 programmer (12)
2 programmers (5)
3 programmers (1)
4 or more programmers (-5)
Use the following equation as a guide to calculate your company's percent of change.
(Cost of changes $____/Cost of initial software $_____) x 100 = _____
1% - 10% (6)
11% - 25% (0)
26% - 50% (-1)
51% & up (-5)
Many companies view the implementation of new systems as a great opportunity to change the way they do business-i.e., to reengineer many of their basic operating assumptions, goals, and methods. Often, these goals are accomplished by means of software, so it is an irresistible urge to combine them. Resist this urge! The implementation of new software with the changes that must be made is complicated enough, so try to avoid more entanglements and complication factors.
Changes should be categorized as either required or discretionary. Required changes are those that must be made to the software package and your operating procedures in order to operate your business properly. Discretionary changes are those intended to significantly improve, rather than simply sustain, current business processes. Calculate, per the formula below, the cost of change including all per-hour people costs required to plan, build, test, and implement the changes. It is divided by the cost of the initial software to calculate a relative degree of change.
Lessons learned: The greater the change, the greater the risk. Everyone knows this is true, but too many are unwilling to say 'no' until failure is staring them in the face, and then it's too late. The pressure to change will increase strongly as the project nears completion. Your strong project manager must fight these 'opportunities'!
Order processing and sales are the company's medium to communicate with its most important resource-the customers. Most companies will not let the software restrict this medium. These functions generally are the most modified during implementation, even where manufacturing and finance are good fits right out of the box.
Possible points: -10 to 24
Use the following equations to calculate your company's required and discretionary changes.
Cost of required change $____/Cost of initial software $______ = ______
Less than 25% (12)
Greater than 25% (0)
Greater than 50% (-3)
Cost of discretionary change $_____/Cost of initial software $______ = _______
Less than 10% (12)
Greater than 10% (-2)
Greater than 25% (-7)
If your doing an ISO 9000 project hand-in-hand with the implementation project, subtract 5 points.
There are many motives that drive the use of outside resources, some commendable, others deserving of laughable contempt. It is right to use these resources to gain expertise to segment the skill sets of your staff, to provide for talents that will not be required after the implementation, or to better let your people install the new systems and procedures. Sometimes it's best to let outsiders carry on the current work until that method of work is gone. But consultants are never responsible. It is never their fault if you fail. Consultants are tools for your use, not scapegoats. Don't let them use you, either.
Possible points: -107 to 8
Rate your companies outside support procedures by answering the following statements.
Consultants have management responsibilities (Yes -3, No 0) ____
Consultants are being used to perform new activities (Yes -1, No 3) ____
Implementation consultants have experience in your specific industry (Yes 2, No -1) ____
Consultants will base a significant portion of compensation on verifiable results (Yes 3, No 0) ____
Consultants outnumber the full-time employees assigned to the project (Yes -3, No 0) ____
The project manager is a consultant (Yes -99, No 0) ____
Have you done a complete specification and needs analysis for your new software? The specification is the document by which you gain commitment from your users. If you don't make them say what they want, the requirements will change throughout the implementation, and the project team will be jumping ever-higher hurdles.
Possible points: -10 to 24
Rate your project's needs analysis by answering the following statements:
Detailed functional specification by users before selection (Yes 12, No -5) ____
Detailed functional specification by users before implementation (Yes 12, No -5) ____
Planned implementation cost
The cost of implementation can dramatically increase overall risk, even for larger companies who think they can manage around escalating start-up costs. In reality, big, slow-moving companies are least likely to accomplish implementation without an additional bureaucratic management cost. Implementation costs include most incremental project's costs such as personnel, systems, modifications, and training.
Possible points: -5 to 12
Use the following equation to rank your company's project implementation cost:
([Implementation cost $_____/Initial software cost] * -2) +14 ____
Software vendor attributes
When all else fails and you can find no one else to blame, companies will target the vendor. Management should close this door early with the reprimand, 'You can beat on the vendor all you want, but it'll be nobody's fault but your own if you fail.' The vendor's job is to provide working code and functionality. But even when the functionality doesn't exist or the code doesn't work; this is more often a sign of poor due diligence by the software selector. Blaming the vendor is merely a pass-the-buck convenience that ends up harming the implementation process.
Possible points: -7 to 6
Rate your company's software vendor relations by answering the following statements:
Your last software implementation was a failure (Yes -1, No 0) ____
Your vendor was the culprit (Yes -2, No 0) ____
The vendor could be blamed again (Yes -2, No 0) ____
There is an organized active user's group for the package (Yes 2, No 0) ____
Your software vendor verbally promised to meet several critical needs with 'futureware' (Yes -2, No 0) ____
Your software vendor contractually committed to meet several critical needs with 'futureware' (Yes 2, No 0) ____
The key point to remember it's your project! The possibilities for success or failure are under your company's control. The selection of project personnel, the development of an attainable project plan, and gaining the commitment of users are keys to your success. That's what being a leader is all about.
Lessons learned: Successful projects have many parents, unsuccessful projects are orphans. This doesn't need to happen. Everyone must know that if the system fails, they all fail. There must be consequences to failure (e.g., no bonuses); otherwise, no one will take responsibility.
Users who are unwilling to assign the necessary resources, or even allow assigned resources adequate time for their project responsibilities, must be strongly dealt with early on in the project.
Make the project dates concrete! Prepare caps and t-shirts with the planned implementation date. This will let everyone know the project is at the point of no return. It also serves as a reminder that no one can bail out from the project at the end.
Possible points: -20 to 24
Rate your company's commitment to the project by answering the following statements:
Project manager is a user of the system (Yes 10, No -5) ____
Project manager was hired from outside for this project (Yes -5, No 5) ____
Management is thoroughly briefed on the results to be expected (Yes 0, They're clueless -5) ____
Management believes two half-time team members are equal to one full-time member (Yes -5, No 0) ____
Project manager commands upper management's respect (Yes 5, No 0) ____
Full-time resources applied (Subtract full-time MIS from full-time users, and multiply by 5) ____
Projects require realistic implementation dates. Once you miss the implementation date, all bets are off. With each day that passes after the schedule change, commitment, interest, intensity, and attention drop rapidly. Your end date, its immobility, its sacredness, its inviolability is one of the most important levers for success.
Lessons learned: Remember, the new system, at least through implementation, is the company's 'baby.' Users have to be prepared for the ups and downs of its adjustment period. Even with the best implementations, some things will be broken and the amount of work required to fix them may be monumental. Your old system may, in retrospect, seem to have been very comfortable and safe. It is at times like this that you will have to keep a stiff upper lip.
Companies that expect the pain of implementation are happy when the ordeal is finished. Companies that are unprepared for the shock are angry by the time implementation is complete. Although either attitude can nevertheless accompany success, the positive feelings that stem from sacrifice and success are denied to the project team of the unprepared company.
Possible points: -15 to 28
Rate the feasibility of your company's plan by answering the following statements:
Implementation date is believable (Yes 4, No -2) ____
Implementation date is concrete (Yes 6, No -2) ____
All user's feel they're getting 100% of what they want (Yes -3, No 0) ___
Plan includes a conference room pilot (Yes 2, No -2) ____
There is adequate scope in the schedule to handle information contingencies (Yes 3, No -2) ____
Data conversion will happen multiple times before implementation (Yes 3, No -2) ____
On-system usage of 16 hours set aside for each employee prior to implementation (Yes 5, No -2) ____
Your project IQ
Transfer your scores from the individual sections to tabulate a total score. Then match the total with the numbers in the box below to determine your company's outlook on new system implementation.
Know your outlook, determine the risk
Fill in the space below based on your total score:
I am ________________ to ____________________ this project.
ready; fire everyone on
an idiot; continue
really concerned and have; re-evaluate
willing to accept the risks; continue
doing the right thing; complete
very confident; complete
declaring success now; take early credit for
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.