Launching a Cross-Organizational Project with a Triage

Our ProcessTriage workshop (on a napkin here) is positioned to sync up a highly siloed team and generate a list of a dozen or two high value process capability improvements in one intense day.  Typically , the sponsor is wanting to fix what’s broken by empowering those who do the work to lead the improvements.

The triage workshop is also an effective kick-off event for finalizing a complex project’s work breakdown structure, where experts from different departments — even companies, must sync up.  The scope of work of requires multiple cycles of a similar project (such as touching multiple locations with the same changes).

We were pleased to lead such a pre-launch triage, hosted by Cisco Systems (CSCO), which included knowledge experts from their customer, T-Mobile (TMUS) and Cisco’s subcontractor, General Datatech (GDT).  T-Mobile subcontracted Cisco to make certain changes in a number of network locations.

30-4 Team Picture (2)





The triaging protocol is essentially the same as a break-fix triage.

The triage  team maps a typical project cycle’s (the work of one iteration) work breakdown structure (WBS), as a Project is merely one cycle of a Process — so process mapping is essentially the same as outlining a project WBS.

The  Process Capability Goal for a pre-launch triage focuses on delivering a sustainable level of quality after a few learning curve cycles, and then running additional project iterations on time and on budget.

The Points of Pain are what the team estimates will prevent a successful project launch initially, and inefficiencies to fight off after the learning curve.

The Small Now’s action item-size improvements and Big Now’s project-size improvements are, taken together, the specific deliverables in the project’s risk mitigation strategy.  These Small’s and Big’s are front loaded immediately, especially the action items or projects that must be completed before the first project cycle or iteration.

Hat tip to James Farrell (executive sponsor) and  Tom Tinsley (host) of Cisco Systems.

When to Put Your Partner Hat On

I received a ‘Client in Distress’ call a few weeks ago.  The  triage sponsor calling ‘Mayday!, Mayday!” had been a successful host of a previous triage a year or so ago.

They had contracted with a the top tier telecommunications company to handle some network equipment upgrades and, along with their subcontractor, decreed a ‘freeze all work’ time out period because initial attempts had adversely impacted the telco’s network.

So we triaged some high-rick equipment scenarios with about 20 of the various experts — engineers and field technicians. They nominated and ranked a dozen Small Now’s (action item-size) and Big Now’s (project-size) proposals.  The program mangers (the triage hosts) baked the triage results into decision brief to report out to the telco — their customer.

This conversation with their telco customer was successful, reflecting completed staff work, great solutions, and an action plan to execute immediately.   The customer – supplier relationship is crystal clear in these kind of ‘How we’re going to pick up and wash off the candy we dropped in the dirt.’ encounters.

But what the triage revealed was the customer performed certain tasks in the equipment upgrade process they could not delegate, using equipment databases the supplier could not steward.  In other words, to process of upgrading the network required the customer to remove their customer hat and exchange it for a partner — team member hat.  This necessity was made obvious by the points-of-pain in the triage and the solutions that only the Customer could resolve.

Lesson Learned:  If you subcontract work out to a supplier, but the business process your suppler must manage requires deliverables only you can provide — your subcontracting orientation ends where process execution begins.  At that point, you need and must be a partner.

One of the triage exhibits was the triage / process map with the deliverables the Customer was responsible for, noting the business risks of failure to do so.

Self cleaning, too

I’m a huge fan of Seth Godin, and enthusiastically recommend his daily blog (here).  Today’s post, titled Self cleanining talks about building things, like a self-cleaning oven, and maintain itself.

Relationships, processes, interactions–these can be self cleaning too, if we build them that way. Seth Godin

Applying the ProcessTriage Decision Cycle to a high-value business process makes it self-cleaning. It keeps the process focused on the enterprise’s most strategic objectives, while fixing the myriad of dysfunctions that appear in the daily, normal course of operations.

1a Process Triage on a Napkin

Making business process self-cleaning takes teamwork.  Three roles or voices have to sing their parts and do certain things in the right order.

Self-cleaning business processes create self-correcting business models.