Insights: Meetings

Occasionally I have the luxury of sitting back and watching project meetings as an FYI attendee rather than a active participant.  During a recent meeting that was to set context for a direction change and gain buy-in from stakeholders I watched as the two meeting leads followed a careful script crafted the previous day gradually spun off track.  These were two seasoned professionals with more than a few years experience.  People I highly respect. So what happened?

Like so many other group meetings, both the pre-meeting developing the script for the buy-in meeting and the buy-in meeting,  understanding the roles at the table and there agendas was not prime on the mines of the participants.  Often in meetings I find we –and I’ll include myself in this pattern– are more interested in our own specific agenda than achievement of the overall goal of the team or scoring points in intellectual arguments on detail procedures rather than outcomes.  While the pre-meeting had established its goal of gaining buy-in from the stakeholders the approach to gaining such was less thought out.  The team spent time creating a logical agenda to present what and why we were going to do differently.  This was done optimistically or blindly in the believed if the logic was correct we’d get buy-in.  While we got some agreement, the buy-in meeting slowly drifted away as stakeholders 1) raised issues that were not covered in the presentation but were of importance to them and 2) had a different understanding of terms, concepts, methods and how these are combined for results.  Even the outcomes expected generated controversy.  The goals of each stakeholders were different than the goals of the project or rather achievement of these stakeholder goals were not necessarily supportive of the overall goal of the project.  That is not to say these goals were counter to achievement of the project, but these needed to be aligned in context of the overall project.

Which brings me back to the corrective action we should have taken during the pre-meeting.  Years ago I brought to the attention of my management an article in Sloan Management Review : A Framework for Managing IT-Enabled Change,  Summer 1993 July 15, 1993 Robert I. Benjamin and Eliot Levinson.   I was promptly told to bury the article, we don’t do that here in this company.  Such effort would be seen as manipulation rather than good leadership practices.

In that article they had an approach towards visually planning gaining stakeholder buy-in which would have served us well.  However, while some progress in language regarding gaining stakeholder buy-in has improved in the IT profession, considered focus and concern in that direction are still merely a follow the numbers activity.  Would the meeting have been different, more productive, and gained agreement -no commitment- faster had we used this approach.  I don’t know for sure.  I expect it would as it had worked for me very well at other companies, but I would have like to have seen it tried.

The other insight gained from the meeting was really a reminder that terms and concepts are not always understood by everyone in the same manner  These are influenced by the context and role people play within a particular situation. This is especially true in the business process domain which is very abstract and often leans itself to multiple interpretations to terms, many times drifting off as a new label to old ways of doing business rather than the new approach it was suppose to be.

 

Advertisements

Structure in Threes: Management Systems

For the record I’m typically for performance based compensation systems.  Maybe because I think you should be focused to perform your role for the best of the company to start with.  I see approaches such as stack ranking, top grading, etc. as creating a cascading effect that has employees and management “game” the system.  The end result is a death spiral where people spend more time looking good than doing good at the expense of the customer and investors.  After reading chapter eight of Rummler’s book reDiscovering Value, I see why and where these systems have gone wrong; basically measuring and rewarding the wrong behavior (local optimization) rather than doing the best to create value across the enterprise.

I’m finding a lot to like about Rummler’s approach towards creating a management system that works:

  • First reengineer the processes cross functionally to enable real value creation
  • Second design a dual management system that focuses on the value creation performance and then resource performance
  • Third design the compensation system weighted towards value creation system performance as top priority

I can see this approach keeping in check the desire to optimize resources in deference to creating value which is what keeps a business in business.

BPR/M: Tools and Techniques

Hate to start out discussing tools regarding BPR/M right off the bat.  However, it looks like I’ll need to find some of my old BPR/M applications for this latest project.  While the client‘s repository can scale to a large size, the configuration management and analysis tools leave a lot to be desired.  Something to be said about building your own tools for the job you’re doing.  The MS Access Process DB application I’d build years ago and continually modify looks like will have yet another year or two of life.  The last modification was to add ITIL packaging enabling me to box up processes for my FEDE client’s Shared Services organization.

This latest engagement looks to be a reduced set of the same issues, without the built in organizational resistance.  With this engagement the internal clients already are looking for a service.  What’s missing is a solid methodology to move from IT Product Delivery to a Service Delivery paradigm.  I’ll box up all the pieces into a Service Level Package (SLP) this week to demonstrate the concept.  This may help the IT organization’s client’s to visualize what is to be delivered and how the pieces fit to accomplish the results they would like.  I’ll see this afternoon whether I’ll get buy-in from the project team.  Either way I expect to build the SLP to make it easier to create a comprehensive solution.

Structure in Threes: Process Notation

Spent past several days deep into research on various process documentation methods.  Specifically comparing IDEF0, Rummler-Brache and BPMN.  I’m still an IDEF0 fan due to its simplicity.  In about ten minutes you can describe a process to a business owner while other methods require a little more instruction and in some cases a significant about of understanding for the rules of construct usage and meaning.  BPMN while easier to understand than UML for line of business management still has a level of complexity that requires interpretation for most.  Thus when using BPMN its often best to do Collaboration and Choreography diagrams at higher levels when presenting to LOB Management.

BPMN however comes into is own when looking at documenting orchestration of processes with more detail.  The advantage of using BMPN at this level is it can be targeted toward translation to UML or automation in workflow systems.  The gap I see in most of these methods though is adequate mechanisms to express business rules clearly and concisely.  Typically one has to use an external method to document business rules which means having LOB management having to learn two methods to visualize the processes they use or are modifying for implementation or augmentation using information technology

Structure in Threes: Process Value

About two decades ago I was fortunate enough to collaborate with several brilliant people in IBM working in manufacturing research.  One of them Dr. Arno Schmachpfeffer had coauthored a paper in the IBM Journal of Research call Integrated Manufacturing Modeling System.   One of the key aspects of the paper was a taxonomy of activities in a process.  I was struck by the simplicity of the taxonomy and the ability for it to catalog any process activity into one of four categories: Rest, Move, Make, and Verify.  After working with this taxonomy for a while using it to catalog activities I had previously created in IDEF0 for various BPR engagements I came up with several simple insights:

  1. Most business ventures derive their value through the execution of one of these activities. Example, a Product development firm creates most of its value through the make activity, a Consulting firm typically from verify activities and an Airline from move activities
  2. Extending that insight further one can determine the efficiency of a process by inventorying, classifying and analyzing the rations of the activities in the processes these firms use to create their value.  Thus comparing the ratio of the firm’s primary value creating activity to the quantity of other activities provides one the BPR equivalent to a Asset Efficiency Ratio in Finance

Throughout the years –as a personal research project– I had been inventorying, cataloging and analyzing processes I have been reengineering.  This past few months as I started to look into valuation of services and processes, the question has come up often.  How does one create a valuation for a process.  Initially I was looking for a hard formula based upon standard accounting practices.  However, after considerable applications of such concepts as Activity Based Costing (ABC) I came to the conclusion that the formula may be standardize but the actual value of the parameters would change.  That is one could use the ration of primary value add activities to non-value add activates to determine the allocation of value applied to each process.

While this is a simplistic approach it enables the Process Analyst and the Portfolio Manager to work together to determine the value of services through a hierarchy without having to get too detailed in data collection.  The next aspect of using this relative allocation approach is to add adjustments for non-value add activities that are required or mandated (e.g., safety and regulation compliance).  However a case can be made for calling such activities value add as they enable a firm to fulfill its mission and requirements.  Thus compliance and safety activities are feature requirements of a product or service and without meeting such do not perform as required.

This month’s agenda is to merge my activity ratio spreadsheet with the value portion of the IT Portfolio Management spreadsheet.

Structure in Threes: IT Investment Strategy Lessons

This week as I continue to research IT Strategic Planning issues for a series white papers I’m writing I’m noticing more gaps in the average IT organization’s planning approaches.  Despite more sophistication in technology, the planning efforts are still rather primitive.   Many IT Planning organizations spend significant time on the technology requirements, functions and interactions; which they should.  However, when it comes to the effects and benefits to the business which they serve, these functions come up fairly short still.  The average business case just little more that a primitive ROI based upon very weak assumptions.  It is not wonder why CFOs and Controllers are tightening the screws on IT projects and considering outsourcing and cloud alternatives.  A few organizations I’m aware of are looking at eliminating their IT function entirely and moving everything to the cloud.

Review of prior Portfolio Management R&D at IBM

This coming week’s agenda is to develop the optimum means for presenting the Modern IT Portfolio Management process to executives and managers.  During the initial portfolio management R&D for business investment at IBM an interesting reaction was observed.  Executives and Managers disliked operating on models with more than two to three factors, preferring two factor matrices with binary values.  This was rather interesting observation in that each Stakeholder when surveyed asked for multiple factors to be evaluated.  However, in practice only a couple of factors are examined for consideration.  These factors typically center around near term monetary consideration.   optimal portfolios with high risk.  Thus other factors or strategies should be considered which infers a more complex matrix of considerations.

Lessons learned from Venture Capitalists

Venture Capitalists (VCs) evaluate investment candidates based upon returns like other investors, however, other factors are often used to classify and filter opportunities.  These are often used in what has been called a stage-gate process.  This is a series of smaller decisions that in effect gate weaker opportunities out of the pool of candidates.  This makes the decision not a single yes/no but a series of yes/no decisions.  The other aspect of a VC‘s investment process is the core to the portfolio management concept; multiple independent investments.  Typically this is accomplished by VCs teaming with other VCs enabling them to make smaller bets but spread amount a larger group of opportunities.  This strategy reduces risk by eliminating the eggs all in one basket approach.  The final strategy many venture capitalist used to mitigate risk is employing a variation of options theory.  Employing this strategy, VCs will often stage release of funds based upon a business venture’s ability to meet specific goals.  If a venture does not meet these goals the VC has the option to discontinue funding and cut their losses or potentially take a more active role in the management of the venture.

Other Research

Other areas of investment research under current study for this practice include:

  • Stock Brokerage [reviewing interview notes]
  • Investment Bankers
  • Insurance Actuaries
  • Natural Resource exploration enterprises

Structure in Threes: Organizational Design

Business Structure verses Organizational Structure

One of the interesting issues that came across my desk today as I was discussing a colleague’s new venture was the taxonomy and ontology of our conversation.  She wanted to cover multiple concepts in the same conversation which is a notable goal regarding economy of one’s time.  However, it became apparent that the terms being used were being overloaded during the conversation.  Example: Discussing the Business Structure and Organizational Structure both terms were used interchangeably.  However, when I hear the words Business Structure I think of the legal form in which the business is established (Corporation, LLC, Partnership, etc.).  When I hear the term Organizational Structure I consider whether it is centralized or distributed; a partitioning along functional, product, customer or geographic lines.  As I continue to develop the Business Design Tool (see below) the question becomes how-to ensure that the dimensions are orthogonal to each other while retaining the interconnectedness of these dimensions.

Organizational Development Tools

Many of the recent texts define various dimensions such as complexity, market, size, etc.  However, the interconnection is only a Infographic.  Perhaps these interconnections are only a probabilistic connection leading one to only heuristics.  I will make a interesting systems dynamic study at the Center for Understanding Change when I have some spare time.  In the meantime I continue to develop the Org Design and Modern IT Portfolio Management tools which are looking more and more like an enhancement to the Business Analysis System and Environment (B.A.S.E.) application built in 1994 on MS Access V1.

B.A.S.E. at that time performed a variety of management consulting analysis:

This application will eventually become the basis for the semi-automated workflow for several of Intellectual Arbitrage Group’s practices and services