What is an organisation’s culture?

A few posts ago, I discussed how Culture eats process for breakfast, but what is “culture”?

At the time, I had the simple approach of “what was there before”. However, and from experience, that is difficult to figure and codify! Where does one start? Who do you ask? What are the parameters for this “organisational culture”? And then, how do you evolve it?

Well I found a partial answer at “Three Bell Curves“, where you can download a document titled “Business Culture Decoded”. In that document, the author describes three bell curves (of course) that helps you understand where lies the culture of your organisation as well as how you can look at its improvement. The author also admits that this is not an easy thing to do, but since culture trumps process, if you change the culture, you will affect the process and, hopefully, get better results!

Silos and the “Triple-Crown” of Agile Product Delivery Communication

In the past, I’ve experienced a lot of cases where silos existed within companies and organisations. More recently, with my work with communications service providers, the silos between product management (part of the CMO organisation), business systems (BSS, part of the CIO organisation), and operations (OSS, part of the CTO organisation) illustrated the problems in delivering their products to customers.

More recently, I was reminded of this during last week’s meeting of the OPMA (Ottawa Product Management Association, which also includes program and project managers) and an INCOSE Canada (International Council for System Engineering) symposium. These silos certainly appear to be the norm in many organisations – and seldom to beneficial effect!

The problem with these silos is that they encourage the transfer of information through documents that are passed “over the wall”. Although this could be seen as a sign of collaboration (e.g., “I provided the requirements, my job is done!”), it is not truly conducive to all parts involved in the product delivery process understanding and meeting the needs of the stakeholder (“the customer”). It also does not promote the adoption of an agile approach, especially when the needs of the customer change or are better understood.
I have come to think of this problem as on of “3-Cs”: Communication, collaboration, and cooperation.

There has always been a lot of talk about communication being essential to everyone knowing what needs to be done. Unfortunately, the silos tend to make this communication one-way, and I do not see that as communication! Communication that just goes one way is publication, even publicity in some case (e.g., “See, I know what the customer wants!”). Publication also tends to be a point in time occurence and not continuous. What is needed is communication that is a continuous dialogue that occurs regularly until the product is delivered – not just at the start and end. Participants need to be able to ask questions and get answers in order to get to a common understanding of what needs to be done, of what the customer problem and needs are and and how they will be solved.
But communication is not enough. There also has to be collaboration during that dialogue – it can not only be a question and answer exchange. Participant need to provide insight from their own knowledge and experience. This collaboration will help the company achieve the best solution for the customer’s problem.

And even that is not enough – we also need cooperation. Collaboration has a tendency to only occur during specific communication events, e.g., meetings. Cooperation happens when communication and collaboration happens spontaneously. In many cases, it is the result of the synergy that happens when communication and collaboration become almost symbiotic, when the team knows enough about the whole product that, when new information becomes available, they are already thinking about new ideas to meet the customer’s needs and they already know who to talk to – there is no more need to way for the next meeting or to create a new document. At this point, the silos are broken and success is assured.

I do realise that I am taking some liberties with the formal definitions of my 3-Cs, and I make no apologies for that. It is an easier mnemonic to deal with (especially since it seems to have already been used often as such).
The important thing in all this, after all, is to remember that when developing products, we all need to become more agile and dedicated to meeting the customer’s needs and solving their problems. If we don’t, we will take longer and risk losing the customer!

Your Business May Depend on Your CMO and CIO Working Together

This is a great article that brings up some issues that can prevent the CMO and CIO from working effectively together and aligning their decisions with the enterprise’s business objectives, instead of their own departments.

Your Business May Depend on Your CMO and CIO Working Together.

This is also an area where IBM Rational can help, in facilitating  collaboration between these two, sometimes silo’ed, entities, especially where software and system intensive solutions are at play.

IBM Rational’s tools for product portfolio management can help manage the input from both the CMO and CIO teams to the definition of the products provided by the enterprise. Each division provides its needs, its objectives, and its desired outcomes, and IBM Rational Focal Point can help blend all of this and keep it aligned with the overall division and enterprise business objectives. Each product (or project) can then be evaluated against these business objectives and scheduled accordingly.

Further integration between the product portfolio tools and IBM Rational’s collaborative lifecycle management platform then ensures that the software and system requirements can be traced to the implementation and deployment of the software/systems products.

Yes, this is a simplified view of the whole thing, but it can and has been done in the past!

Sharing (and collaborating) is power

Here are two great videos about sharing and, by extension, collaboration:

I do believe that sharing knowledge is important. Within IBM (where I’m employed), I do use many of the tools that are provided us to ensure that this is done – from internal implementations of IBM Connections and Rational Asset Manager to wikis and shared project storage area. I will, however, be the first to state that I could do better.

I was, however, wondering… Does using blogs, twitter, Connections, etc. to convey this message just panders to the converted? Are the people already doing this not the ones who would be reading those media?