What's Wrong With Process? Part 3

Here we go again...

"I don't need process, I have advanced technology..."

Cards on the table time...I'm a technology guy. What's worse is that I'm not even "trained" to be a technologist - if you go by my college training, I'm supposed to be an investment banker. Technology has been a passion pretty much all my life in various forms, and I count myself as extremely fortunate that I can make a pretty good living at something that's basically a hobby*. So, arguing that technology will be able to relieve me from having good process should be a natural...

In my experience, nothing could be further from the truth. Modern technology can do wonderous things, from transporting hundreds of thousands of people around the world daily to making medical conditions much more livable and extending everyones' lives, and just about everything in between. However, one thing is constant in all of these uses of technology - the people that design, implement, and operate it. Technology is simply a tool to facilitate human endeavours. It cannot be substituted for people, no matter how advanced the "intelligence" that is programmed into it. Science fiction is replete with cautionary tales of machines threating the very existence of mankind, so it is unlikely to me that machines will replace human functions any time soon - which is a topic that's far away from what we're discussing here (so I'll stop).

Back to enterprise software...The major ERP vendors have developed extremely function-rich applications that can handle most of the situations and configurations present in business today, and they are developing even more and better functionality all the time. Most of this functionality revolves around "industry best practices" in the fields of human resources, financials, customer relationship management, and supply chain management, to name a few major functions. The term "best practice" refers to a base of commonality for each of these functions that has been developed by the vendors in their interactions with thousands of customers - for example, there's only so many ways that a company can compensate their employees. The issue that arises is that most companies' established processes do not fit into the vendor application processes, so some measure of configuration or customization is required to make the software usable to the company.

So, we're back to establishing processes to manage these configurations and customizations, which precludes using the technology to solve the problem - a vicious circle.

Even if a company can miraculously fit into a vendor's software process, the people who administer and use the software will need to be trained on those functions, and it's unreasonable to expect the entire staff to self-train on all of the functionality and permutations of the application. Therefore, the company will need a training program - damn, there's another process that needs to be managed. The executive management will have questions regarding the data that's being collected by the application, and to prevent "query chaos" in the organization, you will need to establish a reporting process - hey, there's that word again! I know there are more areas of an implementation that require human intervention, and therefore need a process or two...but I think you get the idea.

It's very easy to make this argument initially - in my earlier experience, I even made that argument: "If we just had this (database/development tool/report writer/etc), we could get the job done with a minimum of fuss (read: little new process to be implemented)." It may be a function of growing older, but I see the issue now not in terms of technology, but how people use the technology - and that involves developing and maintaining solid processes. There's really no way around it.

Next time: "I don't need process, I have an experienced manager..."


* - Now if I could only figure out how to make the same living making music without selling my soul...

By The Way

I meant to mention this at the end of the Part 2 post, but forgot...old age creeping in again...

Many of the points I bring up are stated much more eloquently that I could (but from a slightly different angle) in a book I'm currently reading called The Fiefdom Syndrome, by Robert Herbold, who was COO of Microsoft, and before that a marketing executive at Procter and Gamble. He has great insight into the formation and destruction of internal groups in organizations, and I highly recommend picking up a copy.

And if you're reading this, Bob, any similarities you see are due to shared experiences and observations, not plagarism...:-D

What's Wrong With Process? Part 2

The next installment in our occasional series...

"I don't need process, I have really good people..."

This is the first argument management will make in defense of their lack of process. It occurs mostly in entrenched industries like insurance, banking, and healthcare. The established personnel in the organization are very knowledgable in their particular jobs and the interplay between departments that always occurs in a large organization. They have often developed their own processes and proceudres over years of experience and varied situations. Therefore, any suggestion of chages to their process from an outside voice meets with disdain and skepticism. After all, since our current process works, why change?

I have several issues with this attitude, mainly having to do with perspective. While it is true that the processes developed internally can be made to work within the organization, the perspective of these processes is specific to the department or organization at hand - they may not translate well to a larger world, such as coordinated enterprise reporting, for example. In this situation, it's a good bet that the other organizations that are to be interfaced have developed their own procedures, which may be similar but likely not identical. When this happens, negotiations on a common path must be done, which are usually difficult becuase neither organization will want to compromise what "works" for them.

The above is only one example of the harm that can beset enterprise-wide projects because of this attitude. Another risk comes with the necessity to codify and release vital information related to the department operations in support of the collaboration project. This goes counter to the training of everyone passing through the Western school system - you are taught that your retention of information gives you better grades, and therefore an advantage over your classmates. There is very little teaching in a team setting with information sharing. Therefore, people entering the workforce value retention of information over sharing, which places strain on projects that require sharing to be successful.

One of the things I've seen over and over in implementing enterprise software is the overloading of resources on the client project team. This is another outgrowth of the "really good people" attitude. Many times, employees are expected to continue their originally assigned duties in addition to being fully loaded (from a project management perspective) on the implemetation project. This invariably leads to incomplete work on both sides of their responsibilities, and lessening morale on the team because of the stress. The balancing of schedule and resource loading is a subject for another rant, but I suspect that overloading would happen less frequently without the companion attitude of having "really good people."

Another consequence of denegrating process because of people comes with the accompanying lack of documentation of existing department processes. This has the effect of curtailing staff career growth since they are required to remain doing what they're doing to support department operations, with the attendant morale decay. The simple act of documentation could mitigate this effect, but many organizations who have the "really good people" attitude do not see the need, and end up losing their "good people" for other jobs, often outside the organization.

How do you avoid this attitude? Does management take the opposite attitude and not trust their employees outside of the process? Of course not. The act of having well-documented, consistent processes allows an organization (of any size) to be much more flexible in meeting business challenges. They can train new employees (either temporary or full-time) much more quickly and consistently since the time of the established employees will not be taken up in basic training. They can have relatively effortless cross-training and coverage of shortfalls. They will not fear career advancement by their staffs, since replacement will be easier. They can take on special projects (like enterprise software deployments) easier. The stress level of the staff will be decreased, and the operation will be more efficient and effective overall.

Don't get me wrong - I love working with "really good people" - I can learn a lot from them. Unfortunately, that attitude is the rare one in today's organizations, and is not generally encouraged. Imagine the increase in corporate efficiency that can be achieved by turning those attitudes...

Next time - "I don't need process - I have advanced technology..."