Transition Management: Integrating Data to Create Knowledge

In my previous post, I discussed how knowledge management was an important aspect of transition management.  I discussed the use of content management systems to help organize documentation to make it easier for the next person in a position to learn from the person who just vacated the position.  This is especially important when the person who left is no longer available to transfer his knowledge to the new person.

But having documentation available really doesn’t solve many transition management issues.  Effective transition management requires knowledge and documentation is really only information.  Various points of information must be integrated to become knowledge.

A case in point is a Visio diagram.  These diagrams are useful for visualizing a process or a system implementation.  They lack depth of information about the things they depict.  That information is likely found in a separate document, spreadsheet, or presentation.  Unfortunately, a decision-maker must have possession and understanding of both documents in order to move forward.  That can be a challenge even when a content management system is employed because it is possible that each document was stored without relating it to the other making their association next to impossible to discern.

I know there are applications that are designed to bridge this gap.  They started out as computer-aided systems engineering (CASE) tools and have evolved into enterprise architecture (EA) suites.   I think these tools are generally directed toward IT professionals for building computer systems.  I don’t think these tools are  generalized enough to address a larger topic like transition management.

Effective transition management requires knowledge,  complete understanding actually, about the current state and the future state.  When transitioning people, the future state can be as simple as the current state operation with new people operating it.  Transition management would employ gap analysis to create a plan for getting the new people up to speed.  When transitioning processes, the transition management plan would be to create a gap analysis of what needs to be done and when to move from the old process flow to the new one.  This would include process initiations, process retirements, and training.

Transition Management: Managing Knowledge

Knowledge is defined in the Free Dictionary as the sum or range of what has been perceived, discovered, or learned.  I really like this definition because it speaks to the importance of both strategy (forward thinking) and experience (recollection).

The field of “knowledge management” was really big about 10-15 years ago.  This wave of technology in search of a problem introduced words like “taxonomy”, “collaboration”, and “codification” to the IT lexicon.  Companies rose and fell based on ideas such as whether an enterprise really needed to get two “experts” within its far-flung employment to talk to each other and how they found each other.

The point of managing knowledge in order to manage transition is to make documentation about what an enterprise does and why and where it wants to go and how available to the people who need it. This documentation is not a single book, it’s a library of books and those books aren’t just written prose.  They’re narratives, manuals, pictures, diagrams, and presentations.  Most enterprises have these things.  The problem is that they’re not organized and not readily available.  These artifacts are strewn all over each enterprise’s network as unstructured documents in shared and unshared folders.  A third problem is that they aren’t integrated.

Many enterprises overcome the organization and availability issues through the use of a content management system (CMS). This allows the employees who follow those transitioning of other responsibilities to more easily learn the nuances of their new responsibilities because the knowledge of the previous workers is made available to them.  This is of course dependent of whether the previous person documented appropriately and placed his documentation in the CMS with the proper indexes and key words.

But content management systems don’t force this knowledge to be integrated in a meaningful way.  It is up to the new employee to determine what he needs to know at a given period and why he needs to know it.  Integration of an enterprise’s knowledge is also important for the the other part of transition management – changing what we do.  I’ll write about this topic next time.

Risk Management: Getting Back on Track

Once the enterprise has identified a risk that can be mitigated, it becomes time to fix the problem. This should be a very disciplined activity because it was a lack of discipline the got you where you are in the first place.

I think mitigation must be approached on three fronts.

  • You must know exactly what you’re doing now
  • You must know exactly what you should be doing
  • You must utilize “gap analysis” to get from what you’re doing now to what you should be doing

I have posted essays previously that describe all three of these activities. I won’t restate those thoughts here other than to reiterate my belief that the “gap analysis” approach offers the lowest risk strategy for attaining a successful remediation. Gap analysis keeps the remediation team focused on the essential repair and keeps them from wandering off to “fix” other things that may or may not be wrong.

Remember, there are two aspects of “gap analysis”. The aspect that is easy to grasp is that the gap should be filled by creating something new to satisfy a deficiency. The more subtle aspect is that something should be removed. For example, the work-around for a process requires that workers be given access to data for which they would otherwise have no need. The access is restricted because regulators require special handling of that data. The gap analysis should be focused on two ideas: redesigning the process to eliminate the need to grant access to the data or reinforcing the data security measures governing the process. The resulting candidate solutions would need to be subjected to a cost-benefit analysis to determine the correct course of action.

Risk Management: Finding Risky Behavior

Risk is the possibility of suffering harm or loss.  The definition in the Free Dictionary also references danger.  Harm or loss for most enterprises either comes from opportunity lost or regulatory sanction.  Either way, the situation is bad for the enterprise.

Some risks can be eliminated but most can only be mitigated by exploiting your advantages and shielding your deficiencies.  This is the essence of risk management.

I think the easiest way for an enterprise to mitigate risk is to know what it is supposed to do and then do it.  In order to understand what it is supposed to do, an enterprise must completely understand its entire set of requirements and then implement processes that satisfy those requirements.  This is not something that just happens.  It must be planned, executed, and implemented.  It must then be constantly evaluated as requirements change.

Another opportunity for risk can be found in those processes between what we do and what we’re supposed to do.  Most exception processes are ad hoc and not well designed. They arise from a crisis situation where workers have a very specific problem to solve and so they solve it.  The problem is that they don’t have or take the time to evaluate their solution against the enterprise’s entire set of requirements.  This opens the possibilities that the new process allows people to do things they shouldn’t or doesn’t make them do things they should. Both of these are risky situations.

So, the first part of managing risk is to identify those processes where the enterprise is not doing what it is supposed to be doing.  This requires that the enterprise evaluate everything it does against its entire set of requirements.  I’ll discuss remediation next time.

Requirements: Types, Levels, and Focus

The Free Dictionary defines requirement as something demanded or imposed as an obligation. An enterprise is required by its customers to keep its products or services available or else they will go elsewhere to meet their needs. Regulators demand that enterprises conduct themselves in certain ways or else they will sanction them in prescribed ways. Management requires the employees to perform certain functions in prescribed ways or else they might face disciplinary action. Requirements come from every direction.

Most Architects are familiar with the requirements because requirements are necessary to define the functionality of the systems they build. I call these local requirements because they are requirements for the specific system being designed.  Local requirements are easy to gather and easy to track because they are a significant deliverable to the project at hand.  The Project Sponsor will want all of his requirements met.

There is another set of requirements that are generally lost in the euphoria of the project process.  I call these enterprise requirements because they are important to the overall enterprise.  Unfortunately, they can actually serve to make the current project more difficult and more expensive.  It is important to note that often times, enterprise requirements become refined into local requirements and that’s a good thing.

Requirements can be subtle or deliberate. All requirements are deliberately set forth by some constituency but they can be delivered very subtly. Local requirements are certainly deliberately set forth and delivered.  They are the wants and needs of the person paying for the project.  Enterprise requirements may not be so important to the Project Sponsor so they become more subtle.

Casting these concepts back into terms we have used previously: local requirements are generally about what we do (or want to do) and enterprise requirements are about what we’re supposed to do.  Unless an enterprise has a mechanism for tracking those enterprise requirements, they can quickly fall out of focus to the people charged with implementing them.

Expanding on the Definition of Business-driven Enterprise Architecture

In a previous post, I described what I consider to be a fresh look at Enterprise Architecture. I offered the somewhat concise, but terse, equation:

Business-driven Enterprise Architecture = Requirements Satisfaction + (Risk Management + Transition Management)

I am going to spend the next several posts expanding on each of the concepts in the equation. My purpose is to demonstrate my premise that EA is a management rather than a technology function and therefore should be business-driven. I also want to reinforce the need for a true methodology rather than just a framework.

My next post will focus on Requirements Satisfaction.I’m going to define various levels of requirements and how they are discerned and then used in the BDEA methodology.

The subsequent post will focus on Risk Management. Enterprise Risk Management is the purview of Business Leadership. A disciplined BDEA program can bring much insight to Business Leaders as to what they really should be concerned about.

The final post will look into Transition Management. As the Enterprise moves forward in time, it will experience many and varied opportunities to change. Again, a disciplined BDEA program will give Business Leaders the information they need to move the Enterprise along.

You Don’t Need to Develop an Enterprise Architecture

If you work for an existing enterprise that has processes and systems in place, you don’t need to create an enterprise architecture. You need to understand the one you already have.

The primary reason Enterprise Architecture programs fail is because the Architects are focused on something other than the reality of the business today.  Business Leaders are fine with strategic planning but they are more interested in running the business day-to-day so they can survive to the future.  Many Architects appear to want to create a “big bang” project to introduce a new future state.  Business Leaders understand there is less risk in morphing a business from its current state to a future state.

An Enterprise Architecture plan certainly is concerned with moving the enterprise to a future state. But in order to be successful, it is equally important to completely understand the enterprise’s current state.  Think of the plan as a roadmap to the future.  Think of your understanding of the current state as being the sign post – “You Are Here”.

Business-driven EA Governance and Accountability

I suggested in an earlier post that enterprise architecture should be considered a business, not a technology, initiative. I use the term business-driven enterprise architecture to reinforce that notion.  That also suggests that regardless of who the Business Leaders choose to execute a business-driven enterprise architecture program, it is they who provide governance and accountability for its success.

I generally see the governance process executed as a steering committee of higher-level executives who meet at set intervals with a project group to settle disagreements, make decisions, and approve expenditures for going forward.  The problem with this is that the members of the governance board are generally not familiar enough with the workings of the project to really make informed decisions.

I generally see the accountability process executed even more poorly.  Usually, the person who is accountable for getting the project completed is the Project Manager who is not empowered enough to cut through the other things that tug on his resources, time, and budget.  She must report to the governance committee why the project might be lagging and only receives platitudes in return.

One approach to solving this problem is the assignment of a project sponsor who is a high-level executive who “helps” the accountable project manager get things done.  The success of this approach is determined by the level of engagement by the sponsor in the project.

The business-driven approach would have the project sponsor be a member of the governance board and be the person accountable to the board for the completion of the project.  All project managers report to the project sponsor and are accountable to him.  It is the project sponsor who works with his peers to manage the things that get in the way of completing the project.

Sometimes You Pay the Fine

No project should ever be considered without considering the cost of not doing it at all. This goes for both technical and non-technical projects.

I worked in the financial services industry for many years. Every few years I was approached by semi-hysterical business leaders who wanted to sponsor quick-and-dirty projects to satisfy some regulatory mandate. The only information they could supply was that it was a mandate and there could be fines for non-compliance.

When vetting any project, it is necessary to understand the cost and benefit of every option for satisfying the need. Quick-and-dirty is always an attempt to brush over the lack of benefit by assuming that the cost is absurdly low. While that may be true in the short run, it’s rarely true in the long run when all of the facets that were missed come to the surface as unexpected consequences of the quick-and-dirty implementation. In other words, it’s a lot dirtier than first imagined. Quick-and-dirty is never a good idea and never as cheap as first proposed.

The one option that is often overlooked is the option to do nothing. Since most mandates to organizations carry civil rather than criminal penalties, no one is going to go to jail over non-compliance. When the fine for non-compliance is low or even undefined, sometimes the correct course of action is to pay the fine when levied and invest in projects with higher payback. It is vitally important to understand the deficiency in the enterprise architecture and to constantly evaluate whether changes in the regulatory environment dictate reconsideration of the enterprise’s lack of action.

Software Rots!

Most enterprises are sitting on a ticking time bomb and the Business Leaders either don’t know it or are not allowing their IT staffs to do anything about it.  This is the risk of major computing systems that run the business every day stopping because some change was introduced into the environment usually to address some unrelated issue.  For example, it happens every month when Microsoft releases its latest Windows patch set.  But Microsoft is not the only culprit.

I once worked with a manager who told me, “Software rots!”  (Parke, I’m giving you credit here in case you ever read this post.)  Parke’s epithet was generally a retort to someone who had a piece of code that suddenly stopped working for no apparent reason.  He knew that something had changed, it was up to the programmer to figure out what it was and why it broke his code.  Even then, as in today’s computing environments, there were so many incremental changes happening at various levels in the computing environment that there was always some cause for every effect and hence, a reason for every failure.

I call this software atrophy.  Atrophy is actually a term in biology.  Wikipedia defines atrophy as the partial or complete wasting away of a part of the body.  A major cause of atrophy in muscles is lack of use or lack of exercise.  I apply this to software when the technology employed in a system is not kept up-to-date.  This can cause it to become incompatible in an ever-changing computing environment.  The risk is that Microsoft or some other vendor of software tools and operating systems will patch their product to fix a problem and simultaneously break a function in an enterprise’s production system that is critical to their operations.  It happens all the time.

The proliferation of software development tools aimed at end users is largely responsible for this situation.  The number of user-developed systems that have become mission-critical in day-to-day operations is astounding.  Often, the authors of these systems have moved on from the organization and the current users only know how to use the system, not how to care for it.  When it breaks, it becomes a production problem whether the IT department knows about the system or not.

End users are not the only source of this risk.  IT departments have similar issues particularly with one-off systems they wrote to solve some operational need that could not be addressed at the time in the enterprise systems.  Unless these systems have been maintained to keep their underlying technologies up-to-date, the dooms-day scenario is one month away when the next patch set comes out.  Typically, the IT staff who developed these systems have moved on leaving the each of their systems without someone who cares for them.  The more systems that used the affected old technology, the more carnage that last patch will cause.

It is well within an Enterprise Architecture strategy to identify and manage this type of risk.  It’s not sexy, but it is vitally important.  It is in fact a foundational activity for establishing an Enterprise Architecture program that yields high benefits in the short-term.  Producing a risk analysis of the probability for a dooms-day scenario after a vendor patch set has been applied is a major component of the value proposition for an EA program.  This is what Business Leaders want, so it’s a great way to get established.