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 project
They 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
Summary
A 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.
Saturday, January 14, 2012
Monday, September 12, 2011
Asset-less IT…What's the future of IT Service Operations’ ITAM?
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.
Monday, August 1, 2011
The Newest Business Super-hero “Shadow IT” – when IT says no…or wait!
“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.
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
Sunday, July 31, 2011
DevOps Micro and Macro-Level Discussions
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
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
Monday, July 25, 2011
BSM, ITIL, Agile...you should have put a (corporate) ring on it.
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
Saturday, July 23, 2011
Have the Stars Aligned for a DevOps Discussion? …Non-IT Compelling Events
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
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
Friday, July 22, 2011
If it aint broke, don't fix it....but IT is broke and DevOps can fix it!
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
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
Thursday, July 21, 2011
You Got Your Agile in My ITIL...
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
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
Wednesday, October 28, 2009
When "Getting The Deals Closed" Is Not Possible
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.
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.
Sunday, May 3, 2009
When the Business need to Cut Cost - IT Needs ROI Tools
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.
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.
Wednesday, March 18, 2009
There is NO ENTERPRISE MOBILITY Market!
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.
...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.
Monday, February 9, 2009
Collaberation Means Giving Up Some Control....
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.
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.
Friday, February 6, 2009
A Season for Partnering
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.
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.
Wednesday, October 8, 2008
Partner Planning and Partnership Life-cycles
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.
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.
Sunday, September 14, 2008
Driving To Success
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.
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.
Subscribe to:
Posts (Atom)