“Nailed it.” A lesson in overcoming project complexity
When your project shows signs of trouble, go basic first.
It was Benjamin Franklin and not 70’s musician Todd Rundgren who first admonished us to pay attention to the basics or be willing to accept unpleasant consequences.
“For the want of a nail the shoe was lost,
For the want of a shoe the horse was lost,
For the want of a horse the rider was lost,
For the want of a rider the battle was lost,
For the want of a battle the kingdom was lost,
And all for the want of a horseshoe-nail.”
Are you singing yet?
“HOWs” and nails have something in common: they’re pointed and effective for building strong foundations.
Much of my work focuses on involving people in activities and decisions about their work and how it will change as the technology they use changes. Having been a consultant/leader with a Big 4 firm, my project experience is extensive and varied. Project work sometimes got complicated, and we’d have to resort to heroic measures to finish. Sometimes people got burned out, but we delivered. Looking back, I can’t help but wonder….when the going got tough, why weren’t we looking more closely at the basics first – the foundations of team effectiveness?
I used to believe the secret sauce of strong project teams –and their effectiveness– was chemistry. Harkening back to a “Camelot” project – we had all the right capabilities and expertise, we were aligned on scope and approach, collaborative, and delivered a great project. Those characteristics are all easily seen. Yet, as I’ve continued to explore the essence of organizational culture I’ve come to realize that a team’s respect for [and engagement in] structure, visible processes, and clear governance, although perhaps more difficult to see, were the foundation, the secret sauce, of what made all the other characteristics work well –and ultimately are what made us successful.
How did I figure this out? Contrast.
Many years after the curtain came down on my Camelot project, I was asked to lead the process / organization side of a large technology project. Starting a project is like building a house – the quality of the foundation defines the remainder of the effort. The project had been operational for a few months when I joined so the foundation had already been poured. I dismissed the occasional hiccups I noticed as “the team getting started on a new project” –for as long as I could. At one point, I suggested that we revisit our project governance – the operational guide, how it was implemented, and whether the team followed it – but this was a mature team and the general consensus was that everyone knew what to do.
And so, I relented. I was the new person and thought it best to heed the advice of Edward Baker “A large percent of the time it is best to just stand there rather than to do something.” Baker was a protégé of Dr. W. Edwards Deming, and is the author of the recent book, THE SYMPHONY OF PROFOUND KNOWLEDGE: W. EDWARDS DEMING’S SCORE FOR LEADING, PERFORMING, AND LIVING IN CONCERT. And so, instead of just doing something, I observed and took lots of notes.
To be honest, there were so many things happening at once, it was impossible to identify clearly any specific, superficial cause for the hiccups. Have you ever been sitting at your desk on a Monday morning and experienced the subtle fragrance that tells you your office trash can wasn’t emptied over the weekend? You know you’d better take care of it – because it’s not subtle for long. Intermittent disruptions quickly turn into a steady stream of issues blockers, miscommunications, and disagreements about how the work should get done.
The “ask” from the team arrived in a one-line email: “Can you help us figure this out?” Now they were ready for me, and I was ready for them.
I had been thinking a lot about what I’d observed, but I was hard-pressed to know where to start. You know how in the movies the sound of a needle scraping across a vinyl record album silences a roomful of people? The thought of my mentor’s reaction to my lizard-brain urge to jump straight to solutions has the same effect. “How’s that working out?” he’d ask in his irritated-but-amused tone. Then, he’d remind me that “faster is often slower.”
One of the things Dr. W. Edwards Deming taught us through the System of Profound Knowledge is the importance of understanding our organization as system. When we do this, we can study it and understand how it performs, and develop and test theories on how we can improve it. When we attempt to “fix” the system without first understanding it – there is a high likelihood that we will make things worse. So, as I slowly backed away from the fire with the still-full gas can in hand, I pondered what my mentor would say and remembered the advice of Tim Timmons, a Major League Umpire who presented at a function I attended. On the subject of expanding our capabilities – and what to do when we’re just short of knowing what to do next – he reminded us to “return back to center” – the place where you know what you know.
So, that’s what I did. Using Dr. Deming’s diagram of how a system operates, I worked with the team to put together the picture of our project as a system – starting with the Aim (the importance of this project in the larger scope of the organization).
After we defined the Aim and value chain (the activities that contribute directly to achieving the Aim), we looked at inputs and influences – starting with the obvious – software, knowledge, development tools and the like. As the list of inputs waned – we crossed over to outputs and outcomes. Again – obvious ones like requirements and designs were mentioned. Then I prompted a little – asking the team to consider some of the outcomes we saw that we didn’t want: strain, and delays…. Light bulbs coming on. For 45 minutes, I shuffled between two sides of the white board -adding some inputs – but more influences; and some outputs – but more outcomes.
When we finished, we had a picture.
That picture helped us develop some themes – which showed us that while the situation seemed complex, it wasn’t overwhelming. In the next session, we did some root cause analysis and looked for low-hanging fruit – the solutions you can test fairly quickly. After three working sessions, we had a plan in place. Everyone was clear on what to do, by when, and by what method.
If you’re wondering, yes, governance (or the team’s lack of clarity with respect to governance) was a root cause. We revisited roles and responsibilities, reinforced processes for communicating across the team, and engaged the entire team in the development of RACIs – articulating what Roles are Accountable, Responsible, Consulted, and Informed – for every operational process. We also clarified the project methodology and trained everyone on it. All of the governance resources and tools became living documents that could be easily accessed by anyone on the team.
You see, it’s one thing to know, in general, WHAT a “role” does on a project. When we don’t take the time to clearly define the HOW, it’s like using too few nails to build a foundation. Before you know it, you’ll be fixing problems instead of marching toward your Aim.