THE WORKSTREAM - Consulting T-Shirt

THE WORKSTREAM

At 8:43 on a Monday morning, a young consultant named Oliver was informed that he would be leading the workstream.

He was delighted.

Oliver was twenty-seven years old, had graduated from business school fourteen months earlier, and had recently purchased a navy-blue suit that made him look considerably more experienced than he was.

He had been working at the firm for eleven weeks.

He knew what a deliverable was. He knew how to build a financial model. He knew that a meeting scheduled for thirty minutes would generally last forty-five, unless a senior partner attended, in which case it might last four.

He was less certain what a workstream was.

He had heard the word approximately six hundred times since joining the firm. It appeared in proposals, project plans, steering committee presentations, and conversations conducted by people who seemed to understand it perfectly.

Oliver understood that workstreams had owners, milestones, dependencies, and deliverables. They could be accelerated, consolidated, delayed, or escalated. Occasionally they were described as critical, which appeared to mean that someone important had become concerned.

But what, precisely, was the stream?

And where was it going?

His engagement manager, a woman named Rebecca Chen, explained that he would be responsible for Workstream Three: Operational Process Harmonization.

Oliver nodded confidently.

Rebecca handed him a project plan containing forty-seven activities, twelve milestones, six decision gates, and a color-coded timeline extending through the end of November.

"You'll own this," she said.

Oliver looked at the spreadsheet.

There was a great deal to own.

The client was a national distribution company that had recently acquired three regional competitors. Each business had its own operating procedures, reporting systems, organizational structure, and strongly held opinions about the correct way to process a customer return.

The acquisition had been announced as a transformational opportunity to create a unified, customer-centric organization capable of delivering operational excellence at scale.

In practice, the four companies could not agree on what to call a warehouse.

One called it a distribution center. Another called it a fulfillment facility. A third used the term branch, despite the fact that some branches occupied buildings large enough to accommodate commercial aircraft.

The fourth company called everything a depot.

Oliver's assignment was to help bring these operations together.

Rebecca explained that Workstream One was handling technology integration. Workstream Two was responsible for organizational design. Workstream Four was developing the financial benefits model, and Workstream Five was managing change communications.

Workstream Three would define the future operating processes.

"You'll need to coordinate with the other leads," she said.

Oliver wrote this down.

He did not yet understand that coordinating with the other leads would eventually consume approximately seventy percent of his waking hours.

By Wednesday, he had scheduled seventeen meetings.

By Thursday, eleven of them had been rescheduled.

By Friday, he had created a spreadsheet to track the rescheduling of the meetings.

Rebecca called this good project discipline.

The following Monday, Oliver chaired his first workstream meeting.

There were fourteen participants, representing operations, finance, technology, human resources, procurement, and three separate business units. Two people attended by telephone. One appeared to be driving. Another had joined from a conference room in which a persistent mechanical humming made every contribution sound like an announcement from inside a submarine.

Oliver began with the objectives.

He explained that the purpose of the meeting was to establish a shared understanding of the current-state processes, identify opportunities for standardization, and agree on the approach for future-state design.

Everyone nodded.

Then a regional operations director named Linda asked whether the new process would require her warehouse to stop using its existing picking system.

Oliver said that the question would be addressed as part of the design phase.

Linda asked when that phase would begin.

Oliver explained that it would begin after the current-state assessment.

Linda asked how long the assessment would take.

Oliver referred to the timeline.

Six weeks.

Linda looked at him.

"It takes us four minutes to pick an order," she said.

Oliver made a note.

He had discovered his first stakeholder concern.

Over the following weeks, the workstream developed a personality of its own.

It acquired a status report, an issue log, a risk register, a decision tracker, and a folder containing versions of documents whose names had become so long that the file-sharing system occasionally refused to accept them.

There were process maps, responsibility matrices, workshop materials, and a presentation entitled "Future-State Operating Model Design Principles" that required three meetings to finalize.

Oliver learned that an action item was not necessarily an action anyone intended to take.

He learned that a dependency was something another workstream needed to finish before his workstream could finish, and that the other workstream was generally waiting for information from a third workstream, which was waiting for approval from someone who had gone on vacation.

He learned that the phrase "Let's take that offline" usually meant the subject would return at the next meeting with considerably more people copied on the invitation.

And he learned that a green status indicator could turn amber during a single telephone conversation.

Occasionally it turned red.

Red required a meeting.

Consulting projects are often divided into workstreams because complicated problems become more manageable when responsibility is organized into distinct areas. Large transformations involve technology, operations, finance, people, governance, and a remarkable number of decisions that cannot be made independently.

Breaking the work into smaller pieces allows teams to develop expertise, establish accountability, and make progress without requiring every participant to understand every detail.

It is a sensible idea.

It also introduces a peculiar complication.

The pieces must eventually fit together.

A technology team can design a brilliant new system that operations cannot use. A finance team can identify savings that depend on positions the organization has no intention of eliminating. A communications team can announce a transformation before anyone has agreed what the transformation actually involves.

Every workstream can be green while the project itself is heading directly toward a cliff.

Rebecca knew this.

She had been managing consulting engagements for thirteen years and had developed an instinct for identifying problems concealed beneath reassuring status reports.

On a Thursday afternoon, she asked Oliver whether his workstream was on track.

"Yes," he said.

Were the deliverables progressing?

"Yes."

Had the process owners agreed on the future-state design?

"Mostly."

Rebecca looked up.

"Mostly?"

Oliver explained that the regional operations teams had agreed on the general approach, but the technology workstream had not confirmed whether the proposed system could support it.

Why not?

Because technology was waiting for the final process requirements.

Which operations could not finalize until technology confirmed the system capabilities.

Rebecca put down her pen.

There it was.

The workstream had encountered another workstream.

Rebecca asked Oliver to arrange a meeting with the technology lead and the operations director.

"No presentation," she said. "Just the people who can make the decision."

Oliver was surprised.

He had already begun preparing a presentation.

Nevertheless, he arranged the meeting.

Linda attended from operations. A technology architect named Sanjay joined from the systems team. Oliver brought the process maps and a notebook.

For twenty minutes, they discussed the requirements. Sanjay explained the system constraints. Linda explained how orders actually moved through the warehouse. Oliver asked questions and drew a diagram on the whiteboard.

Then Linda mentioned that one of the proposed approval steps was unnecessary.

It had been included because the old system required it.

The new system did not.

Sanjay confirmed this.

They removed the step.

Suddenly the process worked.

There was no escalation. No steering committee. No revised governance framework.

Three people had sat in a room and solved the problem.

Oliver was astonished.

He had spent two weeks attempting to coordinate the resolution through status updates, issue logs, and carefully worded emails.

The answer had taken twenty minutes.

Rebecca was pleased.

"That's the job," she said.

By the end of the engagement, Oliver had learned considerably more than he had expected.

He could explain the differences between the four businesses' operating models. He knew which decisions required executive approval and which could be made by the people doing the work. He understood that a process map was useful only if it described something that could actually happen on a Tuesday morning when three employees were absent and a delivery truck arrived late.

He had also learned that managing a workstream required a particular combination of patience, diplomacy, analytical discipline, and the ability to remain polite when someone announced, during the final week of a project, that they had just remembered an important requirement.

THE WORKSTREAM

At 8:43 on a Monday morning, a young consultant named Oliver was informed that he would be leading the workstream.

He was delighted.

Oliver was twenty-seven years old, had graduated from business school fourteen months earlier, and had recently purchased a navy-blue suit that made him look considerably more experienced than he was.

He had been working at the firm for eleven weeks.

He knew what a deliverable was. He knew how to build a financial model. He knew that a meeting scheduled for thirty minutes would generally last forty-five, unless a senior partner attended, in which case it might last four.

He was less certain what a workstream was.

He had heard the word approximately six hundred times since joining the firm. It appeared in proposals, project plans, steering committee presentations, and conversations conducted by people who seemed to understand it perfectly.

Oliver understood that workstreams had owners, milestones, dependencies, and deliverables. They could be accelerated, consolidated, delayed, or escalated. Occasionally they were described as critical, which appeared to mean that someone important had become concerned.

But what, precisely, was the stream?

And where was it going?

His engagement manager, a woman named Rebecca Chen, explained that he would be responsible for Workstream Three: Operational Process Harmonization.

Oliver nodded confidently.

Rebecca handed him a project plan containing forty-seven activities, twelve milestones, six decision gates, and a color-coded timeline extending through the end of November.

"You'll own this," she said.

Oliver looked at the spreadsheet.

There was a great deal to own.

The client was a national distribution company that had recently acquired three regional competitors. Each business had its own operating procedures, reporting systems, organizational structure, and strongly held opinions about the correct way to process a customer return.

The acquisition had been announced as a transformational opportunity to create a unified, customer-centric organization capable of delivering operational excellence at scale.

In practice, the four companies could not agree on what to call a warehouse.

One called it a distribution center. Another called it a fulfillment facility. A third used the term branch, despite the fact that some branches occupied buildings large enough to accommodate commercial aircraft.

The fourth company called everything a depot.

Oliver's assignment was to help bring these operations together.

Rebecca explained that Workstream One was handling technology integration. Workstream Two was responsible for organizational design. Workstream Four was developing the financial benefits model, and Workstream Five was managing change communications.

Workstream Three would define the future operating processes.

"You'll need to coordinate with the other leads," she said.

Oliver wrote this down.

He did not yet understand that coordinating with the other leads would eventually consume approximately seventy percent of his waking hours.

By Wednesday, he had scheduled seventeen meetings.

By Thursday, eleven of them had been rescheduled.

By Friday, he had created a spreadsheet to track the rescheduling of the meetings.

Rebecca called this good project discipline.

The following Monday, Oliver chaired his first workstream meeting.

There were fourteen participants, representing operations, finance, technology, human resources, procurement, and three separate business units. Two people attended by telephone. One appeared to be driving. Another had joined from a conference room in which a persistent mechanical humming made every contribution sound like an announcement from inside a submarine.

Oliver began with the objectives.

He explained that the purpose of the meeting was to establish a shared understanding of the current-state processes, identify opportunities for standardization, and agree on the approach for future-state design.

Everyone nodded.

Then a regional operations director named Linda asked whether the new process would require her warehouse to stop using its existing picking system.

Oliver said that the question would be addressed as part of the design phase.

Linda asked when that phase would begin.

Oliver explained that it would begin after the current-state assessment.

Linda asked how long the assessment would take.

Oliver referred to the timeline.

Six weeks.

Linda looked at him.

"It takes us four minutes to pick an order," she said.

Oliver made a note.

He had discovered his first stakeholder concern.

Over the following weeks, the workstream developed a personality of its own.

It acquired a status report, an issue log, a risk register, a decision tracker, and a folder containing versions of documents whose names had become so long that the file-sharing system occasionally refused to accept them.

There were process maps, responsibility matrices, workshop materials, and a presentation entitled "Future-State Operating Model Design Principles" that required three meetings to finalize.

Oliver learned that an action item was not necessarily an action anyone intended to take.

He learned that a dependency was something another workstream needed to finish before his workstream could finish, and that the other workstream was generally waiting for information from a third workstream, which was waiting for approval from someone who had gone on vacation.

He learned that the phrase "Let's take that offline" usually meant the subject would return at the next meeting with considerably more people copied on the invitation.

And he learned that a green status indicator could turn amber during a single telephone conversation.

Occasionally it turned red.

Red required a meeting.

Consulting projects are often divided into workstreams because complicated problems become more manageable when responsibility is organized into distinct areas. Large transformations involve technology, operations, finance, people, governance, and a remarkable number of decisions that cannot be made independently.

Breaking the work into smaller pieces allows teams to develop expertise, establish accountability, and make progress without requiring every participant to understand every detail.

It is a sensible idea.

It also introduces a peculiar complication.

The pieces must eventually fit together.

A technology team can design a brilliant new system that operations cannot use. A finance team can identify savings that depend on positions the organization has no intention of eliminating. A communications team can announce a transformation before anyone has agreed what the transformation actually involves.

Every workstream can be green while the project itself is heading directly toward a cliff.

Rebecca knew this.

She had been managing consulting engagements for thirteen years and had developed an instinct for identifying problems concealed beneath reassuring status reports.

On a Thursday afternoon, she asked Oliver whether his workstream was on track.

"Yes," he said.

Were the deliverables progressing?

"Yes."

Had the process owners agreed on the future-state design?

"Mostly."

Rebecca looked up.

"Mostly?"

Oliver explained that the regional operations teams had agreed on the general approach, but the technology workstream had not confirmed whether the proposed system could support it.

Why not?

Because technology was waiting for the final process requirements.

Which operations could not finalize until technology confirmed the system capabilities.

Rebecca put down her pen.

There it was.

The workstream had encountered another workstream.

Rebecca asked Oliver to arrange a meeting with the technology lead and the operations director.

"No presentation," she said. "Just the people who can make the decision."

Oliver was surprised.

He had already begun preparing a presentation.

Nevertheless, he arranged the meeting.

Linda attended from operations. A technology architect named Sanjay joined from the systems team. Oliver brought the process maps and a notebook.

For twenty minutes, they discussed the requirements. Sanjay explained the system constraints. Linda explained how orders actually moved through the warehouse. Oliver asked questions and drew a diagram on the whiteboard.

Then Linda mentioned that one of the proposed approval steps was unnecessary.

It had been included because the old system required it.

The new system did not.

Sanjay confirmed this.

They removed the step.

Suddenly the process worked.

There was no escalation. No steering committee. No revised governance framework.

Three people had sat in a room and solved the problem.

Oliver was astonished.

He had spent two weeks attempting to coordinate the resolution through status updates, issue logs, and carefully worded emails.

The answer had taken twenty minutes.

Rebecca was pleased.

"That's the job," she said.

By the end of the engagement, Oliver had learned considerably more than he had expected.

He could explain the differences between the four businesses' operating models. He knew which decisions required executive approval and which could be made by the people doing the work. He understood that a process map was useful only if it described something that could actually happen on a Tuesday morning when three employees were absent and a delivery truck arrived late.

He had also learned that managing a workstream required a particular combination of patience, diplomacy, analytical discipline, and the ability to remain polite when someone announced, during the final week of a project, that they had just remembered an important requirement.

There had been difficult days.

There had been spreadsheets that refused to reconcile, meetings in which nobody made a decision, and an unforgettable afternoon when two senior managers spent forty minutes debating whether a particular activity belonged in Workstream Two or Workstream Three.

Oliver eventually suggested that it might be more productive to complete the activity first and decide who owned it afterward.

Neither manager appeared entirely comfortable with this proposal.

But the activity was completed.

Six months after the project began, the company launched its new operating model.

There were complications, naturally. A reporting interface failed on the first morning. One warehouse continued using an old spreadsheet for several weeks. Linda discovered a process exception nobody had mentioned during the design workshops.

But the operation continued. Orders were shipped, customers were served, and the four businesses began functioning more like one organization.

At the final project meeting, Rebecca thanked the team for its work.

There were slides showing completed milestones, realized benefits, and the transition to business-as-usual operations.

Oliver's workstream was green.

He had never been so pleased to see a green rectangle.

After the meeting, Rebecca stopped by his desk.

"Good job," she said.

Oliver thanked her.

Then she told him that he would be joining a new engagement the following Monday.

A global manufacturing company was consolidating its procurement operations across twelve countries. The project involved six business units, four technology platforms, and an executive steering committee based in three different time zones.

Oliver would be leading the process improvement workstream.

He nodded.

This time, he knew exactly what that meant.

He opened his calendar.

There was already a meeting invitation.

THE WORKSTREAM celebrates the complicated machinery of modern consulting projects, the people responsible for turning ambitious plans into coordinated action, and the remarkable amount of human effort required to make a collection of separate activities move in the same direction.

An original BIENTEVEO design for management consultants, project managers, transformation teams, business analysts, operations specialists, and everyone who knows that a workstream is never really finished until all the other workstreams have finished too.

The T-Shirt

Made from 100% ring-spun cotton, the Comfort Colors 1717 garment-dyed T-shirt has a soft-washed feel and relaxed fit designed for comfortable everyday wear. Garment dyeing gives the fabric its distinctive lived-in character, while durable construction makes this a shirt intended to be worn often.

• 100% ring-spun cotton
• Soft-washed, garment-dyed fabric
• Relaxed fit
• Double-needle stitching throughout for added durability
• Seamless tubular construction with no side seams
• Designed to retain its shape through regular wear