The Evolution of the Process Method that Delivers

The Proven Parker Process Method Saves Millions and Delivers on Expectations

Computer technology, on its road to ubiquitous-ness, 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.

Return to Top