itmWEB Research

  
An itmWEB Classic Whitepaper
 
 
 

Creating New Systems: Perseverance, Pain, or Panic?


Focus Area: Project Management for Systems Development

Author: Russ Finney

Year: 1997



What drives innovation within a company? How are new systems born? One answer is that conditions either within, or external to the business change at a dramatic enough level to warrant action. This change may be in the form of new regulations or accounting methods, it may be in the form of a perceived competitive advantage from enhanced system technological capabilities, or it may be in the form of a perpetuation of disjointed (but related) business processes which now require a single unified approach.



Whatever the source, the driving force is change, and the change is demanding action. But does a systems project always spring up whenever these conditions exist? The answer more often than not is no. Those in the business who are the closest to the situation will usually react and cope with the new needs and requirements as long as they have a comfortable feeling of control. It is when a certain "comfort level" is exceeded that the business client may seek outside help. But at what point in this change cycle do the system builders actually get the call and become involved?



A better answer may be that a project is born when a system no longer exists which can handle perceived business requirements. This is a powerful motivator which very well could result in a decision to expend the capital and the resources necessary to create the desired technological solution. However, the realization that action must be taken, versus actually determining the proper course of that action, are two truly distinct and different matters.



The first decision is fairly easy, in fact it is one that seems be made on a daily basis. "This system is no longer meeting our needs", or "we have got to somehow automate this process" are words uttered in businesses every day! The second decision, choosing the appropriate solution, is the real show stopper. In a vast number of businesses, the process never gets beyond this point. "Just too many options exist", or the "technical know how is not available", or "the business know how can not be marshaled at this time" are all valid reasons for delay.



So what is it that actually causes a project team to be formed? Usually, it is either Perseverance, Pain, or Panic.



Perseverance


Someone within the business has an idea or a plan with merit which represents genuine improvement. It may be from an individual or a group, who may or may not possess the decision/implementation authority necessary to take independent action. But in any case, the individual or the group is able to develop a broad enough base of support to generate action on the idea.



Pain


The business situation is just far enough out of control that it is having a negative effect. People may be working long hours, the business may be losing customers, or the quality of required operational information may be inadequate. In any case, the risk of inaction begins to outweigh remaining within the current status quo and action is deemed necessary.



Panic


Finally, a business situation hits the critical state. Business volume can no longer be managed, a regulation is enacted which invalidates the current system, a new product or service is offered, or a key individual leaves the company. Whatever the circumstances, a solution is required, and time is of the essence!



One positive trend is the number of companies which are actually becoming more proactive in chartering new systems projects. A new project may be started as a result of the implementation of a existing long-range systems plan, or as a recommendation from a series of high level strategic information systems planning sessions. These resulting system building efforts tend to be much more grounded in the long-term direction and goals of the company than projects which are born as a hasty reaction to a business crisis or technological fad.



An organization which is attempting to be proactive in this regard should keep the following considerations in mind:



Focus on the mission-critical objectives of the company.


This keeps the attention centered squarely the business needs of the company rather than the software wish lists of the technicians.



Review the current application portfolio and classify each system based on it's current business performance as well as any anticipated future business impacts.


This helps to maximize the existing investment in the current corporate systems infrastructure.



Align business and technical strategic plans.


In today's technology intensive environment, one plan can no longer successfully exist without the other. Any technology expenditures should depend on business needs, and any business strategic changes should take into account the required technological support.



Insure that the individuals who are the true "strategic direction setters" are involved in the process.


A planning process based on the guess-work of those who report to the decision makers can result in the creation of dead-end projects, misguided efforts, and needless frustration for everyone.



Some companies are going even so far as the creation of enterprise level models to aid with long-term systems planning. These tend to be truly excellent planning resources since both critical needs and future needs can be readily identified. However, one caution about these efforts is appropriate in this context. The underlying purpose of the models should be kept in mind throughout their development: to provide a planning aid. It is very easy for the analysts to fall into the trap of spending years modeling the enterprise without actually developing any working systems. An additional concern is that as soon as the models are complete they are already beginning to become out of date. Once again, keeping the effort reasonable and focused is the key to providing the correct level of detail for identifying future system needs.