Lego My Schedule
There is no question that one of the keys to success on all projects is communication. Almost every project struggles with communication at some point. We define communication plans, have meetings, share minutes, utilize the latest technology, build tools, and still communication is at best difficult. Though we are all born with the basic tools to communicate, and most of us spend a large percentage of our time communicating, we could all use some help being better communicators.
I believe that some of our communications challenges have to do with our predisposition to use speaking and writing as our primary means of communication.
In addition to the daily project management I do for companies, I occasionally speak, write and educate. One of the reasons I enjoy doing these side activities is because they keep me fresh and provide me with a continual flow of new ideas and perspectives. Training in particular is an interesting activity because of the emphasis it puts on being an effective communicator. When training, it is inevitable that the audience of students will have a variety of learning styles that all need to be accommodated if you have any hope of being effective in creating change in people's behavior. I believe in the old adage that "if behavior hasn't changed, learning hasn't occurred," so I measure my effectiveness as an educator by whether behavior changes or not.
For me, teaching is an opportunity to practice communication skills. I say that because I know that most people favor some particular method of interacting with, taking in, and processing information. The primary activity in most instructor-led training is disseminating information. There are numerous popular theories on the various learning styles, and my intention in this article is not to delve into the different styles, but rather to just acknowledge that they exist and have to be considered. Therefore, if you want to be an effective communicator you will need to appeal to the different styles or suffer the consequences of leaving your audience unaffected—a waste of everyone's time.
But most of them boil down to the primary medium of the communication or interaction—i.e., audio, visual, or physical—and the means of processing the information—conceptually or experientially. Unfortunately, most training is highly geared to audio/visual and conceptual, not physical and experiential. This is the mode we were conditioned to through traditional academia and it is also the one we propagate for most of our project communications.
Today, most of the training I do has some form of physical and experiential element to it because I believe and have seen that this is the most effective method of creating behavior change. However, when I get back to my projects, I fall back into the habitual mode of audio, visual, and conceptual. E-mails, meeting minutes, schematics, diagrams, and even dialog can be enhanced by the richness of a physical experience.
On a recent project, we were having numerous discussions regarding the complex scheduling of incrementally adding functionality to a new system (using an Agile approach) while simultaneously rolling it out to a large number of users over the period of a year (using a Six Sigma approach). The interdependencies were complicated and the combination of the two different approaches made it all the more challenging.
So like all good project managers we went to our tool of choice (Microsoft Project, right?) and built a beautiful representation of the proposed rollout and product development to communicate the plan. While this was a valuable exercise to understand dependencies and forecasted resource demands, the look on our stakeholders' eyes as they glanced at the Gantt chart said they needed something else: Legos.
A quick trip to Legoland (I'm fortunate to live near the Mall of America), $100 later, a nod to the smiling security guard (fortunately it is the holiday season), and we had the tools to begin to create our experiential schedule. The goal was to build a 3D Lego representation of the schedule that would increase awareness of the interdependencies and required lead times for the various portions of the plan. So, anyone who had an idea during the planning process was free to get up and experiment with building the schedule themselves. No one was limited by their understanding of the tool, only the physical restrictions of the toy.
Here's how we started. The bottom row of Legos (white) represented the calendar timeline. Each Lego block was a week with the date of the Friday marked on it with a Sharpie. Sitting on top of the timeline were the incremental iterations of the product development sprints and releases (in red), with new functionality being added to the production environment every four weeks. What specific functionality was being delivered in each release was dependent on the requirements of the new users being brought onto the system and any generic new functionality added to the base product that would benefit all users.
Sitting on top of the product development releases were the individual implementations of the different new user groups. Each new group had a repeatable set of similar tasks that needed to be performed: data analysis, process re-engineering, data migration, training, etc. Each of these tasks was represented with a different color Lego of appropriate length and stacked or sequenced based on their dependencies, creating a sub-assembly for each individual implementation.
With the product schedule locked and the implementations chunked, the moving parts were fewer and the illusion that tasks could just be moved independently was visibly and physically evident. Stacking too many implementations in too short a time period created an obvious problem that even the best Gantt chart could not rival. The immediate visual representation of the resource requirements and the lead times necessary to get new functionality into the product to coincide with an implementation provided a collective "aha moment."
The point is not that Legos are a better tool than Microsoft Project (though I'm sure I could find at least a few frustrated PMs who would claim that is true), but rather to explore alternative ways of conveying ideas. The real value of this exercise wasn't that we ended up with a good schedule, the real value was the effective communication of the complexity of the schedule though the personal experience each person had with creating the physical schedule and therefore understanding the result. If a picture is worth a 1000 words, participation in creating the picture is worth a million.
As I left the office tonight, the Legos were perched curiously on the top of the project manager's cube wall for all to see. And there on the top of the highest Lego stood a little Lego man waiving a flag. Go team go!