Getting It Right

The Proven Parker Process Method Saves Millions and Delivers on Expectations

Computer technology, on its road to ubiquitousness, was like a shiny ball, mesmerizing, challenging and narcotizing with promises of fabulous cost-savings and innovations. It advanced faster than did the processes necessary to deploy it responsibly. As such, all of the project and process management methods, developed to gain control after the fact, have failed.

The good news is that Kim Parker (pictured below), chairman and president of K. A Parker & Associates, has developed a process that really works. The better news is, it works with any type of project, computer-related or not.

By Kim A Parker, Chairman and President of K. A Parker & Associates

arly in my computer career I was part of a programming group that ultimately became the Information Technology Department. We had spent a few years developing an application for electronically processing orders for what was then the equivalent of today's cell phone.

The day came when we were ready to proudly roll out our shiny, new programs. Being a member of the maintenance group gave me a unique opportunity to observe the users of what we thought were our well-conceived applications. I sat nervously, anxiously watching as the people we'd written the program for began to use the system. I wasn't prepared for what happened. Our target users not only didn't know how to use the system, they didn't want to use it. There had been an enormous disconnect somewhere, but we had no idea where or why.

Looking back on this humbling experience, it is now clear what the problem was. The end-users for whom we'd designed the system had not been a part of the team that specified how it worked. They hadn't been asked for any input, in fact, yet they were the only people who fully understood the process of handling orders. Their boss, who had been on the team, was really excited about the work we'd done, but that enthusiasm dampened quickly when his staff failed to embrace the system. Unfortunately, he blamed them.

For me, that was a valuable lesson learned, and at the next opportunity, I did things differently. I had moved on to another company where I became a senior systems analyst. It was my duty to define the specifications of I. T. project requests. In the course of doing my job, I stumbled on another serious disconnect, one that generated a gulf between departmental expectations and practical project implementation. That divide made my job hellacious.

I quickly learned the importance of clearly identifying where project requests were coming from and what the expectations were. Most of the time, the I.T. department was called on to fix a perceived problem or automate functions to cut staff. The projects were usually one-liners requested by department heads who conjured up wild estimates of potential cost savings. In addition, I was given specifications that were generally well beyond the reach of practicality. Time frames for project completion were determined by managers who simply never considered project scope or the resources necessary to make the project a success. In short, everything was heavily dependent on the infamous "wish" factor. While this was hair-pullingly frustrating, I learned a great deal about project management, and began pulling together components of what would later become the Parker Process Method.

Over the years, a bevy of project management methods have come and gone. JAD sessionsⁱ, Yourdon modelsⁱⁱ, project gatesⁱⁱⁱ, Method One^iv, best practices^v all reached certain levels of popularity, but they faded because they were predicated on the same myths: automation always = reduced costs; and automation always = business-process improvements. Instead of meeting expectations, systems became disk-space occupiers that generated valueless reports and no real solutions. The lack of success stimulated P.C.-based workarounds that only compounded the issues. In project after project, no matter how different the approach, the outcome was the same: programs failed to deliver on expectations, even though in some cases verifiable cost savings did result.

Case in point: In one year, our group rolled out six major accounting-related projects that generated documented savings of over $1.4 million. Even though the projects were "successful" by financial standards, there was invariably more work to be done. End-users often were not satisfied with the way the systems worked, and there always seemed to be someone on the customer's staff who, fancying him or herself a computer expert, fiddled with the system in effort to make it work. The problems that can cause are legend.

There seemed to be no process method that produced solutions that actually delivered on expectations. Then came a breakthrough.

My boss at the time was a psychologist by training and loved computers, especially the order that he found in data models. He started with a group manager he knew and convinced that person that they needed to have a data model before they started to scope out the project. He gave them a two-day class on data modeling and then did a kind of JAD session to get the input they needed. By using some psychology he was able to get them to at least believe that they were doing a project differently. In reality, he made them think about their job by dissecting it. He was able to produce a moderately successful project. A few other projects came up and he followed the same methodology, but there was still something missing, as was evidenced by several business problems that surfaced after the project was complete. We learned a lot about people's interactions and group dynamics but still had not captured the "requirements". This is where I came into the process.

There had been several methods on the market that tried to capture requirements but did not adequately capture the data. We found that a process modeling session could be done in as little as one to two weeks, two hours a day. We then found that we could capture improvements in the business process that were not computer related. Things like reports that were no longer needed, or jobs (processes) that had no direct output to the bottom line.

We also found that the processes, once documented and agreed upon, not only created a tangible foundation for discussion about business improvements, but also created a tremendous foundation for the detailed design necessary to automate the customer process. This became a great tool for documenting the savings since the cost of an eliminated process could be calculated directly. We could also calculate the cost savings of automation since again, we could calculate both customer (by hand) and automated costs of a process. The cost savings were in fact in the millions.

This became so obvious, so quick and so successful that as word spread, every department lined up to do a process-modeling session. Eventually, I was asked to put together a worldwide manufacturing model and finally a corporate enterprise model. Both of these exercises were completed in a rather ad-hoc format that was not in keeping with my standards but, nonetheless, accomplished the short-term goals.

The end product became the Parker Process Method, which, in fact, is a process that documents and creates a new business process.

My method however was never duplicated because it was more than just a process model; it was the process of creating the process model that made the difference. I made the decision to offer my process to corporate and government clients on my own, and founded K. A Parker & Associates.

Everyone wants to achieve cost savings through well developed processes, that includes you. Contact me at (919) 369-2373 or e-mail a request for information to: kparker@kaparkerassoc.com, so we can discuss your needs and decide how we can help you achieve your goals. The Parker Process Method is a proven process method that no company or government can do without.

References to and Explanations of Other Processes

i JAD, Joint Application Development ii Edward Yourdan, author, various titles iii The reasons given for using gating are because many manufactures use a gating process to determining when a new product is ready for manufacture and that this must also apply to software or computer products. Quality Control today is focused on the process, not on inspection. Gating is inspection. iv Arthur Anderson's system development methodology v This is a technique, not a method, where what someone else has done and done well should be directly imposed on any organization. This has never been the case. In more and more organizations, the realization is that this doesn't work because the people and environment for each organization is different.

Return to Top

Sharing the same knowledgebase

You'd be appalled at how much money is wasted by corporations and governments in the acquisition, grooming and publishing of information that's already been acquired, groomed and published by different departments in the same corporation or government entity.

Corporate competition should be focused on beating competitors, not on beating other departments within the same corporation. Governmental competition should be focused on improving government, not on advancing one's own cause. In either case, knowledge and information access are critical to success. But if that knowledge is hoarded or regenerated at vast expense because of pride or misplaced priorities, the entire entity suffers.

Bob Fuller (pictured below), Vice President and Senior Consultant at K. A Parker & Associates is an expert in creating and implementing team empowerment. He has conceived a unique and innovative way to break down walls that thwart success. With his plan, everybody in a company or government draws information from the same knowledgebase. What a concept!

By Bob Fuller, Vice President, Senior Consultant, K. A Parker & Associates

was sitting around the dinner table at the close of a three-day meeting with all the training managers from 40 divisions of a large electronics company. In the course of our discussion, the following question arose: How can we all share accumulated company knowledge just by attending this gathering?

Companies often own so much knowledge they waste millions of dollars redeveloping what they already have. From that dinner conversation, I went to work trying to solve the age-old problem of capturing knowledge already tried, tested and paid for. It occurred to me that among the biggest barriers to benefiting from what we already had—in training programs, written guides and manuals—was pride. It was the pride of those who did not have the material, or who had not contributed to the development of the material, that compelled them to create their own. Why? To demonstrate value. All those collecting a paycheck had to demonstrate that they were worth their pay. So, what did they do? They never used what already existed, nor did they even try to repurpose it. Instead, they busied themselves by trashing the work done by others and reinventing or redoing that work in the name of progress.

The best material I have worked with generally is well rooted in history. With that insight in mind, I began to devise a way in which pride and history could work together. It began with the recognition that history and historical material can best be found in libraries. And other than the local public library, the best libraries I have used were those at the universities where I did graduate work. So I began weaving together these thoughts:

Universities are places that collect and share knowledge.
Schools of thought are collected in one place.
Many contributors make up the school or college of thought.

Why not do the same things for industry?

I proposed that we create a corporate university or academy. In that proposal, each school of thought becomes the responsibility of a department or division within the company. So, the sales department had programs and books on sales training. They became the college of "sales training". They did not have to produce anything new! They already had the needed materials. Likewise, some division or department had material on Team Building, others on Leadership. And then there was Process Modeling, Communications, Writing and so on. By collecting what groups had already created or purchased with pride, we began to assemble an impressive library of knowledge that we already had. The cost savings rose rapidly to millions of dollars. Contributors were delighted to be recognized, and those wishing to make their mark (justify their brilliance and paycheck) could add to the body of knowledge without replacing or rehashing it. In a relatively short period of time, we became a company that drew its practices and philosophies from a shared knowledgebase, thus we began to know what we already knew. The results were remarkable. The cost savings were enormous, the walls built by pride had fallen, and a new spirit of cooperation emerged. We were all working from the same pages and goal achievement became a companywide—as opposed to departmentwide—proposition.

Every medium to large entity, be it private sector or public sector, has amassed its own knowledge. Parochialism and pride break that knowledge into pieces, which in turn splinterize the company or government. Misplaced competitiveness becomes intramural, and instead of competing for new business or initiatives together, departments try to outdo each other. The result is missed opportunities, higher costs and the shattering of the esprit d'corps that fuels goal achievement.

If you are a corporate manager or governmental department head, you may be unaware of a shared-knowledge problem in your organization. The critical first step toward determining if one exists is to have K. A Parker & Associates evaluate your knowledgebase. If we find ill-conceived segmentation, we'll help you pool knowledge and help build your own "Corporate University." You can reach me, Bob Fuller, at K. A Parker & Associates by calling (919) 606-6371 or by sending me e-mail bfuller@kaparkerassoc.com.. Contact me soon so we can discuss your needs and decide how to best help you achieve your goals by pulling together.

Return to Top