Interested in learning more?

2017 Rise Up Dinner – ROOTS Young Adult Shelter

Plaster Group is honored to have sponsored Seattle’s ROOTS Young Adult Shelter fundraiser Rise Up for the 5th year running, celebrating ROOTS’ anniversary as an 18 year-old organization.

It has been wonderful to watch this event grow from its inauguration.  In the face of rising concerns over Seattle’s homeless crisis, it is incredibly important to support organizations like Roots. Please visit the ROOTS website to find out more about how you can volunteer or contribute in other ways.

 

Check out ROOTS’ Impact

  • It takes $86 in resources to host a guest for a night – but $44 is covered by in-kind donated food and labor
  • 32,400 hours of labor are donated annually for Friday Feast and shelter by ROOTS volunteers
  • ROOTS Supplies 16,000 “bednights” or stays by young people every year
  • 92% of young people without stable housing polled during the 2017 “Count Us In” survey identified employment as their top goal
  • ROOTS washes 2,300 loads of guest laundry and provides 8,600 showers annually

Do you have any Items on ROOTS’ Wishlist?

  • Full-size bath towels
  • Nail clippers
  • Boxer shorts, undershirts, socks (new)

Plaster Group Book Club – Getting Naked, a Business Fable

by Mike Fernandez, Sr. Business Intelligence Consultant

Book Overview

In “Getting Naked”, Patrick Lencioni presents a consulting approach that maximizes value to the client while emphasizing the role of a consultant as a true servant to the client company. He does this by relating a story of how Jack, a senior consultant at Kendrick and Black (K&B), is pushed into a completely different company culture at K&H’s recently acquired company Lighthouse Partners (Lighthouse).  Jack has had a somewhat adversarial relationship with Lighthouse in the past and he is not initially interested in learning about or applying their methods.

During the story, Jack is exposed directly to the way that Lighthouse works and the attitudes that their consultants bring to their clients, an approach developed over time through discussion, observation and application.  Jack’s journey is not an academic one – his insight and growth come from working with Lighthouse consultants at client sites and from personal experience.  At one point, he has several “teachable moments” as he leads a project using the Lighthouse approach.  Jack goes from a biased outsider to a full participant – and as he progresses, he learns to appreciate the results of the different approach. As a result of his new knowledge and viewpoint, Jack creates a model for the methodology and approach.  He then has the opportunity to present this model to colleagues at K&H and gains some converts along the way.

So, what does Jack learn?  The final section is devoted to an overview of the model that’s used by the author’s real-life consulting company, which he calls the Three Fears.   These are available in graphic form at Patrick’s website (linked at the end of the article).  Simply reading the list can provide some info, but the true value comes from reading about Jack’s journey –  which provides the necessary context to truly understand the reasoning and value behind this approach.  That said, here are the primary points of the model…

The Model

The Three Fears and strategies to avoid them:

1) Fear of Losing the Business – the customer needs to know that we’re there to help them; avoid making our primary goal maintaining or increasing our revenue stream

  • Always consult instead of sell
  • Give away the business
  • Tell the kind truth
  • Enter the danger

2) Fear of Being Embarrassed – avoid letting a lack of complete expertise in a client’s business or scenario result in not finding and following important but perhaps not obvious information

  • Ask dumb questions
  • Make dumb suggestions
  • Celebrate your mistakes

3) Fear of Feeling Inferior – don’t allow the need to be an “important consultant”, with certain role and duty expectations, override service to the client and acting in the client’s best interest

  • Take a bullet for the client
  • Make everything about the client
  • Honor the client’s work
  • Do the dirty work

A mindset that will help with all of the above is to always be willing to admit your weaknesses and limitations.

The Reviewer’s Experience

I found the book to have a strong message worth examining by the modern consultant – that as consultants, our purpose and focus should be on the client and what helps them.  Following this approach may take us out of our comfort zones, but a quality and appreciative client can be our best advocate.

For those having difficulty with the idea of not selling their services, the story relates that having happy clients can be the best source of new clients – and that by focusing on consulting directly with the client, rather than spending time on sales, “Those clients in turn became a sales engine for the firm…and it was references from clients that shortened the sales cycle considerably.”  Jack’s chapter titled “The First Fear” explains that “…It’s about building trust.  And in the end, that means the client trusts them and takes care of them.”

I find the second fear to be a challenge – as a consultant, not being the expert in everything.  Although not my first inclination, the times I have stepped back and asked the basic questions about specifics or situations , I was rewarded with a better understanding and with an excellent relationship with my client.  This chapter provided even greater incentive to continue doing this.

The third fear, as the book notes, can be a subtle variation on the second fear, but it is different.  The third fear relates to doing what needs to be done, regardless of what type of task or role it requires.  My experience, like the author’s experience, is that doing some things not normally associated with the role of “Consultant” has been more instrumental in moving projects and deliverables forward than other more “high level” activities – at the right times.

I feel that this book will provide insight to a different approach that can help consultants and non-consultants build better professional relationships.  This book can get you started, but as they point out, “…there is a big difference between understanding something and putting it into practice.”

Interested in learning more? Pat’s website contains information on this book and others.

 

Plaster Group Volunteer Day – Q3 2017

One of the most popular suggestions to improve our workplace environment on last year’s employee satisfaction survey? That Plaster Group should volunteer our time somewhere as a team. So we took our consultants up on their suggestion and did just that.

Did you know 1 in 5 Washingtonians relies on their local food bank? This Saturday, Plaster Group consultants and their families were warmly welcomed by Northwest Harvest, the only nonprofit food bank distributor operating statewide in Washington. With a network of 375 food banks, Northwest Harvest is able to feed a family of three a nutritional meal with only 67 cents due to the work provided by volunteers. We had a great time getting a mountain of beans packaged through coordination and teamwork!

Plaster Group is one of Washington’s Best Places to Work!

Plaster Group has been a finalist on the Puget Sound Business Journal’s WA Best Places to Work three times, and last Thursday we were recognized as the second best medium-sized company to work for in Washington. We are very proud of this distinction as we consistently seek to serve our Consultants, our Clients, and the Community. Read more about why we are one Washington’s Best Places to Work here

July 2017 Management Consulting Newsletter

Agile Nirvana

by Shama Bole, Sr. Agile Consultant 

Growing up, I remember being told the story of a village boy in India who, at a very tender age, wrote a famous treatise summarising his meaning-of-life philosophy and conclusions, and in the wake of that, sought samadhi (death via unending meditation) in a nearby cave that he requested be sealed thereafter. (He has been revered as a saint since the 13th century.) Apparently, life held no more questions, surprises, puzzles worth the pondering.

Unfortunately, people with a similar degree of certitude about their adoptive philosophy are rarely obliging enough to hibernate in meditative solitude. Instead, they evangelise. Nowhere is this truer than in the Agile landscape. (Well, that’s an exaggeration, given the torridity of political and religious evangelising, but it makes my point.)

I think this rather stream-of-consciousness article/gripe was borne out of some frustration with Agile converts and sometimes uninformed zealotry (which sounds breathtakingly presumptuous, I know). But, hear me out.

Art, Not Science

Agile, like project management, is more an art than science and draws more than its share of argumentative fanatics. (This may explain why physical science practitioners seem saner since they deal with absolutes, though Copernicus, Galileo et al might have deeply ironic posthumous thoughts to share on that). Art seems to have a greater margin for opinions and ambiguity and that may be the source of so much dissent within the ranks of Agilists. Natural science absolutely has its own paradigms but there is a grounding in theory and empirically measurable outcomes that is extremely challenging to achieve outside of the laboratory. Agile is very much about people, and relationships are messy things. There is no science around resolution and no clear path to some universal truth, as may be found in managing budgets or PNL statements. Dialectics is critical to intellectual progress but Agile thinkers often seem blind to all views but their own.

Unchecked Passion

Sounds thrilling, doesn’t it? Not quite. My company is often engaged to effect Agile transformation, and we’re always looking to bring on folks who can accomplish that. When hiring, we look for not just competence and expertise but also a level of polish combined with amicability. Inevitably, “a spoonful of sugar makes the medicine go down”, one of the harsher truths in life being that any kind of change is easier when shoehorned by someone personable. It’s not the strength of one’s convictions that sells but rather the efficacy of one’s approach. I’m sure this is true in matters of the heart as well! Too many Agilists seem to forget/ignore this principle and indulge in passion unchecked by any veneer of professionalism.

Old Wine in New Bottles

A lot of Agile presentations and written material is essentially nothing more profound than old wine in new bottles. I saw this in graduate school, where we students floundered for a dissertation topic on which to make our mark in academia. It wasn’t about original thinking, but rather about leveraging intellectual capital to launch oneself out of obscurity.

To illustrate this: at one of the conferences I attended, an Agilist gave a talk predicated on the notion that there were no values prescribed by Agile. To me, that seemed a case of not seeing the forest for the trees. Agile is a philosophy, a set of values and a suggested way of interacting with the world. It’s a directional compass and a behavioural guide. No values?

More Emotional than Cerebral

To a lot of practitioners, Agile philosophy comes as epiphany, and I don’t use the word lightly. After all, what comes to your mind when you think of epiphany? To me it is the image of Archimedes shrieking “Eureka!” as he ran through the streets of Syracuse, naked from his bath, in a state of mental elevation that obliterated everyday habits of common sense and rational behaviour … a possibly apocryphal tale but who cares? What a great story!  Adopting Agile is beyond just methodology – it is an inner transformation that engages one’s passions and beliefs and value systems. To me, that puts it outside the realm of a purely cerebral exercise in project delivery. Some of the fallout/passion is attributable to that.

Hubris

Other than (excess) passion, Agilists also tend to suffer from an excess of certitude and a tendency to dismiss everyone else’s opinion and store of knowledge. I’ve seen CVs posted where Agilists proclaim themselves “Masters” of Agile. Where does this hubris come from? I listened to a hilarious segment by a stand-up comedian who explains the inexplicable success of political rhetoric/pap with the following theory: people tend to see as truth (only) what they can in fact understand. However, truth can and often does come in complex and no-directions-provided packages as well. Interestingly enough, though, understanding Agile is not hard. Implementing it is tricky. The best (Agile) coaches I know are humble and genuinely put other people and their interests first. They get it.

Low Entry Point

Because Agile reads as easy, one other big casualty has been the entry of unqualified and unsuitable practitioners into the field. Maybe this is akin to why there are so many charlatans in what is called “alternative” medicine such as homeopathy and acupuncture. There are a lot of ways and reasons to explain away why outcomes are not as expected. Of course, it is circular reasoning that if Agile were practiced correctly then outcomes could always be predicted (as desired). This is why it also baffles executives who are interested only in outcomes – totally understandable – and have only a foggy conception of what Agile means. And proceed, therefore, to harry and micromanage it to death.

Team-Building, not Reputation-building

Finally, to me a good Agile coach is like a parent. It’s the daily little disciplines and acts of patience, humility (and dare I say) suffering that brings together a community of people embarked on a convergent goal. It’s not about making your mark via displays of bombastic self-virtuosity.

In conclusion: I picked the term “nirvana” almost unconsciously, but I think one aspect that calls to me is the constant striving. To be better, to keep trying, to never rest on one’s laurels. And liberation from painful habits and practices that keep us chained to mediocrity and hamper self-actualisation. (The term “best practice”, which is bandied about with unctuous glee, also makes me cringe nervously.)

Agile nirvana is a lofty ideal but one where the journey is as rich with rewards as the destination. And, my respects to the (very few) coaches who make trustworthy companions on this sojourn.

Unsure of how to begin  your journey to Agile nirvana? Our experienced Agile Team would be happy to provide you with a guide!

How Two Necks in Redshift can help you from Losing your Head in Tableau

by Colin Carson, Sr. Business Intelligence Consultant

Data Warehouse Diagram

Abstract

When a curated data set is needed for reporting, a common design pattern is to create a view in the same database as the warehouse. This view serves as the endpoint or “head” for BI tools and end-users. This “one view in the warehouse db” pattern (a view in the warehouse’s database) provides a layer of abstraction from underlying warehouse structures–the facts and dimensions in a star schema–but is not always the best approach due to several weaknesses (detailed below). Here we propose a high-level “two necks” design pattern with six parts: a dedicated reporting data mart database, a view in this reporting database, two staging tables, a view on top that serves as the single head or endpoint for users, and a processing approach that swaps between one of the two neck tables.

Assumptions

  • We assume some or all of the negatives in the Antipattern section are things your business wants to avoid.
  • We assume you desire a live connection to the warehouse rather than Tableau data extracts. In our solution, we found extracts performed slightly faster but the data could not be refreshed as frequently as our etl that created our user-facing endpoint view. Our ETL process ran microbatches every 30 seconds using a shell script that used psql to call sql commands.
  • We assume the cost of adding additional steps to your etl logic to swap tables is worth the benefits.
  • Our implementation of this pattern used a Redshift warehouse because the transactional source data and etl was already in AWS, and our dashboard used aggregations over potentially many rows (less than a million to start with, but potentially hundreds of millions). There are other databases that could be used for warehousing, and other databases might be more appropriate if high concurrency is required: Redshift supports 500 concurrent user connects, Aurora up to 16000, and when Tableau server is used with Redshift the default parallel query limit is 8.
  • We used Tableau for the dashboard, but this pattern can be applied to other frontend presentation tools too.

Antipattern

A view in the warehouse’s database is simple and can be implemented quickly, but it has weaknesses:

  • Tightly coupled: changes for end-users need to happen to the view in the warehouse’s database. Because downstream BI tools or single-tenant data marts are pointed to a view in the warehouse’s database, it means the end-users and warehouse are tightly coupled. When significant warehouse design changes need to occur, there is downtime and users are impacted. Conversely, when design changes are needed on the reporting side, the view in the warehouse’s database would need to be changed (because the reporting structures live in the warehouse, not in their own separate reporting database). Reporting changes cannot be made independently of warehouse changes. For more information about a reporting database, one resource is Martin Fowler’s writeup here.
  • Fully populating large tables takes time, and users are impacted if they have to wait for the load to finish. Users will see zero rows between the time the table is truncated and fully populated, which can happen frequently in a near real time pipeline (eg every 30 seconds). The duration of the refresh can be lengthy, because the table needs to be fully populated during this step (the database might have to do a lot of work). This processing delay for warehouse base tables can be lessened if processing involves a merge/upsert approach as documented here rather than a full load/destructive refresh; nevertheless, users do not necessarily not have to wait if processing is happening.
  • No backup. There is only a single copy of the data that users access at any time. When the warehouse is processed, no snapshot is saved of a previous state, which can be potentially restored if there is a problem. If there is a problem with the etl job processing the warehouse structures (such between the time a base table is truncated and fully populated, or if there is a bug with merge/upsert logic), there is no copy of data in the system and end-users are impacted (reporting is inaccessible).
  • Avoid a performance hit to the warehouse and speed up user queries. Users can negatively impact warehouse performance, and conversely warehouse processing can affect users. This is related to #1 but slightly different: where #1 is more about intermittent design changes, this item (#4) is about the performance experience by end-users. Downstream dependencies such as data marts, BI tools, and end-users are querying the warehouse indirectly through the view. There is no middle step between users and the warehouse, and no physical instantiation of the data assembled for reporting needs.

Recommended Pattern and how it can be Implemented

The weaknesses above can be mitigated with the two neck design shown in the diagram at the beginning of this article. Here’s how you can implement this solution architecture in Redshift:

 

1. Create a reporting database. Example:

CREATE SCHEMA report_schema;

2. Create a reporting view to serve as the integration component between the reporting data mart and the warehouse:

CREATE VIEW report_schema.v_example_dashboard_loader AS /*enter your logic here*/

Our view used 4 tables (1 fact and 3 dimensions), with 2 dimension tables with outer joins. We had 6 calculated fields with aggregations (3 DENSE_RANK functions, 2 SUM, and 1 MAX). and 24 columns. The view returned 539,000 rows in 2.376 seconds using a dc1.large single cluster.

3. Create the loader and backup tables. These two tables are the two necks.

CREATE TABLE report_schema.t_example_dashboard_loader

AS

SELECT *

FROM report_schema.v_example_dashboard_loader;

4. CREATE TABLE report_schema.t_example_dashboard_loader_backup

AS

SELECT *

FROM report_schema.t_example_dashboard_loader;–notice backup looks at the local primary table, not the view that hits the warehouse with a query that can have expensive logic

5. Create the “head” view that services as the endpoint for Tableau:

CREATE OR REPLACE VIEW report_schema.v_example_dashboard_userfacing

AS

SELECT *

FROM report_schema.t_example_dashboard_loader;

6. In the etl sql script, use logic that takes a backup, then swaps the user facing view to the backup, then loads the primary, then swaps to the primary. (Note: merge/upsert approaches can potentially be used here as well.)

TRUNCATE TABLE report_schema.t_example_dashboard_loader_backup;

INSERT INTO report_schema.t_example_dashboard_loader_backup

SELECT * FROM report_schema.t_example_dashboard_loader;

VACUUM report_schema.t_example_dashboard_loader_backup;

CREATE OR REPLACE VIEW report_schema.v_example_dashboard_userfacing

AS

SELECT *

FROM report_schema.t_example_dashboard_loader_backup;

TRUNCATE TABLE report_schema.t_example_dashboard_loader;

INSERT INTO report_schema.t_example_dashboard_loader

SELECT * FROM report_schema.v_example_dashboard_loader;

VACUUM report_schema.t_example_dashboard_loader;

CREATE OR REPLACE VIEW report_schema.v_example_dashboard_userfacing

AS

SELECT * FROM report_schema.t_example_dashboard_loader;

If we define “one neck” as one staging table (no view on top), and “two necks” as two staging/neck tables with one head view on top (which swaps between the neck tables), we can compare processing time.

a. One neck

TRUNCATE TABLE report_schema.t_example_dashboard_loader;

INSERT INTO report_schema.t_example_dashboard_loader

SELECT * FROM report_schema.v_example_dashboard_loader;

1. 7686ms

2. 6271ms

3. 6109ms

average: 6689ms, or about 6.689 seconds

b. Two necks (only the duration of the statements that affect the user-facing table need to be compared, because only these steps affect users).

CREATE OR REPLACE VIEW report_schema.v_example_dashboard_userfacing

AS

SELECT *

FROM report_schema.t_example_dashboard_loader_backup;

CREATE OR REPLACE VIEW report_schema.v_asset_dashboard_userfacing

AS

SELECT *

FROM report_schema.t_asset_dashboard_loader;

2462ms

1221ms

1405ms

average: 1696ms, or 1.696 seconds

Note: when we doubled or even quadrupled the processing power for the cluster size, and added another cluster node, we did not see clear performance improvements.

Conclusion

In our test results, the “two necks” approach addresses all four antipattern points introduced above: avoid tight coupling, decrease process time and user waiting, have a backup, and speed up user queries. We share these test results as an example where this pattern worked for us to challenge a common pattern (a view in the warehouse) so you can consider this two necks pattern for your own solution architecture.

Regarding processing time, the fastest run of two necks (with swapping the view to the staging table not undergoing processing) is more than 5x faster than the fastest run of the old way. On average, the new way is almost 4x faster. We expect these numbers to be more significant with larger data sets in billions of rows, after accumulation for months or years of warehouse data, rather than in our warehouse that was new. Our test results and sql durations are based on actual client test results based on one view, and our results are not necessarily representative of yours.

For further help with using Tableau with Redshift, you can refer to Tableau’s documentation here. Plaster Group’s Data and Analytics Team partners with Tableau and is happy to help you with any additional questions you might have.

Designing Customer Experience

picture of limo with focus on tire

by Doug Ugarte, Supply Chain Consultant

Designing and managing customer experience is a lot like chauffeuring your customer safely to their destination, when suddenly you have a flat tire… on the highway… at night… and have only a crescent wrench and flashlight to replace it. Did we mention that during this process, your customer should be relaxing in the backseat, blissfully unaware of the mission-critical upgrade you are performing under a constrained schedule? If you’re involved in designing or supporting customer experience, you’ve probably contributed to the Herculean efforts that go into producing delighted customers.

Whether your role sits in Supply Chain, Marketing, or Customer Service centers, a tremendous amount of focus is applied to the design and management of customer experience.  Interestingly, we see each of these teams having varying degrees of ownership of designing customer experience, crafting solutions, implementing services, and managing toward a predictable and reliable result.  How are you approaching the customer experience?  Did you take an iterative approach based on customer feedback and/or competitive benchmarking?  Or did you begin with a vision of the end to end experience and implement a solution to support it?

If you expect your customer to choose you for their next purchase, it is paramount that you deliver on your customer experience promise.  Regardless of your product or industry, customers expect and demand flawless execution.  eCommerce customers expect to know when their product will arrive before they even purchase it.  After purchasing it, they want to know that it shipped on time, who is delivering it, its transit status, and that it arrived…all in real time.  Manufacturing and commercial customers rely on you to deliver on your promises so that they can meet their own customer commitments.  You fail once and you might get a second chance.  You fail twice and you’re done.

Different departments could have ownership over designing customer experience.  It may be Marketing because this could be a branding function at your company.  It could be the Customer Service group because they are closest to managing the reality of customer experience.  Or it may be your Supply Chain organization because most of the building blocks of the solution align to their charter.  Regardless of the owner, a successful customer experience requires these teams to perform in concert to decide what to implement, execute the solution, and drive continuous improvement.

To be successful, you must have these core competencies:

  1. Know what you can promise
  2. Clearly articulate the experience that the Customer can expect
  3. Keep your customer informed of progress of their purchase
  4. Deal with issues as soon as they arise. Reset customer expectations if you are unable to resolve the issue behind the scenes

Looking at the list of core competencies, everything falls into one of two themes – external customer communications or internal operations – that determine what can be promised and the certitude of delivering on that promise.

If you pull back the curtain at leading supply chains, you will find a customer promise that is built on knowing that product is available, how long it will take to ship, and how long it will take to arrive at the customer’s doorstep. The building blocks of these core competencies comprise the following strategies:

Formulate your Customer Promise

  • You can have a customized promise to each customer based on real time supply chain insights. Alternatively, you can provide a static offer to all customers and the offer can be adjusted if there are constraints affecting delivery.
  • Inventory Availability – You have unreserved and unrestricted product to ship.
  • Logistics – Calculate time to delivery. Based on ship from/to addresses, calculate delivery commitment based on customer-determined shipping service level.
  • Fulfillment Center – Visibility to operational performance. If SLAs are not being met, you might need to adjust the customer promise up front rather than apologizing for a missed commitment.

Visibility to Execution

  • Integration across all internal and external partners designed to provide real time visibility.
  • Integration should tell you 1) you have a problem, 2) what problem you have, 3) the scope of the problem, and 4) what time it occurred. Visualization tools help you see the issue and if it is growing.
  • This is where “batch” processing becomes the enemy to customer satisfaction. For every minute you don’t know about a problem that has already started, you diminish your ability to fix it without impacting the customer.

Exceptions Management

  • Identify your most common problems and incorporate automated exception handlers to resolve problems before they impact your customer experience. Examples include: Automatically upgrading your shipping service level from 2-day to Overnight because the fulfillment center is a day late. Or, automatically sending a replacement shipment if the logistics provider system shows the item lost or damaged in transit.
  • If you cannot meet your customer commitment, reset expectations based on real time insights (same logic as formulating the original promise). Automated messaging keeps your customer informed and reduces the strain on customer service resources.

Leverage data insights from your Customer Service organization for feedback on how customers feel about your designed experience and how reliably you are meeting it.  Social media analytics can offer additional visibility to what is being said about your company, your customer policies, customer experiences, and more.  You should also assess your competition to understand what you’re up against.  From competitive analysis, social media analytics, and customer feedback given directly to your company, you can garner a good understanding of purchasing drivers, how customers view you versus your competition, and how customer perception aligns to your designed customer experience.  The more granular view you have into the systems and partners involved in the end to end experience the better you will be able to 1) compare customer perception to reality, and 2) evolve your supply chain to be more closely aligned with the reasons customers buy from you instead of your competitor.

Customer experience requires close collaboration between departments that sometimes measure success quite differently.  It requires a complex technical solution to align directly to the customer experience design.  The weakest link is frequently access to real time data, so systems integration becomes a prerequisite for success.  Lastly, with the solution deployed, leverage every source of customer and market insight to understand if you’ve implemented the right design relative to both customer desires and the competitive landscape.