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!

Corporate mass & inertia prevents agility

Tommy (someone for whom I have the greatest respect) made some very interesting comments in his posting: Corporate mass & inertia prevents agility.

Now, I have also had some experience sailing and that certainly helps me relate to the metaphor he uses. Sometimes I like the slow boat and sometimes the fast one – it really depends on what you want to accomplish. However, in this age where “internet time” is what companies have to worry about, agility is what is needed for the complete delivery of products. There has already been a lot of talk about agile development  for quite a while – and that is certainly a great thing for the software industry, but development is just a part of the product delivery, one has to embrace the complete lifecycle and think about agile product management (check out the front end of SAFe) and agile DevOps.

But then, there’s also some benefits to sometimes take a slow boat to China…just not when you need to deliver a product to your clients!

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!

What to do with “legacy” products?

I am now in charge of the product management for a bunch of “legacy” products. You know, those products that are old and, some cases, decrepit, but that our customers just love to keep around. They are comfortable like a well-work pair of jeans or broken-in shoes. But these products are based on old technology and we now have new platforms, enhanced capabilities, new UIs, etc. that should entice our clients to move…but some of them are stubborn.

So what do we do with these products that still bring in revenue (mostly maintenance, but some transactional)? They bring too much revenue for us to simply decide to throw that away (especially in this time of economic upheaval) as we fear those stalwart clients will move to the competition. And our new offerings, although more powerful, are scary in just those additional capabilities!

There are a few things that we have to look at for those products.

  1. First, to borrow from the medical profession, do no harm. This means that our current clients must feel they are not in a dead end – even though the product itself will not be updated. These users like the product as it is, so we need to work with them to determine why it is still the best tool for them. We need to see if this is a niche that we need (want) to address with an offering, perhaps a modified version of an existing, high capability offering.
  2. Second, we need to get these clients to move to something that we will want to support and augment in the future. We need to make this transition as painless as possible both from tool migration and from usage perspectives. Note that I states “as painless as possible” as it is often difficult to make this painless. Sometimes the artifacts do not migrate properly between the tools and require manual changes, sometimes the user experience is different. In either case, there will be some pain. From a tool perspective, the goal is to make sure that not information/data is lost in migrating the artifacts and to document the migration caveats. From a usage perspective, we need to document the changes in the way the tools look and in the way standard or common tasks are accomplished. This is where the user-centric design teams are very important. In all cases, we would want to consider services to help these clients including consulting, training, and pre/post-sales support.
  3. Third, we need to arrange the two previous points so that our development, maintenance, and support costs are minimised. These are legacy products and are typically not expected to be a drain on resources. We also want to be able to move the resources from these products to our strategic offerings (which should be the migration targets!). Although this is not directly related to our clients, we can’t expect them to stay on the old, comfortable applications forever and, at some point, all these resources will have to move.

So how does this translate into actual plans and activities? This is where knowledge of your products and clients comes into play – and this is what I have to figure out for my products! I don’t yet have an answer, especially not a generic one. But I may just come back to this blog to let everyone know…