TBM: Running your Practice, Part 2 -- Levels of Maturity

Where do we stand now?

Are we on the podium awaiting our bronze or silver or gold medal?

Are we managing our Information Technology area like a business?

Are we close to victory... highly performing... or not even in the game?

In the TBM perspective, IT towers and apps, pillars and infrastructure, are parsed and analyzed for rigorous financial control.

In optimized TBM, technology leaders are stewards of the company as much as managers of IT. They perceive their platforms and programs, code and architecture, compliance and data as enablers and financial drivers.

But remember and embrace this requirement -- TBM is as much management mindset as it is quantified cost analysis.

Further, business orientation is as much a culture of communication as it is robustness in technical delivery or financial control.

You cannot elevate your TBM capability unless you are driving two perspectives.

In Part 1 of our TBM essay, we challenged ourselves to articulate each department’s accountability, in terms of a taxonomy – one that presents the core capabilities where you must excel.

So we think of your space as a practice, which you run, balancing and climbing two axes: Operational Excellence and Business Orientation.

The taxonomical approach is useful in all facets. You are able to realize your touchpoints and dependencies, your value and competencies, when you compartmentalize your department.

If we can’t compartmentalize responsibilities and success factors, then we can’t manage.,

This applies to engineering, R&D, DevOps, architecture, digitization, infrastructure, cloud and every piece of the IT service catalog.

And if we can't see the business orientation aspects as well as technical/operational aspects, then we aren't managing the "practice."

Let's continue with the example of a Digital Product Management group, whose compartments (accountabilities) were:

• Product Strategy and Stakeholder Collaboration

• Product Portfolio management

• Roadmap Integration

• Customer Engagement and Change Management

We will stay focused on the third bullet, the third domain -- Roadmap Integration, whose Operational Excellence discipline mandates Roadmap Execution Management and whose Business Orientation discipline mandates Enterprise Collaboration.

The Operational perspective is pretty straightforward. When you advance Operational Excellence, you seek predictability in delivery. You deliver products and features according to a plan, and you endeavor to stick to that plan.

Simultaneously, you are not managing product in a vacuum. You often depend on the digital delivery in an Agile framework. But it's not just IT helpers. The other enterprise areas (Sales, Marketing, Strategy – those outside of IT) are also key players in your roadmap. There are many moving parts in planning scheduled releases.

I’ve seen a number of instances, within pretty formidable companies, when the product pipeline was not consistent with the expectation of key executives the firm. IT and Digital were building things. And some key executives were not endorsing what was being built! Worse, some of the executives thought the pipeline included many new product features, which were not Product Management's priority at all !

How does this misalignment occur?

Because we forget that operations must be married to a business expectation.

Business orientation is built on communication and collaboration. And to remind yet again, we are here looking at just one domain in just one Digital accountability (Product Management), The TBM mindset is required across the IT spectrum, in all domains, leaders and professionals.

The best TBM-styled leader continually asks herself, am I (a) running with precision, and am I (b) collaborating on business value?

Don't be overly patient with those with overconfident bravado, insisting we should be fast instead of being more precise. Imagine a quarterback who calls the "hurry-up" -- a valuable competitive weapon -- but when he goes to the line of scrimmage and takes the snap he gets no firm grip on the ball's laces.

Fast-paced means nothing without precision.

What are the incremental building blocks? And does it make sense for me to formally migrate from one level of maturity to the next? Well, first we identify the maturity scale and we realistically assess our current situation.

Below, I've sliced out the Roadmap Integration domain to see the Maturity scale and where our fictitious Product Management department sits.

Please note, that an actual analysis will have several more criteria within each Level. For purposes of the essay and the stepwise method, we have just bulleted a handful of characteristics that identify maturity level expectations. We show just one bullet description for each cell level, when there are usually several.

Shaded in green are the capabilities that our department executes now.

Operational Excellence pertains to execution, artifact management, rigor in scheduling, standards and defined accountabilities. This is assurance that we are not making decisions on-the-fly and that we record those decisions, much like a project manager who chronicles development.

The Business Orientation row is about avoiding "internally focused” IT, and being a business collaborator.

We ensure that we are not only reaching out to our internal business partners. We are engaging the business, emphasizing their accountability in the process.

Think of a RACI chart, where project best practices include assignment of participation. In any IT project (and product effort) collaboration and participation is mandatory for the Product Management "practice."

For our example department, they have achieved an Operational Excellence state of 1; the department is barely executing on the lowest cell in that row.

For Business Orientation, the department has progressed just to Level 2, the second lowest tier.

While neither are good grades, it's okay. There are many reasons that a department might be at a low level of TBM maturity. Opportunity awaits.

To share an unlikely but actual episode, there was an entity whose response to their grading was this:

"So what?"

There are firms and departments, which have actually seen no issue with their current low maturity level. They are continuing along, with a short-sighted view. But one can't blame anybody for skepticism when transformative steps are being recommended.

This is the reason for the Risk analysis.

In Part 3, we will identify several types of risks, under a hazard of stasis. We identify the drawbacks and the current negative impacts when we "do things the way we always did them."

We should never stand pat.

We need to move ahead.

The risks have financial impact, as well as reputational, operational and strategic.

And we can mitigate them in a stepwise manner.