| |
| The ExoBlog is maintained by John T. Stough... read the profile here: |
 |
| Mr. Stough is a member of (ISC)2 as a Certified Information Systems Security Professional: |
2_Member_Content/Member_Resources/CISSP_logo.jpg) |
|
[Hint: click the arrow beside a blog to see sub-categories]
|
Operational Effectiveness
Location: Blogs ExoBlog (by John)Strategic Thinking |
 |
| Posted by: exocubic |
3/15/2008 7:27 PM |
OverviewProjects are started for various reasons, including
the favorite "pet projects." This article series focuses on what it
really takes to ensure that the project accomplishes something -
Operational Effectiveness! Granted, the total scope of an effective
operation is more than just the sum of the organization's projects, but
we have to start somewhere and build to the end result. By the way,
the term "we" in the article is not assuming an actual project or
consulting task, it just generalizes everything. The first part of the
series deals with getting the target clearly in sight and understanding
the terms that apply to hitting the target. Once we reach the end, we
hope to have set clear guidelines on determining if a particular
project is support our overall operational effectiveness. Let's get
started!
The GoalThe purpose of any project we
undertake, whether it is building a website or launching a satellite,
should have a driving goal (perhaps several). Our goals should be the
target we aim at, but far to often we get derailed by looking at
Activities, Processes, or Tools that we need to achieve these goals and
miss the mark. Aiming at Tools first is one of the worst (and most
common) mistakes we can make! Our ultimate goal is Operational
Effectiveness - in whatever we do we hope to make it effective, driving
towards excellence! We will talk more about setting goals later, but
it is important to start with the fact that goals exist (wheter we
acknowledge them or not) and that they may or may not be tied to our
overall operations. Ask these critical questions, "How does the Goal
support our":
- Vision - how does this goal tie to the ultimate big-picture?
- Funding and Revenue - how does this goal support the bottom line?
- Participation of Key Groups - how does this goal support our team (including Customers!)?
- Metrics - how will you measure success(You cannot improve what you cannot measure!)?
The ActivitiesThe
Activities are the things we actually do (besides sitting around
dreaming up goals). Activities bring results (both good and bad). We
live and die by the work we perform, not by the dreams we dream - and
at the end of the day results are all that really matter. Activities
include something as simple as "empty the trash" to as critical as
"backup and restore the database" or as complex as "design a new
system"! Activities can be one-time, once in a while, or recurring.
What you invest in solving the problem at hand is partly a reflection
of this balance between importance and commonality. Something you do
all the time is very expensive (over time) and a little optimization
can go a long way in reducing the cost. Likewise, any critical large
task needs to be carefully planned. Some things (like empty the trash)
just need to be done and out of the way! When looking at the
activities, we begin to have a picture of how to build technology that
supports our business - but keep in mind, if we focus on the activities
without a driving goal, we can fix the wrong things! Critical analysis
for any activity includes the following:
- Repeatability
- Continuity
- Sustainability
- Adaptability
- Communication
The ProcessesProcesses
are those activities which have a high need for repeatability; the
other aspects of task analysis are important, but if it is not
repeatable then a process is only important if the task is truly
critical - like sending someone to the moon! Restated, tasks become
processes when they must be highly repeatable and consistent or when
they are critical in some significant way. Processes are very
important, even if only simple, for the tasks that make our
organization run correctly. The process paradigm has been greatly
abused by the pure-process folks; if we make "process improvement" the
goal, in and of itself, instead of making process improvement a means
towards excellence in the real goals, we will cripple our performance
instead of increasing it! However, the other extreme is no better - a
lack of process is properly called chaos! Activities may be correct
each time we do them, but only because the process is in the mind of
the person performing the action; switch them with a rookie and
disaster is bound to strike! So whether formal or informal, processes
must be evaluated in order to achieve our goals.
- Are the processes supporting the right outcome?
- Is there a "natural process", one that should come out if 100 people performed the same task in complete isolation?
- Can you measure the result?
- Is the process a prime candidate for improvement before moving on?
- Does
the process need to be formal, or can it be passed on informally and
still be effective (a great example of this is answering the phone
& logging the call).
- Does the team buy-in to the process (or does it suck)?
- Are
there new ideas which have not been included - is the process truly a
reflection of the adaptability required by the activity it supports?
The ToolsTools
should be the last thing we think about when we are building
technology. You can clearly see the rub here with most technology
companies and the way they promote their products. In most marketing
the TOOL is the SOLUTION. WRONG! Not just a little wrong, but w-a-y off
the mark. Our target should be a set of goals, then the activities
required to support those goals, then the processes that support those
activities, then the tools that support those processes. Instead we
re-write our processes to support the new tools. Until the tools get
upgraded, however, and we have to scrap our processes and start over.
I think the expression is something like "the tail wagging the dog."
Tools are great and very often (if you go about it correctly) the
results of building processes that are common in any given industry can
be simple when using a tool that supports such a common process (for
instance, setting up email accounts) - the tool itself can actually
improve some things. But if we loose sight of the goal, then even the
best tools end up driving the whole show and we begin to drift off.
Cost overruns. Late projects. Poor requirements. Team strife. They
all result from this myopic near-sighted view that the tool is really
the solution. But solutions are about problems (or, if you prefer,
objectives) and unless we have properly analyzed the problem, how can
you select or build the right tools? |
|
| Permalink |
Trackback |
 |
|
From time to time, we all have random thoughts... sometimes they are profound, sometimes they are not, but if they are worth keeping then they are worth recording. This blog is used to record the thoughts on what it means the think creatively, solve problems, and improve processes. You have to be a registered user of the site in order to comment; help us maintain the integrity of the site and comments posted on it. We would love to hear your feedback, so please take a moment to register.
|
|
|