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
- A prescribed sequence of work steps that is intended to be completed in order to produce a
- 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
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
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
The Open Source Business Process Management Ontology
Business Process Management Initiative
Business Process Trends
The Project Management Institute
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.
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:
http://www.csodessa.com/ - Claims support of OS X
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.
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
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
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
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
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
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
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
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.
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
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
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: