Recently I was reading an article on CIO.com (where I also contribute).  The basic premise of the author was that IT is already integrated with business and all of the hype about business to IT alignment is overblown.  This is not entirely true.  As I commented:

Software modifications must be discouraged but sometimes they make perfect business sense. Remember, software exists to support the business, not the other way around.

As an inexperienced project leader back in the 1980’s, I once informed an executive at a large aerospace manufacturer we were going vanilla with our enterprise software implementation. Absolutely NO software modifications or enhancements allowed I proclaimed! His response stayed with me and still rings true today…

“Steve, you mean to tell me we are going to allow a one million dollar software package dictate how we run a fifteen billion dollar business?” I was lost for words. Finally I said, “if we modify the software, future upgrades could be more difficult to implement”. His response “so what, I need to run my business”.  The lesson is…..you need what you need. Software is intended to support the business, not the other way around.

Make no mistake; if you can really go vanilla do it. I am not encouraging software modifications because they take time and cost money. However, regardless of what the sales people tell you, no software package is infinitely flexible and configurable. At the same time, we all know software must address the key business requirements. This “zero tolerance for modifications” philosophy is fine for those that do not have to live with the software limitations. So what is a project manager to do?

In many cases, software modifications are not a huge deal when properly controlled and managed.  After all, no one writes a single line of custom code until at least the project manager and the executive sponsor say so. In other words, proposed modifications should be well defined, business justified (vs. alternatives) and then approved by senior management (with a full understanding of project impact).  When executives approve a mod in this manner, they have made a conscious decision to expand scope, incur additional cost and extent the project schedule. There is nothing wrong with this since they did it for good business reasons.

The religion that software modifications are universally evil comes mainly from the software industry. In fact software vendors can make you feel like a criminal when you sheepishly tell them you modified the software (dumb old me). The reason is vendors want clients to upgrade their software and do not want mods or anything else to get in the way. The idea is to sell the client related software and plenty of consulting services with each upgrade.

While software modifications increase the difficulty of software upgrades, in many cases this issue is over-blown. This is particularly true when keeping the number and complexity of mods under control. First, whether we like it or not, many organizations never upgrade their software. Others may do it only once over the entire life of the system. Also, there are upgrade tools available today that make the process of retrofitting custom code much easier. Finally, do not assume the promise of future software functionality will replace the need for mods. Even if the functionality is delivered, do not be surprised if mods are required to make it work for your organization. Software vendors use buzzwords to describe functionality but when you take a hard look; many times the functionality doesn’t go far enough.

I will not discount the fact that some software vendors refuse to address customer issues associated with modified programs, and for good reasons. However, most vendors will assist when the issue is critical and push comes to shove. Also, keep in mind that some vendors will fully support custom modifications as part of their business strategy. Furthermore, the risk of compromising support from the vendor becomes less of an issue when enhancements are designed to minimize the impact on existing code and tables. Finally, no custom code should go into production unless it is thoroughly tested and then tested again (and maybe again).

Always schedule and budget with the understanding that some mods could occur. Do not have a line item called “software modifications” (this is politically incorrect and sends the wrong message-again no one is encouraging mods). Bake it into miscellaneous, contingency, or related project line items.

~~~~~~~~~~~~~~~~

Editor’s Note: 

Steve Phillips runs another blog at the IT Toolbox and offers some really great insight on doing technology projects.  Visit his site for more info.

http://it.toolbox.com/blogs/street-smart-erp

As I’ve written before not every metric for business or processes is a KPI.  Too many IT systems and too many companies define a departmental goal as a Key Performance Indicator creating unnecessary friction between other departments or areas of the company.

By using a weighted index you significantly reduce, and in some cases eliminate the competing requirements.

As part of a continuing effort on using key performance indicators for building a strategy focused organization I’m offering this illustration.

Fictitious Company ABC Inc. Indexed KPI Example

Let’s take a simple but very common example of how Key Performance Indicators are misused in business.  Using some very generic and very simple numbers to illustrate the problems with all of these “goals” being called Key Performance Indicators we will look at widget company ABC Inc. 

ABC Inc. has what they call a “KPI” metric for Production throughput of 100 units.  The production manager is given a goal to boost that metric to 110 units for a 10% increase in productivity.  This is what is measured and this is how the department is provided bonus incentives.

ABC Inc. has current on hand inventory of $1,000.00 and they likewise want to reduce inventory carrying costs by 10% or to $900.00.  Again, reducing on hand inventory is what the inventory management department is measured on and provided incentives for.

Right away there is an immediate conflict between production and inventory management.  If either of those areas gets out of synch it can create a bit of a mess.  Now, let’s look further. 

ABC Inc. has a delivery department that is provided incentives to ship orders complete, 100% correct first time.  Now there is a conflict between shipping and production as well. 

Because production is narrowly provided incentives for throughput they will naturally try to optimize their scheduling to ensure greatest throughput, not necessarily the best process for fulfilling customer orders.  Production scheduling and customer service and inventory management and shipping are now in conflict because their “KPI” measures are at cross purposes–, they have competing goals.  Because inventory management has stock levels driven down there is insufficient stock to ship full trucks and therefore you incur additional freight and shipping charges. 

This type of example is COMMON throughout business all over the world.  It is routine in business to have these competing goals, where incentives are provided, which many companies (and even software vendors, consultants, etc.) call key performance indicators.

That illustration could be continued to any number of process areas of any business in the country.  The idea is that if everything is a KPI then you create unnecessary competing demands and in some cases “mutually exclusive requirements” that can not be fulfilled. 

Many times one department will meets it goals and another department which is a dependent area in the same process chain will not, then you have a mess.  For example if production meets throughput requirements but inventory management is unable to reduce on hand stock you could end up in an inventory buildup problem.  Production capacity is increased while stock reduction is not improved.  Production may increase capacity by producing the “easier” products that do not line up well with customer orders and then shipping gets backed up.  Or shipping / customer service and inventory management may drive production requirements and then reduce production throughput meaning that while the orders that get shipped are at 100% complete, far fewer orders are shipping and revenue is dropping.

A KPI Index is the Answer to the Metrics and Goals Many Call Key Performance Indicators

As you can see from these examples a weighted index of each of these measures combined into a single KPI is more meaningful.  If bonuses or incentives are paid on the overall increase in the indexed KPI rather than the discrete departmental goals (other than possible merit awards) you are more likely to create inter-departmental cooperation.

Let’s say as a business you have a low backlog but high inventory carrying costs.  You may wish to weight each of the departmental goals accordingly.  This way you are still moving toward improvements in each area but are focusing attention on the areas that matter.  In this example you may wish to weight your on hand stock and 100% order fill rate higher than your production throughput.  By doing this you are providing the correct index for the overall business needs. 

By using the index and tying pay for performance programs to the index rather than a discrete departmental measure you cause the company to pull together in the same direction.  Instead of having disjointed goals which sometimes conflict with other departments each area would automatically pull together to push the overall KPI higher.  If full truck deliveries are weighted higher than inventory reduction and production throughput then all areas would focus on that issue together.  However since they are also measured together, and since their measurement also contributes to the overall KPI score then these departments would try to find ways to achieve their own goals with an eye toward the higher scoring area(s).  This would encourage more teamwork and innovative process thinking rather than the silo focus that departmental goals create.  In other words creating the indexed KPI also creates cooperative dependencies between departments.

By using indexes and weighting them according to the importance to the business you are directing your company’s energy where it is the most meaningful.  Together with this you may wish to craft and communicate a policy that the weighting for each area will be revisited and may change either quarterly or annually depending on business needs and circumstances. 

It is important to keep in mind that if your KPI(s) are used for any type of pay for performance program that you communicate reasonable expectations of weighting changes.  Without that clear communication and expectation setting in the beginning you will quickly lose your employees’ trust and undermine your KPI initiative.