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.

 

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: Tools Development

Organizational Design Tools Need Completion

Continuing to build out Enterprise Analysis and Design tools this morning along with a workflow to integrate the Modern IT Portfolio Management methodology.  After finishing the Org Design Tool, the next steps will be to finish off the Portfolio Management Tool and then document the workflow for possible automation.

Strategy Analysis

Modern IT Portfolio Management

Digital Nervous System Architecture

It looks like I’m going to build out the original concepts I developed when discussing what and how Active Directory should be with Hans.  I had presented to Hans an idea that Active Directory (SMS Server) could accomplish its mission through usage of federation and abstraction into logical units (see below late 1996 presentation).  Added to that were the concepts I had been working on as a side research project during my employment at IBM the 80’s.  This later became a white paper “The body enterprise” where I through the network could become an enterprise’s digital nervous system.  Unfortunately, Hans and I could not get the funding to pursue going any further than simple IT product management.  However, I continued -though through small pieces of other projects- to research how to build a management and control system.  With my Modern IT Portfolio Management R&D at a foreseeable conclusion I’ll be able to build the CIO Workbench I had envisioned years ago.

Slide5Slide13

The unfortunate aspect to this was both IBM and Microsoft had the opportunity to build this out a decade ago but failed to see the vision was achievable. I guess you can chalk it up to other missed opportunities that companies have for not reaching far enough in the future.  I remember hearing internal chatter by Microsoft management when I departed for DMR Consulting this was a dream decades away, though BillG must not have through so or his Ghostwriter wouldn’t have spent so much time interviewing me to included in his book.

Structure in Threes: Positioning and Lessons not Learned

Had great discussion last night at Starbucks on Mercer Island with some former Microsoft Alumni.   One is at a Microsoft competitor now working at developing a competitive service to our mutual former employer’s.  The change in strategy at Microsoft has yielded a large shift in the Architecture domain enabling competitors to move in and eventually succeed.  My colleagues and I rather than sit around the table discussing what could have been are busy creating the future; spending several hours mapping out the landscape and what pieces need to be build or remodeled.  Sounds like Enterprise Architects at work.  However, unlike the paper mill approach that was being pushed we’ve been taking a more engineering design approach looking at how the methodologies we’ve each been developing yield implementable designs specific to client’s needs using modular componentry.

Discipline Maturity Lifecycle

I was wondering how much longer it would be before Enterprise Architecture would reach the next stage in its’ maturity.  I’ve been watching TOGAF, ZACHMAN, COBIT, ITIL, etc. for the past several years ideate and mature into a robust collection of heuristics waiting for the day these take the next step towards modularity. last night’s discussion inferred the time was rapidly approaching, both my colleagues began discussing their specific domains in context of creating a reusable component based approach.  That is to say having a set of design rules as to how to choose what components from a library or catalog of components to achieve design goals.  I was really pleased with the direction the discussion was talking.  Had I had my copy of Jon Lang’s Creating Architectural Theory –I leant it out to another peer at Microsoft this past month– I would have pointed out we’re finally making some progress.  However, that most likely would have confirmed in their eyes I was an academic (odd considering I spend more of my time building tools and applying these concepts than doing primary research in the area).

At different times during the conversation I was frantically searching for documents on my Windows Phone to point out some of the pieces I’ve already built or are in the process of building.  Unfortunately, this is where the promise doesn’t measure up to reality.  I could not get to my Office365 Small Business Online site or SkyDrive (it couldn’t recognize ANY or the Userids I entered).  Microsoft has a lot of work to do to get Services right before they can compete effectively with Amazon, Google, and Apple.  Sure individual components run, however, when combined in a system which is where the Services business is, they’re having challenges.  This systems approach is still elusive to the culture at Microsoft.  

We parted with a plan for a plan which could either mean this will result in just an nice academic discussion or that we will really start assembling a next generation of Architectural practice that will take one step closer to a engineering-like discipline rather than a artist colony debating about aesthetics of design.  In either event the discussion confirmed to me I am on the right track with ‘Structure in Threes” and creating the design methodology that enables using modular componentry at all levels of abstraction.