Is your APM strategy a yard sale or a Beauty Pageant?

This and the next few weeks Carl Engel (Elyon Strategies CEO) and I are collaborating on a white paper about Enterprise Portfolio Management. The insight that we should do this came about a month or so ago at a Industry Vendor’s Conference where we saw some serious misalignment in presentations touting Agile and APM as the key to success. Our objective behind such is to give executives insight and tips how-to implement a beneficial portfolio practice beyond just APM.    My strategy creating this paper is to provide the “Cliff’s Notes**” on the Enterprise Portfolio Management practice I’ve been maturing over the decades for various consulting, technology firms and their clients.

During our brainstorming sessions one insight has continually come to the forefront.  The state of the art in APM is drastically behind the state of the industry in financial portfolio management.  Not only that but the practice in APM could actually be damaging to an enterprise.  Here is one insight from our brainstorming session:

Application Portfolio Management (APM)

APM as practiced by many IT organizations and consulting firms typically focuses on one of two strategies: Rationalization of Current or Curation of Potential.  In the first strategy the organization is seeking to ride itself of assets in its portfolio.  In the second strategy picking individual winners or highest winners is the goal.  Both of these objectives are well meaning however, if not accomplished in alignment to an enterprise’s business can prove devastating.

Portfolio Management was originally introduced as a strategy to balance risk and reward in the financial investment industry by Nobel Prize-winning economist Harry Markowitz.  As the concept of portfolio management migrated to IT the second factor, risk, seemed to have been dropped from consideration.  If a root cause analysis had been accomplished you’d likely find many of the serious issues within IT can be traced back to not considering the enterprise risk of the equation.

With regard to the first strategy Rationalization.  Lets consider why one is “rationalizing” the portfolio.  In several engagements I was brought in, was due to acquisition of multiple assets or copies of assets doing the same thing.  The root questions is why?  The other situation was the asset did not perform or no longer performs at the desired level.  The end result of such is these assets are like the tail end of a yard sale. The only thing left to do with them is box them up for charity (unlikely) or putting that ugly lamp into the trash to be hauled away and forget about them.  But why did this occur?  If it was an asset to the enterprise shouldn’t it have been managed as such?

In regards to the second strategy Curation of Potential, there are many books, consultants and firms touting how-to develop effective business cases for initiatives.   I’ve co-developed several of these for corporations such as IBM, Microsoft, and other consulting firms.  Unfortunately despite cautions to the contrary, these are often watered down to eliminate the interdependence risk portion of the equation.  This creates a popularity contest for funds.  This maybe due to self-interest by the initiative promoter, a lack of insight as to the interdependence of the initiative within the enterprise ecosystem or that no one wishes to discuss the potential downside: “You’re just being negative…”  In any of those cases the risk to an enterprise is an iceberg in the ocean the enterprise is sailing through.

The forthcoming white paper will provide some tips on effective Enterprise Portfolio Management, while the training course to follow will delve deeper into how-to establish and mature a portfolio management practice.  This will also help enterprise determine at what level they are and what level of practice is optimum for them.  That is not every enterprise needs to or should be at a Level 5  of capability/maturity.

 

 

 

**Shorter versions of Dummies books for those born later than Boomers

Advertisements

Saving your way to Bankruptcy

How often have you hear “Honey I bought it on sale and saved us a ton of money”? Really? Did at the end of the month you could see your bank balance increase? Often, we hear similar words inside an enterprise. We’ll saved 1000 man-hours with this new project.   Can you really save man-hours? I’ve not seen any place where time could be saved, much less get paid interest on it.

So, if these questions seem logical, why do we continually hear internally and from vendors about all the time savings? Possibly because emotionally we all like the idea of bargains and savings. The problem becomes that savings is not always savings.

Several years ago, I help develop an economic justification methodology specifically for my employer. As I had done this previously for other employers it wasn’t a large stretch if all they wanted was a standard ROI procedure.   I had brought up to management building an business case on time savings would have little value as CFOs and other management would know time saving is not economic benefit unless you do something with it or avoid having to get more resources to accomplish the goal.

The simple examples: I could automate a process using technology “saving” one hour a day per person. If I can defer hiring additional resources (cost) to accomplish a goal for a smaller investment in the technology, then I’ve actually saved money. If, however, I “save” one hour per day of staff time and nothing is done with that time, then I’ve actually lost money. If I continue to save time and money this way, I’ll be bankrupt in no time.

My advice for avoiding such a problem is while in the planning phases of a new initiative consider what you’ll be doing with the savings. Will the staff be able to effectively use that additional hour a day? This could be getting out one more proposal to a potential client, exchanging knowledge between peers, or any number of other activities. The key here is to have a plan on how that savings is to be used.

Started Enterprise Portfolio Management CMM white paper last night.  Expect this will become a finished chapter in Enterprise Design and Engineering book in progress.  Presently collating and organizing materials from all the engagements and methods I’ve produced for corporations over the years into a cohesive practice guide.  This will be a companion guide to the tools suite I am working on to release some time end of year.

enterprise-portfolio-management-white-paper

Modern Enterprise Portfolio Management

Portfolio Management capabilities roadmap (initial) from last night’s brainstorming.  Planning (aspirational) to have Modern Enterprise Portfolio Management materials ready by February for a possible seminar at my home office over a holiday weekend.  The big question(s) will be if any of my colleagues and followers will be: 1) interested in attending a focused seminar, 2) willing to take the trek ~60 miles south of Seattle for a 1 to 2 day seminar.

 

 

Enterprise Portfolio Management CMM Roadmap

The nice thing about this research is I can leverage it as source materials for current projects I’m doing at work and for internal technical conferences.

Working Insights: Process Analysis presentation creation and the movies

Finished my presentation deck for Wednesday’s Business Architect call, sent it out to my manager & colleague, and other friends for comments.  The topic is business process analysis methods.  Its a short 20 minute presentation on the benefits and some methods of value for analyzing processes.  During developing I rediscovered what I already knew: Difficult to compress 2 hours of material into less than 20 minutes.  Makes me truly appreciate movie editors and directors…it take a lot of skill to cut things down to the bare minimum and no more.

Which has me reconsider my thoughts around BPR/M compliments I get in the form: “I’ve never seen anyone but you be able to diagram a process on the fly while we’re discussing it” or “How can you trim these processes down so well that there are minimum steps and each one contributes real value so easily?”  Often I just smile and say thank you, but really don’t think much of it its just what I do.  But I guess its because I’ve spent years honing my craft like editors and movie directors learning how to cut away what’s non necessary to the accomplish the job; in once case telling a story and in mine making a highly efficient and effective process for an enterprise.  I’m sure by now my colleague Sarah is smiling, nodding her head, and saying of course.

Unified Business Modeling and Architecture Capability: Using a common language across multiple business tools

Started building a Capacity Planning Model to evaluate processes I’m modeling in BPMN.  Contacted a colleague who shares Model-Driven process execution vision with the idea to build a capacity and financial modeling capability add-on to his execution engine.  I can see a real benefit in the ability to model, analyze and execute processes using the same graphical language.  Currently the tool suite for Business Architects is a cobbling of various tools which means having to do multiple translations and transcriptions from one system to another.  The results of which is a lost of productivity, agility, increased configuration management overhead and reduced benefits to the business.  This is similar to the problem programmer have had with using multiple tools not meant to work together.  What’s needed for the business architect is a common tool suite or Framework that integrates the various models and variables making them available for multiple uses; Different types of Analysis, Execution, Monitoring and Reporting.  I had this vision years ago during my CIO Workbench / Activity Directory Conceptual Design days.  Now maybe the time to build it

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.