Practical Analyst

The deepest principle in human nature is the craving to be appreciated – William James

2012-08-07T18:01:40-07:00

Just a brief quote and a comment this evening to capture a thought that crossed my mind while contemplating differentiators between the great analyst and the good:

“The deepest principle in human nature is the craving to be appreciated.” – William James

Time and experience have shown me that one of the best ways to cultivate relationships of trust and mutual respect with stakeholders and team members is to actively seek out opportunities – even the small ones – to show appreciation for assistance, and acknowledgment for hard work and a job well done.

I don’t know whether being appreciative and showing gratitude is best considered a skill or a habit – it may be a little of both. It won’t likely show up in a competency assessment or a job interview, but it is a rare trait and a real differentiator, and one that I’m confident will give you (and your beneficiaries) great satisfaction as you develop it.

It really is the little things that make a big difference!

I won’t develop it much further this evening, but Heather Mylan-Mains shared another thought on Twitter that I wanted to capture here because I consider it another key differentiator between the the great and the good analyst. It stems from how we choose to react to inter-personal adversity; those real or perceived slights and mistreatments:

We choose how 2 react. No one makes us hold grudges or resentments. Choose 2 give people the benefit of the doubt today #baot & move forward

— Heather Mylan-Mains (@heatherM_M) August 7, 2012

Well said!

What are some other intangibles – traits, if not exactly “skills”, that are real difference makers? Please share them below!

The deepest principle in human nature is the craving to be appreciated – William James is a post from: Practical Analyst

Business Analysts: A Resume is a Work Sample

2012-07-19T18:15:19-07:00

Business analyst candidates often provide work samples such as documents, diagrams or presentations during the course of an interview, and I appreciate it when they do. Sample work adds credibility to the experience and skills listed on the candidate’s resume.

Often the sample work is of high quality, and casts the candidate favorably, which is no surprise, really, because for them to have been invited to interview, they will have already passed scrutiny of their first work sample – the resume they submitted upon application. I treat each candidate’s resume as a work product and hold it to many of the standards I would use to evaluate a project deliverable.

Why? A critical part of a business analyst’s job is to maximize the communicative value of documented deliverables. So to me, the resume is an example of the quality I might expect from the candidate’s written communication and documentation. And I assume that because the candidate wants the job, the resume is representative of the very best s/he can do.

Analysts should know better than anyone not to be long-winded and verbose in a resume. We all know how little our stakeholders appreciate a rambling requirements document. A business analyst candidate should know better than to use a bunch of filler/buzz words in a resume that can obscure meaning and require more effort than necessary on the part of the evaluator. A good BA resume should be clear, concise, and make it as easy as possible for the reader to glean the salient points.

Here are a few more quality checks or tips that I consider when evaluating the resume as a sample work product:

Length - I don’t have a rule of thumb on length, although I tend to reward concise resumes and penalize overly long ones. The resume is more an executive summary than a detailed report. Redundancy, and detailed accounts of what the candidate has been doing for the last 20 years show a lack of sensitivity for the reader, and for the situation.
Hyperbole and extraneous adverbs - ”expertly managed”, “collaboratively liaised”, “capably scheduled”, etc. add no value, smack of exaggeration and are best avoided.
Industry or company-specific jargon and acronyms that may not make sense to someone without additional context are inconsiderate, and take away from the communicative value of the resume.
Tailored to the role
- Always make an effort to ensure that your listed experience and qualifications are applicable to the business analyst role and, when you can, further tailor it to the the particular company or industry. This shows a sensitivity for the importance of identifying and satisfying business need.
- If you’re coming from a different role, or most of your experience is in roles other than business analysis, emphasize the points that would add value as a business analyst and leave off the ones that don’t. Experience that isn’t pertinent to the role will almost certainly not get you in the door, but being perceived as long-winded because of it will probably keep you out.

There is much more that can be said about resume evaluation (I have barely touched on content!), and other hiring managers may have slightly different requirements and evaluation criteria, but I hope you’ll consider crafting your resume as if it were a sample of your best work as a business analyst, because that is quite possibly how the hiring manager will regard it!

In a situation where a manager is evaluating a number of similarly qualified candidates, the hiring decision often comes down to the “little things” as differentiators. I hope that taking the extra time to make sure your resume is not just representative of your experience and qualifications, but of the quality of your work will make a difference for you!

Business Analysts: A Resume is a Work Sample is a post from: Practical Analyst

Business Analyst Career Talk on Jobshadow.com

2012-07-18T17:20:56-07:00

Jobshadow.com hosts a collection of interviews with various career practitioners with the goal of helping to “educate, inform and inspire” career aspirants to learn about a variety of career paths. Aaron Stahl, the site’s owner and administrator, recently invited me to provide some insight on business analysis as a career. Those who know me know I love to talk business analysis, so I was more than happy to accept!

The questions covered a range of topics (standard list provided below) and I was generally pleased with how things turned out. You’ll find, among other things:

A brief description of what a business analyst does
What a typical work week looks like
How I got started as a business analyst
What I like and dislike about business analysis
Comments on business analysis compensation
Suggested education and skill set
What is most challenging and most rewarding about a career in business analysis
Advice to people considering business analysis as a career
Common misconceptions about what business analysts do

If you’d like to learn more about business analysis as a career, I’d invite you to check out the interview and post any additional questions you may have. If you are a business analyst, please enrich the discussion by commenting with some of your own insights!

Business Analyst Career Talk on Jobshadow.com is a post from: Practical Analyst

We’re Business People First

2012-07-10T18:36:08-07:00

“We need to remember that we’re business people first.”

Those are among of the first words of wisdom imparted by my organization’s new CIO to our IT organization a few weeks ago, and they’ve been on my mind since. First, I appreciated her emphasis on business literacy throughout IT. Second, I felt some validation in that I’ve long thought that way about my own role as a business analyst/business analysis manager even though I report through the “IT side”.

Business analysis is a business role. Yes, business analysis is a business role.

It’s great to have technical skills and literacy. They give us credibility in our interactions with our solution delivery team members, and are useful in helping provide the business with an idea of what is possible or practical through technology, but business analyst is, first and always, a business role.

BAs don’t enable “IT” solutions, they implement business solutions with business value to meet business goals. Because of the ubiquity of technology in business, solutions typically include a technology component, but they are driven by a business problem and intended to produce a business benefit.

Technology, and, by extension, the IT department, is often viewed simply as a tool of the business, or even as a disconnected entity from the business. Our reporting structures often don’t do much to shake that perception.

With all that, I’ve found value in shifting my own perception of my role from a service provider to that of a partner or trusted business adviser. I try to approach my relationships with business stakeholders as a partner who brings value to the business relationship, not as a subservient or separate entity with separate motivation, and goals. I’ve found that as I approach my role in that way, my business stakeholders begin to treat me in kind.

Beyond that, the most successful business analysts I’ve known (and I know many!) are experts in business. By that, I mean expert in the generalities of what is required for business to work, and in the specifics of the business or market in which his/her company competes. They speak process and human factors with the same fluency as they talk technology and systems. Business literacy is a foundational attribute of a successful business analyst!

So if you haven’t gotten the gist of this post, let me conclude with this: Business analysis – with all the other IT or business enabling roles – is a business role.

We’re Business People First is a post from: Practical Analyst

It’s (Still) All About the Team

2012-06-06T18:13:10-07:00

I had the pleasure of chatting with EBG Consulting‘s Mary Gorman at the May Greater Atlanta IIBA chapter meeting. As we were rapping about training, methodology and the work she and Ellen Gottesdiener are doing on their upcoming book, it was mentioned that the very same core principles that worked in successful plan-driven/serial development projects (and yes, there have been many such – I’ve participated in a few myself) are the same ones that make an agile team successful, and will be the same ones that make delivery using the next big, buzzword delivery methodology successful.

Not long ago, I wrote a few thoughts on what “agile” means to the business analyst, and mentioned that, in the end, it is about adaptability. If we can learn those basic, timeless principles that make any project successful, we’ll be able to identify them and adapt more easily to any environment whether waterfall, spiral, scrum, or the next big thing.

One of those fundamental principles – and right now I’m of a mind that it may be the most important of all – is that of combining and enabling the cross-functional team.

Strip away almost all the other “stuff” associated with methodology and project overhead, and (at least in my experience) the essence of successful projects is this:

Assemble a group of smart, motivated people with the right skills to get the job done. Typically, you’ll want analysis, modeling, design, development and QA skills, and perhaps others depending on the context.
Give the team unfettered access to the business decision makers and users whose regular input and feedback are critical.
Empower the team to decide on the conventions they think they need in terms of planning/process/ceremony/division of work. In some cases process these may be more rigorous, in others less.
Ensure that the team and stakeholders have a clear and unified understanding of what “done” means, what success looks like (and how it will be measured!), and a plan for getting there.
Give the team time to work through the inevitable kinks and challenges of transforming from a group of individuals to a team. This implies enough time to establish familiarity and a sense of accountability one to another; time to gain a sense of the value and role of each individual, and time to establish a repeatable, maintainable rhythm.
Facilitate a learning environment where lessons of the past are applied, and constructive feedback a commodity that is valued and not feared.
Keep the team together and give them time to optimize performance.
Get out of the way, and let them deliver.

Regardless of the methodology you use, or what you call your requirements, if you can manage the above, you have a pretty good chance at success in any environment.

It’s (Still) All About the Team is a post from: Practical Analyst

Visual Modeling: A Critical Skill for Business Analysts

2012-05-17T20:41:26-07:00

Peter Senge in The Fifth Discipline: The Art & Practice of the Learning Organization, said that, “[a]t its simplest, a shared vision is the answer to the question, ‘What do we want to create?’”

As facilitators of knowledge exchange, tasked with helping business and delivery stakeholders reach that “shared vision”, effective use of visual models is a critical skill:

Visuals act as metaphors for our life situations, our goals, our hopes, our dreams, and our ideas. People tend to think in patterns, which are how we organize, create, and execute processes, i.e., how we get from here to there successfully. Patterns are most easily understood visually! - Dean Meyers

So what does a visual model look like? I like a description from (my all-time favorite resource on communication using visuals) Idiagram:

We don’t hold a narrow definition of exactly what a ‘visual model’ should look like: they should use whatever visual elements or styles – diagrams, maps, graphs, charts, pictures, cartoons, etc. – that will most effectively represent the problem at hand.

If you’re interested in learning more about communication using visuals, and want to check out some excellent examples of ideas portrayed visually, go spend some time poking around the Idiagram website.

As a hiring manager of business analysts, it’s been encouraging to see a general uptick (at least locally) in the proportion of candidates that can demonstrate competency visually modeling flows, mock-ups, and diagrams.

In the near future, I fear the BA that is stuck in the rut of primarily writing textual, declarative requirements is going to have a harder time competing for work. Stakeholders that have been treated to visual models have seen that there is a better, less laborious (for them) and more effective way to understand requirements than the 75 page, big, thick requirements spec.

Do you agree on the criticality of visual modeling skills to having a successful business analysis career? What are your go-to visuals? How have you developed your modeling skills? I’d love to hear your comments!

Visual Modeling: A Critical Skill for Business Analysts is a post from: Practical Analyst

I want to be a great business analyst. Help!

2012-01-12T18:02:55-08:00

Take “me” as, of course, a hypothetical example.

I think I’m a pretty decent business analyst. I have a bit of experience. I have a pretty good grasp of the fundamentals. I have a pretty good understanding of my business and industry. I’m pretty good with people and technology. I enjoy what I do. The problem is, I want to be a great business analyst.

What does it take to get to that “next level”?

Ok, as business analysts, some of you are going to respond with something like, “first of all, you have to stop using ambiguous terms like ‘great’ to describe your objective.” Well, I’m purposely vague in this case because I’d also like to know, from a group of peers (that’s you), what makes a great business analyst as well as what it takes to get there.

What are the distinguishing factors, in your opinion, between a serviceable to good BA, and a great one?

What are some common characteristics of the best business analysts you’ve ever worked with? What set them apart from the others?

I, of course, have some ideas of my own, but I’d really be interested in seeing some of your thoughts. If you’re a BA, or if you manage or work with BA’s, please take a minute to add a comment or two on what you think makes a great business analyst.

Not only will “I” benefit from your insight, but I know from my interactions with readers of this site that there are many out there who will benefit from your knowledge!

Thanks!

I want to be a great business analyst. Help! is a post from: Practical Analyst

The “Best Kept Secret” Benefit of IIBA Membership

2011-12-01T13:00:42-08:00

I’ve been an IIBA member for several years now. I think the BABOK is great resource for business analysts, and I refer to it regularly. I think the agile extension to the BABOK is shaping up to be another really useful resource. As a manager of business analysts, I love the competency model.

I plan, one day – some day – to become CBAP certified. I occasionally attend and enjoy the free webinars that IIBA provides for its members.

None of those items – useful and beneficial as they may be – is my favorite “perk” of IIBA membership, though.

In my opinion, the best kept “secret” member benefit is access to the on line library of business analysis-related publications. Of course it’s not intended to be a secret at all, but for its value, I just don’t think it gets as much pub in BA circles as I would expect. I aim to change that just a little with this post. You see, to me the library is gold. If you took away all the other benefits, access to the library alone would make the fee for IIBA membership a great bargain.

Here are some of the facts regarding the online library from the IIBA website:

[I]f you tried to purchase these works individually, it would cost you around $15,000 US. A subscription to services that provide you access to all of these works online would cost you around $700 annually. As an IIBA member, you have access to this wide selection of books for FREE! Membership in IIBA is now more valuable than ever.

The online library includes works on a large number of different topics including:

Agile methodologies and techniques

Business process modeling and management

Business rules

Data modeling

Enterprise analysis

Elicitation techniques

Structured analysis methods

UML

Underlying competencies (coaching, facilitation, decision analysis)

There are also books to support chapters and volunteers such as strategic planning for non-profits, basic financial management, event planning, running board meetings, virtual teams, and product management.

As a confessed business analysis junkie, I love to absorb all the information I can through social networking and blogs, but for concentration and development of detail on a topic, I love being able to delve into a good book.

My typical usage of the library is to scan multiple books by respected authors or on topics of particular interest to me. Of those I scan, I’ll pick a few that I think will be really interesting and delve into them in detail, taking notes and then applying and sharing key points of what I learn. The other “read later” books I am able to add to topical lists so I can refer to them at need, or when I have a few minutes to spare.

Anyway, I like to pass on great values to my fellow business analysts, and if you weren’t aware of this one already, I definitely wanted to remedy that.

If you’re already an IIBA member, but just haven’t checked out the library, here’s how navigate to it on the IIBA site: Click on “Professional Development”, then select “Online Library” from the dropdown (have a look at the picture below). That will take you to the page from which you can access the library. If you want to take a little shortcut, you can just click here!

Over the past year or so, I’ve referred to numerous books in the IIBA online library to assist with training my team members on the fundamentals, learning and improving my BA techniques, identifying potential tweaks and improvements to our team’s business analysis approach, and most recently I’ve been doing some research on establishing a community of practice and found an excellent book on that very topic in the online library.

Feel free to let me know if you have questions about the library, or about my perception of IIBA membership benefits. Also, I’d be interested in hearing your experiences and thoughts regarding the IIBA online library. Were you previously unaware of the library? Any of you others think this is as cool a deal as I do? Please feel welcome to comment below.

The “Best Kept Secret” Benefit of IIBA Membership is a post from: Practical Analyst

The Value of Small Wins (or, How to Eat an Elephant)

2011-11-21T18:29:15-08:00

I’ve been very fortunate lately to have had my company send me to receive some leadership training. I really appreciate the investment, and have been trying hard to make it worthwhile by studying and finding ways to apply what I’ve learned.

During one of our sessions, one of my favorite references, Peter Senge’s The Fifth Discipline was cited on an occasion or two. Now, I don’t want to get off topic here, but if you’re a business analyst or work with complex systems and problems, the concepts of “shared vision”, “mental modeling” and, of course, “systems thinking” covered in The Fifth Discipline are well worth your time and study.

Getting back to the topic at hand, though… As a result of the training, I picked The Fifth Discipline up again myself and started reviewing some of my highlights. One particular quote really hit home with me in a way that it hadn’t before. It is the following:

“You can get a great deal done from almost any position in an organization if you focus on small wins and you don’t mind others getting the credit.” – Roger Saillant

To me, that quote is gold. It articulates well the feeling I’ve long had about being a business analyst. While we don’t necessarily wield power of position, we are ideally suited to make a difference when we help our businesses make those incremental changes which, over time, add up to significant wins and success in the marketplace. Because we’re not the leaders in title, it is important that we also don’t mind not necessarily getting the credit.

Small Wins, Defined

So, what exactly are small wins, and why do they seem to add up as well as they do? The balance of this post will include citations and snippets from sources I’ve found valuable while studying the topic on my own. I hope you’ll find them useful, and will frequent the originating sources yourself for more information.

A small win is a concrete, complete, implemented outcome of moderate importance. By itself, one small win may seem unimportant. A series of wins at small but significant tasks, however, reveals a pattern that may attract allies, deter opponents, and lower resistance to subsequent proposals. Small wins are controllable opportunities that produce visible results.

Once a small win has been accomplished, forces are set in motion that favor another small win. When a solution is put in place, the next solvable problem often becomes more visible. This occurs because new allies bring new solutions with them and old opponents change their habits. Additional resources also flow toward winners, which means that slightly larger wins can be attempted. – Karl Weick from “Small Wins: Redefining the Scale of Social Problems,” American Psychologist, January 1984.

Why Small Wins Produce Results

What makes small wins effective? Here are a few reasonable ideas:

Small wins produce results because they form the basis for a consistent pattern of winning that attracts people who want to be allied with a successful venture. Small wins build people’s confidence and reinforce their natural desire to feel successful. Because additional resources tend to flow to winners, this means that slightly larger wins can be attempted next. A series of small wins therefore provides a foundation of stable building blocks. Each win preserves gains and makes it harder to return to preexisting conditions; each win also provides information that facilitates learning and adaptation.

Small wins produce results because they actively make people feel like winners and make it easier for others to want to go along with their requests. If people can see that a leader is asking them to do something that they’re quite capable of doing, they feel some assurance that they can be successful at the task. If people aren’t overwhelmed by a task, their energy goes into getting the job done, instead of wondering “how will we ever solve that problem?” They then have heightened interest in continuing with the journey.

Small wins produce results because they build personal and group commitment to a course of action… By working at finding all the little ways that people can succeed at doing things differently, effective leaders make people want to be involved and stay involved because they can see that what they are doing is making a difference. Small victories attract constituents, create momentum, and get people to remain on the path. - from The Leadership Challenge by James M. Kouzes and Barry Z. Posner

The Psychology of Small Wins

Part of what makes a “small wins” approach the way they can ease tension and build confidence:

Complicated issues also induce frustration, stress, and personal friction. Psychologists have shown that individuals become anxious and tense when they perceive a problem as beyond their capability to solve. People typically evaluate their skills, as well as the capabilities of the groups and organizations in which they work, and they assess whether those capabilities match the demands of a situation. If they perceive a mismatch—namely, that the demands of the situation exceed their skills and competences—they become flustered, worried, and stressed. Those emotions make it difficult to actually solve the problem and make an effective decision. Therefore, the socio-emotional challenge is to keep everyone engaged and committed to a decision process by coping effectively with these intra- and inter-personal tensions. A “small wins” approach proves effective when a problem appears overwhelming to people. As Weick writes, “A small win reduces importance (‘this is no big deal’), reduces demands (‘that’s all that needs to be done’), and raises perceived skill levels (‘I can do at least that’).” – from Why Great Leaders Don’t Take Yes for an Answer: Managing for Conflict and Consensus by Michael A. Roberto

Focusing on Small Wins can help us get “Unstuck” and Build Momentum

Developing a Small-Wins Strategy for Growth from Leading Blog tells us how to break free from the paralysis of fixation errors:

Small-wins focus on the here and now. What can we do now and what can we safely ignore or eliminate. It is an antidote to the fixation error trap. It’s easy to caught up in “everything”—the full impact of what is happening and the habits and perspectives that have become so much of who we are—that we become overwhelmed and unable to act at all. Fixation errors keep us from noticing what is really happening, separating us from reality. Reassess after each win and keep moving to build momentum.

Now, About that Elephant…

How many times have projects failed because we try to do too much all at once, and/or prematurely? We take on that 2 year initiative only to find, six months in, that the business landscape has changed in such a way that the value has decreased, or gone away entirely. So many times I’ve chided my stakeholders, project team members or even myself with the old, humorous question:

Q: How do you eat an elephant?
A: One bite at a time!

Each bite we take of the proverbial elephant represents progress – a small win – toward the larger, more significant goal.

Again, from Developing a Small-Wins Strategy for Growth from Leading Blog provides some context we can appreciate as professionals interested in providing solid business solutions:

Begin by breaking tasks and issues down in to manageable pieces; pieces that you can take responsibility for and act on now. If you are not in a position to implement this strategy on an organizational level, adopt it for your team or even individually. Lead from where you are. It’s contagious.

Dan Erwin in his post Why Small Changes Work, and Big Changes Don’t acknowledges that it really is a mind shift for most of us to exercise the discipline and diligence to go after success in “small chunks”.

Successful changes take place in small chunks. So you’re after small wins, not big ones. That’s an important change reality. You succeed on the multiplier effect of small wins. You’ll lose if your objective is too large.

I hope you’ll benefit from some of these resources the way I have, and if you have comments or other resources to add to the discussion, I hope you’ll chime in in the comments below.

The Value of Small Wins (or, How to Eat an Elephant) is a post from: Practical Analyst

Read “The Checklist Manifesto”!

2011-11-07T18:22:05-08:00

I recently bought, read, thoroughly enjoyed and am now recommending Atul Gawande’s book, “The Checklist Manifesto”. In “the manifesto”, Gawande pulls examples from the medical field, construction, aviation and others to show how simple checklists, coupled with timely and effective teamwork, can vastly improve the quality and effectiveness of what we do; in some cases, literally making the difference between life or death.

I’m sharing some teaser quotes that I bookmarked during my read of “The Checklist Manifesto” because I think they are good at conveying some of the underlying principles that solution delivery professionals will find interesting, but mostly because I think they’ll push you toward giving the book a read yourself (click on the image to purchase through Amazon). While the snippets are neat, it’s the compelling, real-life stories in the book that bring those principles to life and make it such a great read.

I’ll also include a few words of my own around why the teaser quotes are relevant to business analysts and project professionals.

The Problem

Know-how and sophistication have increased remarkably across almost all our realms of endeavor, and as a result so has our struggle to deliver on them. You see it in the frequent mistakes authorities make when hurricanes or tornadoes or other disasters hit. You see it in the 36 percent increase between 2004 and 2007 in lawsuits against attorneys for legal mistakes—the most common being simple administrative errors, like missed calendar dates and clerical screw ups, as well as errors in applying the law. You see it in flawed software design, in foreign intelligence failures, in our tottering banks—in fact, in almost any endeavor requiring mastery of complexity and of large amounts of knowledge.

Avoidable failures are common and persistent, not to mention demoralizing and frustrating, across many fields—from medicine to finance, business to government. And the reason is increasingly evident: the volume and complexity of what we know has exceeded our individual ability to deliver its benefits correctly, safely, or reliably. Knowledge has both saved us and burdened us.

Essentially, the old paradigms aren’t working when it comes to addressing the complexity of many of today’s problems. With regard to business solutions, I think we’re seeing this evidenced by our quest for “agility” and in the mind shift away from processes that attempt to handle software and systems solutions as “assembly line”-type activities.

Simple Checklists help eliminate “stupid” mistakes:

Substantial parts of what software designers, financial managers, firefighters, police officers, lawyers, and most certainly clinicians do are now too complex for them to carry out reliably from memory alone.
[Checklists] remind us of the minimum necessary steps and make them explicit. They not only offer the possibility of verification but also instill a kind of discipline of higher performance.

[P]eople can lull themselves into skipping steps even when they remember them. In complex processes, after all, certain steps don’t always matter. Perhaps the elevator controls on airplanes are usually unlocked and a check is pointless most of the time. Perhaps measuring all four vital signs uncovers a worrisome issue in only one out of fifty patients. “This has never been a problem before,” people say. Until one day it is.

I think this is the essence of the book. Basically, checklists aren’t the proverbial “silver bullet”. What they do is free us to focus on the hard, complex issues without worry of overlooking the “stupid” mistakes which can be easily overlooked when we’re trying to keep up with so many variables and dependencies in delivering solutions.

To best address problems and risks associated with complexity:

Decentralized decision making

[U]nder conditions of true complexity—where the knowledge required exceeds that of any individual and unpredictability reigns—efforts to dictate every step from the center will fail. People need room to act and adapt. Yet they cannot succeed as isolated individuals, either—that is anarchy. Instead, they require a seemingly contradictory mix of freedom and expectation—expectation to coordinate, for example, and also to measure progress toward common goals.

The philosophy is that you push the power of decision making out to the periphery and away from the center. You give people the room to adapt, based on their experience and expertise. All you ask is that they talk to one another and take responsibility. That is what works.

Think “empowered teams”. Take away almost all the other “stuff” associated with agile (or any other type of) delivery methodologies, and the essence is this: Get a group of smart, motivated people together, let them agree to whatever conventions they think they need in terms of planning/process/ceremony, and, for the most part, get out of the way and let them deliver, and you have a good chance at success.

Cross-functional collaboration and effective communication

In the face of the unknown—the always nagging uncertainty about whether, under complex circumstances, things will really be okay—the builders trusted in the power of communication. They didn’t believe in the wisdom of the single individual, of even an experienced engineer. They believed in the wisdom of the group, the wisdom of making sure that multiple pairs of eyes were on a problem and then letting the watchers decide what to do.

The examples given in the book were around the lead surgeon and the master builder; individuals who, historically, would almost, if not entirely single-handedly make and execute the key decisions with a largely subordinate cast of supporting characters.

Nowadays, complexity and super-specialization has given us circumstances where one person – even a remarkably gifted and high-performing individual – cannot possibly know enough about everything for the “single superstar” model to be sufficient anymore. That’s why we’re seeing such an emphasis on cross-functional teams of members with (largely) equal voices.

Bottom Line…

[Checklists] supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how.

Recap

As I alluded to in some of my comments above, what I found particularly interesting, are the similarities between Gawande’s recommendations around basic checklists and collaboration as a means of addressing problems of scale and complexity and the agile principles that we find becoming more and more popular for addressing the same in software/systems delivery methodology.

If you’re not sure if you want to buy the book yet, have a look at this article which served as the precursor for the book, and provides an amazing example of “checklist” principles at work.

If you’ve read the book, please share your impressions with me below. I’d love to carry on the dialog!

Read “The Checklist Manifesto”! is a post from: Practical Analyst