The difficult thing about our knowledge-management portfolio at Amdocs was that almost everything on the list had a reason to exist.
Years of grassroots work had produced portals, document-management capabilities, collaboration spaces, knowledge-reuse tools, search initiatives, forums and other internal services. Different groups had real uses for them, and the area was gaining more attention from senior management.
That increased the opportunity to invest, but it also meant there were more worthwhile things to improve than we could treat as equally important.
Too many reasonable things
Earlier in my career, much of my work had followed a familiar discipline: understand the business problem, map the current processes and systems, explore alternatives, then shape a solution that could actually be delivered.
At Amdocs, the same discipline had to operate at portfolio scale. We were looking across an existing set of products and services: Search had a case, the portal had a case, document management had a case, and collaboration, internal communities and knowledge reuse all had users and advocates of their own.
Most of them could defend their existence, which made tool-by-tool planning increasingly unhelpful. If every conversation began with something that already existed and asked what to do to it next, the portfolio would mostly reproduce its own history.
We went back to what the business groups were actually trying to achieve: which needs appeared across more than one part of the organization, where the important gaps were, and only then which solutions belonged in the discussion.
The working sequence became roughly:
business goals → priorities → possible solutions → final priorities → work plan
That meant an existing system could remain useful without automatically earning another round of major investment. A new request had to compete with needs elsewhere, and maintaining something became different from choosing it as an area for growth.
Choosing where to concentrate
Enterprise search showed what this looked like in practice.
The need came from across the organization. Amdocs had accumulated information in separate systems and what we sometimes described as knowledge islands. People knew useful material existed; discovering the right piece was becoming a problem of its own.
The work around Search became correspondingly broader. We looked at different content repositories, metadata, relevance, permissions and administration. The proof-of-concept work tested whether authorized results could be brought together across different sources and how the search experience could be tuned once those sources were available.
Another major focus became an internal social and community platform.
The opportunity was to help people discover colleagues and expertise, form communities and share knowledge across a large organization. As the work matured, it moved into detailed definition around communities, discovery, discussions, documents, events, permissions and related capabilities.
In my memory, Search and the social/community platform became our two major areas of focus, while Portal, document management, reuse and collaboration services continued to serve real needs. Some evolved selectively, some mainly needed to remain healthy, and some accumulated structures or content that eventually required review or cleanup.
By that stage, the area was explicitly being treated as a product line spanning document management, sites and portals, collaboration, Search, forums and blogs, reuse and other services.
Some capabilities deserved concentrated new attention, while others were worth sustaining without continuing to expand simply because they already existed. Search and the social platform could absorb more product and development attention without requiring everything else to disappear.
The roadmap had begun to express an actual choice.
Turning choices into commitments
Choosing priorities mattered only if the organization could act on them, and I saw that particularly clearly while working with one of the group’s knowledge-management experts.
He brought deep research and analytical thinking about what knowledge management could become. Part of my role was helping turn that thinking into something management and other stakeholders could engage with.
The planning approach that emerged connected those ideas to a sequence of decisions: define the mission, goals and scope; clarify responsibilities; identify stakeholders and people who could champion the work; understand the current state and shared needs; map the gaps; develop recommendations; prioritize them with the relevant stakeholders; and turn the agreed direction into an implementation plan.
One of the plans from that period followed almost exactly that progression, moving from business needs and responsibilities through stakeholder research, current-state mapping and gap analysis into a prioritized roadmap, approval and implementation.
The specialist thinking remained his. My contribution was helping make it actionable: something people outside the immediate discipline could understand, decide around and support.
For those choices to matter, they also had to move from the people who understood the problems deeply, through the people setting priorities and allocating resources, into the teams expected to execute them.
The structure around the work became more explicit as well. Architecture and implementation, portfolio responsibility, tools and technologies, and Development were increasingly treated as connected parts of the same operating system. The portfolio roles covered functional design, version scope and work plans.
Later, the business-facing delivery group and Development both came under my responsibility.
In my experience, that made coordination easier. There was less friction in moving large initiatives from business need into delivery, and more of the path from prioritization to execution could be steered within one accountability boundary.
What mattered was that the priorities expressed in the roadmap were increasingly connected to the way the work actually got done.
What the roadmap changed
Earlier in my career, a large part of product and systems work involved finding the right solution to an enterprise problem.
At Amdocs, several problems could be real at the same time. Several systems could be useful. Several stakeholders could have legitimate reasons to ask for more.
The harder question was deciding which of those things deserved sustained organizational attention.
The roadmap helped make those choices visible. The work around it connected goals to priorities, priorities to capabilities, and those capabilities to ownership and execution.
I remember that more clearly than the roadmap artifact itself.
The roadmap started when we stopped listing tools, because that was when we started choosing.