FRAMINGHAM (08/01/2000) - Have you ever looked in a medical journal or encyclopedia and begun to wonder how many of the various ailments you might have? I believe that IT managers can suffer from the same type of hypochondria when it comes to improving the processes in their organizations.
As we read through the latest IT magazines, websites and white papers, we begin to look to the latest acronyms for answers to our problems: ERP, CRM, KM. The list goes on. When I see deficiencies in my current infrastructure, I am tempted to believe I am suffering from problems I can resolve by implementing some new technique, management fad or killer app. But I know that's not true.
So when I start to feel that way, I take a look at a different kind of B2B. I go back to basics, and I evaluate my circumstances based on four premises:
First: Constantly reevaluate existing resources. With deadlines always looming, it's easy to forget about the 10 computers we purchased to complete the last project, the new training Team B received and the existing skill sets of our present staff. Keeping track of this information may be the last thing you remember to do when finishing a project, but it has saved me many hours of consulting fees and has helped keep projects within time and budgetary constraints. I create a simple inventory of my equipment, software licenses and so on, in a spreadsheet for use in budgeting for improvements and reengineering needs. Then I take a step back and reexamine all my current staff. I prepare a list of all their talents, skill sets and areas of expertise and keep it in a handy place for constant review and maintenance. Compiling this information gives me the ability to determine who can assist in intradepartmental projects and who can fill a gap when needs and resources are at issue.
Second: Think big, build smaller. The best concepts begin on a strong foundation. It is vital to the success of any large project to examine how the project can be completed in stages. Why not consider your present infrastructure as one that needs only small transitions for improvement rather than attempting large projects that historically have high failure rates? For example, 65 percent of all CRM projects are considered failures in meeting their objectives. In some cases, you may be better off not implementing a CRM project but finding the places where the concepts of CRM may improve your processes. Here's where I go back to basics: I complete a gap analysis to see where I am and where I want to be. Sometimes the results shock me. The analysis can help me recognize if my foundation is the area that requires change or if only some small processes need improvement.
Third: Maintain your intellectual capital. Company intranets are commonplace in most IT organizations, yet information is constantly out-of-date and hard to find. Networks have become a repository for disjointed, unorganized documents, spreadsheets, project plans, e-mails and who knows what else. Finding the current business requirement is like finding a needle in a haystack. In order to get back to basics, IT managers must begin to organize, in small ways, the massive volumes of information they create and accumulate each day. In my company, we have begun to compile the seemingly endless streams of documentation on the various programs developed in the past 10 years. We have included the location of business requirements, test plans, system documentation and help files to create a database that designates the location to keep track of our intellectual capital. In addition, we have created what we call system expert presentations. These presentations were initially created to train our team on new applications, but we are presently preparing them so that other members of our technology group can take advantage of this wealth of knowledge.
Fourth: Involve all necessary teams in product development. When using a standardized software development life cycle, project managers need to include all teams throughout the entire process. That may seem unnecessary, but the discussion and information conveyed by each participant during these conversations offers them a sense of ownership. Often overlooked groups will benefit greatly by simply having access to this information. For example, network services can ensure the impact on the network is minimal. Training groups can create accurate materials for customers. QA analysts can develop and maintain test plans that help ensure the product quality. Meeting discussion points should include the following: common terminology, definitions of complex terms or processes, changes to existing and dependent applications. One way we have improved our project development is by sharing this valued information. We maintain spreadsheets to describe the changes to the applications for the upcoming development cycle. Project plans and statements of work and business requirements are available to all.
Another added improvement in my company has been to invite all technology teams to alpha tests of new, enhanced or redeveloped applications. These meetings provide every team with valuable insight into the program and the information needed to complete their assignments.
For example, in my previous position with another company, we were challenged by the need to convert information from one database system over to our present system. The initial analysis from the programmers suggested that the conversion effort would require many long hours and late nights to complete in the scheduled time frame. During a meeting focused on how to attack this major effort, a data-entry specialist pointed out that we had all the paper records for these entries. Another member of the project then suggested that we calculate how long it would take to enter the data into our system manually.
The calculation was roughly equal to the time needed by a programmer for conversion. In order to save costs, we decided to enter the data manually. The knowledge of the data-entry specialist proved vital in saving the company time and money. From that experience I learned that the key to scheduling meetings is to invite anyone who might have knowledge needed to make the project a success.
Infrastructure changes are never easy. New project managers, loss of unrecorded intellectual capital and the high employee turnover rate for IT groups make these changes seem insurmountable. When I am tempted to reevaluate change, I remind myself to return to the basics. That way, I find it easier to see the holes in the present processes and make the appropriate decisions needed for improvement. Management fads are good in small doses, but the real nugget benefit of these proposed solutions is the answers they provide to common problems we all face as IT managers.
So the next time you see an article with the title "B2B," it may refer to business-to-business, but now it can also serve as a reminder to go back to basics when you attempt to solve problems in your business infrastructure.
Looking for a platform for your ideas? Let us know as firstname.lastname@example.org. Ken Lengel is the director of system integration at tax preparation service Jackson Hewitt, a subsidiary of Cendant Corp. Often overlooked groups will benefit greatly by simply having access to information.