Volume Number: 20 (2004)
Issue Number: 12
Column Tag: Programming

Business Processes... they're good for you... No, Really

by David Sobsey

My Reluctant Indoctrination Into The World Of Documented Business Processes

I have very little formal business or technical education. Most of what I have learned in these two areas has been experiential. When I was in college I thought I was going to make my living for the rest of my life playing golf. Except for a few philosophy classes taught by the poet laureate of my school, a great American Constitutional Law class taught by a card carrying member of the American Communist Party, (notice I didn't mention the name of the school I attended) or the English lit class that introduced me to the worlds of Kafka, Joyce and Hemingway (his short stories, not his novels!), I largely viewed class work as an interruption from what was truly important, pounding out a couple thousand balls a day on the practice range. I was so obsessed with golf I wrote my term paper in a comparative religion class on the mythological implications of the game. Needless to say, life has a way of conspiring to keep us from fulfilling our dreams and golf is now barley a hobby let alone my vocation.

In 1991, after over 10 years in the business world, about 5 of which were in the IT services industry, I co-founded a support service outsourcing business with a guy who has two degrees from M.I.T and an MBA from Harvard. I liked to tell him he obviously didn't want to take any chances. We couldn't have been more different in our approach to tackling business tasks. I had always flown by the seat of my pants, ignorantly and blissfully confident that my ability to think, reason and solve problems would get me to where I needed to be. He on the other hand could not get up from his desk without a clearly defined, well laid-out plan for how to take his first step. Wanna guess which one of us has more money in the bank?

Unfortunately one thing we did have in common, at that time at least, was our rather verbally violent, hair-trigger tempers. The arguments he and I used to have over the best way to address a given issue made the interaction between Paul Sr. and Jr. on American Choppers seem like two mature seminarians discussing the true meaning of a line of scripture.

Fortunately for us both, and the ultimate success of our business, he won most of these battles. Eventually I came to realize that the most important element missing from my approach, and usually the source of our disagreements, was a plan, a clearly defined, formal and documented set of tasks and goals that would efficiently and successfully get me from start to finish. I came to realize it's hard to get to where you want to go unless you know how you're going to get there. So, against my nature and the ego I was trying to protect from admitting my partner was right, I learned how.

Business Processes, What They Are, and Why We Use Them

I've seen Business Processes defined in many ways. Here are some bullets I think collectively provide a good basis for a general understanding of what Business Processes are, how and why they are implemented and the value they provide to an organization.

Business Processes are:

• A set of procedures that coordinate the activities of a group of people.
  
• A group of business activities undertaken by an organization in pursuit of a common goal.
  
• A collection of related, structured activities-a chain of events-that produce a specific service or product for a particular customer or customers.
  
• The execution of a series of activities which leads to the achievement of a measurable business result.
  
• A prescribed sequence of work steps that is intended to be completed in order to produce a specific result.
  
• A group of logically related activities that use the resources of an organization to provide defined results in support of the organization's objectives.
  
• A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure, defining roles and responsibilities

For me, each of these similar but subtlety different collections of elements contributes to an overall definition of a Business Process. I've highlighted in Bold text the elements I think are most important.

Broken down to its base elements a process is a set of linked, logically related procedures. These procedures most be definable and documented. (More on the tools available to document your processes later.) They must flow in a logical sequence. They must clearly define the roles and responsibilities of the people using them. The goals and objectives of a process must be clearly defined and achievable. And ultimately the results must be measurable.

I'm sure these concepts for the most part need very little explanation. They seem to be pretty self-evident. Therefore, I won't devote time on an academic exploration of these concepts. My objective for this article is to break this down and highlight what I feel are the most important elements to focus on from an IT services perspective. I want to make this discussion meaningful for you and to give you practical examples and advise regarding how to successfully develop and implement Business Processes in your environment. If you would like to explore these concepts from more of an academic, foundational standpoint, here are some resources you'll find helpful.

Google Answers: Definitions of Business Processes on The Web

http://www.google .com/search?hl=en&lr=&oi=defmore&q=define:business+process

The Open Source Business Process Management Ontology

http://www.jenzundpartner.de/ Resources/RE_OSSOnt/re_ossont.htm

Business Process Management Initiative

http://www.bpmi.org/>

Business Process Trends

http://www.bptrends.com/

The Project Management Institute

http://www.pmi.org/info/default.asp

Documenting Business Processes

Business Processes are of no use unless they're documented. A documented process is nothing more than a road map, a complex one yes, but a road map nevertheless. The unique road map used in documenting a process is called a Flowchart. Creating a Flowchart allows you to break down any process into individual events and activities, to display these in simple, graphic form and show the logical relationships between them. Constructing Flowcharts promotes better understanding of a process. You're forced to sit down and analyze each activity and event, think through what happens at each step in your process, and clarify the relationships between each event and its linked activities. I've found that when the process is going to be used by multiple people, each representing a different function or activity in the process, making this a team activity is particularly helpful. Having representatives from each function clarifies activities, improves group knowledge and understanding, builds team spirit and relationships and gives each member of the team a vested interest in the success of the process. If there's a bar near the office, all the better! We had a combination pool hall/brew pub near DARPA that we referred to as Conference Room 7. Whenever the subject of documenting our processes arose someone would invariably say, 'Hey, how about holding this meeting in Conference Room 7!".

There are very specialized tools, generally referred to as diagramming applications that allow for the creation of Flowcharts. The most popular, and from my experience the most powerful tool for performing this function is MS Visio.

MS Visio

http://www.microsoft.com/office/visio/

In addition to creating Flowcharts, Visio can be used to create Org Charts , Network diagrams and even contains am XML standard for the creation of web graphics. Visio is not available for the Mac. A quick Google search for "Macintosh flowchart tools" found:

ConceptDrawV

http://www.csodessa.com/ - Claims support of OS X

TeamFlow

http://www.teamflow.com/ - Claims support of OS X

I don't have any experience with either of these products, so I can't recommend them to you. I will contact the vendors and see if they would like to participate in a product review with MacTech. If we are successful, be looking for these reviews in upcoming issues.

Also be aware that the symbols and graphic elements that comprise a Flowchart is a language all its own. Mastering this language is essential for building good quality documented processes. If you are new to this arcane world I suggest you find yourself some good books or, better yet, some training resources where you can learn and master this unique set of skills and knowledge.

Case Study

In a previous occupational incarnation I was Director of IT Operations at DARPA, the Defense Advanced Research Projects Agency. DARPA is a truly amazing place. Besides really being the place where the Internet was invented (Sorry Al!) it has the highest number pf PhDs of any government agency, over 500. To say this is a very demanding group of IT users would be akin to calling Shaq tall. I guess I'll never forget the day I sat in a program director's office working out a plane to give him high-speed Internet access while he was sailing around the Chesapeake Bay on his 25-foot schooner. Not the kind of issue IT managers are confronted with during their typical workday. The mission statement given to me by the Director of DARPA, who BTW reports directly to the Secretary of Defense, was "Give our users whatever they want, as often as they want it, for as long as the want it, and give it to them as soon as they want it. Actually, before they know they want it would be best." We stared testing prospective analyst's psychic abilities as part of our interview screening process.

My job was to manage the approximately 100 good people who had the responsibility for keeping the DARPA classified and unclassified networks 100% secure, pretty much 100% operational, and technically very current. Like most mature IT service organizations, to successfully achieve these big picture objectives, we employed many different Business Processes that comprised our IT Service Management Plan. Examples of these processes include:

The Service/Help Desk Process - The process that's responsible for the end-user interface function in service delivery

Incident & Problem Management - The processes for the prevention and resolution of IT related business disruptions

Service Level Management - the process that negotiates the services to be delivered and the corresponding service levels for these services. This process also ensures all agreed upon services and service levels are met and measures the organizations success in its performance against prescribed service levels.

Release Management - the process responsible for the management of software development, installation and support of an organization's software products

The DARPA scientists fervently believed if they did not have the latest and greatest versions of their desktop hardware and software the success of their projects would be significantly impacted. It was not my job to question the validity of this position, but to ensure the success of the projects we undertook to give them what they wanted.

The desktop environment consisted of approximately 2,000 Windows fixed and portable workstations, (government-speak for desktops and laptops) and about 50 or so Macs. As an aside, at some point prior to my tenure at DARPA, the environment was the reverse, with Macs comprising the large percentage of machines on the network. There was many a time when one of the support analysts would come to me for help troubleshooting a particularly difficult Windows issue when I found myself longing for the good old days when Macs were king at DARPA and my Mac knowledge would have made me top dog rather than largely worthless in a situation like this. Anyway, we were continually refreshing (industry buzz word for upgrading) some aspect of the technology, hardware and/or software. This effort was so continuous we had members of our staff that did nothing but work on these projects.

When I arrived at DARPA amongst the staff I inherited were two tier-one support analysts and one senior engineer who supported our Mac users. The tier-one guys weren't really Mac people, but Windows analysts who had been sent to Apple support training to give them some basis for supporting the Mac users. The senior Mac engineer was perhaps the best Mac support person I have ever met, (and who, BTW, will be a future contributor to MacTech!). As a result of the low number of Mac users on our network and corresponding support issues, during a cutback in staff I was forced to loose both of our tier-one Mac analysts. A newly earned dual citizenship and the resulting security clearance issue caused the sudden departure of our senior Mac engineer. You might find it interesting, (I know I did), that apparently there are only two organizations within the DOD that can make a unilateral decision to revoke someone's security clearance without a hearing or any other type of legal due process, and these are the Secretary of Defense's office and DARPA. This should give you some idea of how serious the network access and security issues were.

Our Mac users were largely career DARPA research scientists who, when told by a previous Director of IRD (Information Resource Division, again, government-speak for IT) they would be forced to give up their Macs and use Windows, had fought the good fight, and in protest, had ultimately gone to the Director of the agency in their successful effort to keep their Macs. They were passionate Mac users, and some of them were fairly knowledgeable. Working to support them was one of the highlights of the time I spent at DARPA.

During the time I was at DARPA we undertook projects to upgrade our Mac users from G3 PowerBooks and desktops running OS 9.x to a combination of 15" G4 Titanium laptops and 933Mhz G4 "QuickSilver" desktops running first, OS X 10.1.x and OS 9.2.2, and ultimately OS X 10.2 and Classic. One particular problem I remember the very much second-class citizens our Mac users had was getting their machines backed-up. They had never been given a network back-up solution that would run in OS X. If they wanted their machines backed-up on the network, before they left work each day they had to remember to reboot their machines in OS 9 so the version of Retrospect they had would run. Of course with the back-up schedule we had they would need to remember to do this every night to have any chance at all of being backed-up.

The company I worked for was delivering services to DARPA on a "managed services" basis. The company owned all the assets on the network and provided the assets and the services to the government for a fixed price per seat. A seat was a CPU. The contract very clearly defined what would be delivered for this fixed cost and allowed for incremental charges when the government needed something that was outside the scope of services as defined in the agreement. I'm sure at least some of you are aware of a huge multi-billion dollar contract the Navy awarded to EDS several years ago called NMCI, Navy Marine Corps Intranet. This was the model for the DARPA contract.

The idea is for the government to buy IT capability in the same way it buys utility services like electricity. They plug something into a wall outlet and out comes what they need. The incentive for the vendor of services under this type of arrangement is to keep tight control on the configuration of a user's machine. The more "vanilla" a machine is the easier it is to support and maintain that machine. Typically the plan is to NOT give users local admin privileges. That way they can't install software or otherwise customize the configuration of their machines. This is the how the Navy does things under NMCI. This is not the way things were done at DARPA. Try telling a PhD research scientist they can't have admin privileges on their machine. The folks at DAPA had tried, and they had lost!

I mentioned earlier that DARPA scientists were sure they could not do their jobs without always having the latest and greatest version of their desktop technology. This was so important to them they had written it into the agreement that defined the services my company delivered. We were contractually obligated to deliver to the government the newest version of the OS, applications and hardware they were using within six months of its public release. Think about that. We had to test, build a load, and refresh over 2,000 machines every time Dell, IBM, Apple, Microsoft, etc. released a new version of what we were using. This included maintenance releases, patches, service packs, etc. Next to network security, this was perhaps the most difficult aspect of the job we had. It was a huge challenge to keep up with all the projects associated with this task, keeping our analysts trained and current on the new stuff. Most importantly and perhaps most difficult was our obligation to make sure, when we gave a user a new version of the OS or their hardware, what they got back was set-up and configured exactly like the machine we took from them when we began their refresh.

Believe me when I say we gave our users back a "new" machine that was configured EXACTLY as it had been before. I remember part of our process (more on this in a second) was to take screenshots of a user's desktop and position the icons for their files, aliases, etc. in the exact position they had been on their old machine. We had one user who stored everything on their desktop. They had over 400 file icons sitting on their desktop. I'll never forget the frustration of the analyst who sat for hours looking at the pictures of the old desktop, working to position each icon exactly where it had been previously. I took him out for beers that night. I think it helped; he came back the next day!

Let's use a Technology Refresh project I managed at DARPA as a case study for our exploration of Business Processes' role in a successful IT service management plan. The specific project we'll be looking at here is the project we undertook to migrate our Mac users from a dual-boot OS X 10.1.x/OS 9.2.2 configuration to a single-boot OS X 10.2.x/Classic set-up. Remember earlier I mentioned we had lost our entire Mac support staff at one point. The project had been delayed several times as a result. Our Mac users were grumbling loudly about their desire to have Jaguar and all the other benefits they knew they would receive from this project. Given the dearth of good Mac support resources in the market at that time, and our obligation to provide updates to the newest technology within six months of its release, we had no choice but to undertake this project with myself and a few well meaning Windows analysts who were pretty much completely ignorant to all things Mac.

Given the lack of Mac knowledge on the part of the analysts who would be assisting in the project, and my lack of desire to work 24/7 until I was able to complete the project myself, I knew we would have to rely on a well defined, well documented Business Process to ensure successful completion of the project. So in the midst of our full-time jobs of making sure DARPA's users were happy every minute of every day, we sat down and built a process that would ensure the objective of our project would be completed.

There are many critical elements that comprise a successful technology refresh project management plan. There's no way I can go into all of them in detail here. My intention here is to use this type of project as an example to illustrate the kinds of elements that need to be part of your business processes. If you're doing a technology refresh, great! Use my experience to hopefully contribute to the success of your project. If you're going to build business processes for some other activity, this should give you a good sample of the kinds of elements that should be part of your processes.

Work with senior management to establish the business goals and objectives for your project. You need to win management's buy-in for you project. Better yet, find a champion within the senior management team who will run political interference for you when necessary. Few complex projects are completed without a few unexpected developments (in the software world these are known as undocumented features). If management has made a prior commitment to support your project, you will pass over any bumps with much less difficulty.

Meet with you users as a group prior to beginning your project. Create a committee of users to represent the user base for your project. Hold meetings to discuss your project's goals and objectives with them. Ask them questions that will help you develop a service plan that takes their needs and interests into consideration. Users hate being without their machines. Find ways to minimize the disruption and inconvenience this project will inevitably cause. Use this opportunity to realistically set user's expectations regarding the project and its benefits as well as the disruptions it will cause. Tell users what to expect. Give them a basis to know how to judge your success. If you don't their criteria for judging your success will be unachievable no matter how well you plan or how hard you work.

Create a Pre-refresh checklist and meet individually with each user to fill it out. Go over your procedures with the user so that they know what to expect when you take their machine. If you need their machine for four hours to complete the refresh, tell them this. If they have a laptop and desktop machine arrange to do them one at a time. That will minimize the disruption your project will cause. Make sure your checklist has the following elements at the very least:

• The passwords for their local and network accounts.
• The path to the network share the use to store files.
• Their default printers.
• Their default browser and e-mail client.
• Any non-standard applications they use.
• The default directories they use to store their documents.

Set-up an on-line scheduling system and let users schedule the time and date for their refresh. Make sure the system sends them a confirming calendar item so the scheduled date gets on their calendar.

Make sure your process ensures that you plan for retaining their unique customized settings and user definable preferences. includes taking screenshots of key user areas like their desktop. Make sure you preserve their key personalized resources like their browser bookmarks and home page

Create a detailed, step, by step set of instructions for the analysts who will be performing your refresh. Take nothing for granted regarding what you think they know. Make the analysts use the instructions.

Thoroughly test your plan before going live with user's machines. Do many dry run- throughs on test machines and work out the bugs in your plan before you ever touch a user's machine.

Ensure your user's data is safe. This is paramount. The IT service version of the Hippocratic oath, (Do No Harm) is "Never Loss A Customer's Data". There is no sin you can commit greater than this. Don't rely on your regular backup plan to ensure their data. Assume they haven't been backed-up and you won't be sorry. Create an image of their machine before you begin the refresh. Then backup the image to a secure location.

Expect the unexpected. Plan for any eventuality you can imagine. Remember your goal must be to give the user their machine back set-up exactly they way it was when they gave it to you. I'll never forget the user who called up after we had returned their machine to complain they couldn't find any of their files. I went to the user's office and here's what I learned.

The user kept all their files at the root level of their hard drive. They had over 1,000 files stored there. They way they managed their work was they sorted this window by last modified date and kept their most current works in progress at the top of the list. Our process called for us to run Norton Utilities on all machines prior to imaging. The idea was if there were any damaged directories or the file structure was corrupted in some way, we would repair this first and then create an image without these problems. Well one of the repairs Norton does is fix any file creation or modified dates that fall outside a set of parameters. When Norton does this it changes the file dates to the moment it runs this fix. In this case all the users files at the root level of their drive had corrupted dates. When they got their machine back all file dates where now the date and time we ran Norton during the refresh. This was a very unhappy user.

If there are resources from multiple departments that will be working on your project, make sure you involve them in the development of your processes. For example, if you have a Business Apps group who is responsible for installing their apps on a machine you will be refreshing, make sure they are present when you detail this event on your process map or Flowchart. Make sure they have a schedule for the project and know when they must be available to perform their step in the process.

During your project's duration meet with users you have been completed. Ask them how it went. Your objective here is two fold: Good customer service requires follow-up. Close the loop and make sure your users are happy with the work your team did. This session will also allow you to determine if any aspects of your processes need to be refined or changed on the fly. If your users are reporting feedback that allows you to identify trends, use this information to quickly improve your processes so future participants in this project will experience more positive results.

Remember earlier we said that a business process must have a measurable result? Measure the results of your project by surveying your user's satisfaction with the project's outcome. Ask them to rate you on your performance against the project goals and objectives you communicated to them prior to beginning the project. Also ask them questions that will reveal the business value of the project. Did the project make them more productive? Do they find it easier to get their work done with the new technology they were given? Someone in your organization, probably the CIO or CFO, will love you for this. It's their job to measure the ROI (Return on Investment) for all IT related expenditures. A review of the anecdotal evidence you will gather from your survey will be very helpful in this effort.

Another benefit from your survey will be to use the user's feedback to conduct a lessons learned session with your team. Go over what worked as well as what didn't. What can you do better next time? What did your users tell you the feel was positive and negative. Take this data and make your next project better.

Finally, make sure you reward you team. They worked very hard no matter what the outcome. Acknowledge

Taking It To The Next Level

Recently I spent several months working with a very large government IT agency where I live in the Washington DC are. The focus of the work I did was to review, document, and where necessary, reengineer the agency's core business processes. The overall effort was to develop a coherent, consistent set of interrelated processes that, together, would form the agency's Enterprise Business Architecture. Prior to my arrival the agency had realized it needed to adopt a common set of standards or best practices to use as a framework for its efforts in this regard. My favorite anecdote regarding standards came from an Apple sponsored Enterprise Computing Conference I attended in Boston back in '92 or '93. A Gartner analyst began his talk on standards by saying, "The best thing about standards is there's so many to choose from". I really love that!

The agency looked and evaluated such models as ISO 9000, Six Sigma and CMMI. But it choose to standardize on ITIL, the IT Infrastructure Library. ITIL was originally developed in the UK as part of a government effort to establish a standard framework for IT service delivery that could be deployed across all government agencies. ITIL has become the most widely accepted formal approach to IT service management. The framework defines how service management is delivered within an organization. Given that it's a framework, ITIL is completely customizable to meet the needs of a given organization. It's a series of documents comprised of industry best practices for IT service delivery management.

During my time working for this agency I earned my ITIL Certification. For anyone who is serous about expanding their knowledge and formal understanding of IT service management, I highly recommend studying for the ITIL certification exam and gaining the ITIL certification.

If you'd like to learn more about ITIL, visit the home of ITIL and ITSM.

IT Service Management

http://www.itil-itsm-world.com/

There's a lot of great information on the site about ITIL including lots of information regarding implementing ITIL in your environment and also how to gain your certification.

I hope you found this article informative and valuable. I had a great time writing it and sharing these experiences with you!

The accomplishment David Sobsey is most proud of is being father to two incredible children, Zach and Alexa Rae. He makes his living doing something he really loves, working as the Editor of MacTech. David's background includes 20 years founding and growing businesses in the ITS services industry, and serving as a senior IT manager for a large government technology research organization. His passionate relationship with the Mac began in 1984 when his brother Joe showed him the pure magic of MacPaint. Please direct all comments/suggestions/ideas you have for David to: editor@mactech.com.