Nigel Vickers asked...
Have any of us investigated, applied or constructed patterns to build
solutions? as a way of housing knowledge?
Good question Nigel. I'll get to it in a second but I haven't replied to
a message on this list in so long I'd like to briefly reintroduce myself
for those wondering who the heck I am.
My background is in chemical and petroleum engineering; more specifically,
lately, as a project manager involved in drilling wells. I now work with
a company who specializes in organizational learning in the oil business,
OGCI Management. I have been working as a consultant with BP Exploration
for the last few years specifically on a project related to the topic you
are asking about.
Every well is different. The above ground conditions, subsurface
conditions, equipment used, personnel involved - some of this is the same
from well to well but not all of it. Therefore each project is different
and typically people fail to see any pattern involved. However, the
process, or pattern if you like, of preparing to drill - involving design
calculations, preparing the team, getting equipment prepared; actual
drilling operations; and post analyzing the performance, there is a
general "pattern" to this, of which, if you map it, about an 80/20
solution will become noticeable. 80/20 meaning, if your careful about how
you map the processes involved, you can end up with about 80 percent
useful process tasks to carry forward to an entirely different area.
There are assumptions involved with this, the main one being that the
processes are carried forward within the same company.
A major problem in the oil business, particularly right now, is that
people move on after projects. What happens, which many people can relate
to, is that the previous personnel learn things which make their lives
easier on successive projects. When they leave that information goes with
them, and isn't retained by the group or team. They're not around for the
successive projects, and if you can find them, they usually are just as
busy as you are working on their own projects and therefore don't have
time to help very much on yours. The team suffers.
When working on development projects in a particular field, and this
applies to exploration projects as well, the wells will not be the same,
but they will be similar in nature. Also, when working in different areas
of the world, the wells will be different, but most of the engineering
work performed does have a similar process to arrive at results.
Therefore, there are many repeatable "patterns" that a team could map, and
slowly develop and mature so that as individuals joined a team, they could
get up to speed quicker; and other teams working on similar projects could
share processes that they found successful so that teams aren't
reinventing the wheel for a problem solved, sometimes, even months ago by
another team somewhere else in the world but within the same company.
The team I work with in BP was charged to develop, and did, tools and
methods for capturing and sharing the common processes that teams develop
with other teams as they became available. The whole goal is
"organizational" learning. We have developed a common protocol, that each
site has implemented, for mapping processes related to drilling wells,
managing those processes through project post analysis / continuous
improvement by the teams so that the "best" processes are carried forward
and are always "live", and a way to share these processes with any team in
BP who wishes to use them.
The results are that the teams using the tools improve their performance
and have a documented trail of how, and more importantly why, the plans
have changed from project to project; the learning is retained by the
teams so that as new personnel come on board they get up to speed quicker;
and other teams trying a new area most likely have a base from which to
start based on similar operations somewhere else which was better than
starting with nothing.
Stating the problem and outlining our method of attack is one thing, and
this post has turned into a book. Getting the teams to implement this and
the ongoing issues involved would be a four part series. Hope this was
worth reading and that it helps.
C. Dwight Alworth
OGCI Management, Inc.
*E-mail: AlwortCD@BP.com or DAlworth@OGCI.com
--Dwight Alworth <dalworth@compuserve.com>
Learning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>