Are PM's in the Services or Experience business?

I recently read The Experience Economy after hearing Tom Peters refer to it in an old speech of his I try to listen to annually. The book talks about progressing from selling commodities, to products, to services, to experiences, and ultimately to transformations. One of the things that struck me was the notion of what you leave behind or what does the customer/client get to keep or come away with after the transaction. With goods they obviously get to take home the item they purchased. With services it can be s a bit tricky. Maybe they get a new haircut or a fixed car. When you buy an experience you take with you a memory (say of your Disney vacation) or a new skill (like a certification). After a transformation you walk away with a new outlook or a new organization.

It got me thinking. As a consultant coming in to manage a portfolio of projects for a client, what business am I really in? Frankly I think I've framed what I do as being in the services business. My client gets projects done well, on time, and within budget. My firm bills for the hours I work. I get paid. Services rendered.

Hmmm. What if I wanted to be in the experience business instead?

So now I still manage a portfolio of IT projects on time and within budget. But with my new paradigm I've started to also spend focused time with the business analysts, project leads, vendors, and the executives I work with slowing down a bit and training them on various aspects of what I do for them. I'm leaving behind useful skills in the organization and in their partners that will allow my client to analyze situations, manage projects, lead changes, and do a number of other related things they may not have been able to do before. I want my clients to have the memory of being part of a well-oiled team working toward something that matters. In short, I want them to think back on this time as me having orchestrated a great experience they were fortunate to be a part of--not just as someone who managed a bunch of projects.

This is something I continue to work on. The next step is to create transformations through my consulting.

What business are you in?

Managing vendors is a lot like house cleaning

My wife and I are teaching my teenager how to really clean a house. We've been kind of teaching him for a long time, but now we've really got our sleeves rolled up and are taking this seriously. My first step? Go back and watch Don Aslett's video (literally, a VHS tape) Is There Life After Housework and review one of his books. My next step was to try out what I was about to teach.

One of the tips that stuck out for me from Mr. Aslett was the simple idea of doing a little cleaning every day instead of leaving all the cleaning for one big multi-hour cleaning session on Saturday. For instance, I bought one of those plastic cleaning caddies, put all the necessary cleaners in it, and keep it in my bathroom instead of under the sink and on various shelves in the laundry room. Each day before I shower I take two minutes and clean something. On Monday, I might clean the mirror. On Tuesday, wipe down the sink, etc. Doing it this way means the bathroom never gets too far out of whack and I don't even notice the time it takes.

Managing vendors in a software project can be very similar. If you bite off huge amounts of functionality in contracts or task orders with delivery dates way off in the future, and one big demo scheduled at the end you're asking for trouble. Every vendor can bill you like clockwork for hours they burned over the past month (or two, or three). They can even itemize exactly what part of the code they worked on for each hour. But not every vendor can actually DELIVER, get something actually coded, tested, done, and ready for prime time. Some can't handle the pressure.

So part of your job as a PM is to find out which kind of vendor you're dealing with: a burn hours and bill and bill and bill vendor or a focus and deliver vendor. The best way to know is to give them a small piece of work with a deadline and hold their feet to the fire. If you're dealing with a burn and bill vendor, you want to know that pronto so you cut your losses and move on.

The well known consultant Ram Charan refers to "operating mechanisms" in his book Know Hows (which I just finished and enjoyed). Jack Welch described an operating system he developed at GE in Straight From the Gut. Each of these experts is describing a series of meetings, training programs, and retreats scheduled throughout the year on regular intervals where various parts of the business are analyzed or dealt with. In other words, they clean a little bit of the organization every day or week or month so it never has a chance to get too far off track.

After you've had your kick-off meeting and have the project charter or user stories in hand, the PM needs to do the same thing: put an operating system in place. This may mean daily stand-ups with on-site employees and contractors, weekly GoToMeetings/WebEx calls with off-site vendors and remote teams, weekly status reports out to project sponsors, and monthly higher-level project portfolio reports to management. Each PM will work out what works best for her/his situation. The point is not what your operating system looks like; the point is that you have one and that the feedback you're asking for is more than just "did you bill some hours last cycle?" Of course they did. When dealing with vendors, you obviously need to address general scope, schedule, and budget issues, but you specifically need to know if they produced their agreed-upon deliverable for this specific iteration or not.

So keep some Windex handy in the bathroom and your vendor's direct line on speed dial.

Making software smarter sometimes pushes customers away

A colleague and I were talking about how MS Project tries to anticipate, intuit, and proactively rearrange your project plans for you--and how often this goes wrong and just ends up frustrating us to the point of doing what we were doing at the time: looking at a simple gantt chart I'd built and shared with her on a competitor's product (in this case smartsheet.)

We have to be careful about how we try to make software "smarter". Done wrong, we can make the user feel too dumb to use it and drive them away.

37signals is famous for (among many other things) their approach of deliberately trying to "underwhelm" the competition by doing less, saying no to most feature requests, and keeping things so simple, so clear, so easy-to-use, so mission-focused that it does its job REALLY well and that's it.

Think about your phone. I was talking with a gentleman the other day who'd just bought a smartphone and realized after a week it was way too much for him; he was complaining about how hard it was to find a phone that was literally just a phone.

It's okay to put all kinds of sophisticated intelligence in our software. Enterprise-class problems are complex and require a solution that fully addresses each need. But we need to keep in mind the old Naisbitt idea of High Tech/High Touch and ensure we spend at least as much brain power on making it usable and friction-free. "Smart" shouldn't just mean logic and rules and number crunching on the back-end; it should mean we've arrived at the simplicity on the far side of complexity in our interface. Sometimes it just means let me do it myself, thank you very much.

How iPods in cars is like process improvement

I have a 15-year-old son who is also a talented musician. Whenever he's in the minivan he assumes he's in charge of the sound system and grabs the long cord we have plugged into our auxiliary port, plugs it into his ever-present iPod, and begins blaring Led Zeppelin or Pink Floyd (fortunately he has good taste!). Now I like loud music from time-to-time, but not ALL the time like he does. So we play this little game where he slowly cranks up the volume on his iPod and I slowly notch it down via the volume controls on the steering wheel.

Process improvement is a lot like that.

It used to puzzle me to no end how I could go into a given functional area, reduce the required man-hours to process a given widget from dozens or hundreds down to a handful, and then watch as no discernable impacts made it to the bottom line--or even downstream! Then I discovered the Theory of Constraints (TOC). Now I know it's all about the iPod example.

TOC teaches us to think systemically and see the organization as a whole. It then gives you the lens to see that the parts that make up the whole come in two flavors: those that have a capacity equal to or greater than the demands placed upon them, and those with a capacity less than their respective demands. Then, you're able to look at the latter group and find the bottleneck, the constraint.

If you improve the throughput of a resource upstream or downstream of a bottleneck it's like you've just turned the volume up on the iPod but then the bottleneck turns it back down on the radio dial; it cancels out the benefit. In fact, improving the throughput upstream could actually be making things worse--you're just building the pile of work in front of the constraint higher faster.

The Integrated TOC/Lean/Six Sigma (iTLS) approach most notably outlined by Robert Fox in his new book (as well as by others such as the book Velocity) uses TOC as a focusing mechanism to first see where should we focus our improvement efforts. Then we can bring in Lean to reduce waste, Six Sigma to reduce variability, and technology to automate and streamline (maybe that should be changed to iPIT for Integrated Process Improvements and Technology? Or maybe TiP for Technology integrated with Processes?) . Taking this approach gives you the comfort of knowing anything you do will have an immediate systemic effect and that someone else doesn't have their hand on the volume control downstream.

Lessons in business analysis from MS Courier

I'm just as excited as the next IT gadget geek to see what Microsoft releases with its upcoming dual screen Courier Digital Journal. But rather than speculate on what features it may or may not have, I want to pause to observe something about the preliminary videos we're seeing pop up--particularly the ones found on engadget.

Watch the videos, and even without sound you get it. You know what this device should do. You have a good idea of who it's for. How many pages of written requirements would it take to convey all the information you just received from this short video?

Watch Joe Levine's TED talk on a proposed mission to Mars and you come to the same conclusion: in a few minutes of video you find yourself saying that's possible. You are previewing the future. It's a simulation, but somehow tangible at the same time. How many words would it take to convey the same information? And how long would that take to digest?

I've spent a lot of years writing requirements documents for software and technology projects. They still have their place. But what is the single most important skill for business analysts of today and tomorrow? Film making.

Lessons from West Coast Customs (Part One)

I don't get to watch much TV, but when I do, I enjoy the show West Coast Customs. I love watching craftsman of any kind bring their considerable skill and creativity to a new project that has its own unique requirements and constraints. There is so much to learn about project management from this show.

The point I'd like to make today is how important one word can be: what they call their final deadline.

But for those who are not familiar with the program, essentially people bring their (often very expensive) vehicles to West Coast Customs to have them customized in some way--they are definitely one-of-a-kind when they drive away. The customer drops it off, West Coast works on them, the customer comes back to see how it looks and to pick it up. The show documents the steps, the challenges, and the process to get from drop-off to pick-up.

Everyone in the shop calls the final deadline for the project "The Reveal" knowing the customer will be at the shop on a given day to see and pick up her/his car--and they will want something truly amazing.

I like to encourage my clients to use a lot of outside vendors in the projects I manage for them. When I'm setting up the ground rules for a new vendor relationship I like to schedule a weekly status update call where we get on GoToMeeting or a similar product and talk about what was accomplished last week and what we'd like to get done the coming week. We talk about priorities, who is responsible for what, any internal pressures we need to consider, etc. Most importantly, we ask the vendor to be prepared with an on-screen demo of what they accomplished last week.

This helps keep the vendor focused and on track in several ways. It also helps them remember we're business users and often only see tangible business value through interacting with an interface--coming back with a demo of a bunch of database tables or infrastructure they built without tying it to some button we can push to make something happen makes for an awkward phone call that usually doesn't happen again.

I think I'm going to start calling the weekly calls "Reveals" instead of status updates.

(Note: I will now also require all current and future vendors to read this blog post [and watch one episode of the show?] before we begin working together.)

From Backlog to WIP Part One

So let's assume you've been following my recent blog posts and have put in place a "Three Column Planning" or "TCP" system as I've outlined. You've got a growing list of things you could work on (your "Backlog" or "Project Pool"), a nice tidy list of what you're actively working on (your "Work in Process" or "WIP"), and you're starting to see a steady stream of items hit the "Done" column. Today I'd like to touch upon when you should move something from your Backlog or Pool into your "WIP".

The first thing to keep in mind is that this is a business decision. In my prior blogs I've talked about "drive-bys" where the VP of a given division pops his head into your office on his way to a meeting and drops an IT project on your desk in a high-level 20-30 second description. If you've implemented the TCP system appropriately, these encounters are very different now and the VP's dropping by are very clear all they are doing is giving you a head's up and not putting something directly into your WIP.

So the first step is to give your internal clients a good sense of your capacity and how much of it is dedicated to "keeping the lights on" and how much can be deployed to new projects--your reserve capacity. In most cases, it becomes clear you and your team can't do everything anyone in the organization can think up right now. Some things will need to wait. Others might not happen at all. Priorities need to emerge.

Too often this process is delegated to the IT Director or CIO/CTO along with project execution. When business unit managers/VP's/members of the Executive Team can come up with an idea and dump it on IT without having to think through and articulate the business value this new IT widget will provide, the opportunity cost of doing this instead of some other Executive's pet project, the budget and other resource implications, etc. it just means someone else has to because you can't do everything. Usually this means the IT Director spends time trying to read minds and keep everyone happy. I suggest that's too much to ask of an IT Director or CTO. I suggest these are questions that need vetting by the Leadership Team. Peers need to work together to share a finite amount of IT resources and to prioritize according to what's best for the enterprise--not necessarily for their division.

In an upcoming blog post I'll describe the process I've implemented with my clients that seems to work well. As a preview, it involves getting all stakeholders around a table or some online collaborative workspace to weigh proposals next to one another. For today, I just want to make the point that the IT Director or CIO/CTO should certainly have a seat at the table, but they shouldn't be driving the boat on this yet. That comes after the next step when the business is clear on what IT initiative we should be working on right now.

Just Add Water

So I'm in the grocery store looking for some household cleaner and come across Arm & Hammer's Essentials. At first glance it looks like they are selling an empty bottle.

Then I notice the tiny little extra bottle attached to the empty one that apparently contains the real cleaning agent. It dawns on me that all the other "full" bottles on the shelf are trying to sell me water. Hmmm.

I would imagine this product (although not a new idea, really) kind of upsets the apple cart in the cleaning solution industry. It changes the game and makes all the other guys look bad. I may be wrong, but I'd think selling water + special sauce is fairly profitable vs selling just your concentrate. But it was bound to happen. Better to be the first one in than play catch up on this.

So here's a company that deliberately put out a product that would cannibalize its profits. But it positions itself as the brand that's on the side of the consumer--not other cleaning solution suppliers--and that's significant. Customer trust and loyalty go way up. And there's now kind of a dark cloud floating over other "full bottle" brands that wasn't there a few moments before. But the point is that the consumer still ultimately gets a full bottle of cleaner--but cheaper.

It made me think about some advice I got early on as a new consultant: a good consultant comes in and solves a problem. A great consultant comes in, solves a problem, but does it in such a way that she/he teaches you how to solve part or all of that problem on your own in the future. There will probably always be some special sauce that you have as a consultant that your client will not--even if it's just the perspective you have that comes from dealing with multiple clients across many industries over several years or the skill or "touch" you've built up over time that can't be faked (watch a good drywall guy and you'll know what I mean).

So here's the takeaway:

1. If you're a business using outside consultants, ask yourself if she/he is leaving behind some capability with your internal people. If not, find another consultant.
2. If you're a consultant, ask yourself what is something that you do that you charge for that you could transmit to your client over time and start letting them add their own water.

Imagine a plumber or an electrician that comes to your house to fix a problem, but rather than just diving in and taking care of the issue while you're off checking email or something, they offer to show you how to fix it so you can save a $100 trip charge if that problem ever comes up again. In my book, just the offer would be enough for me to designate that person my plumber or electrician for life.

Jason Fried from 37signals has been talking about similar ideas for a while now. I'd encourage you to watch or listen to as much of his content as you can. And just boil your service offering down to its essentials.

We're All in the "Done" Business

In prior posts I've talked about the idea I got from Allistair Cockburn which I now call Three Column Planning. I proposed that the "Done" column is the one that really matters. I've received some push back on this notion from some--citing having multiple irons in the fire shows how busy we are and that we're productive.

Suppose you were the new sales manager for a paper company in say...Scranton, PA. You could send your sales team to every parking lot of every grocery store in town making sure a flyer about your paper made it on every windshield. Heck, by doing this you've even given all those prospects a product sample, right? You could even coordinate an intranet-based staff calendar where you send your staff back at different times of day in order to try to maximize the number of people you're likely to reach. You could bring your staff members who have some desktop publishing experience together to create two or three versions of the flyer so you could do multivariate testing analysis on what works best. You could create a war room covered with printed Google maps showing aerial views of local strip malls and place neatly prepared color-coded push pins to show which sales associate is assigned to which area. And you could hold training sessions in the company parking lot on the proper way to lift wiper blades so as not to set off car alarms and at what angle you should place the paper to get maximum notice from the driver. All of this could keep you and your staff super busy. Just think of the meetings you could create around this.

As your turn comes in the Monday morning staff meeting you could pull up a PowerPoint showing both cumulatively and by week how many reams of paper you've been through (where the bars in the bar chart are actual stacks of paper [clever, I know!]), show pie charts of parking lot penetration, and even submit expense reports for all the shoe soles that now need repair.

But quite obviously, that's not what the CEO wants to hear. She wants to know if the sales team sold anything.

This goes back to the old adage of not confusing being busy with being productive. When you focus on the "Done" column you get focused. You notice what's working or not and modify your approach. You invite the other father who showed up at the cub scout meeting last week to play golf remembering he's at a decent-sized law firm in town (that goes through lots and lots of paper). You adapt. You evolve. Quickly.

When you focus on the "WIP" or "Work in Process" column, you wind up doing what Dewey Tobias used to call "majoring in minor things" and creating ribbons for who posted the most flyers this week. In sales, it's easy to see the scoreboard. But I submit we're all in the "Done" business--regardless of what we do. We're paid to get things to the finish line. And the smart one's watch carefully what got them there and make sure they start spending increasing amounts of time on those things; they let the other things fall by the wayside for those who see the world through the "WIP" lens to do.

This is one of the central themes of Brian Tracy's Eat That Frog and the popular Tim Ferriss book The 4-Hour Work week. It's what Larry Bossidy and Ram Charan talked about in Execution: The Discipline of Getting Things Done. And it's the theme of the Covey seminar called Focus.

There are two mindsets. I'm convinced the "Done" paradigm is the perspective of true leaders. The "WIP" mindset makes for a great sitcom.

Spening Too Much Time on the Backlog

Spending Too Much Time on the Backlog
brought to you by Livescribe

Books mentioned at UTC CTO P2P Forum

I mentioned two books at the recent UTC CTO P2P Forum--both from the company 37signals:

The first is Rework which just came out and is already a bestseller. This is more focused on running a business.

The second is Getting Real which is their first book and talks primarily about how they build software. You'll find Agile principles all throughout both books. Enjoy!

Two vs Three Column Planning

Two_vs_Three_Column_Planning
brought to you by Livescribe

Agile and Critical Chain Similarities

In my previous post I shared slides from my recent remarks at the Utah Technology Council CTO P2P Forum. I used a three column planning model with "Backlog" on the left, "Work in Process" or "WIP" in the center, and "Done" on the right.

One of the principles I outlined was to keep the WIP column "clean" so when project work comes in, all (or at least sufficient) resources are deployed to get it completed ASAP. I mentioned that too often we load up the WIP column with as many projects as humanly possible thinking that's a virtue. Author, speaker, and consultant Alistair Cockburn who taught me this model believed (as do I) that getting things to the "Done" column is what really matters--not how many plates we can keep spinning. How many staff meetings have you sat through where the PM essentially itemized the baby steps he's taken with all 23 projects he's juggling but he has nothing to demo, nothing Done!

I was watching a video, recently, of a speech author, speaker and consultant Lawrence Leach gave at the 2009 Continuous Process Improvement Conference. He pointed out how counterintuitive two tenants of Critical Chain Project Management are:

1. Waiting to start some projects actually helps them get done faster; and
2. Reducing the WIP increases overall project throughput

Obviously, Agile and TOC have some very similar philosophical roots. One of the first principles of Lean Project Mgt (LPM) and even Covey's Four Disciplines of Execution is to provide those you manage with the luxury of clear focus. Tell them that for a given period of time they can just put their attention on this module, this problem, this functionality and at the end of that period of time we'll be demonstrating it live in production to a client.

This principle works for a number of reasons which I might attempt to enumerate in a future blog post, but suffice it to say, when you provide clear focus on who needs to get what done by when, and you give your folks a transparent scoreboard where everyone can see how everyone is doing, things get done. When you tell your team to work on these 12 "priorities" all at once, you paralyze them and create what David Allen calls a rapid refocusing nightmare for them.

I'd like to clarify (as they do in the Four Disciplines seminar) that this principle applies to each team or resource in an organization. If an enterprise has a dozen teams, it will have a dozen or more projects in its collective WIP. But if you were to ask a given team what they are working on, their three columns are very clear--with only one or two items in WIP.

I'll post another time about what happens when an organization tries to matrix individuals to multiple teams and implement this model (hint: not pretty). I'll also post in the future about how giving each team a secondary item and sometimes even a third relates to the "buffer" concept in TOC production theory.

#UTCAgile Presentation

First, thank you to everyone at the UTC who invited me to speak alongside with Chris Marsh at the recent CTO P2P Forum on March 12th.

Second, my thanks to Chris Marsh for being such a pro about collaborating and presenting.

I think we posted eight or nine topics we could speak on when we started. I have not seen the final list, but by the time everyone posted their own topic areas I'd guess we'd have about 20 or so. And I think we only covered two or possibly three areas in the time we had. If you'd like to do another session to cover additional topics please contact the UTC and let them know. In the mean time, I thought I'd post the slides I used to cover the first topic:

You'll recall this topic related to what to do when multiple stakeholders (e.g., divisions within an organization) need to use the same IT resources.

I sincerely hope Chris and I are invited back. But if not, I intend to cover some or all of the topics you posted that we didn't cover here. More to come...

Gift wrapping tip for golfers

If you're like me, you keep your putter or two in your home office with a decent home putting machine. I just realized golf clubs are perfect for holding the wrapping paper down as you're trying to cut it to size.

Agile Project Management and Golf

I've just had two similar experiences: one working with a vendor on a software development project and another working with some of my wife's staff on setting up some hardware and software. In each case, what they considered "done" is not what I would call "done" and it's caused some problems.

In an agile approach, you bite off a piece of work for a given amount of time (a sprint), design it, build it, test it, make sure the user interface is complete, and that all the code is in a production environment. In other words, you deliver something that provides immediate business value. On the software development project referenced above, the vendor would come back with most of the code working, most of the user interface done, some system testing accomplished, and the code would still be in a development environment. They would take the approach that they had some "tweaks" to wrap some things up but "we get the idea...".

I tried to relate this to playing golf. Suppose you're on a 450 yard hole. The approach above would be analogous to hitting a 250 yard drive, then maybe a 185 yard shot from the fairway to put you within striking distance of the green, and then picking up your ball and walking to the next hole saying you got close enough. Looking at it from the distance perspective, 435 yards is obviously 97 percent of the way there. But depending upon how well you execute, those last 15 yards could take a chip onto the green and into the hole (if you are really good or really lucky), or multiple chips and multiple putts. From the number of strokes perspective, being 15 yards out could mean you're two-thirds of the way there at best or maybe even only one third of the way there if it takes you two more chips and two more putts.

The point is, you've got to do the detail work to get the ball into the hole before you move to the next hole. We don't play all the big driver and fairway woods shots for the whole course and then go back and do all of our short game work. I think project management works best when you play it the same way.

Software is like Tic-Tac-Toe

We just taught our three-year-old son how to play tic-tac-toe. I was in the beginning stages of the very lengthy porcess of putting him to bed the other night, and we were taking turns drawing on a little refreshable drawing pad when I drew a tic-tac-toe board. We played a few games. Then it was his turn to draw and he decided to draw a "better" tic-tac-toe board with more lines on the playing board so you would have to get five in-a-row to win instead of three. I chuckled because I remembered doing the same thing as a kid. But it occurred to me that traditional tic-tac-toe where three in-a-row wins was, in fact, the best (and maybe only really usable) version of the game. There is an optimal point where you hit "enough" and putting more complexity into the game makes it worse and sometimes not even worth trying to play.

The company 37signals has been an advocate of this same idea in software for some time: a given application should be about getting certain things done. The developers should find the easiest, fastest, most intuitive way to do just that and stop. Adding more lines (in this case, lines of code) to the game does not make it better. It buries the core functionality so that the software becomes too complicated, too hard to find the function you need in all the drop down menus, too much of a hassle. And we wonder why user adoption is so hard. I think the winners are those, like 37signals, who find that point of "enough" on the curve and deliberately stop while they can.

24 is Agile

The director speaking in a short film from the bonus DVD of Season 2 of 24:

In that 12 hours I gotta figure out how I'm gonna achieve everything I need to achieve in blocks of two hours and three hours. We do what's called a timeline, and we give ourselves a certain amount of hours to work on every scene. And we need to try to get to those hours to make our day--to stay within our 12 hours of shooting time.

Then as the day goes on you're constantly changing--things aren't working out, you look for a shorter way. A sort of more economic way to shoot a scene.

Keifer Sutherland speaking in the same short film:

When you actually put something on its feet, logic issues will come with the physicality of the scene that might not come up when you're simply reading it. Stuff hopefully is continually changing until the very last moment until we shoot it, and I think your ability to adapt in those specific situations and certainly adapt at speed in many cases is the difference between your ability to do something well and not.

The genius of Ken Burns

I've just finished watching the Ken Burns film Thomas Jefferson. In my mind, Mr. Burns is the preiminent historical documentarian. In the special features section of the DVD I found two short films on him and his work. Here are some notable excerpts:

Listen to the photos
One of Mr. Burns' trademarks is taking a still photo and either zooming in or out or panning across it in some way while the viewer hears an audio track. It's now even called the "Ken Burns effect" in filming jargon. There's a whole lesson in just this point on embracing constraints (see a chapter on this in 37signals book). But Burns says he would stare at a photo and "listen to it." He elaborates by saying the trees in the photo had a rustling sound, the boat going by, the people walking and chatting in the background all would have been making sounds. He even goes so far as to ask, "What did the dust sound like?"

Find an emotional connection

My work is not just interested in the dry dates and facts and events of the past, but the emotional archaeology--and I call myself an emotional archaeologist--because we know that's the glue that makes these complex past events stick in our minds and in our hearts and become permanetly a part of who we are now.

This is very similar to the approach author David McCullough takes to his work.

History is

History is, not was. We're never going to change what happened...But the way we engage our questions now about it tell us who we are right now. (now quoting Harry Truman) The only thing really new is the history you don't know.

Meaning accrues
When asked about the length of his films in general and his slow, gliding shots in an era of quick frenetic cuts:

We realize that all meaning accrues in duration. The things that we are all proudest of, the work we've done, the relationships we have, accrue in duration. It's the things we've given our best attention to, and we realize in the end the only thing we have is our attention.

Think wrapping paper is a commodity? Think again...

I'm trying out some premium wrapping paper we bought off a school fund raiser. It's maybe a tad thicker than the Walgreens cheap stuff, has the snowflakes on the front, yada, yada...but wait...flip it over to start actually wrapping and what do we have here? One inch dotted gridlines are lightly printed across the whole roll. Now, even though I graduated from pre-school many years ago, I can actually cut a straight line so my packaging doesn't look like it was done by a bonobo. It's remarkable how simple and yet useful that is.