#entarch Following my blogpost on EA and the Big Picture, @carlhaggerty asked does it matter if EA disappears into a core C-Suite competency?
Clearly it matters to some people, especially those who have committed themselves and their careers to the idea of enterprise architecture (EA) as an independent practice. If EA were to disappear, some people would be upset, and some organizations would need to find a new mission or fold.
@carlhaggerty agreed that some people might be upset but thought if it is in the best interests of the enterprise surely it would be the best thing to do.
Well perhaps. I am certainly not a defender of the current position of EA as a defacto knowledge silo, because this offends against the principles of EA itself. (See my post on A Value Proposition for Enterprise Architecture.)
But I have two problems with making a judgement about "the best thing to do" purely on the basis of "the best interests of the enterprise". The first problem is who shall speak for the best interests of the enterprise. C-level executives are often driven by extremely short-term considerations, such as stock market prices, as well as their own personal advantage. Merging enterprise architecture into C-level management might mean that EA would be forced to adopt this perspective to the exclusion of any other perspective. The second problem is that there have always been enterprises that are based on a corrupt business model - flawed or unethical - and there is clear conflict between the best interest of these enterprises and the best interests of society as a whole.
Ultimately, this comes down to the possibility of designing a complex organization to produce behaviour that is effective, intelligent and ethical. @carlhaggerty would rather see EA being done whether or not an EA exists in an enterprise, and he personally doesn't care who ;) I agree with him up to a point - I don't care who does EA, but I do want to see an organizational design giving a strong independent voice to an EA-like perspective.
Friday, December 31, 2010
Wednesday, December 29, 2010
EA and the Big Picture
#entarch Some people think that what uniquely characterizes enterprise architects is that they are the ones who "get the big picture".
If this is true, it is because EAs have differently wired brains to the rest of humanity, or because their position and practices give them a different perspective on the enterprise? For a summary of a Twitter debate on this topic, see my blogpost Getting the Big Picture.
The next question is what this implies for the relationship between EAs and the rest of the enterprise. If EAs have these special powers of perception, do other people find this threatening? And how much of the Big Picture can be communicated? For a summary of a Twitter debate on this topic, see my blogpost Selling the Big Picture.
When I raised this question on the Enterprise Architecture Network group on Linked-In, Graham Berrisford thought this was a bit tautologous. "Enterprise Architecture is the big picture, therefore Enterprise Architects are the ones who have the big picture."
But it is only a tautology if that's how you define enterprise architecture and if you only recognize one kind of "big picture". Stock market analysts and venture capitalists might have an entirely different "big picture".
To the extent that enterprise architects have a single set of lenses for viewing the enterprise (e.g. Zachman), their claim to have THE big picture is disputable. (Hence my interest in lenscraft - the use of multiple lenses providing alternative perspectives.)
Tuomo Stauffer suggested that the big picture comes from the board. In which case EA's job is not to "get" the big picture but to codify it.
But my question wasn't just whether the association between enterprise architecture and big-picturehood was true, but also what this association would imply (a) for the recruitment and development of EA skills and (b) for the (possibly threatening) relationship between EAs and the rest of the management world.
If this is true, it is because EAs have differently wired brains to the rest of humanity, or because their position and practices give them a different perspective on the enterprise? For a summary of a Twitter debate on this topic, see my blogpost Getting the Big Picture.
The next question is what this implies for the relationship between EAs and the rest of the enterprise. If EAs have these special powers of perception, do other people find this threatening? And how much of the Big Picture can be communicated? For a summary of a Twitter debate on this topic, see my blogpost Selling the Big Picture.
When I raised this question on the Enterprise Architecture Network group on Linked-In, Graham Berrisford thought this was a bit tautologous. "Enterprise Architecture is the big picture, therefore Enterprise Architects are the ones who have the big picture."
But it is only a tautology if that's how you define enterprise architecture and if you only recognize one kind of "big picture". Stock market analysts and venture capitalists might have an entirely different "big picture".
To the extent that enterprise architects have a single set of lenses for viewing the enterprise (e.g. Zachman), their claim to have THE big picture is disputable. (Hence my interest in lenscraft - the use of multiple lenses providing alternative perspectives.)
Tuomo Stauffer suggested that the big picture comes from the board. In which case EA's job is not to "get" the big picture but to codify it.
But my question wasn't just whether the association between enterprise architecture and big-picturehood was true, but also what this association would imply (a) for the recruitment and development of EA skills and (b) for the (possibly threatening) relationship between EAs and the rest of the management world.
Thursday, December 16, 2010
Complexity and Power 2
#entarch #orgintelligence In an earlier post, I pointed out the architectural trade-off between Complexity and Power. There may be a choice between a simple-but-inefficient solution and a more sophisticated solution, and this choice has important structural implications. The architectural design of a large enterprise involves any number of these choices.
Furthermore, a given organization has a finite capacity for managing sophistication and complexity, and a limited willingness to invest in the management costs and overheads that may be required to extract the full benefit from more powerful systems.
There are two agendas that each appear to address opposite sides of this situation. The first is the simplification agenda, advocated most persuasively by my friend Roger Sessions, which addresses the problem that most organizations and their support systems (including IT) are riddled with unnecessary complexity.
The second is the maturity agenda, which suggests that an organization can extract more benefit from certain systems and practices and technologies by becoming more sophisticated. Maturity models are typically arranged as a series of maturity levels, and should be derived (although I suspect many of them aren't) from a robust theory of organizational change and technology adoption.
There are some subtle and usually ignored issues in the interaction between these two agendas, but I don't want to go into these issues here. Instead, I want to point to a couple of critical questions
The first question looks like a simple engineering question, which should be bread-and-butter for requirements engineers. The need for complexity and power is driven by some set of demands, together with an economic argument that links cost to value (possibly but not necessarily expressed in financial terms).
The second question is clearly an architectural question. Two things are intuitively obvious about the design of complex machines: not every component needs the same amount of power and complexity; however, some components need proportionality of power and complexity. (It doesn't make sense to put a massive engine in a tiny car, and a fast car needs more powerful brakes than a slow car.)
Power and complexity are higher-order examples of so-called non-functional requirements. Architects need to be able to reason about the composition and decomposition of non-functional requirements.
The enterprise is a sociotechnical system, so I'm not just talking about technical components here. A racing car needs a driver whose reaction speeds are matched to the speed of the car, and a maintenance team capable of rapidly diagnosing and fixing all the minor technical problems that could occur during the race.
Similarly, an enterprise needs a set of management capabilities whose intelligence is matched (proportional) to the power and complexity of the operations and operational systems - thus we have an architectural view of the enterprise as an intelligent sociotechnical system, with an appropriate balance of power and complexity.
I don't want to hear that the complexity has been completely removed from the technical systems, because I then fear that the necessary complexity has been merely displaced onto the people inside the organization - or worse, onto the customers.
Conversely, I don't want to hear that the complexity has been completely embedded inside the technical systems, because I then don't trust the people inside the organization to fully manage this complexity.
What I want to hear is that there is just enough complexity and power in the technical systems AND at least enough intelligence in the human systems to manage this complexity and power properly. And I expect the enterprise architect to be responsible for maintaining this proper balance.
Furthermore, a given organization has a finite capacity for managing sophistication and complexity, and a limited willingness to invest in the management costs and overheads that may be required to extract the full benefit from more powerful systems.
There are two agendas that each appear to address opposite sides of this situation. The first is the simplification agenda, advocated most persuasively by my friend Roger Sessions, which addresses the problem that most organizations and their support systems (including IT) are riddled with unnecessary complexity.
The second is the maturity agenda, which suggests that an organization can extract more benefit from certain systems and practices and technologies by becoming more sophisticated. Maturity models are typically arranged as a series of maturity levels, and should be derived (although I suspect many of them aren't) from a robust theory of organizational change and technology adoption.
There are some subtle and usually ignored issues in the interaction between these two agendas, but I don't want to go into these issues here. Instead, I want to point to a couple of critical questions
- how much complexity and power does a given enterprise need (requisite variety)
- how should this complexity and power be distributed and connected
The first question looks like a simple engineering question, which should be bread-and-butter for requirements engineers. The need for complexity and power is driven by some set of demands, together with an economic argument that links cost to value (possibly but not necessarily expressed in financial terms).
The second question is clearly an architectural question. Two things are intuitively obvious about the design of complex machines: not every component needs the same amount of power and complexity; however, some components need proportionality of power and complexity. (It doesn't make sense to put a massive engine in a tiny car, and a fast car needs more powerful brakes than a slow car.)
Power and complexity are higher-order examples of so-called non-functional requirements. Architects need to be able to reason about the composition and decomposition of non-functional requirements.
- Let P be some property of systems and components - say performance or quickness or reliability or security or throughput or whatever. If the components of a system have properties P(1) ... (Pn), what can we say about the composite property P of the whole system?
- Conversely, if we have a requirement for the whole system to have property P, what can we say about the properties P(1) ... (Pn) of each component?
The enterprise is a sociotechnical system, so I'm not just talking about technical components here. A racing car needs a driver whose reaction speeds are matched to the speed of the car, and a maintenance team capable of rapidly diagnosing and fixing all the minor technical problems that could occur during the race.
Similarly, an enterprise needs a set of management capabilities whose intelligence is matched (proportional) to the power and complexity of the operations and operational systems - thus we have an architectural view of the enterprise as an intelligent sociotechnical system, with an appropriate balance of power and complexity.
I don't want to hear that the complexity has been completely removed from the technical systems, because I then fear that the necessary complexity has been merely displaced onto the people inside the organization - or worse, onto the customers.
Conversely, I don't want to hear that the complexity has been completely embedded inside the technical systems, because I then don't trust the people inside the organization to fully manage this complexity.
What I want to hear is that there is just enough complexity and power in the technical systems AND at least enough intelligence in the human systems to manage this complexity and power properly. And I expect the enterprise architect to be responsible for maintaining this proper balance.
Wednesday, December 15, 2010
An Architectural History of Social Networking
@ruskin147 is in California to meet the networking pioneers, including Stuart Brand.
In 1985, Stuart Brand was one of the founders of an online community called the Well. As Rory reports, the Well provided "inspiring stories of the power of online communication, as its members used its forums to share their lives, their thoughts, and their passions - whether it be for obscure technology questions or discussions about the meaning of life".
In 1994, Brand wrote a brilliant and controversial book about architecture, How Buildings Change, which among other things contained a theory about evolutionary change in complex systems based on earlier work by the architect Frank Duffy. The theory was then known as Shearing Layers; Brand now prefers to call it Pace Layering. If there is a difference between the two, Shearing Layers is primarily a descriptive theory about how change happens in complex systems, while Pace Layering is primarily an architectural principle for the design of resilient systems of systems.
In the original Shearing Layers theory, the slowest-moving layer is known as Site. In the context of physical buildings, this is the geographical setting, the urban location, and the legally defined lot, whose boundaries and context outlast generations of ephemeral buildings [via Wikipedia].
An interesting question for Brand then is whether social networking continues to occupy the same "Site" as early initiatives such as the Well. In other words, the boundaries and context outlasting generations of ephemeral technology.
Brand told Rory that he saw some of the same principles in Facebook that had governed The Well: "I'm really impressed at a lot of the instincts that Zuckerberg has had. Taking non-anonymity as an absolutely fundamental value of his company and thereby beating off the competition. A Facebook identity is one of the most valuable things his company offers. The lack of anonymity is what gives it value." [Friendster, Facebook and the Well]
But that's not quite the same as asserting a historical path from the Well to the present day. The critical question here is not how aware Zuckerberg and his associates were with the history of social networking, but to what extent this history directly or indirectly influenced their actions and choices. For example, our collective understanding of "anonymity" is coloured by the past couple of decades of internet and pre-internet activity. Zadie Smith (a near contemporary of Zuckerberg at Harvard) talks about Zuckerberg's idea about what a person is, or should be, and worries that her own idea of personhood is nostalgic, irrational, inaccurate [New York Review, 25 Nov 2010]. And of course ironic.
Where exactly did Zuckerberg's idea of personhood come from? There may be a sense in which echoes of the Well may persist in Facebook through the way such concepts are understood and managed. And although we wouldn't necessarily take Brand's opinion of this at face value (or for that matter Zuckerberg's) there can be few people whose opinion would be so interesting and well-informed.
See also
Roger Hudson, The Evolving Web - A Pace Layering view of the development of the Web and the W3C (March 2008)
Howard Silverman, Panarchy and Pace in the Big Back Loop (People and Place, March 2009)
In 1985, Stuart Brand was one of the founders of an online community called the Well. As Rory reports, the Well provided "inspiring stories of the power of online communication, as its members used its forums to share their lives, their thoughts, and their passions - whether it be for obscure technology questions or discussions about the meaning of life".
In 1994, Brand wrote a brilliant and controversial book about architecture, How Buildings Change, which among other things contained a theory about evolutionary change in complex systems based on earlier work by the architect Frank Duffy. The theory was then known as Shearing Layers; Brand now prefers to call it Pace Layering. If there is a difference between the two, Shearing Layers is primarily a descriptive theory about how change happens in complex systems, while Pace Layering is primarily an architectural principle for the design of resilient systems of systems.
In the original Shearing Layers theory, the slowest-moving layer is known as Site. In the context of physical buildings, this is the geographical setting, the urban location, and the legally defined lot, whose boundaries and context outlast generations of ephemeral buildings [via Wikipedia].
An interesting question for Brand then is whether social networking continues to occupy the same "Site" as early initiatives such as the Well. In other words, the boundaries and context outlasting generations of ephemeral technology.
Brand told Rory that he saw some of the same principles in Facebook that had governed The Well: "I'm really impressed at a lot of the instincts that Zuckerberg has had. Taking non-anonymity as an absolutely fundamental value of his company and thereby beating off the competition. A Facebook identity is one of the most valuable things his company offers. The lack of anonymity is what gives it value." [Friendster, Facebook and the Well]
But that's not quite the same as asserting a historical path from the Well to the present day. The critical question here is not how aware Zuckerberg and his associates were with the history of social networking, but to what extent this history directly or indirectly influenced their actions and choices. For example, our collective understanding of "anonymity" is coloured by the past couple of decades of internet and pre-internet activity. Zadie Smith (a near contemporary of Zuckerberg at Harvard) talks about Zuckerberg's idea about what a person is, or should be, and worries that her own idea of personhood is nostalgic, irrational, inaccurate [New York Review, 25 Nov 2010]. And of course ironic.
Where exactly did Zuckerberg's idea of personhood come from? There may be a sense in which echoes of the Well may persist in Facebook through the way such concepts are understood and managed. And although we wouldn't necessarily take Brand's opinion of this at face value (or for that matter Zuckerberg's) there can be few people whose opinion would be so interesting and well-informed.
See also
Roger Hudson, The Evolving Web - A Pace Layering view of the development of the Web and the W3C (March 2008)
Howard Silverman, Panarchy and Pace in the Big Back Loop (People and Place, March 2009)
Tuesday, December 14, 2010
Conceptual Architecture
Interesting article today about Andrew Zambelli, former aide to Mario Cuomo and now appointed aide to his son Andrew Cuomo, describing him as a "conceptual architect" [Capital New York, 14 December 2010]. He will be responsible for the oversight and strategic integration of the communications, inter-governmental, legislative and constituency efforts of the Office of the Governor.
Zambelli has been working for a consultancy (Strategic Frameworking) that describes itself as a Corps of Conceptual Architects and defines conceptual architecture as follows.
But perhaps the most interesting insight into Zambelli's role as aide to Cuomo senior comes from a Time article reporting Governor Cuomo's decision not to run for President in 1992. Cuomo's political advisers were "sticklers for order and slaves to planning" and wanted to know his decision ahead of time, but he refused to decide until the last possible moment. [Michael Kramer, Politics At Last: A No-Go From Mario (Time, 30 Dec 1991)] Even the uncharacteristic extravagence of an unnecessarily chartered plane to New Hampshire wasn't enough to persuade the Governor to show his hand. As top assistant, Zambelli was therefore required to prepare for something that in the end never happened. But I guess that's what conceptual architects often have to do.
Zambelli has been working for a consultancy (Strategic Frameworking) that describes itself as a Corps of Conceptual Architects and defines conceptual architecture as follows.
We create strategic frameworks for business development based on significant insight regarding the evolving needs of consumers and customers. ... Heavily steeped in psychological exploration to uncover the true essence of “brand,” SFI’s proprietary approach to brand building — what we call “conceptual architecture” — has produced some of the most touted and far-reaching brand strategies over the past quarter century for clients such as PepsiCo, Anheuser-Busch, Tricon (Taco Bell, KFC, Pizza Hut), Hershey, Microsoft, Colgate-Palmolive and Kraft Foods.
But perhaps the most interesting insight into Zambelli's role as aide to Cuomo senior comes from a Time article reporting Governor Cuomo's decision not to run for President in 1992. Cuomo's political advisers were "sticklers for order and slaves to planning" and wanted to know his decision ahead of time, but he refused to decide until the last possible moment. [Michael Kramer, Politics At Last: A No-Go From Mario (Time, 30 Dec 1991)] Even the uncharacteristic extravagence of an unnecessarily chartered plane to New Hampshire wasn't enough to persuade the Governor to show his hand. As top assistant, Zambelli was therefore required to prepare for something that in the end never happened. But I guess that's what conceptual architects often have to do.
Monday, December 13, 2010
Can Single Source of Truth work?
@tonyrcollins asks if any healthcare IT system can provide a Single Source of Truth (SSOT)? In his blog (13 December 2010), he discusses a press release claiming that an electronic healthcare record system from Cerner Millennium Solutions is a "single source of truth", citing the Children’s Cancer Hospital Egypt 57357 (CCHE) as a success story (via Egyptian Chamber).
My first observation is that even if we take this success story at face value, it doesn't tell us much about the possibilities of SSOT in an environment such as the UK NHS that is several orders of magnitude more complicated/complex. I'm guessing the Children’s Cancer Hospital Egypt 57357 (CCHE) doesn't have as many different types of "truth" to manage as the NHS.
My third observation is that single-source of truth may be a bureaucratic fantasy, but responsible doctors will always strive to get best-truth rather than sole-truth. People in bureaucratic organizations don't always stick to the formal channels, and often have alternative ways of finding out what they need to know. So perhaps the Egyptian doctors at CCHE have managed to preserve alternative sources of information, and the "single source of truth" is merely a bureaucratic illusion.
See my previous post What's Wrong with the Single Source of Truth?
My first observation is that even if we take this success story at face value, it doesn't tell us much about the possibilities of SSOT in an environment such as the UK NHS that is several orders of magnitude more complicated/complex. I'm guessing the Children’s Cancer Hospital Egypt 57357 (CCHE) doesn't have as many different types of "truth" to manage as the NHS.
- one type of patient (children)
- one type of condition (cancer)
- a single building
My third observation is that single-source of truth may be a bureaucratic fantasy, but responsible doctors will always strive to get best-truth rather than sole-truth. People in bureaucratic organizations don't always stick to the formal channels, and often have alternative ways of finding out what they need to know. So perhaps the Egyptian doctors at CCHE have managed to preserve alternative sources of information, and the "single source of truth" is merely a bureaucratic illusion.
See my previous post What's Wrong with the Single Source of Truth?
Friday, December 03, 2010
Embedding Intelligence into a Business Capability
In some recent posts, I have talked about embedding different forms of intelligence in a business process. Intelligence may make the process more powerful, or it may merely make it more internally efficient. But in the examples I've looked at so far, the essential purpose of the process remains the same.
In this post, I'm going to look at something more radical. Prompted by a blog on the Death of Market Research from Tamara Barber of Forrester, I'm going to show how a basic business capability such as market research can be transformed into something else by introducing new forms of intelligence.
Barber's basic premise appears to be that in a complex world, it isn't enough for market research merely to gather information to be fed into business strategy and tactics. Instead, market research needs to be fully engaged in the intelligence loops of business decision-making and innovation. The challenge is not collecting information - there is already more than enough raw data - the key value-adding activity is in interpretation and insight.
In terms of organizational intelligence, this means extending from information gathering into active participation in the intelligence loops - from sense-making and decision-making to experimentation and learning. Barber defines this new role as follows.
There have been many criticisms of intelligence organizations such as the CIA whenever they have apparently failed to "connect the dots", and there are probably some useful lessons here for civilian organizations as well. One of the common problems appears to be a bureaucratic separation between the information gathering, sense-making and policy-making activities, which may cause insight to be fragmented or lost. It is surely better to build business capability around the whole intelligence loop, rather than chop it into separate pieces and hope that it all somehow works.
Places are still available for my Organizational Intelligence Workshop on December 8th.
- Embedding Intelligence into the Business Process
- Embedding Intelligence into the Business Process 2
- Joined-up collaboration
In this post, I'm going to look at something more radical. Prompted by a blog on the Death of Market Research from Tamara Barber of Forrester, I'm going to show how a basic business capability such as market research can be transformed into something else by introducing new forms of intelligence.
Barber's basic premise appears to be that in a complex world, it isn't enough for market research merely to gather information to be fed into business strategy and tactics. Instead, market research needs to be fully engaged in the intelligence loops of business decision-making and innovation. The challenge is not collecting information - there is already more than enough raw data - the key value-adding activity is in interpretation and insight.
In terms of organizational intelligence, this means extending from information gathering into active participation in the intelligence loops - from sense-making and decision-making to experimentation and learning. Barber defines this new role as follows.
"This role will be responsible for collecting and analyzing both internal and external sources of data, analyzing it, and presenting a unified view of the truth on customer/consumer wants and needs, as well as the market conditions and health of the brand within that market. In order to do this, leaders of today’s market research departments will need to consider how they can organize their teams, scope their capabilities, and collaborate with internal teams (customer intelligence, anyone?) and external vendors in order to come to the table with relevant insights and recommendations — all based on business objectives."
There have been many criticisms of intelligence organizations such as the CIA whenever they have apparently failed to "connect the dots", and there are probably some useful lessons here for civilian organizations as well. One of the common problems appears to be a bureaucratic separation between the information gathering, sense-making and policy-making activities, which may cause insight to be fragmented or lost. It is surely better to build business capability around the whole intelligence loop, rather than chop it into separate pieces and hope that it all somehow works.
Places are still available for my Organizational Intelligence Workshop on December 8th.
Wednesday, December 01, 2010
Joined-Up Collaboration
@inmagic 's Phil Green suggests an Enterprise 2.0 Best Practice: Unite Internal Collaboration with External Communication (CMS Wire Nov 29, 2010)
As he points out, internal and external are often disconnected. Clearly, different tools are appropriate for different kinds of collaboration. As Phil acknowledges, "external collaboration ... has usually taken the form of activities such as blogging, tweeting, Facebooking, Flickring, YouTubing, etc. with customers and communities outside the firewall".
In advocating unification, Phil appeals to the following two facts.
Phil describes a scenario where he thinks there is a plausible case for some kind of collaboration spanning internal and external.
Frankly, I don't think this is a very good example. It looks to me like a highly conventional product development process, with a narrowly constrained chunk of customer consultation in the middle. I'm guessing that the customers are not given seamless access to all the internal product ideas and issues, merely to a top 50 list which is a separate knowledge artefact, possibly constructed solely for this purpose. In which case, the word "seamlessly" here merely refers to the fact that the top 50 list and the full list happen to reside in the same software tool. (A tool, by the way, which looks suspiciously like the one Phil's company sells.) A paper questionnaire might have been more trouble to administer, but it might have been just as effective in terms of customer feedback and customer relationships.
In order to create a more convincing example, one should start not from the desire to sell a particular software tool, but from the business desire to collaborate more intelligently and intensively with the customers all through the product development cycle. The product management process would probably need to be radically changed, and we might not even need a separate marketing campaign. We probably need to think about organizational unification (radically new kinds of collaboration) long before we bother with platform unification (Phil's Social Knowledge Network).
Places are still available for my Organizational Intelligence Workshop on December 8th.
As he points out, internal and external are often disconnected. Clearly, different tools are appropriate for different kinds of collaboration. As Phil acknowledges, "external collaboration ... has usually taken the form of activities such as blogging, tweeting, Facebooking, Flickring, YouTubing, etc. with customers and communities outside the firewall".
In advocating unification, Phil appeals to the following two facts.
- Both internal and external collaboration are based on relationships.
- Each kind of collaboration should contribute to the organization’s collective goals.
Phil describes a scenario where he thinks there is a plausible case for some kind of collaboration spanning internal and external.
- A business unit that is gearing up for a new product development cycle.
- A list of possible product enhancements is maintained in an internal E 2.0 tool.
- The organization uses the E 2.0 tool "to seamlessly expose the top 50 internal product ideas to customers and receive feedback and reactions".
- The product management team analyses the customer feedback and initiates further investigation into features identified as high customer priority, including internal search for relevant R&D as well as focused research on competitor products.
- Following this investigation, they set the product strategy and start building a marketing campaign.
Frankly, I don't think this is a very good example. It looks to me like a highly conventional product development process, with a narrowly constrained chunk of customer consultation in the middle. I'm guessing that the customers are not given seamless access to all the internal product ideas and issues, merely to a top 50 list which is a separate knowledge artefact, possibly constructed solely for this purpose. In which case, the word "seamlessly" here merely refers to the fact that the top 50 list and the full list happen to reside in the same software tool. (A tool, by the way, which looks suspiciously like the one Phil's company sells.) A paper questionnaire might have been more trouble to administer, but it might have been just as effective in terms of customer feedback and customer relationships.
In order to create a more convincing example, one should start not from the desire to sell a particular software tool, but from the business desire to collaborate more intelligently and intensively with the customers all through the product development cycle. The product management process would probably need to be radically changed, and we might not even need a separate marketing campaign. We probably need to think about organizational unification (radically new kinds of collaboration) long before we bother with platform unification (Phil's Social Knowledge Network).
Places are still available for my Organizational Intelligence Workshop on December 8th.
Subscribe to:
Posts (Atom)