Technology Alliances - Changing Industry

2012-01-14T14:02:00.000-08:00

IT Development - Who Makes the Decisions (process / tools)?
I tend to break IT Development conversations into 2 metaphors Elephants or Cats.

IT Development focused on Elephant management...
These are organizations that leverage Large Platform (mostly on-premise) apps that have millions of lines of code, 1000's of features, 100's mission critical dependencies in the data center and typically schedule large "upgrade" efforts every 2-4 years to help the business with stable growth.

Elephant IT Development decision making...It tends to be left up to Sr IT Development Management teams (who raise from the ranks of a specific era). And whose decisions are normally best served by "waterfall" best-practices, sustainability and scalability issues.

Elephant tools for IT Development tend to focus on...
- driving well-coordinated orchestrated and sub-project assembly of many efforts over long periods of time
- needing layers of specialty quality control processes (projects, release, operations) along the way
- requiring BIG Operations Systems Management platform, designed to "corral elephants and infrastructure impact"

Elephant tool value:
The value of the tool needs to control and coordinator the people and projects to deliver "BIG Change"
- Code is often a means to an end..."it's a bit like lettuce, it's value fades over time"

Company's measure of Elephant IT Development processes:
- Measured on how "BIG Applications" are graceful introduction, leveraged and supported in complex data centers

Business's measure of Elephant IT Development processes:
Kind of understanding the sausage-making process, "I am not sure I want to know whats inside."

Elephant IT Development Vulnerable:
Tends to make the business "wait" long-periods of time for dramatic changes.Big projects tend to have delays, experience budget over-runs and create operational maintenance challenges

---------------------
IT Development focused on Cat management... (I'm borrowing the EDS' image of cat herding)
These organizations value and leverage small agile efforts (embracing Cloud and mobility) and making smaller changes more often.
Their Application efforts leverage modern code languages with...
- fewer code-lines (more common services),
- focus on business prioritized single-feature function releases,
- with fewer critical (disruptive) dependencies
- and they leverage staggered release efforts over time to make big (sometimes unnoticed) changes for the business.

Cat IT Development decision making...
It tends to be mostly driven by business demand, but the business and management teams tend to allows development teams the flexibility to select agile tools needed by the "project-type" and environment destination (cloud, mobile, etc.) within the company's guidance. A "project-scope and Cloud-type should self-determine different tools needed be a team.

Cat tools for IT Development tend to focus on...- a "business needs negotiation" process with the development scope capability- well-managed small teams (Scrum?), and re-use processes and communications for quality
- It should include code management and automation tools to "release and track Cats"

Company's measure of Cat IT Development processes:
How well they can monitored and track tools, activities, teams, and the "LITTLE" stuff in a big projectThey should use security rights for access and see Code as "Corp IP" can be managed for re-use, up-grades and quality control strategies.

Company's measure of Cat IT Development processes:
- Tend to measured on business usable, and "fast" application completion "on-time and on-budget"

Cat IT Development Vulnerable:
Vulnerable to development flexibility that can stray from Corp-goals, and have slow 1st year transitions

SummaryA company's environment (current IT stage) determines the nature of an IT Development conversations. Organizations will normally toleration of change, and the current infrastructure priorities will indirectly "frame the development" discussion. Knowledge of development best-practice/innovators, along with process "change-tolerance" levels, will determine the potential competitive-edge a business can hope to leverage from its IT Development team.

Asset-less IT…What's the future of IT Service Operations’ ITAM?

2011-09-12T02:04:00.000-07:00

I was talking with a friend about some of the changes that are impacting IT including…

- the adoption of virtualization,

- Cloud (Public, Private and SaaS),

- mobility

- and agile development efforts.

We compared notes on how each of these are directly and indirectly impacting IT Operations (as defined by ITIL, BSM, etc.) and IT Service Development (ALM, App-Dev, etc.) at many companies. We stumbled in to the concept of an Asset-less IT (no HW & SW to manage), and talked about this future role of IT.

So how did we end up at an Asset-less IT discussion? Initially, we started with a discussion on Virtualization. Outside of the many benefits of Virtualization in the data center, IT Development effort were greatly simplified (over time) as development teams “defocused” on specific hardware and OS environments and relied on Virtualization technologies to manage that layer.

And as the Cloud (in whatever flavor) emerges as a legitimate option for many organizations; development teams are relying on well documented and stable environment to make smaller apps quickly, with ongoing modifications, available more cost-effectively.

At the same time business users are quickly adopting mobile devices to be more effective and better-connected. These smaller devices and the thinner apps they run, are driving the need for more client-ready data access on different mobile devices and across a variety of networks. And like it or not, the business users are ready-and-able to download Shadow-IT apps as needed, if their own IT teams are not ready to provide services.

Finally, the nature of IT Development services has changed along with the nature of software applications…

1) OLD SCHOOL – SW was millions of lines of code, 100’s of developers working over months and years…

2) TODAY – smaller Agile development teams, work on small focused SW apps that release weekly

3) OLD SCHOOL – stand-alone SW had redundant functionality, often tied to specific DB, HW and OS

4) TODAY – the agile apps rely on more “standard” common services and automation, via virtualization or Cloud

5) And TODAY almost 80% of all IT Development services are moving to agile methodologies, continuous integration, continuous delivery and continuous improvement efforts, and completing projects in a few weeks with teams routinely deploying to live environments on a weekly, or even a daily basis.

IT Asset Management and IT Change Management were defined in a different era and find it hard to track or keep pace. The trends point to a day when IT, and the SW applications, may need to be managed at the Source Code level. If a company defined its core assets as the Source Code/IP, and managed it in a way that…

- allows development teams to re-use pre-approved and security-cleared code,

- provide real-time source code access and controls, for internal and contract developers

…the company could move the organization toward an Asset-less IT Operations team leveraging the Cloud and its Source Code strategies. OK, so really it’s just pushing asset management to the source code level and tracking it into internal and externally provided services.

But we are seeing more organizations push closer to this model; collapsing IT Operations and Development services into a single DevOps staff, and setting up IP strategies that drive policies and guidelines around the use and re-use of their source code. The benefits of both efforts should create advantages for IT's reliability and business agility.

The Newest Business Super-hero “Shadow IT” – when IT says no…or wait!

2011-08-01T18:19:00.000-07:00

“Shadow IT” delivers… mobile, Cloud, SaaS, social, games, personal Apps…when IT won’t!

Faster than an Agile iterative… More persistent than a corporate mandate… And able to leap ITIL and BSM efforts in a single bound…

”Shadow IT” responds “Yes I Can!”
…to whimsical innovations any business users, with a corporate credit card, can find.
…maneuver around IT, if IT is reluctant to drive blindly into new territory.

Is “Shadow IT” the next super-hero for your business? Or…it might be time for a new discussion with IT?

Changes in the business climate, inside IT, and the expectations of corperate users might be creating the “perfect storm”. Is this a chance to re-think “how and why” we might want to do IT differently? IT departments seem to have 2 camps when they talk with business users.

1) The IT Operations teams (Service Desk, Data-Center/PC/Network management, etc.) often embrace ITIL or BSM. And discussions are focused around MAINTAINING “High-Quality, High-Performance and Undisrupted Services” to assist the business. They are careful about supporting only critical business and resisting un-necessary changes…

2) The IT Development teams (Business analysts, project managers, developers, QA, etc.) often embrace Agile or ALM. Their discussions are focused around CREATING “High-Quality, High-Value, and reliable” applications quickly to assist the business.

The differences between the 2 IT teams may seem minor but organizations really struggle with re-aligning the goals and the changes need by both. Delaying a DevOps defined IT conversation, simply allows “Shadow IT” to drive deeper into IT-indifferent decision-making of the business.

Shadow-IT helping me define my smart-phone and tablet based business services right now!

http://bit.ly/PaulPeissner

DevOps Micro and Macro-Level Discussions

2011-07-31T18:29:00.000-07:00

I wrote this originally in response to a LinkedIn DevOps conversation, specifically about how DevOps promotes “good working relationships at all levels of collaboration”. I think it’s important to point out that few IT initiatives make ”soft people skills” a priority; and understand how far reaching benefits are when teams can see things from “a lot of different angles.” DevOps supports the need for better “culture building” and having “a spirit of communion and mutual support” across the organization, and it is what I think makes DevOps at both a “Macro and a Micro-level” unique in the IT conversations.

DevOps at a “Micro-level” will always involve “Geek-chat” (the tool-chain, automation, collaboration and better transparency). Adjacent IT silos’ and IT process transition teams are collapsing into more holistic efforts, and adjusting the self-serving “reward systems” that perpetuate the silo-benefiting behaviors. We can see IT maturing and evolving to accommodate the bigger concerns of the Development (Dev), Operations (Ops) and the Business teams. I believe projects focused on “integrated frameworks/platforms, improved collaboration and more automation” are outward signs that an organization (or an individual IT silo), is moving toward a wider DevOps approach to IT…even if the initial driver is only a cost-saving effort.

DevOps at the “Macro-level” is the best means to “discuss” the last mile in many organizations about problems they with IT in general…
- Is IT misaligned (or non-collaborative) with business and/or any corporate imperatives?
- Is corporate (or the business) misaligned (misunderstanding) of a holistic approach to IT?
Both are topics for a great DevOps discussion with management teams from both sides.

Are there some examples of DevOps working with in-house and 3rd parties?
Yes there are some great DevOps stories of “micro-level” teams working closer together and tool integrations. And there are a few organizations that are taking a new approach to IT that includes the “strategic use of outsourcing” for some IT functions.

One company my team has worked with, expanded their “investment in IT Ops initiatives” pushing “Service Desk Self-Service and Service Request Portals” to include a portal for “NEW Requested Service/Application.” The NEW Requested Service Portal, and its predetermined workflow, is designed to make sure all stakeholders are involved in an applications lifecycle discussion at the earliest stage…
In this case the NEW Requested Service/Application Portal starts an initial 5 stage workflow process…
1) Takes requests (answering many questions up front) and ensures that it is aligned to corporate priorities (cost-reduction, revenue growth, GRC, etc.) and addresses “business benefit” criteria
2) IT Ops reviews it for “supportability, scalability and sustainability” (and can decline the request)…
3) IT Dev assigns a business analyst to clarify the request and determines if external teams can be used
4) If the project is approved…
5) IT Dev teams then provisions a Scrum team the Application Development Framework (in this case CollabNet’s TeamForge with Subversion for both the code and QA repositories, integrations to a variety of eClipse-based IDE’s with integrations to Hudson and HP Quality Center / ALM; for more complete QA-Dev-Project transparency).

This step is also true for 3rd party participants, who are seen as “project-oriented” team mates. The 3rd parties are also provisioned access to the framework (roles-based and project type access) and any relevant source code and related artifacts, via the TeamForge Cloud-based framework.

This DevOps approach, accommodates globally distributed 3rd parties, and has helped speed up delivery, lower costs and reduce risks (especially by encouraging code re-use, with code that have been tested and approved in previous applications). This App-Dev framework also allows for better management of 3rd party code after the project team is done as well. This customer’s innovative project also identifies best performing teams (internal or external), and “recommends teams” based on the long-term evaluation-data from, project team members, IT Ops, Service Desk, business users, and the original corporate objectives, of previous projects.

http://bit.ly/PaulPeissner

BSM, ITIL, Agile...you should have put a (corporate) ring on it.

2011-07-25T09:37:00.000-07:00

If the two worlds of IT are colliding... (driven by internal IT and external industry changes). So what would this new IT model look like, and how would it be different from the silo-limiting initiatives and their micro-focus, or self-serving, agendas?

DevOps - Rounding Up a Corporate Discussion
If the emerging DevOps conversation is going to address the Macro-focused issues and take on a bigger picture of IT, then this "bigger picture model" needs to look the whole process, and be generic and universal enough for any organization to use. In my mind, a generic "ring" model needs to enable an open-ended process flow discussion of "how" any organization currently does two things...
1) Creates new Business Apps
2) Solves IT service incidents

Putting a Ring Around a DevOps Discussion

The organization's maturity, tools, processes, practices will range greatly, but every organization must address these two core functions, to have a working business of some sort. Every organization should be able to use the DevOps model today and walk you through an "inspiring" event (whether it's an indecent to be fixed, or new idea for consideration). In my experience this model, shown here, starts to reveal strengths and challenges in an organization. The model also helps me figure out "who" I am talking (or negotiating) with. Any unknown owners or processes (blind-spots) in the ring discussion are a good indicator that there are silo issues that will need to be addressed.

No other IT initiative model that I have worked with leverages a "Macro-Ring model" that starts at the Business-Need AND ends with a Business-Benefit evaluation. This model can facilitate a discussion on almost any topic related to technology; across ALL parties in the organization; and over the whole life cycle. DevOps puts a "ring" around the whole process, and helps a company identify opportunities for continuous-improvement processes, where ever the organization may be broken.

Enabling the Teams to Work Together

In addition to a "process flow" discussion. Organizations need to discuss the culture, goals and language differences within the 3 core groups, tribes, silos, etc, effected by any Macro process. The process needs to discuss how much freedom can be provided for "best-practice practitioner" tools and processes to enable optimal team performances. And how to balance the micro-needs with the bigger macro effort, that can address...
- corporate-wide continuous-improvement,
- long-term reward systems,
- better compliance adherence capabilities,
- more organization-wide automation,
- and optimal resource management.

Herding the Cats...people, processes, tools, silo agendas, etc.
Finally, putting both of these together (the people/culture and process/tools), provides a model to talk about "who and what" happens in a current-state discussion. But the same model also allows for a "big picture" review of what needs to be improved and the "business benefits" for every project or activity.

Let me know what you think of both the model and your experience with organizations looking at DevOps challenges...

http://bit.ly/PaulPeissner

Have the Stars Aligned for a DevOps Discussion? …Non-IT Compelling Events

2011-07-23T15:04:00.000-07:00

See previous posts for internal IT silos and the need for a big picture IT approach…DevOps.

In this post I wanted to focus on 4 non-IT issues that help the cause for a DevOps discussion:
1) The volatility of the new economy
2) The global markets and resources
3) A general changes in corporate cultures
4) And agility enablement processes

The Volatility of the New Economy
Business agility or the lack there of, is becoming strategic component in the life and death of companies, industries and even a country’s economy. No matter how great a particular silo performs to its “internal-industry best practice” agenda, if the corporate business is going down so is the best-practice silo.

Today, I see greater awareness by the whole organization (shareholders, business owners and even IT staff members) that are making better attempts to align all their resources with a company’s urgent need to innovate. Likewise, we are all painfully aware of companies with best-of-class silos that failed to adjust. A couple of “failed” financial institutions that I am aware, had IT Service Operations strategies that were confirmed as being “much better” than the acquiring organization, but could do little to help their dying organization. We all understand the potential of the new economy to punish outdated legacy folks and reward over-night innovators. There is a new urgency by the wider corporation that the business must innovate, or die! And this new commitment to High Performance Business Agility is opening up new change-oriented discussions that were non-existent a few years ago.

Global Changes (New opportunities and risks)
It is surprising and inspiring to see the “levels of change” some organizations are willing to embrace to re-invent. I am amazed, watching how these “old dogs (so to speak) are able to learn new tricks” by leveraging technologies and resources that have fewer geography or physical boundaries. The organizations that can make quick adjustments, take advantage of market changes and leverage the elasticity of outsourced innovation, have clear advantages and great potential to be first-movers with fast-growth and unprecedented profitability.

This upside does come with new risks and challenges as well. We have all read about risk-dismissive teams that have suffered the consequences for corporate negligence and the lack of controls or commitment to quality. A shared commitment to quality-change and continuous-improvement is essential to a company’s long-term success.

Recent Technology Changes
All groups, including IT, are adjusting to the harsh-reality of “cost cutting efforts” and “doing more with less”. Plus asking employees to be 'fast and flexible' to accommodate the business re-invention and ongoing business agility, places a new pressure on everyone, especially IT. IT Service Operation teams have often matured in a more predictable economy, and in an IT-industry silo that was overly focused on “stability and performance”; and in IT environments that resisted changes for quality reasons. Change was considered potentially disruptive to the business and a moving target for IT to support. So ITIL and BSM allowed IT to limit IT’s focus to “subset” of supportable services that could “sustain” the current-state business. Two recent innovations have great promise for Business Agility, but represent new challenges for IT Service Operations teams: Cloud and Mobility. I plan to spend time exploring the potential and impact of both Cloud and Mobility in a separate post, but I wanted to point them out as contributors to a DevOps conversation.

Corporate Culture Changes
In addition to the outside changes listed above there is growing interest in creating a culture of collaboration, trust and shared (business benefiting) success across traditional silos. There are a lot of reasons why there is “new” interest…but I want to focus on the methodologies and challenges especially for globally distributed teams. It’s not a question about the ability of a web technology, but it’s more of a question of “how” teams should interact, across time-zones and address culture challenges.

Agile
I have alluded to Agile, but Agile has been associated Development and R&D efforts, historically consumed with time objectives. A “big picture” view of agile has questioned quality, usability and supportability of a rushed R&D effort. And historically agile has run “best” in a single room environment where the ideas and communication around a project, flows freely. Using this Agile Scrum process with global team needs to build trust and accountability (with co-workers and virtual 3rd party project team members), accommodate time-zone delayed collaboration, provide secure flexibility, and a cross-discipline “business-benefiting” reward system (beyond a project delivery date). Again this is topic for a later post.

So, if the wider DevOps conversation is also being encouraged by industry concerns for…high-performance business agility, global markets and resources, corporate culture changes and better long-term agile team goals… What would IT look like if the two worlds (Dev and Ops) did collide? Could a simple model be introduced to help teams define DevOps-centric processes and goals?

http://bit.ly/PaulPeissner

If it aint broke, don't fix it....but IT is broke and DevOps can fix it!

2011-07-22T08:00:00.000-07:00

In a traditional view of the "IT silos" you could argue that IT is maturing just fine; with their self-serving silo agendas and self-justifying metrics data...

But if you take a BIG PICTURE view of IT, you get the sense that things are really broken and that a bigger conversation needs to take place.

I have a few examples of IT data I have had presented to me from "niche" IT silos that together makes me think its time for a more coordinated effort...

In the IT Service Operations discipline...
- ITSM - The "average enterprise" gets more than 70,000 requests for change a month...that sounds like happy customers to me
- ITCM - As many as 80% of new enterprise Application releases are considered a failure...that sounds like a lot of weekend work

In the IT Service Development discipline...
- QA - "Most BUGS" are baked into new Apps from the start, "at Requirements" because of
...lack of continuous user feedback during the project development process
...undocumented changes to the infrastructure that will host the App
...changes in the business that occurred after the project was started
...surprise Cloud strategies, a business decision...with real Dev and QA impact

- Development - With no real "Dev feedback loop" from test, Ops, ITSM or users, global Developer teams have no readily available "qualitative data" tied to source code when making re-use decisions. And there is little chance developers will get it right, the first time.

- Development - I know of one Agile Dev Team that has reduced "development times" from 48 months to 3 months; but the ITIL driven IT Ops team has created a stock pile, with a 2+ quarter waiting list, for these "revenue generating Apps" to go live, while IT Ops waits for an ITIL change window to "work them into" the schedule.

And IT's reputation is suffering...40%+ of enterprise users believes IT under delivers on expectations...basically "IT stinks" and can't be trusted to deliver what I need. So while some IT software vendors claim to run the IT software that runs the business...I hope they are trying to do that "better".

For now, my point is this...
There are a number of "problems with BIG PICTURE IT" that the silos can't fix. And beyond the "IT internal reasons" for DevOps there are even more "IT external reasons" that DevOps makes more sense today than ever before (see my next post for external influencers)...

(The data source for the percentages above is said to come from Gartner...across many IT discipline reports - I'm sure they would be happy pull that data for you. - For a definition my "IT disciplines and silos" see my previous post... "You Got Your Agile in My ITIL")

To read more...
http://bit.ly/PaulPeissner

You Got Your Agile in My ITIL...

2011-07-21T10:47:00.000-07:00

After a long 'quiet-period" and a career expanding journey.. I feel inspired to post a series of observations and insights coming from a number of spirited discussions around emerging IT initiatives and best practices.

With 10+ years involvement, in helping IT "enable and align" better with the business, I recently jumped over to the world of IT's "application creation" process (where the Root Cause monsters have come from). I hoped to see if there was a better way to prevent business disruptive incidents; and to try and help restore "IT's reputation" - to see if IT could be run like a "trustworthy" business.

Bottom line, after a year...I found that there are 2 clear and distinct IT disciplines (Dev and Ops), but that both "care" about supporting the business. But both IT disciplines seem to be driven by initiatives that are in conflict with each other... Let me separate and summarize the two camps...

IT Service Operations (Ops), generally refers to the Systems Management offerings that historically includes Service/Help Desk/ITSM, Asset Management, Configuration Management, Change Management, Release Management, Data Center/Network/PC management, etc.... Ops "best practice" discussions have "historically" been focused around ITIL and BSM. For the sake of my discussion, ITIL, is a non-product, "process-focused" discussion about how maturing IT teams "should" manage their IT environments; and BSM is the technology/product-centric discussion about how "platforms, tools and integrations" could manage an environment and deliver high-performing and reliable business services for the organization to run business efficiently.

IT Service Development (Dev), generally refers to the Application Lifecycle Management (ALM) space that historically includes Application Development, QA/Test, Requirements management, application end-of-life management, release management, etc... Dev or ALM "best practice" discussions have found a lot of momentum around going "AGILE". For the sake of my discussion, agile is the process of breaking large (macro) funded initiatives, in to small (micro) projects and teams, that can build a series of "products" quickly that meet the needs of the business; allowing the organization to leverage this agility to better compete in the market place.

Obviously, it wasn't long before I learned that an open IT conversations about "ITIL and Agile" will never unify an IT team. I have seen IT co-works launch emotional comments and politically charged observations about the other side, creating an "us and them" division, faster than a room full of passionate baseball fans from NY and Boston.

And in my journey into the "Dev" side of IT, I found myself alone in a foreign world, surrounded by people who saw things from a different perspective... And now, a year later, I am amazed at the potential of these two worlds colliding. I believe the coming innovation will provide unexpected and unprecedented High-performance Business Agility benefits... And the new IT discussion that can facilitate this change... DevOps!

Feel free to follow and challenge my observations...I am still learning and uncovering the eco-system of innovators that is needed for this DevOps nirvana.

To read more...
http://bit.ly/PaulPeissner

When "Getting The Deals Closed" Is Not Possible

2009-10-28T21:28:00.001-07:00

On a recent phone call I had a painful exchange. A friend of mine wanted me to help him wave a magic wand and start driving deals overnight. However, he could not see any value in spending time or effort solving the problem that created crisis. He just wanted "help" closing more deals. It took only a few minutes to discover the deals were not just "slow to close" but the whole pipeline was almost empty as well. That said, he could not see why "wasting his time and energy" on marketing, lead generation or pre-sales activities and resources, was going to help help him "close" more deals.

And after several attempts at explaining how deals come easier when you have the important early engagement sales pieces in place (called marketing) and a strategy to grow the opportunity pipeline; I found myself throwing in the towel, his blinders were glued too tight to this guy’s head. The reason were no "deals" to close, was that parts of his business process were missing; there was no scalable or sustainable sales process creating interest, demand, or systematic opportunities. The early part of the sales process was either missing or not funded.

Deals flow when you have the necessary pieces in place. Relevant products and services will always struggle when one or more of the needed parts is missing. In this case, dramatic changes to the marketing, sales team and the partner community earlier that year, created the crisis. Re-discovering and fixing the process was NOT the answer he wanted to hear. And its no fum being the messenger that gets to state the obvious to guy who just can't see a holistic sales process in the first place.

When the Business need to Cut Cost - IT Needs ROI Tools

2009-05-03T16:46:00.000-07:00

Companies looking for ways to streamline, increase efficiencies and cut costs, often target IT for cost cutting. Its a common perception that IT service costs are "too high" and a clear understanding of the service benefits are "too low" throughout the rest of the organization. So organizations often make first cuts to IT project budgets, delaying scheduled upgrades and technology investments; and what has not yet been outsourced, will probably be.

IT organizations that can not demonstrate their value to the business will be among the first to go. Those that have embraced best practice and are able to show greater efficiencies and quality of service will have advantages when the organization is looking to cut costs.

All investments in the IT infrastructure should have an ROI calculator provided by the vendor and IT staffs should routinely use those tools to measure their own effectiveness for the business to be aware of. Without the ROI data business will only see IT as a cost center and cut it to the bone, without realizing the damage that are doing to the business.

There is NO ENTERPRISE MOBILITY Market!

2009-03-18T12:45:00.000-07:00

Just in case I get one more person who wants to know...
...there is only the newest enterprise productivity platform...in your hand! Let me explain from my perspective...

The Enterprise Opportunity for Mobility
I see the smart phones (e.g., BlackBerry, etc.), as simply the newest enterprise productivity platform. Mobile devices are just like all the other enterprise productivity platforms (desktops, laptops, servers, networks, etc.) and IT needs to develop, deploy and support the mobile assets and services that drive the business. And with the ever improving functionality of the mobile devices (i.e. processing power, UI, screen resolutions, etc.) more enterprise productivity functions are transitioning away from desktop to these mobile devices.

The Enterprise Situation for Mobility
Relative to all the other productivity platforms, Enterprise mobility is growing faster and businesses are more dependent on real-time access:
1) Mobile email (Growing 93% annually - 49M accounts in 2008 to 603M accounts in 2012).
- Radicati Group (2008):
- Wireless email (worldwide) should grow from $15.7B in 2008 to $67.5B in 2012.
- Over 22% of active email mailboxes globally will be accessed via mobility by 2012.
2) Improved Mobile Device Security and secure data access are enabling more mobile business apps
3) The combination of mobile application enablement and the incorporation of "time and location" data are fueling new innovative business uses.

The Mobile Enterprise Problem
While the strategic use of the mobile platform evolves from a "tool" for strategic IT notification into something more. The IT tools to support this new productivity platform have not kept pace. From an IT Service Desk perspective the lack of standard and scalable IT tools makes this potentially the most expensive enterprise platform to support and enable. There is no "risk-limiting" single "killer app" for the enterprise, and no single "mobile support tool" that can address the needs of the entire platform.

The mobile platform “needs” will mature just like the Network Matures at any enterprise. Core to an enterprise mobile strategy IT will need to address...
1) Network Management - tools to determine internal (IT) or external services failures and the tools to inform the users
2) Software (App) Configuration Management and Support. – Test and development tools specific to device OS & local device apps, network/online connected apps and mobile enablement of IT’s Client-Server apps
3) Asset Management (device, user, user-skills, location, etc.) and the advantages of better of field workforce management will emerge to have a strategic role in the business only with the IT organization incorporates that data (static and dynamic) into business advantages.

The Complex Issue of Enterprise Mobility
There is no single mobile player (internal or external) for the enterprise who provides all the services for the whole "stack" of enterprise mobile needs. It won't be long until a variety device functions/service, IT disciples and critical business needs will be mashed-up into highly productivity and very unique configurations for individual, team, and standard corporate-wide uses. Only an eco-system of partners with specialty niche expertise in conjunction with an IT platform vendor could address the enterprise potential. Eventually the mobile enterprise will to incorporate...
• process & task orchestration
• discovery
• service level management
• dashboards & analytics
• application problem resolution
• predictive analysis
• event & impact management
• capacity management
• configuration audit & compliance for enterprise smart phones

The Mobile Enterprise Solution
The solution for the mobile enabled enterprise, is to assign "ownership" of all IT disciplines that correlate with their Mobile functions to ensure that all strategies include and address the unique requirements of this platform.

1) Smart phones should be managed by "Client / PC / end-point" teams that require all the same development, deploy and device management tools.

2) Mobile connectivity (while reliant on local outside service providers) should have all the network tools for monitoring, managing and security.

3) Mobile development teams should optimize mobile applications and enable them to be “easy to use” while addressing security and compliance issues specific to this mobile platform

Basic Building Blocks of Enterprise Mobile Enablement
First Generation (every enterprise)
- IT - Red Alert Notification for infrastructure failures, when normal IT communication tools are lost
- Business – (Phone, email, text) Driven by traditional communication and a single application enabled.
• Primary Benefit: An Insurance policy - Mission critical business app information and IT notification

Second Generation (mature enterprise with workflow coordination)
- IT - Support resources and services for the management of the device, services and user experience (including simple application development tools) and better cost management of mobile devices (re-claim, operational tracking, warranty management, depreciation, supportability, etc.)
- Business - Multiple application and workflow enablement to improve productivity and drive business efficiencies
• Primary Benefit: Business growth in the field and IT Service Desk, Assisted-Services – quicker "time to resolution" (resolve incidents) with tools that can improve “closure time” by over 90%

Third Generation (Pro-active/Smart tools and applications that resolve issues on the fly)
- IT - Cost reduction and automation tools to improve Service Level Agreements - Tools to determine (external) un-resolvable issues.
- Business - incorporating "unique" mobile data (location, time, user information) as part of the managed corporate assets.
• Primary Benefit: Enables self-healing and self-service (knowledge search) capabilities to users, reducing Service Desk call volumes by 60% and increasing access to dynamic relevant business data

An Eco-System of Mobile Partners... (My personal opinion of the players)
As a platform vendor employee I have a unique position to review many mobility products with innovative integrations that bring a variety benefits to our customers. To date we have identified the following as having “best in class” functions for our specific platform architecture, our defined markets and our customer needs.

Alarmpoint (Notification) - Monitors infrastructure with a non-dependency architecture to ensure notification enablement even in total IT failure situations

Aeroprise (Mobility for IT Service Management) - IT service workflows enabled for mobile devices including asset, change and field management

Bomgar (IT Service Management - Assisted-Service tools) - Chat and Client access (remote control) to resolve issues quickly.

Zenprise (Network) - Monitors, troubleshoots, and manages mobile devices, network services and the mobile infrastructure.

No real 3rd generation mobile partners (IT enabled Self-Healing and Self-Service tool) have emerged in a leadership position...but I'm looking.

Collaberation Means Giving Up Some Control....

2009-02-09T23:55:00.000-08:00

A friend of mine twittered, "Collaboration means giving up some control, regardless if you are the David or the Goliath - can your org truly handle that?"

Especially tough words if the Goliath is also clumsy and trips all over himself. The nimbler David's may be painfully aware of how slow the big guy moves. They must wonder at times if he will ever get his feet under him long enough to build any momentum. It would be especially helpful if the Goliath was honest enough to factor "how long it takes" to get things going.

And the David's should set realistic expectations with their management teams. A little guy's agenda may or may not align with the big guy's agenda. Planning time-lines, calendars, internal initiatives, market conditions, reorganizations, and cultural differences could all impact collaborative efforts.

Partnerships are dependent on each party, to leverage the strengths and overcome the others' challenges, in a way that works for both.

A Season for Partnering

2009-02-06T20:25:00.000-08:00

In today's economic environment, companies are looking for every advantage to get more for less. For those in the partnering community its an opportunity to drive home the value of partnering and deliver real economic savings and efficiency gains.

In a recent conversation, I actually had someone say to me, "that this was the right time to 'slow-up' because no one would even notice if we withdrew from our aggressive growth activities." He suggested that we could "take a step back" and take smaller amounts of responsibility.

If your company can live without your partner program "stepping it up" in a down market, then I would suggest that your company could simply live with out you. There is more interest in partnering today then I have seen in a long time. And the focus of these partnerships is revenue attainment. And its an excellent goal to chase, and it should be part of all partner development plans.

This is the season for meaningful partner contributions to your cooperate strategy. It the time to set-up, not stand-down.

Partner Planning and Partnership Life-cycles

2008-10-08T21:16:00.000-07:00

Alliance partnerships are not just about how much one party can give and the other can take. It’s about what each party brings to the table (strengths and vulnerabilities), with an understanding of the shared risks and shared rewards.

First and foremost every partnering discussions should first have clear internal goals and resources to sustain a partner strategy... Every needs to know "why" they need to partner a all?

Second, partnerships have windows. Timing, organizational maturity, re-organizations, a cultural understanding of "shared success" and internal politics can all help or hurt partner opportunities.

Both organizations need to be have realistic expectations and invest over a defined period of time. There must be enough of a "win" for both parties to be healthy and continue the efforts to sustain it.

Defining and building "process flows" that are non-disruptive, sustainable and scalable are essential to avoid excessive stress as momentum and velocity start to take off.

Also, understand what success means for each party and having predefined goals, milestones and transition plans will the partnership evolve and adapt when the market changes.

Finally, knowing what the possible "end-game" options are for both parties can help partnership self-identify obvious next-steps or appropriate times to make changes over the entire life-cycle.

There are huge benefits in partnering but its important to enter into them with the right perspective, resources, flexibility and targeted goals.

Driving To Success

2008-09-14T22:46:00.000-07:00

Its frustrating to see initial partner success hit a momentum killer. Trying to re-negotiate and re-define a "pre-revenue" business, is like tying your shoe in a race. If a successful partnership has a clear goal, then both parties should be able to overlook the occasional "getting it started" obstacles as the 2 teams learn to work together. No business plan or partnership is perfect out of the blocks. And sweating over the early stage small stuff, can tarnish the partnership over the entire life of the relationship.

My suggestion, be patient and work through the tactical difficulties in the back office. Get the business working first. Never negotiate little problems in front of executives, sales, or customers. Spin confusion to a "learning opportunity" that drives best-practice changes.

Partnerships need to build business, confidence and revenue. Be prepared to solve issues quickly and quietly. Escalate only as a last resort, knowing it can have a long-term impact on the relationship.

Sometimes it’s a Perfect Fit

2008-06-23T09:22:00.000-07:00

Recently I was part of a partner acquisition that was done the “right way.” It took lees then a year from first conversation to acquisition. The partner joined the alliance program, completed their integration, re-worked their message and re-focused their resources to support the partnership. Once we established the “fit and value” in this partner product, we were able to take the field momentum and setup a series of meetings that accelerated the vetting process until it was clear that this partner was on a path for M&A.

Not every partnership ends this way, but the reality is that this acquisition process was enabled through the standard partner development process. Many partners want to “join” a “big” partner program for exposure. But many partners miss the opportunity to explore strategic conversations by not doing their homework (completing integrations and re-writing their marketing collateral and sales force messaging) to better fitting into the world of big “enterprise software” selling.

It’s pretty exciting to watch partnerships evolve, but there is a lot of work on both sides.

The Only Constant For Enterprise Partnering is the Constant Change

2008-06-09T22:21:00.001-07:00

More Service Subscription-model partners are finding ways to work with on-site enterprise license-model partners. It seems like only a few years ago that some start-ups introduced a new subscription-model. The model has proven a challenge for the larger enterprise software companies to embrace. But slowly the big guys are finding ways to partner with subscription-models. One of the biggest challenges has been figuring out what appeals most to a specific customer-type and compensating the sales force. And just as we start settling in with partner strategies that seem to work, a new model begs to be addressed, the Advertising model.

The Advertising model will displace some subscription model partners, but this Google-like model brings new challenges to the large Enterprise Software companies. And there are lots of questions to ask...
- With value of a large sale force greatly diminished, how will partners measure success?
- How do both companies thrive with their different business models?
- Can they find ways to partner?
- Do they need to partner?
- Will they need to develop a new model for partnering?

And now the self-service model is slowly displacing the agent intermediary model. This change, places a whole new value on ease-of-use, customer-experience and low-maintenance/high-reliability products. This new element along with the new business models create a huge opportunity for partnering models and innovative solution offerings.

Darwin's theory appropriately applies here, the most "adaptable" will survive.
How adaptable is your partner-business model?

Its that time of Year...when Every Meeting is Delayed by Vacations

2008-06-05T23:01:00.000-07:00

Its that special time of year when every decision or strategic project is impacted by a summer vacation. Ok, I'm guilty too. I'm taking a day-off next week if I can cancel or move all my meetings. Every one seems so polite but I know what their thinking. This week I was delayed on the announcement of a new partner-based solution, because the person who plays a role processing the paperwork was out.

Tip of the week:
During the summer I am becoming a fan of the "voting button" in Outlook. It allows the virtual "vactioning" team members to have a say without setting up the impossible meeting time with all the players.

The biggest challenge...the "Voting Button" doesn't work on the Blackberry. So forget being able to sit at the beach and approve my stuff between a big set of waves...I still have to make a couple of strategic runs to the nearest Starbucks (hotspot) to approve things! Come on Blackberry give me email voting!

The Role of Legal in Negotiating Partnerships

2008-06-04T23:06:00.000-07:00

On many occasions I have had the opportunity to talk to the legal teams of "potential partners" about "generic" partner agreements. It is the job of the legal team to identify the "potential" risks. And explore work-around options to resolve issues. In some cases, negotiating an "industry-standard" agreement is not an option. And the reality is that doing business involves some level of risk-taking.

In these rare cases I have found legal teams recommending that an "industry changing" partnership NOT happen because they were "not comfortable" with the language in an "industry-standard" generic partner agreement. In those situations the potential partner's executive team is forced to weigh the "opportunity loss" against the "risks" and make a go/no-go decision.

I will avoid the lawyer jokes...but its important to remind a legal team that they serve the business. Sometimes legal teams forget this and they see the negotiation opportunity as a way to justify their role, or display their wealth of knowledge, or secure a leadership role in the organization. It's in those situations that I like to remind counsel that they are employed because the organization has taken enough of the right kinds of risks to grow the business.

And of course, this is never true of my legal team, nor of the wonderful partners I work with everyday.

Who's Needs a Partnership Anyway....

2008-05-27T07:20:00.000-07:00

As a portfolio partner manager I am asked to reach out to outside organizations to see if there is interest in working together. I am amazed how often potential partner organizations are not able to leverage partnering strategies.

When building out their original business plans and channels, many organizations forget to consider alternative revues that can be attained through partnerships. Once an organization is committed to a specific model for doing business they may be unable to adapt. If the organization is unable to see the benefits of a new partner-oriented opportunity, then there may be no way to align the business resources in order to take advantage of a partnership.

In some cases I have found engineering-rich companies that think they don't need need any help. In other cases, organizations with a strong sales teams have problems sharing account ownership. Organizations with a strong vertical marketing skills have challenges re-messaging to a wider audience.

Partnerships start with a dialogue and require adjustments to existing processes. Often times the adjustments need support from the highest levels. The benefit analysis should include measuring new revenues, time-to-market, market-reach, new value propositions, etc. Partnerships can often justify the impact of a change...as long as the business is open to change.

Partner Events Can Provide Innovation Dialogue - Lisbon Event Photos

2008-05-18T18:10:00.001-07:00

My personal focus at Shows and Partner Events that I attend is to drive as may short "get-to-the-point" discussions and quickly vet-out partnering possibilities. In a short period of time I can have a series of executive level meetings, explore timelines and outline next-step "action items" that would normally take me weeks and $10,000+ in travel.

The ROI of an effective show should be measured in both long-term and short-term benefits. Knowing what you want (individually and corporately) before you get to an event makes a huge difference.

Is OK to have fun...but you have to work the event and commit to follow-up action items right away.

Ready, Set, Grow

2008-05-06T18:55:00.000-07:00

I have run into partners who say they .are "ready to go" with a their revenue generating partner product today launch. The reality, partnerships need a a lot of work to be ready.

I can think of 5 stages in my experience partners need to work through to 'really" be ready:

1) Define the goals and secure cooperate "buy-in" to support the partnership long-term.

2) Get all the partner paperwork completed and make sure product integrations get validated.

3) Create a product data sheet, co-marketed solution materials and company summary information.

4) Create the education materials for Technical and Account resources and schedule a role-out plan.

5) Set-up demand-generation activities and customer-facing events to build momentum.

After that a partnership is ready to grow. Be patient while working through all the steps to pursue success. Short-cuts will slow up the process and the wrong time.

Interesting Mobile Market Developing

2008-04-28T13:20:00.000-07:00

My observations about the mobile market...

Early mobile solutions were software product extensions. Next generation solutions were "mashed-up" combinations of applications. So whats next?

Feels like mobile devices are becoming mainstreamed "value-points" for every application and they can add strategic "new data" that is uniquely available from the devices itself (i.e. location). That means the way these devices are supported and managed, better include remote configuration and remote control functions for us "end-losers" who always find new ways to stump the help desk.

ITIL and BSM A web example of Business Service Benefits

2008-04-23T16:15:00.000-07:00

For those who have asked about ITIL and BSM...

Here is a simple and fun way to explain it.
Its a 5 minute web game without the stress-filled test.

ITIL - BSM Game Link

Changes To My Alliance Team

2008-04-23T10:03:00.000-07:00

My organization has a new leader. Should be very exciting to see how new leadership will influence current strategies and relationships. See the press release.

Customer Service Could Cost You...

2008-04-20T15:39:00.000-07:00

I recently read a couple of articles that got me thinking about the enterprise software industry. There is need for real "account management" and for products to provide a "higher-layer" of value. The first article focused on the poor customer service that is driving business away from telecom vendors at a very high rate. Interesting how this same industry with a high customer "churn-rate" spends millions each year buying efficiency software products and millions more in marketing to find new customers. Its easy to forget about the customers you have and improving their experience.

The second article I read a few months ago made a couple of bold claims. "Don't get sidetracked by describing your service or product - stay focused on solving their problem...Interview people about their particular challenges, needs, and problems. Try to get enough data to help see the trends among your target audience. By tailoring your (message) to solving your customers' problems, you will position your company to be magnetic to your customers." Great account management advice. But that may mean reaching beyond your landscape of traditional buyers and having to understanding the customers' whole business.

I noticed a new trend, many products have expanded their functional focus from the "worker bee" by providing additional "measure and manage" features (i.e. dashboards, analytics and monitoring) to those that "manage" the worker-bees. This NEW LAYER of value allows managers and executives to have a better real-time view of the business and it helps them justify their "product" spend. Product companies that sell "efficiency tools" need to build value-added layers that Measure (the benefits) and Manage (the people) better. We need to look after all the customer layers or they may feel neglected enough to ditch us at some point.

Project and Portfolio Management, ITIL and BSM Feeding Off Each Other

2008-04-18T08:55:00.000-07:00

I continue to see momentum around Project and Portfolio Management (PPM) from enterprise customers and enterprise sales teams. In a recent article I found at CIOupdate.com it claimed that by implementing Project Management, ITIL and BSM together a business could decrease IT budgets by 70%. Here is the full article.

While I question the accuracy of this bold statement, I agree with the author's main point, that a more strategic use of project management across IT and coordinated with the rest of the business it would produce significant financial rewards. Project Management should not be an isolated discipline..but part of a more integrated business service. Combined with the "common sense" benefits from the adoption of ITIL and the top-down approach of BSM - it should always provide significant and far-reaching corporate benefits.

By definition PPM is under going dramatic change. PPM is expanding beyond its historic tactical role and is helping to redefine the BSM enterprise software industry and the role of IT to the business. It should be interesting to see how this market matures.

Don’t Shop when You’re Hungry & Ask For Help When You Need It!

2008-04-16T21:37:00.000-07:00

I found an article in a Harvard Business Review article...suggesting that shoppers "resist the urge to buy" when they are hungry (i.e. attempting to compensate for poor performance or missing key components in the technology market). Instead we are encouraged to "expand" from our strengths. Brilliant idea!

However, when a team is "too hungry" it can do some unhealthy things like rewarding people for throwing a "tactical patch solution" at a strategic problem. In some cases they depend on people who are not personally involved or even subject matter experts in the specific line-of-business they plan to fix. I have seen the chaos when people are driven to "MAKE A DECISION" quickly. They drive blindly through the initial exploratory and vetting stages with "process expertise" (often involving top executives) who just want to get to "a" decision.

When making a "decision" that will impact the business, its OK to ask for help...especially from "non-powerful" people with niche expertise and specific business knowledge.

ASK FOR HELP FROM THOSE THAT KNOW AND CARE...THEY WILL LIVE WITH A DECISION LONG AFTER YOU HAVE MOVED ON TO THE NEXT "BIG" DECISION.

Inside Selling - You Got To Do It.

2008-04-13T10:27:00.000-07:00

Inside selling is strategic for the success of alliances and partnerships, especially those that are international. It is important to communicate with internal strategy groups, regional sales teams and executives to ensure there is "buy-in" and a clear understanding of the benefits, goals, challenges and/or liabilities. Alliance managers in large organizations have a complex matrix of individuals, committees and agendas they need to work through as they explore future partnerships. Smaller organizations have few layers in the decision making process and need to be patient with larger organizations in the earliest stages.

Holding strategic "decision-making" meetings before adequate inside selling and collective "buy-in" has been accomplished. When the enemy from within surfaces they can kill momentum. Its important to work through the difficult details early and document the decisions and action-items. I found an interesting article on this subject.

In recent weeks I have been especially thankful for securing "rules of engagement" with partners when things were going good. When we were suddenly confronted by industry-changing announcements we were able to calm emotions (with some additional inside selling), focus on the goals of the partnership and begin working on the appropriate next steps. Inside selling is undocumented art-form that every successful alliance manager learns to do in their organization.

Coopetition, Overlap and Partner Around Strategies

2008-04-07T21:36:00.000-07:00

Rarely are partnerships perfect. My experience has consistently shown that the business of a partnership requires a healthy and balanced road map. Which by its very nature creates situations where partners will have overlap issues.

I have worked with teams that react defensively (almost with a sense of paranoia) extremely terrified that an overlap issue is an indication that the entire businesses and partnership is under attack. Likewise I have worked with organizations that have been very confident and laser-focused on their core business, the goal of the partnership, their ability to deliver a best-practice product and willingness to to work with over-lap issues for the benefit of the solution-value, the customer need and the industry.

Obviously, it's easy for organizations to simply cut partners for minor overlap issues, but easy is not always better. The goal of a partnership should be driven by a business plan to reduce-cost, speed-up time-to-market, introduce innovation, and/or address customer/industry needs. In the case of organization's with mature partner strategies, a clear "partner-around statement" process can address confusion, and drive success past an overlap speed bump. Some good co-opetition articles from IBM, The New Economy Index, and Channel Register.

Program-based Partner Development, Executive Sponsors and High Maintenance

2008-04-03T21:38:00.000-07:00

Many large partner programs provide guidance and assistance to help partners adapt their marketing and gain a quicker foothold with targeted sales organizations and customers. It's important to take advantage of all the "program-based" resources, training, and development process.

Many partners over emphasize the need for an executive sponsor and want to jump-over the process. Executive sponsors can be very helpful in overcoming obstacles, challenges and provide top-down support. However executive sponsors that have to get involved with high maintenance partners on a regular basis, because they have skipped the standard partner development process, can make the partnership expensive to maintain from a corporate perspective.

The purpose of most partner programs is to reduce costs, maximize efficiencies, anticipate scalability issues and drive profitability for both organizations. Being “easy to work with” (i.e. modeling the cultural fit between the organizations) is a benefit that is often over-looked by everyone except the alliance managers.

When an executive sponsor has been identified, be selective when requesting or leveraging their assistance, it will cost you.

One Effort - Outbound Marketing, Sales Messaging and Customer Engagement

2008-04-02T15:13:00.000-07:00

Many partner programs are intended to build an ecosystem of supportive or “strategic” partnerships that culminate in logo sharing, press releases, and promoting a “working nice-together” relationship. Many folks in alliance work refer to these as “Barney Partnerships" (i.e. the purple dinosaur that sings, “I love you and you love me…”).

Partnerships that are built on “revenue goals” must be more tactical in their marketing and focused on customer adoption. It's important to build campaign marketing efforts (with sustained messaging) and jump-start sales success (to build sales momentum and confidence). Both organizations need to accommodate for duplicate teams and sales overlay resources at initial customer opportunities.

The pipeline growth, compressed sales-cycles, sustained sales activities and revenue success is the byproduct of effective sales messaging that includes field education, technical training and sustained customer messaging. It's also important to ask the sales organizations to identify “target accounts” and set-up customer engagements. The sales force also needs to promote “success stories” to the rest of the sales force to build momentum. Its amazing how easy it is to forget some of these steps in the early stages of the partnership.

Partner of My Partner

2008-03-21T12:12:00.000-07:00

One of the most creative elements in alliance management is seeing the 1+1=3 opportunities that can be leveraged. When two (outside) partners independently work together and bring a "NEW" joint-value to the table for a 3rd partner (me) to take to market. Its a win for all 3 partners and the industry (time-to-market speed, development cost reduction, and sharing go-to-market resources). I don't know how I over-looked this in the past...but it appears to be the new trend in recent partner planning discussions and part of my long-term strategies moving forward.

Example - Partner of my partner

2008-03-21T00:13:00.000-07:00

At the RSA show in SF.

Run over By a Corporate Agenda

2008-03-20T13:46:00.000-07:00

Recently I had the experience of working tirelessly on the number of partner projects and initiatives. Playing the role of the project caretaker; taking a team-building approach to negotiate the win-win-win (my team, partner team, and customer/industry benefit) opportunities. And while I was busy juggling stuff, I was executing to plan pretty effectively until...

...I got broadsided an unexpected, earth-shattering and market-changing "corporate surprise." My best laid plans gone in one press release. A ll my projects and plans were impacted. Everyone on my team took a big step backwards to adjusted to this new "corporate agenda."

Naturally, partner emotions ran high with speculation of how this "news" would negatively impact current efforts. Everything was instantly delayed, projects scaled-back, and communications went silent. It's important to remember that markets are "dynamic" and "industry-changing" events will reshape the landscape where the original plans were defined. Alliances need to be flexible, patient and understanding as companies adjust to change.

When impacted dramatic chaanges teams should...

1) re-evaluate the original plans,

2) quickly make a go/no-go decision,

3) and if the decision is to move forward adjust "without emotion" and chase the "new" goal.

Alliances should be the most nimble and market-centric asset a business can leverage. Also, don't attack or target frustrations at the alliance teams. They commonly get blind-sided by change. Its no fun to be the punching bag for partners facing a major disruption. It is rewarding to be a first-responder and pioneer a new agenda, vision and goal.

Your Elavator Pitch - Portfolio Partner Managers

2008-03-16T18:53:00.000-07:00

As a technology portfolio partner manager (focused on a specific market segment) I am asked to reach out to third party organizations to see if there is potential in working together. I am amazed how many potential partner organizations are not able to take advantage partnering strategies. In the Build-Buy-Partner options many organizations never included the "Partner" options to reduce costs, speed-up go-to-market or expand industry reach.

The trends I see...
1) Engineering driven companies sometimes don't think they need need any help...

2) Sales/marketing driven organizations sometimes don't want to re-think revenues they built their business plans around.

3) Vertical partners often times don't see the business opportunities that partners could open up with little risk to their current business.

In most cases a single conversation with the executive team is all it takes to start making the changes that include partner strategies.

Underdog Opportunities

2008-03-10T08:34:00.000-07:00

I was a fan of the old Rocky movies. I find myself rooting for the underdog to beat all odds. I have the same opptomistic attitude in the technology space when I find a team of innovators with a vision (i.e. business plan) and an "A" team of players that believe in their offering. The biggest challenge that I find blocking successful alliances is the language barrier.

Innovative point products find their way (via sales) to early adpotors (through a long sales cycles), over-coming a variety resistance issue to install on top of a pre-existing platform or architectural design.

The language issue is primarily the challenge of a flexible and agile start-up trying to embracing the plaform value. Asking a start-up to fit their partner product into a platform strategey, is often a challenge to both organizations. Platform vendors feel its an issue of the tail "wagging" the dog. But at the end of the day small start-ups will find their sales cycles "mainstreamed" and part of large opportunity solution discussions. The earlier a start-up can adopt and embrace platform marketing and messaging the sooner they can expect field success.

Know the Table you Want to be at and Bring Something Real

2008-03-06T22:53:00.000-08:00

I see 2-5 partner applications a week interested in joining our partner program. What is interesting is the various levels of "known value" and "corporate-wide support" these applications initially identify. Interesting not all the "innovators" or "perfectly aligned" technology companies ever get off the ground. And some complex partners with less of a fit sometimes raise to the top.

In some cases a lone visionary is driving the engagement. Interesting initial meetings fade when the "go-forward" planning discussions start and the partner company is asked to accommodate changes to their current business model. You can feel the tide turn when management teams get surprised by a "new" request.

Alliance folks should understand the strengths and weakness of a new partner program and walk through the risk/return issues with their management teams and the their counter-part before hand. Management teams need to know "the cost" of partnering and the desired end game. I have seen great opportunities with "cool technologies" (a red flag term for me) that expect special treatment because of they are "cool." Sorry, but today's cool stuff is tomorrows standard stuff. The real business questions Alliance folks should ask...

- Of all the (partnering) tables I could sit at what is best for my business goals.
- What is the cost of sitting at this table (real and lost opportunities elsewhere)?
- Know what you can and can not bring to the table before you get there.
- Walk away early and know your internal "show-stoppers" before talking with a partner.
- Choose the best one(s) and drive it with 100% management support.
- Be ready to make the "painful sacrifices" to build or keep momentum.
- Measure milestones and success, and communicate it to the whole corporate team.
- Watch for changes (teams, business goals, industry) and be ready with a plan B.

The Alliance "Grim-Reaper" Guy

2008-03-04T11:49:00.000-08:00

Recently I was accused of being the "grim reaper" of partner management, in humor of course. But it got me thinking about how many dead or dying partnership just continue because of the painful work involved in terminating the relationship. I had to remind myself that partnership exist to serve the needs of both partners AND the market. It has to be that "win-win-win" value (customers and both partners). If one of those 3 wins is missing then the partnership is not working. And partner life-cycle questions need to be applied to determine status and next steps. In my case a number of legacy partnerships I inherited came up with the same ending...time to terminate.

OK, not all the partners in my portfolio are under-achievers. I carry a quota on revenue attainment for partner product sales and I plan to end the year 200%+ of quota. So I have had a lot of success with the partner selection process. But I am cleaning house and found almost half of the current partners (all the legacy ones) came into partnership with "unrealistic" expectations and sat around waiting for success. As I end the partnerships I find myself "improving" my role as the 'trusted advisor' for folks that sell these partners products. Also, some of the partners 'thanked me' for the 'brutal honest' feedback that identified elements that contributed to the failing relationship.

If you ask me why some of these partners fail...sometimes organizations change (people or business goals) and sometimes the market changes. Either way the hard work of "actively watching" the changes that could impact a partnership give both parties the best opportunity for continued success. Ignoring a failing partnership never helps.