At various times in the past, there has been someone in one of the Lotus Notes/Lotus Domino newsgroups complaining about how terrible his Domino network was performing and how difficult it was for the employees in his company to use. This complaint is something I have heard (and Ive seen both the causes and results of his concerns) in the three years I have been working as a Notes consultant and developer. The causes of poor Lotus Notes and Domino performance seldom have anything to do with the products themselves; they are in the group rather than in the groupware. Although every organization is different, experience has taught me that the problems organizations face when using Lotus Notes and Domino are almost always caused by one or more (and sometimes all) of five common failures.
Failure #1: Failure to Train
As widespread as computers are in our society today, there is still a large number of people who do not have computers at home or who are still not computer-literate in any deep sense. Yet there tends to be the expectation at the corporate level that everybody can just figure it out. Management often ignores the fact that many employees wont even know what it is. Companies fail to train because of both the high cost of outsourced training and a lack of in-house expertise. If you do not train your employees on Lotus Notes and Domino, you do so at your own risk. Education is the key to keeping employees confident and capable. Just because employees can crank out a Word document or enter figures into a spreadsheet does not make them computer-literate enough to handle Lotus Notes and Domino. Notes and Domino are not word processors or spreadsheets. They are complex tools that require a well-defined training program. The unrealistic expectation that employees will figure out complex software on their own has some rather far-reaching negative effects. An expensive rollout of Domino can quickly be hog-tied by ignorance and fear of the unknown.
Fix #1: Implement Peer-led Training
There is a common-sense alternative to the time and expense of the traditional method of instructor-led training. And no, it isnt passing out manuals; that usually results in a new
place for employees to create coffee cup rings and coffee stains. Train one or more users in each department thoroughly in the use of the Notes client or Domino applications so employees who are expected to use these applications know which coworkers to get answers from. These team leaders can then educate teammates on how to use the Notes client and any appropriate applications. Not only does the team concept (sometimes called teamware) save a lot of money and time, but it also allows employees to learn at their own speed, retain information better, and learn only what they need to do their job. After a few initial sessions, the time spent learning is only 5 to 15 minutes at a time. This learning time is also scattered throughout the workweek, so it has a minimal impact on the work flow in the company.
Failure #2: Failure to Control
Notes and Domino applications multiply like rabbits on Viagra. In small- to medium-sized companies, it is not uncommon to have 200 or more Notes databases created on several servers after a few years. How does this happen? A Notes database often can be created and rolled out more quickly and cheaply than many non-Notes/Domino applications. Once employees catch on to this fact, they start finding all sorts of uses for these applications. Add in normal turnover and intracompany transfers, and you are guaranteed to have lots of undocumented Notes applications on your system. The administrative problems caused are numerous:
Each one of these hundreds of databases or applications has its own security in the Access Control List (ACL) that must be changed every time there is a change in the employee population or corporate structure.
Each corresponding group in the name and address book (NAB) will have to be updated to reflect any changes in the employee population or corporate structure.
Each of these databases can increase in size slowly or more quickly than one would expect, so they can quickly absorb all available disk space.
Each one of these databases increases network traffic, and many will have one or more replica copies on other servers.
Add in problems such as links between databases created by different people, the need to update picklists, and other tasks, and you quickly have an IT support dilemma that will almost inevitably outstrip the resources you have allocated to it.
Fix #2: Create Standards and Use Them
One of the easiest and simplest ways I discovered to control otherwise rampant growth of Notes databases is to charge the requesting departments budget at the cost it would take any internal Notes developers in the IT department to create them. Other standards that can help immensely are avoiding hard-coding of peoples names (usually for certain security problems and certain types of email) in formulas and code, appointing people within the requesting department to be the database managers and thus responsible for maintaining the database ACLs, and setting standards for the creation and maintenance of groups and roles. Having requests for Notes applications reviewed before being implemented to determine their overall benefits and where they will fit into the scheme of things from both a business and an IT viewpoint can be a very helpful standard indeed.
Failure #3: Failure to Plan
One of Notes/Dominos strengths is also a weakness. Because Lotus Notes and Domino are so very customizable, its common to see customization run amuck. It can happen in
one database or across multiple databases, but what essentially happens is that users and implementers fail to do the kind of forward planning that it takes to create a coherent application strategy. Its knowledge management without the management. For example, a company might have a human resources database but enter vacation data in a separate database. Ive seen situations in which employees have up to 40 applications or databases that they are expected to use. Even worse, you might have the same information being entered in several different databases. To expect employees to be able to find and use information in applications that are not logically organized is absurd.
Fix #3: Proper Planning Prevents Poor Performance
How does a company prevent this duplication of data? Generally by applying the same kind of planning that gets applied to the mission-critical applications. Proper planning can keep the Notes database population under control and improve employee efficiency in a number of ways. A good strategy will maximize the value of the data without turning your staff into data-entry and -analysis drones. Reducing redundancy and thereby the number of databases also has the benefit of increased server efficiency and reduced network traffic. Reducing duplication of work by employees leads to increased productivity and reduces the amount of data entry for higher-level staff who should be focused on attaining strategic goals.
Failure #4: Design Failures
Too often Lotus Notes and Domino applications suffer from poor design. While poor design sometimes comes from hiring a designer who lacks the necessary resources or experience, it most often comes from within the group that will be using the application. When poor design is the result of the company requesting the design, it can usually be attributable to these factors:
One person within the company controls the design requirements. Applications built under these circumstances are unlikely to meet the needs of the larger group of employees who have to use them. In an extreme case, an executive pushed through a very expensive application for the company. (Although it was not a Domino application, the lesson here is still applicable.) After it was deployed, one employee discovered it took him 20 minutes to get the information he needed from a different application, write it down on paper, do the calculations with a calculator, and then reenter the numbers into another applicationwhich happened to be 2 minutes faster than doing it with the million-dollar application the vice president had pushed through designed to his own specifications.
Design access is not controlled. Individuals within the company who have no business having designer or manager access to a Notes application should not have those access levels. I have had users start changing the design after it has been completed. In one case, the individual decided that he didnt like the buttons where they were, so he moved them. He couldnt figure out why no one could see the buttons anymore. (He had moved them into a hidden area of the form.) In the other situation, an employee started changing security settings in the database ACL, and suddenly all employees had access to everything in a mission-critical database. Security in any enterprise application is a necessity, and sometimes this fact is overlooked.
Requirements arent prioritized. Often, requirements are cut in order to control design costs. But, those changes have to be made with a plan. Ive seen things that would enhance productivity and efficiency cut when there were things that would simply be nice to have that could have been eliminated instead. Companies also fail to take into account that paying for the back-end programming to create those productivity and efficiency enhancements can save a lot of time in terms of employee man-hours.
Fix #4: Seek First to Understand
Before you embark on a Lotus Notes or Domino development program, make sure you have thorough knowledge of what your company needs and how employees really work. The design should reflect your real-life corporate situation. And of course, involve the employees in the design process as early as possible. Doing so will make the implementation go much more smoothly. This is actually the recommended method for any type of custom software development, yet it is not always implemented by the corporation. When it has been done, in my experience, the applications tend to be simpler, less expensive, easier to use and maintain, and much more cost-effective.
Failure #5: Failure to Look Forward
Often when a company rolls out Domino, it has the necessary hardware to make it run efficiently throughout the organization. If the company doesnt have the necessary hardware, it will usually get it at that time. Three years and one or two major software releases later, the company will still have the same hardware and networking, but the company (and the demands on the systems) will have grown. Hardware will be huffing and puffing like a couch potato in a marathon because the number of users has grown, the number of applications has grown, and the size and complexity of software has grown.
In terms of real productivity, this situation means employees have to wait to do their work. Email starts getting lost, and servers slow down or crash due to system overload. Agents fail to run to completion, resulting in incomplete documents or notices. Documents may not be delivered on time, so employees do not have the information they need to work efficiently, their schedules are disrupted, and productivity suffers.
Fix #5: Budget for Growth
As computers become more and more necessary to a business survival, failing to keep hardware and software up to date can negatively impact a companys bottom line. Although trying to forecast software needs a few years in advance may be nearly impossible given the rate of change in the world of software, the hardware end is not so difficult to predict. A company should have a business plan dictating where it wants to be in the future and how it wants to get there. Project the size of your company a year, two years, and three or more years down the line and budget to support desktop and workstation computers connected to the Domino servers. Have an idea of how much bandwidth you will need to support your network traffic. It should not be that hard to at least roughly forecast the IT needs for your company.
End the Cycle
Most of the problems my clients run into with Lotus Notes and Domino are neither hardware nor software problems; they are human-ware problems. Smart companies put human nature to work for them, instead of battling it. The remaining companies keep grinding along more and more slowly, until eventually they blame the hardware or software for poor performance and spend big bucks to replace it all with something newonly to repeatedly go through the same cycle of efficiency, then degradation and failure, resulting in an expensive overhaul. Take heed of the potential problems Ive pointed out: Doing so may save you lots of aggravation as well as some serious financial headaches.
LATEST COMMENTS
MC Press Online