How to ruin a great team

In following through How to ruin a great team, you will find a great piece about what not to do when you take over a team (soccer, in this case). The two main points I got from the original article is that a manager must be able to communicate and must be able to adapt to the culture of the team (instead of imposing his own from the start).

I believe this to be true whether you are talking about a sports team or a software/system development team!

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!

I’ll be changing jobs…

I did post, in the past, about the work I am doing at IBM. Well, this is about to change. Starting in January, I will be taking on a new role within the organisation – no more governance. I will make a note to discuss it at that time…and perhaps my delicious links could give you a hint! But for now, I have to get back to work and finish up what I am currently doing so that my replacement will not feel overwhelmed!