MBA 628 – Improving Organizational Performance

Andy Gruenbaum

November 3, 1998

Orientation

Although this paper was completed while I was working at Battelle, the project could still have been completed if I were freelancing. Although the web industry has grown recently, many of the young people involved have made no effort to introduce quality into the development process. Thus, regardless of my particular position at this time, the introduction of quality into this “black science” will be a beneficial one.

Improvement Opportunity

While working with a variety of clients as they are deciding to implement web sites, I have found the process is not designed to capture all of the relevant requirements at the beginning of the process. This has led to many frustrations. If only there were a documented process that could serve as a template at the start of all web projects. Despite previous frustrations that have occurred throughout the development process, it is believed that gaining control of the first meeting will provide direction for the entire process. Thus, the purpose of this study will be to develop a process that can concentrate the gathering of all web project requirements. If successful, the gathering of all requirements will occur before the end of the first meeting.

Expected Benefits

• As the requirements are gathered, the responsibilities can be assigned. Otherwise, there is no level of accountability.
• As I consult at Battelle, any improvements I can make in the process will enhance my opportunities for full-time employment in the spring.
• I will learn much from the process. This knowledge can be taken with me and applied wherever I go.
• Since I am a consultant, everything I can do to project a more professional and organized image is a huge positive.

Tools and Rationale

• First, I chose to work with a flowchart. The flowchart provided a way for we to see how I am directing the entire process presently. Once that is presented, the flowchart can be reviewed to determine where areas of improvement may be found.
• Second, I chose to work with a Fishbone diagram. A Fishbone diagram allowed me to focus on the root causes rather than just the symptoms.
• Third, I chose to work with a pie chart. A pie chart allowed problems to be quickly displayed and understood. It also presented the problems as they relate to the other problems. Thus, the larger sections of the pie were targeted for immediate attention.
• Fourth, I chose to do an additional flowchart. The additional flowchart gave a picture of what should occur during the first meeting. It focuses attention on the problems of the previous process and provides preliminary solution to address these concerns.

Application

First Flowchart

The first flowchart was a little difficult to draw. Since there had been no process up to this point, the process that existed was a poor one. It was typically very erratic. Sometimes it went very smoothly, but more often than not, there was no method to the process. The flowchart I drew to present this illustrates the failure of the early part of the web requirement gathering process. Presently, the requirements for the project may continue to be added until near the end of the project. Additionally, the requirements may come in the form of an email or they may be developed during a meeting. Because of this and many other inconsistencies between projects, the flowchart is only a generalized commentary on the existing process.

Fishbone

The fishbone allowed me to evaluate the influence of people, procedures, policies, and place in the process. Because I had no team members to solicit responses from, I relied on brainstorming to build the diagram. An obvious weakness would be the limited experiences that effected the causes listed. If I would have had a team of webmasters to gather information from, I would have felt the data was much more complete. That not being the case, I took the four categories mentioned above and came up with what I believed sources of the problem had been in the past.

Pie Chart

The results of the fishbone were graphed. Of the problems that surfaced using the fishbone, the major problems were grouped. After being grouped, values were assigned to each group. These values were a result of the number of times I had encountered each of these problem groups. The software took the information placed in the table and graphed it in a percentage format. The pie chart serves as a easy to understand visual of what problems need to be addressed.

Final Flowchart

The final flowchart was done in an attempt to pull the results of the previous tools together. Although the bottom information is solely based on specific requirements, the top part of the flowchart addressed the issues that arose out of the pie chart. By incorporating these into the final flowchart, a guideline has been established. A process, although untested, has been created to serve as a template for the creating of web projects.

Results

• The mere fact that something has been committed to paper is a reminder that thought went into the process
• Now when a meeting is completed, the next meeting will be planned. If meetings are scheduled just to schedule meeting, no benefit results. Follow up meetings with a purpose will keep all group members focused on the goal of the project.
• As I have made preliminary efforts to implement small parts of the final flowchart, I have been disappointed. As a consultant, I am viewed as a consultant. I am viewed as an implementer not an instigator. This prevents me from being emphatic about my points. In my role, I do as the client wants and look toward my next position. Hopefully, the next position will allow me to influence the process more than I can now. As long as I am learning and growing, I can still add value to even the most primitive of processes.
• The inability to push for change is a challenge of consultants. The client pays for my presence. They can have all of my opinions that they want, but it is not my place to draw attention to areas of weakness. As was stated in class, “You toe-the-line for a year before attempting to change things.” When you are only on an assignment for six months, the opportunity to express unsolicited opinions is almost nonexistent.
• The lack of good communication and the lack of an existing process make any effort a step in the right direction. As my experiences grow at this assignment or at subsequent assignments, I can continue to build my experience base. Thus, when the client wants a process, I can immediately provide a possible model.

Learning

The primary benefit of this exercise was it established a starting point. It is not perfect. Many can and will improve upon it. Fortunately, doing it perfect the first time is nearly inconceivable. The abilities of man and machine will constantly be changing. As these changes occur, a process can always be improved upon.

Secondly, the quality of this type of project increase when it has more than one person providing the input. The introduction of additional ideas and insights will strengthen the quality of the final product. Additionally, the more people that participate the more people who will be proponents of the final process. Even though one group proclaimed something as a final process, it still needs to be revised as the people, places, policies and procedures all change. As they change, the process must continual to improve. As soon as something is stamped as “FINAL”, it becomes a target for the next improvement.

Additionally, my exposure to team projects within the MBA and the total lack of team projects in my work life has convinced me of my need to be on a team. Their is no team interaction for me at Battelle and neither was there at previous job. I have occasional interactions with my boss, but that is an occurrence of less than once a day. In my next consulting assignment or full-time position, the presence of a web team environment is a must. I am the first to admit my insights are not always that insightful. The synergies created within a group will make my work product more consistent and my interest more genuine.

Lastly, the use of the quality tools helps you focus on the problem from a variety of angles. If limited to just one tool, the value would not be the same. When tools are allowed to build on each other, insights surface that an individual tool would not have permitted. When the individual components of a problem are broken down, learning can occur. If the focus is maintained on the problem as a whole, frustration can result. When the individual parts are reviewed, the size of the initial problem does not matter. An improvement is made on the problem one piece at a time. Unfortunately, using the tools and creating a simplified process does not mean the new process is going to be used. Circumstance just may not allow the new process to be implemented. It does not mean it was a bad process; it just means the time for the process is not right.