The 4 Phases of Successful Bidding Reply

ICT deals are unlike other technical deals. Whilst engineering deals may be ‘complicated’ with their detailed technical details, ICT deals are often exponentially more ‘complex’ because they blend loose business concepts with technical specifications. Technical success is pegged to business benefits or unknown end states at the end of lengthy business transformations based on multiple increments of capability. For this reason the standard Colour Phases of bid development do not adequately support large, complex ICT deals. Robust process is a must in order to ensure adequate cross-functional collaboration across large, dispersed organisations. However, tech deals need to evolve through iterative stages of architectural development. The diagram below sets out a colour phased development lifecycle for large and complex tech deals. In this way, they get the process to manage the organisational governance as well as the architectural focus necessary to develop a winning value proposition.


The issue is never designing the solution it is unpicking it. Tech deals are not only complex they are aggregations of complexity: security systems, infrastructure, applications, business rules, benefits, integration – it all develops in isolation and it all has its own logic and its own costings and commercial parameters. It does, however, all work together. So, when it comes to the end of the bid and the team have to reduce costs in order to hit their estimated price-to-win it is somewhat akin to playing a giant game of “Kerplunk“. Straw by straw the architecture is unpicked and all the stakeholders around the metaphorical table just hold their breath and hope that not all the marbles fall down. If they don’t it is pure luck.

Technical ICT architectures are not like normal technical engineering projects or other capital works. The customer is not building an independent means of production. ICT (less robotic systems, i.e. embedded technology) is an integral and entwined part of business capability. It is inextricably linked to the business. If the dots are not all joined at the outset of the bid then when it comes to reducing costs at the end, the executives will strip down random parts of the technical solution which is usually the foundation of the value proposition. What will be left is a patchy solution that has obvious structural weaknesses (to the intelligent customer).


The problem is how to design elegant and sophisticated architectural solutions within cost, commercial and time parameters. The individual system components will be designed in splendid isolation with a variety of assumptions and guesses. The entire solution, however, needs to be designed, costed, stress-tested and reviewed within tight timeframes and against aggressive price points. In order to lead a large and disparate (often virtual) team to achieve these goals will take a robust process and a strong personality exerting herculean effort. The crux of the matter is how to manage varied personalities through a convoluted development process without stifling the elegance of the design yet still manage to corral such strong temperaments through tight review gates.


The solution is a blend of both the traditional colour-phased bid structure and the complexities of the architectural development process. Together it might be referred to as Colour-Phased Architecture. In this way the bid team are cognisant and appreciative of the subtleties and complexities of the architectural design process and the executive get a strong process which even the strictest governance may rely on.


Adapting Krutchen’s 4+1 Views the architecture is developed through 5 critical structures:

  • Use Cases. The Customer narratives and scenarios are developed to produce and update the various iterations of the architectural solution.
  • Architecture. The solution should develop through 4 iterations:
    • Logical – This will ensure that it is anchored by the strategy and accurately reflects it.
    • Physical – This is where specific solutions are developed and the tighter parameters are loaded.
    • Transition – This addresses the specific issues around the deployment, transition and change management issues for the customer.
    • Transformation – The vendor should make the majority of the margin during this phase and so much of the strategy, modelling should focus on the incremental capability uplifts. This is where the primary benefits realisation management should focus.

Architectural Development

The architecture of the solution is defined by a careful communication between elements. The interaction between the structural colour-phases and the functional solution development supports this in two ways: (i) the Use Cases inform the design of the solution, and (ii) the phases inform the development of the solution. Initially, the customer use cases determine solution design. The solution must be derived from a desire to solve the customer’s problem. A list of requirements is essential and usefully but may only result in a patchwork quilt of technical components and business benefits. The logical solution will then be molded and developed using the vendor strategy and broad parameters.

The physical solution along with more detailed attention to the Transition and Transformation stages is then pushed through another 3 phases of development. In this way, the team ensures that the architecture is not only technically comprehensive but that it is a sensible, well costed solution that will meet the customer’s needs well into the future.

Process Colour-Phases

The colour phases are essential because without them the architectural development process would just spiral out of control. The colour phases ensure:

  • that the development of the solution occurs within a structured governance framework,
  • that there is cross-functional collaboration between the technical silos and the commercial support, and
  • that the progress of development is measurable and communicable to the non-technical executive.

To that extent there are 4 essential phases to ensure that the technical solution does not exist in splendid isolation but is a well costed, commercially sensible plan to make money by delivering something which plays to the vendor’s strengths whilst delivering something of real value to the customer. In order to do that the process must ensure it develops:

  1. Strategy. The strategy must be developed from the outset. Architecture is not strategy. Without strategy there is nothing to anchor the technical development with and nor is there anything to prod and cajole business partners with.
  2. Architecture. Solution development is only part of the process. As with any design process, the artistic talents and temperaments of the team must be constrained and focused.
  3. Commercials. The commercials have to be right. No matter how elegant or sophisticated the solution, unless it works commercially it will not be signed off.
  4. Viability & Review. The solution must be able to be reviewed internally by peers and colleagues. It must exist as a coherent body of documents (which will be pulled together into the bid document). The team must be able to prove that the solution will work over the long term and exist as a part of the customer’s enterprise architecture.

There is both art and science in the design, development and management of large and complex bids. Bids team not only require the gravitas of deep technical ability but also leadership and communication skills. Without these the solution will not be balanced but rather a mess of technical solutions competing to over-deliver functionality. There is no easy way to navigate the issue but a colour-phased process of architectural development blends the best of both worlds into a practical and deliverable lifecycle.

Figure 1 – A colour-phased lifecycle for technical bids.


In a word – Yes. Although it is probably not possible to outsource an entire front office capability it is possible to outsource key elements so that the capability is (i) better supported, and (ii) more effective.


In a particular UK outsourcing company the account manager of a Local Government account in a in a poor area once asked the CEO of the Council if he felt that more IT would help him. The CEO snapped back that unless the account manager could solve teenage pregnancy with his IT then to stop bothering him! The question remained: could we help reduce teenage pregnancy through the use of our services? At the time no single process or set of processes existed which was particularly focused on the reduction of teenage pregnancy. Social workers merely had a bag of blunt tools which they applied on a case by case basis, usually after the fact (or in cases of extreme and obvious risk).

It would be ambitious. The area in question had the UK’s youngest grandmother. She was 28. Many young girls saw their only way out of the poverty cycle was by falling pregnant in order to get a council house and benefits. Regardless of the social problems this causes the sheer drain on the public purse is immense.

On an investigative trip to India where the outsourcing delivery partners were visited the Use Case was put to them. 3 areas were focussed on:

  • Analytics. Analysing and correlating large volumes of data is key. This is not something that social services did nor could they do. Analysis would not only require the infrastructure but it would also need the personnel to input and interpret the output.
  • Security. Data security and anonymity is critical. Employing local people was a key differentiator of the vendor and sending personal data offshore would be sensitive. Data would need to be cleaned, anonymised and then transmitted. Only when analyses were made and returned would results be matched with identifying indicators.
  • Reporting. Reporting needs to be intelligent and intuitive. The analysis could not spit out typed reports but rather would need to target social workers directly and inform them of specific risks and link the risks to benefits, programs, policies and guidance in and around the entire area.


Being part of such a complex capability would be very daunting for a business. Outsourcing vendors typically eschew complexity. Profit is based not only on an economy of scale but also on lower pay-band workers performing the tasks (typically in countries where labour is cheaper). Any increase in complexity adds the need for managerial oversight which adds the indirect (non-chargeable) costs of higher pay-band workers. Complexity is not good.

In order to avoid this in front-office outsourcing the vendor needs to get the customer to perform service orchestration. This is where the customer performs the oversight and configures the services as they wish. This does not mean that the vendor is just crunching numbers in the background. Rather, the vendor provides a level of human interpretation on the analysis as well as feeding them back into a vendor rep in the social services environment who can then ‘push’ the information. This last part is essential because the vendor is likely only to be financially incentivised on the basis of lower teenage pregnancy. Dealing with public service apathy and stagnant processes at a personal level is critical.


What if it goes wrong? Vendors are now part of vulnerable people’s lives. If something goes wrong who carries the liability? Should the vendor provide warranties for the services? Or simply guarantee results year by year? These areas are untested. However, it is likely that vendors will only warrant the technical aspects of the services which is not really front-office outsourcing. One way around this is to ‘own’ a number of key roles or at least the role specification. In this way they can realistically provide warranties for some of the outcomes.

In the end, front-office outsourcing is not only possible but it will be increasingly necessary in the future in order to provide vendors with the differentiators necessary to maintain profits. The most critical issues will be getting vendors to deal with complexity without paying too much for the additional risk and in a way which allows them to take on the overall liability as well. The front office is a prime source of differentiation but it can be ground captured by outsourcers so long as they are smart about both complexity and liability.

CONTRACTING FOR CAPABILITY: the future of outsourcing Reply

Outsourcing only works for vendors. It does not work for customers. Revenue curves for vendors show a slight increase since 2008 for global outsourcing growth but the picture is less clear for customers. When looking at the economic-value-added (EVA) for businesses before and after outsourcing deals most show a nett decrease, which is to say only that they are weaker after the deal but not necessarily because of it.

The reasons are myriad however there are a few standard reasons:

  1. outsourcing is usually part of cost reduction activities of panicking organisations.
  2. there is usually a nett decrease in headcount which wipes out the value-added aspects of reduced costs.
  3. the customer’s SG&A costs usually rise due to the increased management activity needed in finding and using information.

Due to these reasons there is a feeling in the market that outsourcing does not work despite the claims of vendors. Therefore, vendors have increasingly (certainly since 2007) seen themselves fighting for an ever shrinking slice of the economic pie. The greatest sources of competitive advantage have been reputations and economies of scale. All, however, have been scrambling for a differentiator that does not involve reducing their own profits.


One large UK outsourcing outfit saw the writing on the wall. It felt that it would not be able to compete with the lower labour (and similar outputs) of India-based companies. It rationalised that eventually it would be squeezed out of the back-office (i.e. highly standardised financial processes) outsourcing and infrastructure hosting markets. It would, it rationalised, need to move into middle-office outsourcing. Front-office outsourcing, on the other hand, is largely fictional as it encompasses the customer-facing aspects of a business which is where the key differentiators are.

Middle-office outsourcing (such as a council planning approvals process) is unique because it involves less repetitive processes and sometimes ad hoc activities.  Success here is necessarily predicated on a flexible IT infrastructures (often service-based, i.e. SOA) and a sophisticated management which is able to choreograph technology-based processes and services.


Being able to outsource the middle-office involves positioning the vendor into a customer’s capability. A capability is the ensemble of systems, processes, people and information/data necessary to do something. In business terms this means all the stuff that is necessary to perform a process. Technically, capabilities are specifications of an enterprise’s Value Chain, so in broad terms a business will have about 20-ish key capabilities. All capabilities are, necessarily, linked. The closer one gets to the front-office the more these capabilities need to (i) be performed and supported in real-time, and (ii) they also need to consume information and services from elsewhere in the business. For instance, in our planning approvals process example the vendor will have to (a) log approvals in real-time, (b) consume up to date information on structures and utilities, as well as (c) access information on business rules (i.e. council policy, governance, law etc). As with any outsourcing activity, more narrowly focused personnel on lower pay bands are used to perform tasks more ably supported by better technology. All these aspects not only add to the complexity (and therefore the price) but also to the potential liability. When offering low pay band workers to crank the handle on repetitive processes liability is something a vendor wishes assiduously to avoid.


Capability is a term much abused but little understood in Defence circles. Much of this is because Defence does not use a standard value chain. Although there is a business model for most western Defence communities (Inform > Project > Operate etc) there is no need for a value chain because there is (i) no need to differentiate, and (ii) planning and financing is based on the use of ‘unlimited’ funds to confront external threats (i.e. Treasury tends to play second fiddle during war).

The military user will often class themselves as a ‘special’ customer. The defence industrial complex is a special environment for the simple reason that they are providing equipment which – if the enemy is successful – is useless to the customer by the time it enters service. Unlike the commercial enterprise, where such a situation would mean they lost some competitive advantage/margin, in the military such a situation is untenable. The purpose of a military capability is therefore to change quickly and radically over time in line with the threat. Corporate structures are notoriously incapable of maintaining the same tempo of development, even with lavish operational funding. The purpose of ‘Contracting for Capability’ is to solve the problem of commercial-lag whilst still providing a cost effective and commercially robust means of contracting.


This is possible by viewing the capability environment as a complex evolving system which requires the commercial deal to be a complex adaptive system. This is not new to the law. Building and construction deals have been taking this approach for years and German franchising law has excellent precedents showing how risk may be judicially assessed throughout a large, distributed network of commercial entities – for a common purpose or effect.

Figure 1 – Shows how commercial deals fail to keep pace with and support military capabilities.

‘ROLES’ – The Key to Capability

The key difference between commercial and military capability is that in the military environment the vendor cannot own the people. In business, the customer will transfer the roles over to the vendor. In the military equivalents of the middle and front offices (i.e. front line and forward echelons) the vendor will never own the people. Soldiers will always perform critical tasks. This will remain a constant for some time to come as soldiers do not say (i) “the computer isn’t working”, or (ii) “do I get overtime?” etc.

Although a vendor cannot own the people it can own the ‘Role’ or the role specification, i.e. the processes, information and systems that a role uses. In this way, a vendor can support the core functions of a role without hindering the actual person’s ability to go outside the boundaries of that specification to ensure that something is done. For instance, a aeromedical evacuation must take place regardless of whether a computer is not working. The airman performing the tasking may have at their disposal a sophisticated orchestration of processes based on flight availabilities, supporting gunships, bed availability and surgeons on duty. However, if the network is down it is unacceptable to let a soldier die just because the computers are not working. That airman must now use their deep knowledge to work the radios and help save a life. On the other hand the military is largely incapable (and unwilling) to integrate the vast array of ICT necessary to develop the initial systems.

Figure 2 – ‘Contracting for Capability’ using commercial communities to support capability clusters.


The example of an aeromed evacuation is somewhat simplistic. The example above refers to the Deep Target Attack capability. This capability may be performed by submarine/ship-launched missile strike, aircraft or even Special Forces. The choice is a military judgement. In the case of a submarine launched method the enemy will try to prevent this through anti-submarine naval activity (ASW). The submarine needs to close to striking distance, reach launch depth and then withdraw safely. How is it possible to support such a process which involves very long and expensive R&D lead times, long into-service acceptance testing, new training and tight export controls as well as restrictions on the use and sharing of sensitive information?

The trick is to incentivise the commercial community to do some of the thinking for the military. Instead of having to wade through the commercial treacle of Defence procurement the following steps could be taken:

  1. Base contracts on Capability Increments. In this way, the vendor is obliged to keep pace with threat evolution and the development of capabilities.
  2. Outsource the Role Specification. This will ensure that the military community is forced to involve its commercial delivery partners (without being hamstrung by systems).
  3. Create Commercial Communities around the support to certain key systems/clusters of technology. This is similar to German franchise systems whereby all parties are legally obliged to discharge their contractual obligations in line with a common purpose. This will circumvent the horrific impasses usually experienced in alliance contracts.

Contracting For Capability is a logically sensible concept which simply builds upon the work already achieved in the Enterprise Architecture community (especially MoDAF, MoDEM and the IDEAS Group). It is not overly complex nor is it a step too far. Once again, the real question is whether Defence and industry have the sophistication and diligence to complete the task.

McKinsey – Why the Customer pays for Risk Reply

In the forthcoming McKinsey Insights article “Avoiding Blindspots in Your Next Joint Venture” the authors point out some of their recent research into the failure of JVs. Further to my previous post about the need to design accurate risk models into a JV/Alliance/PPP, the authors note:

“At the beginning of any JV relationship, parent companies naturally have different risk profiles and appetites for risk, reflecting their unique backgrounds, experiences, and portfolios of initiatives, as well as their different exposures to market risk. Parent companies often neglect this aspect of planning, preferring to avoid conflict with their prospective partners and getting to mutually agreeable terms—even if those terms aren’t best for either the JV or its parents. But left unaddressed, such asymmetries often come to light during launch, expand once operations are under way, and ultimately can undermine the long-term success of the joint venture.

Certainly, some JVs must be rigidly defined to be effective and enforce the right behavior. But when that isn’t the case, JV planners too often leave contingency planning to the lawyers, focusing on legal protection and risk mitigation without the business sense, which shows up in the legalese of the arbitration process and exit provisions. Both tend to be adversarial processes that kick in after problems arise, when in fact contingency planning should just as often focus on the collaborative processes that anticipate changes and create mechanisms or agreements that enable parent companies to adapt with less dysfunction. As the head of strategy for one insurance company noted, “If a JV is set up correctly, particularly regarding governance and restructuring, it should be able to weather most storms between the parents.” Such mechanisms might include, for example, release valves in service-level agreements, partner-performance management, go/no-go triggers, or dynamic value-sharing arrangements and can allow a joint venture to maintain balance in spite of partners’ different or evolving priorities and risks.”

Designing proper risk models need not be adversarial. In the hands of a skilled lawyer or commercial manager it is a sharp and powerful weapon at the negotiating table. This does not mean that the contract is not a win/win deal. On the contrary, insight into the proper and necessary allocation of risk is essential for a win/win deal. Anything else is simply wilful blindness. In fact, a more mathematical approach to risk modelling lays the foundation for a negotiating process that is more inquisitorial rather than adversarial. The primary questions remain: is the management sophisticated enough and does the business have the stomach for it?

The Customer Always Pays for Risk: risk allocation in large and complex contracts Reply

A recent report in The Australian (17/12/13) newspaper into the Air Warfare Destroyer (AWD) debacle states that the project is already $106M of its $618M budget for 2012-13 (a wastage of over $2M a week). The article states that the project delays are a combination of “shipbuilding bungles, infighting between partners, Defence budget cuts and a cultural clash with the ship’s Spanish designer, Navantia.” Poor efficiencies at the ASC in Adelaide and little coherence in the support phase are also contributing to the mess but the AWD Alliance still maintains it is on track because its emergency funds have not been exhausted.

The AWD Alliance is the “unwieldy and largely unaccountable” body responsible for the AWD project. The alliance is made up of ASC, the Defence Materiel Organisation and Raytheon Australia. The “secretive” alliance is apparently fractured by internal disputes, with the DMO blaming the ASC. The ASC, in turn, blames Navantia. Further still, the ASC is also blighted by a “poisonous” relationship with its primary subcontractor, BAE Systems.

This is a contracting issue:

  1. There is no issue with the Spanish design. This design was picked as part of a strict and comprehensive procurement process. If the ASC did not perform the requisite due diligence on the engineering then it should not be in the game of building ships.
  2. In multi-party construction contracts poor site efficiencies are largely a result of (i) cumbersome management, and (ii) poor depth of vision into the total supply chain. Both issues should have been obvious and ironed out at the contracting stage.
  3. There is no doubt that budget cuts and legislative change pose a high degree of risk. However, if the revenue curve of the corporate entities were subject to ill winds from Canberra then those teams did not do their jobs.
  4. Lastly, if a project is eating its emergency/contingency funds then it is an emergency and it is definitely not on track.

So, what’s wrong with Alliance contracting?

John Cooper, writing in the journal of Building & Construction Law (2009 25 BCL 372) notes that alliance contracting is increasingly popular in Australia. Promoted by contractors and adopted by some state governments it is seen as a way to overcome the problems said to be associated with “more traditional forms of contracting”. From this I assume he is including PPP contracts and their PFI/PF2 subset.

Alliance contracts are supposed to be more conducive to collegial management and better outcomes because:

  1. They are governed by a charter of principles and not the black letters of a strict contract.
  2. Each party (theoretically) operates in good faith (although, unlike German franchise law, not necessarily to the mutual benefit of the project).
  3. There is an understanding of “collective responsibility”
  4. There is a socially enforceable culture of “no-blame, no dispute”.

In fact, all of these points are patent nonsense and the article in The Australian and the Australian National Audit Office report on the same project clearly highlight the complete ineffectiveness of an Alliance contract in this instance.

At the heart of the problem is the risk model. Alliance contracts are popular for Defence because (i) the government underwrites the requirements risk (i.e. future requirements creep), and (ii) they do not have to expose this as an additional cost. So, the project appears to be good value for money. In fact, DMO is to blame here because it knows that it would never be able to get the AWD it wanted if it had to expose/pay for the risk. This is standard Defence sharp practice and to my mind borderline procurement fraud. By getting the government to underwrite the risk the DMO ends up getting the ship it wants at a bargain price. It ends up paying way over the odds but the project would never have been approved if the risk had been exposed. The price would simply have been too high.

In a standard construction contract the client would not underwrite future risk. So, the builder would cover this through (a) additional systems engineering to uncover and cost future dependencies, (b) they would insure against certain risks, and (c) they would then add this into the cost model, i.e. the customer would end up buying the risk back. In the end, the customer always pays for risk. Even if the builder has to absorb hefty liquidated damages for lateness the customer will still pay for them down the line in more aggressive management practices or exorbitant extension-of-time claims and even larger margins on acceleration costs. The customer always pays for risk.


The primary cause of these problems is an unsophisticated and uneducated approach to contracting. Underlying these is the simple fact that risk cannot be allocated if the allocatee does not endorse the allocation. In fact, I would posit that risk cannot be allocated at all. Risk must be bought and sold in order for (i) a party to be truly incentivised to deal with risk, and (ii) the risk to go away. The last point is critical. In standard risk flow-down models risk never goes away. Rather, it simply flows down to the party with the least bargaining power to offload it. In the end, the customer always buys the risk back. In a network model, risk is sold to the party who wants it the most. In the end, they absorb the cost (or a certain percentage) based on the value they will reap in the event the risk is realised.

For instance, the network model below at Figure 1 is based on a large outsourcing contract. A multi-divisional outsourcing company won a contract to deliver products and services to a government body. Part of that contract was the hosting of IT infrastructure, a portal for public access and a billing application. The latter of which was being coded from scratch. In this model, the risk that the code for the billing application is held in escrow and the risk that the billing application will not be ready or fit for purpose (significant) is sold (i.e. the contingent risk) to another company in the model. In this way:

  • the purchaser of the risk get a (partially finished) billing application at a knock-down price (if the risk is realised).
  • the primary outsourcer can simply pass the application on to the former without having to find a suitable programmer in mid-flight, and therefore
  • the primary outsourcer does not need to insure this risk (so much), and
  • the original application company are greatly incentivised, lest they lose their R&D costs.

Additional vehicles (other than escrow) for contingent risk may be:

  • Step-In Rights
  • Holding other titles and licenses in escrow
  • contingent transfers of other property.

In all the cases something happens automatically. There is no better way to make this happen than for someone to profit from another’s poor performance. In such cases, the vampiric action of the vestee is swift justice for sub-standard management. When risk is realised, the vestee swoops and kills. There can be no greater motivation for either party. The primary question is whether a business has enough faith in its management to set up contracts in this way. Although a network model of risk is, technically, the best means to manage risk in large and complex contracts the businesses need to decide whether they have the management sophistication and the stomach to deal with risk in this way.

Figure 1 – Model of “Derived Risk” in a large outsourcing contract.

Give Me Back My Silo! The problems with cross-functional collaboration Reply

Collaboration requires trust.  Collaboration often requires risk with new relationships.  Collaboration requires doing something new.  In short, people do not like to collaborate.  People do not like to share.  People like safe relationships with others from the same educational background.  They collaborate with those who  share the same problem solving paradigms, issue identification and decision making criteria.  Knowledge and knowledge-intensive work is intensely hierarchical.  People guard their secrets and their weaknesses.  So, although the business may look towards de-layered flexible working structures as a cost saving measure, people do not necessarily follow.  Knowledge is and has always been a powerful means to embed and entrench power within an organisational hierarchy. 

Collaboration, however, is worth money.  In 1969 Peter Drucker noted that sharing and managing knowledge is “essential to organisational success” because it ensures sustainable competitive advantage.  How then do businesses best help employees engage and collaborate in a meaningful way which creates business value?quopte

Larry Prusak notes that large organisations performing complex tasks have been around since about 1860.  So far the corporate community has had over 160 years to solve this problem and we seem no nearer to it.  He posits that it seems so hard because, essentially, it is not possible.  There is no science behind it only heuristics.  Solutions are not algorithmic but rather anecdotally commonsensical.


The problem is that cross-functional collaboration is counter-intuitive.  It is not a normal feeling to share intra-discipline information with other functions around the business.  Complex ideas are not easily understood or translated outside professional groups.  Geologists and pharmacists can only explain an important discovery if it has immediately recognisable business value.  Lawyers can only explain the value of an idea if it averts imminent loss.  Manufacturers articulate the value of a process where it creates savings or improves revenue.  Everything else is esoteric gibberish. 

Thought leaders such as Prusak and Drucker well note that the answer to the standard problems of intra-disciplinary collaboration is to create well supported Communities-of-Practices (CoP).  Practices, they note, are best kept to about 200 members who meet about 2-3 times per year.  In the diagram below, such CoPs may extend beyond the walls of the organisation and may even include other competitors. 

To misquote Shoeless Joe Jackson in “Field of Dreams:  ‘Build it and they will not necessarily come.’  Increasing networks and their IT support will not necessarily produce any tangible return.  Most likely it will needlessly absorb organisational time and money only to increase the personal fiefdoms and create further bottlenecks and over-centralisation.  Such networks will help to increase the volume of knowledge within an organisation and problem solving but, critically, it will not help convert it it into business value.  In order to realise business value knowledge must cross functional boundaries.   

xFunctional Collaboration


Knowledge will flow relatively freely within disciplines.  CoPs  address the problem of collaboration for such knowledge generation and problem solving.   Knowledge does, however, need to be forced across functional boundaries.  Commercial teams will not be drawn to good ideas.  They will not recognise them.  Workflows are essential to implement collaboration across organisational functions.  The key to implementing cross-functional (as opposed to hierarchical) workflows is to embed them in governance.  People will collaborate across functions if they cannot achieve their goals or get their work done.  The difficulty with any governance, however, is making sure that these ‘gates’ do not become bottlenecks.  Although the onus may be on the professions to present their work for approvals, so to is there a burden on the executive silos to understand and approve in a timely manner.  In this way there should be no burden on the operational disciplines to present their work on an ad hoc basis.  The presentational form must be agreed between professional and executive branches to understand.  There is no sense in letting commercial elements of the business dumb down sophisticated ideas.   Only when both parts of the organisation come together in mutual understanding is there truly any sense of collaboration across functions.

In the end trust will always trump value when it comes to the exchange of knowledge.   Indeed, businesses must actually increase organisational silos and insulate them rather than fight them.   The solution is not to break down the silos but to build them up.  People like safe relationships.  They like to feel warm and closeted from ‘outsiders’.  The key is to increase their sense of importance through revenue generating communities of practice in order to increase the volume of knowledge in an organisation.  Only then should the business increase the pace of converting knowledge to revenue through cross-functional workflows strictly embedded in the corporate governance.