Once a system is created the parts of a system are fixed unless the system contains an additional activity, the management activity. It is the most powerful of all system activities. It can plan, organize, allocate, schedule, implement, evaluate, etc., the principles of management, but all of these activities only provide support for the most powerful activity of management. Management can dact operators, operands, and instructions to ensure the goals of the system are achieved and maintained. This capability allows the management activity to indirectly dact an entire system. The management activity can dact instructions to dact the system or any part of the system. A new operator and or a new operand maybe needed to operate the dacting instructions.
    Why an new word? Because change maybe capricious, random, or accidental and dacting has none of these attributes. Jerry Noder created the word dact from the acronym for file maintenance operations, Delete, Add, Change, Transfer, during my tenure as manager of information systems.

                            Delete identify as waste and eliminate a resource.
                            Add create or accept a new resource.
                            Change change an attribute of a resource.
                            Transfer move a resource to a different location.

    The last two operations can be achieved by executing the first two, but in doing so the efficiency of the system is reduced. Later the word dact was expanded to include all the steps necessary to achieve and maintain a goal.
    The management activity does not operate the system, one or more operators operate the system. In a simple system with only one operator, obviously that operator will operate the management activity as well as all the other activities of the system. Generally the management activity is supplied by another system, the management system. It may be internal or external, dependent or independent. The user can be the management system.
    The effectiveness of the management activity is limited by the quantity and quality of the goals, reference points, and directions supplied by the user; by the precision and accuracy of the dacting; and the quality and quantity of the communication between the management system and the managed system.
    Precision and accuracy can be thought of as the result of a marksman shooting three rounds at a target. If the three rounds hit the target close together, the marksman was precise, if all three hit the bull's eye close together, the marksman was precise and accurate.
    The power of management is directly proportional to the operators, operands, and directions that management can dact. Management can not manage what it can not dact. This explains our difficulty with bureaucracies. A bureaucracy does not have a management system only a supervisory system. All directions are created external to the bureaucracy and can not be changed by the supervisors.
    To evaluate is to compare all attributes of a resource to reference points and to determine the meaning of any significant differences. If a difference is significant, does it indicate what dact should be performed next, if so management should create the directions to be used to perform the dact. During the evaluation management should create directions to be used during regulation for each possible output of the comparison. Never let an operator guess what to do next.
    People resist dacting and are more likely to resist the social changes rather than the technical changes listed below.

                    1. Threat to status, new position below old position.
                    2. Threat to ego, present skills not needed on new job.
                    3. Economic threat, loss of job or reduced income.
                    4. Job complexity, a new system is usually more complex.
                    5. Job ambiguity, system appears to be in control instead of a person.
                    6. Job rigidity, program and system time schedule must be met.
                    7. Insecurity, a report replaces people contact and or relationships
                        changed because of a change in data flow.

    Because of these reasons people have been unwilling to participate in system dacting. 'If it's not broken, don't fix it,' and 'leave it the way it is,' are common responses. Rarely can a system stay the way it is if new equipment is used. New codes will be needed to tell the new equipment what to do.
    A system must operate in reality (today) not what someone thinks it should do or what someone would like it to do (tomorrow). Once a system is operating (today), then plan the system dacting so the system will do what is desired (tomorrow).
    Don't confuse plan or intend with wishful thinking, people often say they plan to do something or they intend to do something when their plans or intentions are little more than wishful thinking. A plan is the intended directions of a system to definitely do something at a scheduled time in the future. There is nothing wishful about a plan, it will be carried out unless conditions change, a plan is a variable goal.
    On the other hand technical people have been trying to teach the users the technical aspects of a system instead of a general understanding of the system. How can communication take place if a general understanding and the definition of new terms has not taken place?

    People will support system dacting because:

                    1. Development and growth.
                    2. More opportunities are possible.
                    3. New skills to be learned.
                    4. A new system should eliminate dullness and drudgery.
                    5. An increases in status.
                    6. Work is more satisfying.
                    7. Greater rewards.
                    8. More efficient.
                    9. Decrease in pressure.
                    10. Work simplified.
                    11. A person is in control.

    Does it surprise you that the reasons to support system dacting were often the opposite of the reasons to resist system dacting? Too often we resist before we analyze.
    The systems approach is a useful way for people to define and analyze their world and to restructure or create new systems.
    The steps to dact a system are:

                                                        System analysis
                                                        Problem solving
                                                        Design
                                                        Construction
                                                        Implement
                                                        Audit

    During each step use the definition of a system as a guide to help prevent errors of omission. Make sure the level of detail is appropriate to achieve a given step. The following assumes the above steps have been assigned to a special subsystem, a project team, consisting of users, mangers, system analysts, operators, etc.

                                    System analysis

                                            Determine goals
                                            Establish reference points
                                            Determine present conditions
                                            Why change
                                            Gather data
                                            Present system analysis to management and obtain
                                                   approval  to proceed, else recycle through the
                                                   analysis.

        Determine goals
    Determining the goals is the user's responsibility. The attributes of a goal must be logically consistent, otherwise the goal can not be achieved. If a system has multiple goals, the goals must be logically consistent or the achievement of one goal may negate the achievement of another, leaving one or more goals permanently unsatisfied.
    Don't limit the number of possible solutions by stating a goal in terms of form, structure, or method because many times the attributes of a goal can be achieved with a different form, structure, or method.
    A goal is not a solution, never state a goal in terms of a solution, obviously the number of solutions is one or minor variations of that solution. For example, our goal is to increase the income of the poor by taxing the wealthy and giving the taxes to the poor. A better goal would be, our goal is to increase by five thousand dollars every family with incomes below five thousand dollars.
    State goals in concrete attributes. Choose attributes that are countable, measurable, comparable, or observable, in this order. If these conditions are met, everyone can recognize the progress toward the goals and morale and enthusiasm can be easily maintained to reach the goals. Don't say, "We want a fast efficient system," say, "We want a system with a one hour turnaround and at a cost of five cents or less per transaction."
    Counting can be very precise and accurate, such as counting eggs, oranges, or dollars. Measuring is less precise and accurate than counting. Measuring is using a standard to make a comparison. A reference point becomes a standard when two or more systems agree on the value of the reference point. If two or more systems agree on the accuracy and precision of the standard and the measurement, the value of a measurement will be the same for all systems, it will be objective. A comparison is subjective, it has value only to the system that made the comparison.
    The purpose of a goal is to give everyone a way to recognize what has to be done without constant re-explanation. If goals are to be effective, they must be thoroughly understood and accepted. If those responsible for achieving the goals participate in setting the goals, understanding and acceptance is more likely. The most effective way for a user to communicate a goal is to make their actions consistent with the goal; to state the goal in concrete terms; and provide rewards only to those who move toward the goal.

    Establish the reference points.

    Identify the factors that will determine success or failure and create reference points to be used during regulation and evaluation. A reference point is a data resource stored in the environment to be used by the compare operand to indicate a goal is being achieve, it has been achieved, and it is being maintained.
                        Determine the present conditions a system survey
                                    What is being done?
                                    How much is being done?
                                    How long does it take?
                                    How is it being done?
                                    Where is it being done?
                                    When is it being done?
                                    Who is doing it?
                                    How safe is it being done?
                                    Is protection adequate?

                        Why change?
                                    Why is it being done?
                                    Why is that much being done?
                                    Why that long?
                                    Why is it being done that way?
                                    Why is it being done there?
                                    Why is it being done then?
                                    Why is it being done by that operator?
                                    How well is it being done, can it be improved?
                                    Is there duplication, substitution, similarity else where?
                                    What and where are the obstacles?

    Are these the only questions that should be asked? No! Every system is unique and most of the questions will be unique to the system. Beware of the error of allness, I shall return to it later.

    Gather data

    What are the facts (data)? What are the obstacles? Research the historical records, determine the different types of transactions, the resources involved, their volume, their frequency, and their identity. Don't forget to include the historical records as part of the data gathered. Identify resources, their attributes, use, and source. What is the order of events? What degree of accuracy is wanted and needed? What regulation is required, the level, time, and location?
    Interview the users and operators, ask for ideas. What should the new system produce and in what format? How can it be done more easily? Take notes and write a memo to the users and operators and ask for comments on what you thought they said. This helps to eliminate misunderstandings and documents the interview.
    Observe the system in action. Remember an inexperienced operator is usually of little help and an experienced operator may know the system very well, but may not be able to communicate that knowledge.
    An old story illustrates this obstacle. A traveling salesman was lost, not a building or a road sign was in sight. He saw a small boy sitting on a stump near the side of the road and felt a little relieved. He asked the boy, "How do I get to the nearest town?"
    "I don't know."
    "What is the name of this road?"
    "I don't know."
    "Is there a main road near here?"
    "I don't know."
    "Where do you live?", and the boy pointed across a field.
    "Tell me how to get there."
    "I don't know."
    The salesman was very frustrated but continued to think of questions to ask the boy in the hope of gaining some information. "How do you go to town?"
    "I don't go."
    "How do you get to school?"
    "I follow the cow path to the creek and the creek to the bridge and then I follow the railroad tracks  to the highway and there's the school."
    "How do you do go to church?"
    "My dad takes us."
    "Which way do you go?"
    "I don't know." The salesman had reached his limit.
    "You don't know very much, do you?"
    "I know one thing."
    "What?"
    "I ain't lost."

    Sometimes the only way to learn about a system is to observe the system in action, follow the operators without interfering with the operations. Record what they do and when they do it. Take special note of any unusual resources used. Don't frustrate an operator by asking 'why'. Remember, an operator follows directions, so ask, 'Can this operation be done another way?' Be careful not to ask questions that will put anyone on the defensive. Follow the principles of active listening and transactional analysis.
    A word of caution, be prepared for the unexpected when observing a system in action, you may discover operators not following directions and managers not doing their job, such a discovery can be very embarrassing for all concerned. Also you may discover larceny or other forms of misconduct, know what your response will be before you are faced with such situations.
    Review the data, eliminate irrelevant data, consider the source of the data and consider the quality of both the data and the source. Make sure the data gathered covers the entire scope of the system. Recycle through the system analysis steps until the system analysis is as complete and error free as is feasible. Can a system analysis ever be 100% complete? No!

    Present the system analysis to management and obtain approval to proceed, else recycle through the analysis again.

    The systems analyst must translate the user's and operator's statements into system specifications. The principle cause for disappointment with systems analysis is the failure of the analyst to obtain proper data from the users and operators. They may have made many elegant statements, but none of the terms were defined and neither was a method of quantification established. When such statements are translated into system specification they will be incomplete and incorrect. The users and operators usually don't know or can not communicate all the details in one interview and the systems analyst is not allowed enough time to do a thorough job, making systems work evolutionary instead of revolutionary. Why is there never enough time to the job thoroughly the first time, but always time to do it over?
    In addition, users and management have abdicated their responsibility by refusing to become involved or acquainted with new technology and is applications. This abdication is not new, it has occurred with every new technology. The technicians on the other hand continue to teach the user and management the technical aspects instead of a general concept.
    Management does not manage the technologies, it lets them manage themselves, viz., medicine, law, engineering, accounting, etc. A technician becomes a manager of a technology and eventually learns the principles of management.
    Systems analysis gains by eliminating the execution of unnecessary instructions. For example, a secretary receives five documents every hour, opens the file drawer, removes a file folder, places the documents in a file folder, places the folder in the drawer, and closes the drawer.
    Each step takes ten seconds, for a task time of fifty seconds. This task is done each hour of the work day for a total time of four hundred seconds.
    Let's change the instructions. The secretary allows the documents to accumulate in the 'in box' until the end of the day and opens the file drawer, removes a file folder, places five documents in the folder, replaces the folder, and shuts the drawer, and repeats the instructions until the task is finished. The total task time remained the same.
    Let's change the instructions again. At the end of the day, the secretary opens the file drawer, removes a file folder, places all forty documents in the folder, replaces the folder, and shuts the drawer for a total time of fifty seconds, a savings of three hundred fifty seconds.
    'More is better,' is a very common fallacy, it assumes time was saved by handling 'more' at one time. The handling of 'more' didn't save the time, handling 'more' was the result not the cause. If the instructions had remained the same except for changing the task from each hour to the end of day, the first change, no time would have been saved at all. The time savings was gained by eliminating seven redundant repetitions of the task, the second change. Remember an operator follows instructions and operates the operand according to the instructions, nothing more and nothing less.
    According to Drucker optimizing resources ranks third in increasing resources. He ranks exploitation first and discarding unused resources second.

                    Problem solving

                          Determine the problem
                          Solve the problem
                          Do a feasibility study
                          Present the study to management and obtain approval to proceed,
                                        else recycle through the appropriate steps again.

                    Determine the problem

    The problem is how to achieve the goal, how to proceed from the present conditions to the conditions of the goal. In order to state the problem, the present conditions and the goal must be defined. State the problem in terms of attributes of proceeding from the present condition to the goal. If the problem is not stated in terms of proceeding from the present conditions to the goal, the problem may be forced to fit a solution.

                    Solve the problem
                                    What should be done?
                                    Why should it be done?
                                    How much should be done?
                                    How long should it take?
                                    How should it be done?
                                    Where should it be done?
                                    When should it be done?
                                    Who should do it?

    Think about the attributes of the problem in rapid succession several times until a pattern emerges which encompasses all the attributes simultaneously. Suspend judgment. Don't jump to conclusions. Explore the environment. Vary the temporal and spatial attributes of the resources. Examine each attribute independently and coupled with other attributes. Create as many solutions as possible. Be careful, the first solution tends to inhibit or limit other solutions, so create a second solution as soon as you can.
    During problem solving don't concentrate so much on the trees, the forest can't be seen or vice versa. If you can't create solutions, change your representational system, if concrete, try abstract, if similar, try opposite. Examine corollaries and their converses. Vary attributes. Take a break. Do something else. Talk about the problem. Redefine the problem.
    Remember, some problems have no solution and some solutions are infeasible. Some problems can be proved to have no solution or current technologies may not be capable or current knowledge may not be far enough advanced to provide a solution or a solution may not be achieved in a reasonable length of time or without expending unreasonable amounts of other resources.
    For example, find the integer values of the ratio of the circumference of a circle to its diameter or travel to another galaxy, or manually count a billion one dollar bills or manually count the number of connecting wires from each node to every other node in a net work with twenty nodes. In such cases, redefine the goal to create a new problem that can be solved.
    Wait until you have generated three or four solutions before evaluating any of the solutions. Critically evaluate your solutions, constructively evaluate the solutions of others. Don't criticize the solutions of others and above all don't ridicule their solutions. I don't know of anything that will stop the formation of new ideas any faster than ridicule. Everyone's mind will go blank faster than you can blink and no one will be able to create another solution. Ridicule has a very serious and insidious side effect no matter how subtle, it inhibits the sharing of ideas. Don't ridicule, it discloses the bigot, the demagogue, and ideologue. Ridicule is a sign of stupidity, ignorance, and prejudice. Always show respect for yourself and those around you.
    Estimate the resources required to effect each solution. Then choose a solution, but have at least one alternate solution available. Make a list of who and what will be affected by the solution and how they will be affected.
    How successful the solution to a problem will be, depends upon the nature of the system and its operating directions, the support management gives to the solution and the systems projects staff, the technical skill and personal finesse of the staff, and the degree to which the solution is regulated.
    For a solution to be successful, regulation needs to be centralize, for cost, quality, quantity, coordination, and education of staff and users. If a solution is the first of its kind, then construction and implementation must be a part of the solution.
    Remember, a goal is not a solution, an error common in the political arena. Many times a goal is touted as a solution or a solution is touted as a goal, they result in highways that end in the middle of nowhere, factories on one side of the river and workers on the other, refrigerators sent to a topical country to store pharmaceuticals and the country doesn't have electricity, etc.

    Do a feasibility study

    Compare the operating cost of the current system with the estimated operating cost of the new system. Don't forget the cost of new equipment; the cost of maintenance on all equipment, systems, programs, and training of staff and users; plus the cost of error and failure recovery procedures; and the cost of documentation and paper handling. Compare the benefits of the new system to the old system. Will the benefits justify the cost of dacting the new system?

    Present the feasibility study to management and obtain approval to proceed, else recycle through the appropriate steps again.

    Design

    Define and design the output that will achieve the goal, then define and design the process that will produce the output, then the resources can be determined that will be needed by the process. Then the supporting activities can be defined and designed and their resources determined. Then the directions for all activities can defined and last, the environment can be defined and designed.
    At the operation level work backwards from the output that will achieve a goal, define the operand than will produce the output, followed by the operator, the input, and the instruction. Then define and design the next to last operation whose output will be the input to the last operation and continue to work backwards toward the first instruction of the activity.
    An example will illustrate why this order should be followed. A baker must know the output first because most baked goods are made from three main ingredients, flour, shortening, and water. Their ratios and preparation methods may vary some what, but the major difference is the leavening. The difference between bread, biscuits, crackers, and pie crust is, bread is made with yeast, biscuits with baking powder, crackers with soda, and pie crust without any leavening. If the output is not defined first, the baker may end up with wallpaper paste.
    The two steps, determine the problem and define the output are the most difficult to do and the most critical to the success of the project.
    If the system design includes more than one operator and or uses one or more systems, communication and the delegation of authority and responsibility must be included in the design. Do not separate authority and responsibility. Is it any wonder why 'good' people never run for public office or work for the government or any bureaucracy. The people in control want to keep the authority and give you the responsibility.
    When the design is complete recycle through the design step again until the design is as consistent, complete and efficient as is feasible.

    Construction

    Construction and implementation are unique to the system, only general guide lines will be presented here. Use the systems approach on every step of construction and implementation. Using the system design, add a list of all the resources needed by the construction activity along with an estimate of quantity and quality to the list of resources needed to create the system.
    Select the construction crew, organize, coordinate, communicate, and train. Assign responsibility for each construction activity and allocate resources to each crew member. Together develop a manpower schedule and a relational schedule for each construction activity. Use such techniques as PERT, Critical path, etc.
    View schedules as a long trip, if the speed limit is not exceeded, everything that happens will slow the trip, the only way you will arrive on time is if you made a lucky guess or a very poor estimate. Emergencies, absenteeism, reruns, delays beyond the control of the construction crew, etc., make detailed time schedules infeasible. Errors in estimates and instructions and failure of operands and operators can not be predicted. Besides, most systems are unique, they have never been built before so how can anyone have had the experience to make a time estimate, how could a detailed time schedule be accurate? A detailed time schedule will be a waste of resources make a relational schedule instead. What should be done in what order.
    People tend to underestimate the time needed to do any given task. One of Murphy's laws states that a well planned project will take twice as long as planned, a poorly planned project will take three times as long.
    If a project schedule slips, seven alternatives are often used, the first three are constructive, the last four are smoke screen.

             1. Change the schedule.
             2. Increase resources.
             3. Decrease quality.
             4. Start another project.
             5. Point out problems in another area.
             6. Reorganize.
             7. Tell someone else how to do their job especially if unqualified to do so.

    Changing the schedule is the most realistic choice. Decreasing quality is undesirable and increasing resources is generally a waste. Once a project is behind schedule, it takes four times the resources to get back on schedule, not twice as much as most people assume. They forget the learning curve of new crew members and the time lost by old members while teaching them.
    Over time is not a viable option for more than two weeks, don't use it on a large project. After two weeks of over time the amount of work being done in an over time day will be less than the amount done in a normal work day before over time began. After one month the error rate will be so high more errors will be made than were corrected and the project will fall further and further behind schedule.
    Make progress reports to all involved at predetermined intervals of time and on the completion of major segments of the project. Make sure everyone knows who is involved, who is going to do what and when, where the resources are, and the communication links between each system involved with the project.
    Make detailed specifications for all parts of the system and detailed instructions for their construction. Name each element of data, each type of transaction, each activity, each resource. Make each name unique to avoid misunderstandings. Modify the system design as the detailed specification become known for all parts of the system and the construction activity. Make a list of all critical points for all activities.
    Review the plans to construct the system and the system design to ensure errors are absent. Update all documentation and begin construction. Using the previous list create detailed recovery procedures at all critical points. Test each part as soon as possible and run the new system in parallel with the old if possible. A one for one comparison is the most reliable error check. Macro testing almost always exposes errors not discovered in micro testing. Recycle through the appropriate steps until all known errors have been removed. Update all documentation, make the final project report to management, and obtain approval to implement the new system.

    Implement

    Before doing so, double check user and operation manuals, train users and operators, and establish operations schedules. Don't let up now and make a foolish mistake when the project is nearly complete. Coordinate the implementation. Create detailed instructions to implement the system. Use the list made earlier to review and remind, who is involved, who and what will be affected by the new system and how they will be affected.
    Implement the system, shut down the old system, and update all documentation. Be sure to remove all old user and operation documentation and store them. Have an alternate plan ready to execute, such as restarting the old system or doing it manually if something unexpected happens.

    Audit

    At an agreed time following the implementation, audit the new system. I mean audit, not review, check or test every detail. Does the system perform as designed and deliver the anticipated benefits? Compare the results of the audit to reference points to make sure all goals were met. If not, dact the goals, the reference points, the system, the documentation, etc., until the user is satisfied.
    Was the project accomplished within the budget? What improvements in the management activity may have permitted better estimates and avoided the schedule slippage. Would additional training or knowledge have helped. Did the new system create unanticipated obstacles? Were the new obstacles eliminated? What new dacting should be considered as an extension of the old dact?

    Present the audit report to management. If additional dacting is approved recycle through the appropriate steps, otherwise prepare for the next project.

    Dacting a system is a recursive and a reactionary process, it will always be evolutionary. There is no way to be certain a system is consistent, complete, and error free. When an error is found, invoke the appropriate recovery procedures, recycle through the appropriate steps to correct the error, and proceed.
    Thinking should be done before a crisis, most people do not think well under pressure and it is highly improbable any solution created during a crisis will be effective and almost impossible for it to be efficient. Do a system analysis before a crisis is reached, before panic prevents effective thinking.

    Before turning to the next chapter, use the systems approach to answer the questions from the last chapter.

    1. Did you state their goal, their present condition, and define their problem? What was their goal? Did you say 'survive'?
    I intentionally threw you a curve ball by asking, 'How did they survive?'. Users and operators commonly describe their situation using similar statements. Selecting which data elements to focus on can save time; however, when you asked, 'What is the obstacle?', you should have reformulate their goal.
    The obstacle to survival was the lack of fresh water; therefore, their goal was to have a supply of fresh water, their present condition was the lack of fresh water, and their problem was how to obtain a supply of fresh water. Did you gather data and then vary form, structure, and method?

    2. The crew in the desert had the same problem.
    3. The key to the man and the truck is to concentrate on what conditions can be varied and by trial and error a possible solution will emerge.

    1. To solve their problem you do have to have some knowledge about what constitutes fresh water and the various forms of water. Sea water and sea ice contains salt thus eliminating those two sources. Glaciers are formed by layers of snow and snow is frozen fresh water. By selecting the small pieces of glacier ice, melting the surface in their hands to remove the sea water and placing the remainder in containers for later consumption, they were able to obtain a fresh water supply.
    2. The solution to their problem involves another form of water, water vapor. They slept during the heat of the day and at dusk they hung every piece of metal in their possession to expose as much surface area as possible. As the night air and the metal cooled, what little moisture was in the air condensed on the metal surfaces. They collected the water and filled their canteens. At day light they traveled until it was too warm and repeated the process.
    3. A little boy suggested, "Let some air out of the tires."

    For the next chapter define information, recognition, a document, a carrier, a channel, giving, and sharing. You should be able to answer, "Which came first the chicken or the egg?" And what makes a manager unique?"