This is the third installment of my collaboration with John Hunter and friends on the Year-End Management Improvement Carnival, where we review the best management improvement blogs and share which posts we found to be the most insightful or helpful.
PART 3 of 4 – Clarke Ching’s stream-of-consciousness blog covers random musings, cartoons, links to useful articles, recipes, mathematical puzzles and games, and thoughts about quality-related techniques including Theory of Constraints and software development.
Testers – the worst thing that happened to software development? (5/30/2008) – This story describes a first-person view of how software quality can be achieved more easily – by studying the successful approaches used by good maintenance teams. “There’s a huge amount that development managers (i.e. those that work on bigger projects) could learn from the way good maintenance teams work. The first would be to break down their work into smaller chunks.” (Again, this reminds me of “stackless thinking”which really appeals to me.)
Critical Chain Scheduling (8/22/2008)– Clarke wrote an article, published over at stickyminds.com, covering how to use the critical chain method to improve scheduling in agile development environments. “Critical Chain, as I’ve described, is a great way of rebuilding trust between managers and their staff. In fact, it is THE best way I’ve found. It’s also sorely needed, judging by some of the comments.”
Lord Kelvin (9/13/2008) – Why measure things? On a trip to Scotland, Clarke reflected on this question as he pondered the intro to Douglas Hubbard’s book, How to Measure Anything: “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of science.”
A Theory of Everything for Software Development (8/7/2008) – Physicists pursue the grand unified theory to explain space, time and everything in between… while noop.nl attempts to reconcile the myriad of approaches to software development by reminding us of context-dependent approaches. Here’s a sample: “Unix and Windows are both proper solutions, though each in its own limited cultural context. And they cannot both be the best solution at the same time and place. (And might I suggest that, in the case of operating systems, a Theory of Everything has already been found with the invention of virtual machines? Just a wild thought.)”
Simple vs. Complicated vs. Complex vs. Chaotic (8/20/2008) – You can have predictable, complex, and chaotic systems that are simple – or, you can have predictable, complex and chaotic systems that are complicated. This is the best description (and collection of online references) I’ve seen to explaining the differences between these concepts. “My computer is complicated. My software project is complex. My house is complicated. My household is complex. My blog is complicated. My thoughts are complex. Your dinner is complicated. Your dog is complex.”
Thank You, Stupid Americans (4/23/2008) – This is an interesting blend of software development insights and politics! Although I don’t personally equate simplicity with stupidity, and I realize there are plenty of smart Americans too, I found this to be a lighthearted and stimulating read.
How to Handle Many Simultaneous Projects (9/30/2008) is also an excellent commentary. I don’t know any manager who doesn’t have this issue – whether they are a quality manager, a technology manager, a construction manager, or a manager of software development.
I’m privileged to be partnering with John Hunter and friends to produce the Year-End Management Improvement Carnival. Our goal is to review the best management improvement blogs out there, and find out what gems were posted during 2008 – then take you on a guided tour of the past year’s most intriguing management insights.
PART 1 of 4 – The first three favorites on my list come from David Anderson’s http://www.agilemanagement.net, a blog that focuses on effective and productive implementation of agile methods in software development and management.
Providing Value with Lean (3/31/2008) – One of the most important considerations while implementing a quality program or process improvement initiative is that you focus on the right aspects of the problem at the right times. This is much easier said than done, especially since the problem solving environment is socio-technical – and as a result, complex. But David makes the excellent point that “doing lean” means more than just eliminating waste. You have to take a systems perspective, and first consider how value is to be added, then analyze the process for flow, and then work on eliminating waste. Sometimes, to get a better process, you have to add waste before the improvements can be realized in a sustainable fashion.
Personal Hedgehog (11/2/2008) – What are you uniquely good at? What are you passionate about? What motivates you economically? The most productive people are in roles that fit them well, and the Personal Hedgehog concept can help you find your niche. (Might also be good for managers who want to help their team members find a good fit.)
Your team is busily working to meet a deadline for an upcoming project, and you’re wondering whether you’re going to be able to pull it together. Everyone is getting nervous, drinking a lot of coffee and Mountain Dew, and staying at the office until the wee hours of the morning. But have you or your project manager stopped to think about whether you are working towards a “real” deadline, or spinning your wheels to meet one that is “not real”?
When real deadlines are not met, there will be negative consequences (e.g. product failures, loss of revenue, loss of goodwill, loss of credibility). Deadlines that are “not real” may have consequences internal to your organization (e.g. loss of goodwill with your boss, delay in providing materials to other employees in your company) but typically can be shifted with less impact.
So why do project managers even set deadlines that are “not real”? Sometimes, internally-focused milestones are required to keep a team aligned, and to provide feedback to assess how well the team is progressing towards externally-focused deadlines. More often, the reasons for originally setting a real deadline have shifted, and the original scenario no longer applies – but no one has stopped to reflect on the fact that the previously set deadline has shifted from being a real one, to one that is not real.
Here are some examples of cases where the deadlines are “real”:
“Life or Death”/”Health or Wellness” situation. If you or someone else will die, or otherwise experience a degradation in their health or sanity or well-being as the result of your actions or inactions, then your deadline is real.
Time-sensitive systems. This is a special case of the “life or death” situation. If your products or processes will stop working unless you deliver a fix by a certain time, then the deadline is real. Y2K was an example of this kind of deadline (regardless of whether the potential impacts were enough to incapacitate software).
Cash flow requirements. If you or your company will run out of money unless you meet your deadline, then you are facing a very real deadline.
Previously set external expectations. If you promised a customer that you would deliver their final project on December 5th, the deadline is real. Not meeting the deadline will result in a loss of revenue, credibility, goodwill, and potentially future business as well. Aggressively setting expectations and striving for transparency are two tactics that can help make “real” deadlines like this a little more malleable.
Inflexible resource allocations. If you only have access to a team member for a limited time before their visa expires, or if you only have enough money to employ contractors for three months, then getting done what you need to get done in a limited time forms a real deadline.
Biological constraints. Oftentimes a woman’s “biological clock” must be considered for deadlines that involve producing new children, but there are other biological constraints that may impact deadlines as well. For example, if today is Saturday and you have a major deliverable due on Wednesday, you could choose to stay awake 24/7 to get it done but you would probably not be successful. Your biological need for sleep (and possibly food as well) would thwart your project plans.
Inflexible policy. If your company has a policy that you are required to follow, and it impacts your projects or milestones, it is very likely that you are facing a real deadline (but you might want to ask the “owner” of the policy you are being impacted by, to confirm). As a more extreme example, if a curfew has been imposed in your area, you will need to finish what you’re doing before a certain time of night.
Meeting laws and regulations. On April 25, 2002, the Sarbanes-Oxley bill was passed, increasing the stringency of requirements for financial reporting. Companies were required to take steps to comply immediately, and had a limited amount of time to prove their compliance (or else there would be financial and legal consequences). When deadlines are externally imposed, and not meeting them can cause lawsuits and fines, they are real.
Shifting sentiment/public opinion/seasonality. If you need to deliver a product that’s meant for use in the summer, and the ice has started to melt and people are headed to the beach, then your deadline is probably very real. If you need to capture “buzz” or other trends in popular culture, and you risk selling less product or increasing your market reach if you don’t finish your work on time, you are facing a real deadline.
How can you tell if a deadline is real? Look for the root cause of the deadline, for example, by asking “5 Whys”. One you know why a milestone or a deadline has been established, you will be better able to find ways to iron out issues that arise when your work is delayed. Furthermore, you will more easily recognize where to focus your team’s effort to prevent negative consequences.
[Note: Some people prefer to call these “hard” and “soft” or “firm” and “not firm” deadlines, but I like the angst that comes along with calling them “real” and “unreal” even though it requires a little bit of hyperbole. Note 2: These elements were brainstormed with Ron DuPlain.]
There is not one person I know who doesn’t have to deal with complexity in their work or personal lives. Either the subject matter they work with is complex or specialized, the politics are stressful, or there’s just too much information to process and the information overload becomes oppressive.
Fortunately, dealing with complexity has been the subject of recent research and there are some lessons to report. These lessons revolve around the importance of “sensemaking” – a term coined by Karl Weick to reflect concerted effort made to understand the relationships between people, technologies, places and events, how they behave, and how to respond to their current and future behaviors.
Weick and Sutcliffe (2001) studied the environments of aircraft carriers, nuclear power plants, and fire fighting teams – situations where the stakes are high, and on-the-job errors can be costly and dangerous. These are the workplaces “that require acute mindfulness if they are to avoid situations in which small errors build upon one another to precipitate a catastrophic breakdown.” Snowden (2003), who worked at IBM, said that most environments just weren’t like that – so it would be difficult to generalize how those workers dealt with complexity to the typical office.
Browning & Boudes (2005) compared and contrasted these two studies to try and define some guiding principles for how people make sense of complex scenarios. Here’s a synopsis of what they found:
1: “Acknowledging and accepting complexity is better than placating it with planning models. There are simply too many situations where the standard tools and techniques of policy-making and decisionmaking do not apply.” The lesson: move away from a “training culture of obedience” and towards a “learning culture of understanding and action”. (This will be a challenge, because it requires humility and trust.)
2: “It is important to acknowledge failure and learn from instances of it.” Self-explanatory, but as above, this requires humility and ego-transcendence. For people to learn from failure, they must first confront it. I can think of some “death march” software projects where failure “never” occurred!
3: “Self-organization is an order that has no hierarchical designer or director.” Browning & Boudes cite Peter Drucker’s idea that “in the Knowledge Economy everyone is a volunteer.” Volunteerism means that everyone is fundamentally qualified to do some part of a project, that roles shift to accommodate existing talents and the development of new talents, and that if a person isn’t working out in one role, they can move to another. In volunteer contexts, leadership is often dynamic, where everyone serves for a time as the leader and then moves on.
4: “Narratives are valuable for showing role differentiation and polyvocality.” There are many voices, and many perspectives, and these can be effectively communicated when people relate to one another through stories and examples. Diversity of opinion and distance from a problem can help raise solutions – but the people who know the situation best, and who are closest to it, must be open to the possibilities. (Easier said than done.)
5: “Conformity carries risks, and thus we need diverse inputs when responding to complexity.” The authors suggest that learning should be valued over order and structure. This does not mean that order is unnecessary, but that any order that is established should be viewed as temporary – a framework to serve as the basis for new learning.
6: “Action is valuable under conditions of complexity.” Acting, learning, and adjusting is more effective and more productive than trying to identify the right solution, plan it, and then do it. Action builds identity and creates meaning; “the most useful information is contextual and need-driven.”
7: “The focus is properly on small forces and how they affect complex systems.” The authors suggest that focusing on small wins and keeping things simple is a strategy for success. I love the following story that they describe, so I have to include it here:
Snowden relates a story of two software development groups – one expert, the other a lesser group – whose experience in programming was limited to the fairly routine requirements of payroll systems. In a competitive exercise between these two groups for learning purposes, the experts created a plan for an elegant piece of code that would take two months to develop. The payroll programmers, meanwhile, downloaded a “good enough” list from the Internet that cost five dollars (Snowden, 1999). Thus one feature for smallness for Snowden is the decisions that can be made that allow the group to move on – to accept “good enough,” implement it, and then see what that action means.
8: “It is important to understand the irony of bureaucratic control.” Producing data and information can be overwhelming; innovative achievements can be suffocated by measurement, evaluation and control. We assume that organizations are deterministic and behavior can be programmed, using carrots and sticks. But people are neither rational nor linear, and this can be both the strength of the organization and its Achilles heel.
New organizational models are needed to be able to follow this advice. So many of the projects I see today are like solving mysteries: you know what needs to happen (because you have requirements documents), there are motivated people all around you who really want the mystery solved, someone is footing the bill (at least for a while), and everyone wants to make progress. But because the process is full of learning new information, finding clues, and relating to people’s needs – it’s impossible to put a timeline on it. This frustrates project managers (and their bosses) immensely, because their jobs revolve around bringing some order to complexity and setting expectations in terms of time and budget.
Can you imagine a crime show like Law & Order starting out with a murder – and then you cut to the scene where the police chief says: “We need to solve this murder immediately… all the clues need to be found by next Friday, all the suspects interviewed by the following Wednesday, and then I want a report on my desk with the solution three weeks from today!”
It sounds funny, but this is exactly what plenty of managers are trying to do right now in their own organizations. The “corporate consciousness” will support this kind of behavior until a rational alternative is found.
I remember a few years ago hearing about a study that claimed using Microsoft PowerPoint makes you dumb. On the basis that effective communication can either enhance or hinder quality improvement efforts, I decided to look back today and see a) where that information came from, and b) if it’s accurate. Given that over 400 million people used PowerPoint in 2003, the number of people who use it today (or other comparable presentation software, like OpenOffice) is probably even larger.
”It is easy to understand how a senior manager might read this PowerPoint slide and not realize that it addresses a life-threatening situation,” the [NASA] board [reviewing the project] sternly noted.
My advice would be for senior managers preparing these presentations to communicate more deliberately, in words like “THIS IS A LIFE-THREATENING CONDITION!! IMMEDIATE ACTION REQUIRED!!” Unfortunately, that might be perceived as “too easy” or alternatively, the senior managers might not have wanted to admit a problem for fear that they would lose their funding. In any case, respect for human life should come above all, and should certainly be a reason for bare, clear communication – regardless of whether the message is delivered by PowerPoint, in person, or as part of a 40-lb., 500-page treatise.
Ultimately, Tufte concluded, PowerPoint is infused with ”an attitude of commercialism that turns everything into a sales pitch.”
I would think that the burden of communication is on the communicator. There are many times where we only have a few minutes or an hour to convey a complex message, and for this, PowerPoint can be effective. However, if there’s a message that cannot be conveyed in simple terms, it’s up to the communicator to say so, and in really simple language, e.g. “this is a grave concern, and you need to review the complete report, now!” Easier said than done, I know.
But a far more complete review of the Tufte brochure at http://contactsheet.org notes that Tufte specifically argues against this position, noting that communicators are just victims of the product’s lack of user-centered design. Is the criticism of PowerPoint accurate? Possibly – I didn’t read the in-depth study so I don’t have a reason to believe or disbelieve the causal link between PowerPoint and stupidity. However, the recommendation ignores one critical element: that if the material is indeed comprehensively described in a much larger memo, people may or may not read and comprehend it.
However, let’s say you’re a patient in the hospital facing a life or death diagnosis, and a team of physicians is charged with solving your mystery. Do you want them making a decision based on the PowerPoint version of your case, or on all 800 pages of your medical history? Personally, I’d vote for the latter.But I would also insist that the medical team be given appropriate time to review, internalize, and reflect on the information before making a decision. This is a step that unfortunately has become a luxury in many organizations! Bottom line – the burden still remains with the communicator for now.
Buss (2006) doesn’t argue with the premise, and just writes about ways to use PowerPoint effectively. His article provides five tips from a professor in the Graduate School of Business at SUNY Albany. Starting with the premise that PowerPoint is ubiquitous in training sessions and presentations, the author first recommends that we subvert the linear “title and text” format that everyone is accustomed to because it does not capture peoples’ attention. Though this point is a sweeping generalization that is not substantiated, one opinion of the author is to remedy the situation by “switch[ing] the display order of the presentation. Present supporting data with points on the first slide and show the data and draw the conclusions on the next.” He also suggests that PowerPoint first be used to outline a message, and then a report should be written to expound upon the details, rather than the other way around. Buss also recommends to keep the information per slide short (though he does not suggest a “good” length for training slides), and provides the clichéd guidance that one should not merely read out his or her slides. The best advice is given in the author’s fifth point, where he recognizes that the presentation begins well before you start talking, and ends until your meeting is over. He suggests that the presenter mix with the audience to get a sense of their needs, and target those needs in the spoken presentation.