#Fail: How to Handle Failing Technology Projects

Episode Notes

Transcript

The Kennedy-Mighell Report

#Fail: How to Handle Failing Technology Projects

07/11/2017

[Music]

Intro: Web 2.0, Innovation, Trend, Collaboration, Software, Metadata… Got the world turning as fast as it can, hear how technology can help, legally speaking with two of the top legal technology experts, authors and lawyers, Dennis Kennedy and Tom Mighell. Welcome to The Kennedy-Mighell Report here on the Legal Talk Network.

Dennis Kennedy: And welcome to Episode #196 of The Kennedy-Mighell Report. I am Dennis Kennedy in St. Louis.

Tom Mighell: And I am Tom Mighell in Dallas.

Dennis Kennedy: In our last episode we probably got a little over-enthused about our interest in the possibilities of virtual reality and augmented reality. In this episode we will take a much more practical turn.

Tom and I were talking about a collaboration approach that we had tried that didn’t work out quite as well as we had hoped, that got me thinking about failed and failing tech projects and how you need to deal with them. In today’s terms that probably means #Fail or pivoting. Tom, what’s all on our agenda for this episode?

Tom Mighell: Well Dennis, in this edition of The Kennedy-Mighell Report we will indeed be trying to answer an unfortunately increasingly common question, can this tech project be saved? In our second segment we have another question from one of our listeners, keep sending those questions in. We love them.

And as usual we will finish up with our parting shots, that one tip, website, or observation that you can start to use the second that this podcast is over.

But first up, failing and/or failed technology projects, it happens from time to time of course, a project that you are working on fails for one reason or another. It’s not just technology projects, but we are a technology podcast so we are going to talk about that. We are going to talk about projects, efforts and initiatives that go wrong at some point in time and how or whether to recover from them.

Before we get started though Dennis, did you really actually just admit failure on a tech project that we were involved in?

Dennis Kennedy: Yes, I actually did, and when I did it I was surprised by the stunned silence on the phone. People always seem surprise when you acknowledge that something didn’t quite work.

And so in this case, with the Legal Technology Resource Center aboard, we tried one of these collaboration efforts using Slack, which Tom, both you and I really like and it has tons of benefits, and we were kind of looking back on the past year to see how well it had gone and sort of describe it. And I had this initial impulse to try to spin to say, well, you know, there’s some challenges, but we accomplished something and I just said, it was an utter fail.

I mean there’s just like a limited number of messages, but let’s see if we can maybe figure out what we learned from that and then just call it a fail, because that’s what it was and see whether we can take a different approach, use a different tool or whatever we do.

And that was one of the things that got me thinking about this is that, where I work and being at MasterCard and being involved in a lot of innovation efforts, people like to talk about failing fast. Sometimes people actually do that and sometimes they don’t, but there is a notion that it is — for me, that it is good and I find myself more willing to say, hey, I started something and it’s not going right, so let’s figure out whether we need to keep doing it or we need to try something different or we just have to make a change to that. So that’s what I want to talk about Tom.

And then also I think it’s worth pointing out that I do feel there’s a difference between a failed project I guess, a failing project and I think for purposes of our podcast just troubleshooting on something. So I think we want to focus on actual projects that aren’t working so well.

Tom Mighell: Right, I agree. Because the Slack effort notwithstanding, I think that that’s one of those instances where failing fast is a good thing, but I think that projects are a different item, because once you have committed to a project, once you fail, then it’s a failure, it’s not something that you can say let’s adjust or let’s try something new. It’s a failure.

Although, I am going to argue as we head down the road of what makes and what causes failed projects, I am going to probably serve as more of a devil’s advocate on some of these things to say that I think that a lot of what you may think or you may say or causes or can be causes of fails are actually salvageable. You can still salvage the project given the right people and the right attitudes.

But I think that — I agree, we want to talk kind of about when there is a technology initiative and I think that for purposes of this discussion, I am probably going to be bringing a slightly more corporate perspective to this, because I have been involved in several technology initiatives with large corporations, where they have tried to implement some type of technology tool that helps their information governance efforts. But frankly, any of the projects I think we are going to talk about in the abstract can apply to law firms of all sizes and technology projects of all sizes.

(00:05:15)

Dennis Kennedy: Yeah. So I guess Tom, what I think I — so I sort of jokingly say #Fail is kind of the way people actually describe these projects once they are in them or how they instant message each other with the hashtag and fail on the messages.

So one thing I think about for me a failed project that I have noticed is that it does seem like when you have a failing project, everybody, and I think even in their heart of hearts the person in charge who usually is the one who is willing to stick with it, knows that the projects aren’t working.

And so I think that if you can kind of pull that information out of people, you start to see that attitude, you start to see the little breakdowns and the lack of support. I think that it’s actually easier to diagnose some of these things, because there really is something close to a consensus on it in people’s heart of hearts.

I don’t know Tom, am I maybe simplifying it too much, thinking that it’s always there or it’s more like a mixed thing going on?

Tom Mighell: Well, I think it depends. I think that there are certainly lots of projects where everybody has an idea that something isn’t working or that it might be failing. But my common theme that I am going to have this whole time is, is that if a project is being run well, if it’s being managed appropriately, then those types of issues either get minimized or aren’t a factor at all, and they can be turned around so that you don’t have a particular failure.

Now, if you have a project that’s not being managed well, if you have it where you don’t have the right project leader, the right project sponsors, that’s sort of asking for trouble on the front end and that can certainly lead to that. But I really believe that with the right group you can take a lot of what appear to be causes of project failures and turn it around and make it successful or at least try to salvage part of it.

So do we want to maybe talk about some of those causes and what we think are the things that have the potential to doom a technology project?

Dennis Kennedy: Yeah. I mean I do want to touch on that. There are some other symptoms that I typically see and one of them is pretty noticeable delays and sometimes inexplicable delays, cost overruns, budget cuts, just a sort of failure for something to actually launch, cutting away features, people working around with other tools instead of using the project and just that pure lack of adoption, so a number of things that you will see out there.

So I think there are a number of causes and I guess I think that Tom, what you were saying, I think good management and communication does help on a lot of things, but sometimes you run into things that just aren’t going to work no matter how well-managed they are.

And so some of the causes that — the one I will start with is just poor project definition in the first place. And so I see this a lot of times in law, where people say we need to implement case management or document management without really figuring out what that means or what the project is or figuring out exactly what the beginning, the end of that project is or what the phases should be.

So there’s a concept out there and so I don’t think there’s great project definition and so I think it makes hard to manage those things, because in a way you are not really understanding where it is that your endpoint is.

Tom Mighell: My response to that really is that with poor definition, I think that that’s something that, you are right, there can be a failure, with the right team, with the right leadership I think that a course correction can be made. I think that you can come in and say, you know what, we didn’t really scope this the way that we needed to scope this, something is not working here, so we really need to redefine this project and do better.

A lot of these things I think can be fixed, but it’s hard, it’s not easy. It’s not something that’s like, oh, that’s an easy fix or a cheap fix. But I am going to make the argument that that’s a recoverable cause. That you can get back from that, again, given the right team, given the right people. Some of the things that I think are on your list Dennis are less recoverable, but that’s not one of them.

(00:09:52)

Dennis Kennedy: Okay. So sometimes you see something where people just made the wrong technology choice. So you are thinking, you looked at a number of options, and I think this is sort of big in the legal area, I don’t think that people understand all the options or know there are as many options as there could be in the technology that you could choose, and you choose something that’s just the wrong thing. It’s better suited for a larger firm. Maybe you really swing and miss at the ball as it’s coming in and you pick something that’s depending on something else that you don’t have or that you — it requires you to upgrade versions or upgrade hardware or do other things. So sometimes there’s just a wrong technology choice and that will lead to a downward spiral.

And then I would say variation on a poor project definition is that you sort of have a change in either the requirements that you have, the goals that you have, or maybe just have a better understanding of those requirements, and that to me will go hand in hand with the wrong technology choice.

So once you figure out what it is that you want to do as you get into a project and have a better understanding, that’s when you may recognize that you have kind of picked the wrong technology to use.

Tom Mighell: Yeah, I think the wrong technology gets you much closer to a fail that’s hard to recover from. There are a lot of projects where you get in and you figure out, this just isn’t what we wanted.

We worked with a company that needed to buy a connector that helped them connect Outlook to SharePoint and they went through three tools and it took them the better part of a year before they really finally decided on what they wanted. They just weren’t satisfied with each one of those tools.

Now, the good news is they didn’t implement all of it fully and so they were able to recover from all of that and were back on track with everything, but I think that if you get something in and it’s the wrong choice, I think that that’s much harder to recover from.

I will again make the argument that if requirements change, it will make for a longer project, it will make for a more painful project, but I think it’s still possible to recover a project by helping to refine or modify the requirements.

I mean I think that where I see projects that start to fail, where you just don’t really have a lot of control over it is on issues like budget, where we only have so much money to spend on this. It’s entirely possible to course correct on a project until you run out of budget and then everything is gone, and so that to me what I see is sort of the ultimate failure.

You still haven’t hit on what I think is the number one cause of why projects fail, but I am going to let you keep talking about it and then see if you can hit on what I think is the number one cause.

Dennis Kennedy: Okay. So I want to emphasize the point that you have been making Tom, that I think that a lot of these things that somebody might think are fails are recoverable, and so there is a notion and we will talk about it of pivoting, which is the popular term these days, where you take the learning from what’s gone wrong and actually do the recovery.

There is one I think that’s kind of interesting that’s a fail, that can be a potential winner, which is the technology itself changes over the course of the project. So as you are making — and the classic example for me is you start a project and you think it’s either going to be a software installation or a customization and then you realize that there is a cloud tool that does everything that you need that you could get started up right away and is a fraction of the cost and is a better solution.

So that original custom project, if you are able to walk away from it, is the fail, but the result of implementing a cloud tool could be a big win, and one of the better recoveries that you can do.

Tom Mighell: I think that’s true, but I think it can also work in the opposite direction, and I am going to use Microsoft as another example to this, where we were involved in a project where, again, they were trying to implement some feature of SharePoint and it was something that they really — that was a must-have requirement of the tool that they wanted to implement, and all of a sudden Microsoft made a change to the product where it was no longer possible to do what they wanted to do.

And no word from Microsoft on whether or not they were going to reinstate it or bring it back in a different format in the future, but I would argue that’s another kind of technology change that you are all in on something and then suddenly the functionality that you wanted has been yanked.

And frankly, I think that when you get a cloud tool, the possibility for yanking it becomes greater, because it’s easier to iterate on cloud tools than it is on other applications. So I think that definitely has some good potential, but you still haven’t hit on what I think is the number one answer, so I will let you keep trying.

Dennis Kennedy: Okay. So I am going to give you the rest of my list and then I am going to identify what I believe is your correct answer.

Tom Mighell: Okay.

(00:14:55)

Dennis Kennedy: So I think there can be other scope and project changes and scope creep and drift, that can definitely lead to fail.

Cost issues, either the cost goes up or the budget gets cut can really cause a problem.

And then I think you do occasionally get things where things just don’t work and you can never get them to work and you just sort of get to the 98% completed project and you can’t get the last 2% and the project fails.

But the one I think where I think you actually get the fails is where people change, and so either the person in charge of it leaves or key people leave or a new person comes in who is not committed to the project or has their own approach, and I think that people change is what can actually bring projects to a dead stop.

So that’s my best guess, Tom.

Tom Mighell: So I will agree with you that if you get the wrong person on a people change that can be a problem. If they don’t have the same mindset, if they don’t agree with the direction, then they can torpedo the project the minute that they walk in. So the hope is, is that you find somebody that’s of the same mindset and that you are also communicating well to them when they come in.

I am going to make the argument that I think that the single — the number one cause for projects to fail ultimately is a lack of buy in or consensus among all the people who need to be a part of the project, who are involved in the implementation and ultimately roll out and adoption of the project.

And I don’t mean that users don’t adopt it. I mean that, for example, an organization we worked with legal decided they wanted to have this big technology piece and it was going to help them with a lot of risk issues and they brought in a consultant to work on it and they went to IT, and IT immediately said, no, we are not going to do that. I mean they didn’t even want to talk about it. They said absolutely no, we are not going to do it, and that was pretty much a dead end. It never recovered from that.

So I think that the same thing in lots of law firms is a bunch of lawyers can’t make decisions on a technology project without having IT involved, likewise, IT can’t get involved in the same project without having lawyers involved. And so there really needs to be an idea of who is affected, should these people be on the project team, should they be consulted, should they be part of the requirements gathering that is part of all of this.

No matter what, there needs to be that communication upfront. We are going to do this, we want your input, we want your participation, we want you to invest in this and be a part of this whole process, because if that doesn’t happen, I will say from experience there are guaranteed to be some level of negative reactions down the road, even if the people pushing back are actually in favor of the change. I have seen people who push back because they weren’t included, because their voice wasn’t heard, because they felt like their opinion didn’t matter.

So that’s what I am going to argue has the potential to torpedo most, just because I have seen it happen so many times.

Dennis Kennedy: Yeah, and I think there are probably many, many examples of the one obstinate partner who has killed new technology projects at a firm, especially somebody who is a rainmaker who controls a lot of clients.

I think another side of that is losing the buy in from the people at the top. And sometimes this can be — this can happen really quickly. I was aware of a situation where new projects rolled out as part of the big announcement in front of everyone. The head of the firm makes, not just one, but two jokes kind of belittling the project and it went nowhere, and it should be the surprise of no one that it went nowhere. So those are some of the reasons.

Then the next step Tom I think is actually recognizing the problem. And so we started out with me saying that I said, hey, our Slack thing is a fail and sort of feeling there was stunned silence on the phone. So I think it’s sort of where the people actually do say, hey, there’s a problem, we need to do something about it. It’s a little bit out of the ordinary.

And I think it comes back to this sort of key question that needs to be decided at the beginning of a project and often isn’t, which is who has the responsibility for declaring a project is actually done and who has the responsibility for pulling the plug on the project. And the better definition you have of that and the engagement of that person, the more likely you are I think to be able to say, hey, we need to do something about this, get that done, and start us on the route to recovery.

So I don’t know Tom, has that been your experience as well?

Tom Mighell: Oh absolutely. I think that a project, a successful project benefits from a couple of different things in terms of recognizing the problem and taking responsibility for dealing with a potential failure.

(00:19:56)

Hopefully you’ve got a good project manager. The project managers in place, I think they are sort of that first line to be able to say, hey, I think something is going wrong. You want your project team to realize it as well, but I think the project manager is in a best position because they are following everything. They know where all the bodies are buried. They know what’s going on, and hopefully, you want them to bring that to the attention of the right people at a higher level to start getting things going, but, with the right process, with the right project process the whole team should be learning about this through the project manager sooner than later.

You’re having regular calls or regular meetings to discuss it. You have reports on it that let people know with complete transparency, not only about the current status of a project but also what are the risks, what are the problems that we might be facing right now. Things are slowing down or we’re coming up against a budget requirement or we’re not getting the agreement to the buy-in that we really need to get.

Having those issues addressed on a regular basis, really helped you to, one, identify it early, but then — which helps you either, one, fix it or two, fail fast, like you talked about, and now, I think that no project is successful without a strong project sponsor and that project sponsor — I don’t want to say, the higher the better, but I want to say that someone who has the power to command some degree of attention and support from the groups that are putting all this together, and I think that person has a dual responsibility. I think that they have the privilege of declaring victory and they have the responsibility of declaring defeat in consultation with that project team. But without a strong sponsor who can kind of lead it through, navigate through the upper echelons of the firm or the company’s power structure, but who also can make the tough decisions, and then a strong project manager to talk about the day-to-day stuff. I mean, I think those are two important pieces to making sure that even if something happens to go south, it doesn’t have to be a fatal event.

Dennis Kennedy: I see three hurdles, I think Tom will talk about like what do you do to save a project? But I think there are sort of three big hurdles that I often see, so one is the sunk cost issues. As humans it seems like we’re programmed to say, hey wait! We already spent a million dollars on this project that’s going nowhere, let’s throw like another two million dollars at it and it might not work, but we don’t want to throw away that first million dollar, so this is like how can you step back and sort of look at things and say what’s been spent is spent that just becomes a part of the cost to what becomes a successful project and if we have to go in a different direction let’s not think about that is money down the drain, that’s just part of the project.

So that sunk cost thing and there’s been a million words written about it, and psychologically it’s really difficult any organization, that’s a hurdle. The other thing is because the people involved you want to come up with approaches that allow people to save face or not lose face because of what happened before, and then can you put together whether it’s a new group or the same group, a way to cut, do a fairly objective and hard-headed analysis and make hard decisions, and I think each of those can be a hurdle and they’re probably all three present in almost every project that is failing.

So Tom, we have this failing project and how do we determine if it can be saved or better yet how it can be saved, because I think as you’re saying in many cases these are recoverable failures?

Tom Mighell: I think that the recognizing if it can be saved really depends on smart people being able to look and say, what’s the reason for this failure, what’s the root cause of it? Being able to recognize all the things that you just discussed can be potential true failures of a project, but some of those things if you recognize them in time, if you develop a plan, if you do a good cost-benefit analysis of so that you avoid having to sink more costs in and if you don’t want to, you say, well, we’re going to cut our losses right now and get out of it or it makes more sense to put a little bit more money in and make this succeed because over the long run it’ll be a lot more successful.

I think that really identifying that cause and then making, like you say, an objective determination of can we really recover from this, what we need to do to salvage this project justify the cost, the time, the effort, perhaps the stress and the anxiety of the team involved. If the answer to that is, yes, it does justify, then you move forward with it, but that’s got to be a determination of not only the project sponsor but the project manager and the team as well. It’s got to be a group decision.

(00:24:51)

Dennis Kennedy: Well, and I think the other thing is, there’s — there are books, there are podcasts, there are a bunch of articles these days and this term pivot is probably becoming ubiquitous’ disruption in its way, but pivot I think is really a useful term. So the notion is pivot, in startup companies, you start out with one project or one product you think is going to work. When it goes out to the customers they don’t like it and your business ends up turning to something that does work.

So in a way you have a fail but it’s a fail that you learn from and turn into a positive direction, and so, I think the notion of pivoting a failed project is really important psychologically and also creatively because you say, okay, so we could take this project and we can take the endpoint that we’re trying to get to and say, how can we pivot either to that endpoint that we wanted or to something better that we found is a better result and that look at it so much as is a failure, as a loss but as a learning process and that if you come out at the end better than you had hoped then the fail is a temporary thing and it’s all good.

And so, I think if you take that approach you look at the lessons that you’ve learned, and then also look at some of the things like, was it scaled too big, can you phase it, can you make it smaller? And again, the pivot notions, a lot of times companies start out with this very elaborate product and what they find the customers want is something quite simple, and so, if you looked at that — again that notion of pivot in startups I think can be really helpful and then you are going to have to figure out what’s the best way to go forward or pull off the band-aid or you are going to do it more gradual, do you need to change people to change the course, a lot of issues out there.

Tom Mighell: Yeah, well, I guess, I’m going to end this with a whimper rather than a bang. I agree with everything that you say there. I guess my only comment would be that to me the term “pivot” sounds a little bit like spin, it sounds like we’re trying to avoid the negativity associated with the failure and so we call it a pivot instead.

I know that there are many benefits to the pivot, so I’m not going to argue that, but I really think that the important things to understand when you’ve got a project that’s failing is whatever it is that you call it, recognize the issues, figure out whether those issues are surmountable issues, and if they are, then work like heck to make it work because if you’ve decided to engage in this project, chances are it’ll be a successful project. If you just do what you need to do to fix the issues it might be there.

Before we move on to our next segment, let’s take a quick break for a message from our sponsor.

[Music]

Advertiser: Looking for a process server you can trust,  HYPERLINK “http://www.ServeNow.com/”ServeNow.com is a nationwide network of local prescreened process servers. ServeNow works with the most professional process servers in the industry, connecting your firm with process servers who embrace technology, have experience with high volume serves, and understand the litigation process and rules of properly effectuating service. Find a prescreened process server today. Visit  HYPERLINK “http://www.serve-now.com/”www.serve-now.com.

[Music]

Tom Mighell: And now let’s get back to The Kennedy-Mighell Report. I’m Tom Mighell.

Dennis Kennedy: And I am Dennis Kennedy. We have another audience question for this segment, reminder that we’ve opened up a number for calling us with your questions and we really want to get your questions. Tom will give you some more details about that number at the end of the podcast.

I’ve had a few people tell me that they actually rather hear what Tom and I want to talk about and that they are concerned that maybe their questions aren’t interesting enough. Au contraire, we think that our audience is great and your question will be of interest to the whole audience, so fire away.

This episode’s question interestingly, Tom, is from a listener named Tom and deals with collaboration tools, so here we go.

Tom Mighell: Go figure.

Dennis Kennedy: I was talking to someone about collaboration tools they used and they mentioned the time zone calculator for planning conference calls. I get that the calculator might be helpful, but tell me where the other people come in? If you aren’t actually working with another person using the tool, then is it really a collaboration tool? Tom, what do you think about that?

Tom Mighell: All right, so let’s just cut to the chase here and say that the Tom that we’re talking about is this Tom that’s talking right now and that the person I was talking to is on the other side of the microphone, and we’re talking about the next edition of our collaboration book, and one of the tools that Dennis wants to mention in the book or was thinking about mentioning were the idea of time zone calculators. I think that time zone calculators are great tools. They allow you to help schedule calls with other people around the world by understanding what time it is, where everybody else is, because it’s hard to keep track of multiple time zones for multiple countries all over the world.

(00:30:12)

What I don’t agree with is that it’s a collaboration tool. I think it’s a great productivity tool. I think it’s something that you can use yourself, but for me, the definition of a collaboration tool is something that two people use together to accomplish an end goal. And I don’t see the other person using this tool to help you schedule that meeting and that was why I questioned that it’s a collaboration tool.

So now I’ll let you go ahead clearly in this segment so you could actually talk about the time zone calculator tool, so now you get to do that.

Dennis Kennedy: So interestingly I started my day early this morning with a phone call with people in Kenya and this evening before we recorded the podcast, I was on the phone with people in Singapore. So I actually find the time zone calculator is really helpful to me, and it can be really tricky to figure out times that are convenient for a lot of people.

And if you can’t get that done then it is hard to collaborate when you need to do calls. So I think if — I actually may let you win this argument, Tom, because I think that you’re right, when we think of a collaboration tool is something that you’re doing the work in, the actual collaboration tool is going to be the telephone, where the time zone calculators come in. And sort of once you kind of get a feel for what the time zones are in rough terms, then you don’t need the precise calculator unless you have a lot of people on a call.

So I may grant you that these don’t need to go into the chapter of the book that you are writing, but I do think it’s one of these great useful tools that is simple and helpful to people and scheduling. It can be really difficult in the fact that you put the extra work into finding a convenient time for everyone is something that everybody appreciates.

So you’re right, Tom, it’s a great tool, these are great tools I really like them especially if you work internationally at all, but it is a good way for us to kind of plug the upcoming book and to think sort of more philosophical what a collaboration tool might be.

Tom Mighell: I totally agree that that’s a great tool but I am also glad we got that out of the way.

Dennis Kennedy: And now it’s time for our parting shots that one tip website or observation you can use the second this podcast ends. Tom, take it away.

Tom Mighell: Okay, I think we both have podcast tips this week. The podcast tip I want to mention is the Reply All podcast. It’s a technology podcast. I may have mentioned that in the past they had just finished a series of two podcasts called Long Distance and it operates on the premise.

What if you get a call from a scam company clearly wanting to scam you, in this case saying that your iCloud account had been compromised and what if you call them and try to track them down and find out who they were? And the reporters who are part of the Reply All podcast actually did that, they actually called, they have many conversations with the scammers. They went and visited the scammers, it’s fascinating to listen to, it makes me want to actually talk to the people who call and try to scam me too. It’s called Reply All podcast and the podcast episodes are Long Distance, part 1 and 2.

Dennis Kennedy: Tom, this is kind of a really interesting parting shot from you because I just made a parting shot to the Reply All podcast because I just unsubscribed from that in the last couple of weeks, so I missed those two.

Tom Mighell: Get out of town, why did you unsubscribe to it?

Dennis Kennedy: I don’t know, it’s just like the topics just weren’t working for me. So my parting shot is as many people know that I’m a big David Allen Getting Things Done fan, and so there is a Getting Things Done podcast. I think it is quite worthwhile, but the newest one, episode #32 with Meg Edwards and Kelly Forrister is called The Better You Get.

And the idea is that it’s some tips for people who are fairly advanced. I mean, you don’t have to be that advanced, but a sort of long time advanced users of Getting Things Done. And so the focus was on the notion of projects, which can be difficult, so I mean, a project in the Getting Things Done world is something that has multiple action steps.

And so, they came with a four-step approach to help you surface things that are more projects and the idea is to get this stuff out of your head so you can work with it. And so, I just found it really useful, those things like problems, like processes and procedures, about competencies that you need to build, those sorts of things and once you kind of look at what you’re doing in those terms, I think it helps you identify that you do have some more projects out there and to capture that stuff and to turn them into things that you can work on.

(00:35:07)

The other thing they talked about is a part of Getting Things Done called the Someday/Maybe list. This is going to be esoteric if you’re not Getting Things Done user, but they had this tip to say that Someday/Maybe sort of feels like, yeah, maybe never lists and is not helpful. And so, they talked about creating lists of things that they call either incubate or on hold or some day, but not now, and these were just really useful tips to me and things that I put into place right away.

Tom Mighell: Very cool. So that wraps it up for this edition of The Kennedy-Mighell Report. Thanks for joining us on the podcast.

You can find show notes for this episode at  HYPERLINK “http://www.tkmreport.com” tkmreport.com. If you like what you hear, please subscribe to our podcast in iTunes or on the Legal Talk Network site, where you can find archives of all of our previous podcasts.

If you would like to get in touch with us, please email us at  HYPERLINK “mailto:[email protected]” [email protected] or visit us on LinkedIn, you can send us a message on LinkedIn or as Dennis mentioned before, we really love to get voicemail questions from you, our voicemail number is area code (720) 441-6820. Give us a call, leave us a message, we’ll answer your question on our podcasts.

So until the next podcast, I’m Tom Mighell.

Dennis Kennedy: And I’m Dennis Kennedy and you’ve been listening to The Kennedy-Mighell Report, a podcast on legal technology with an Internet focus. Help us out by telling a couple of your friends and colleagues about the podcast and give us a call with your tech question.

[Music]

Outro: Thanks for listening to The Kennedy-Mighell Report. Check out Dennis and Tom’s book, ‘The Lawyer’s Guide to Collaboration Tools and Technologies: Smart Ways to Work Together’ from ABA Books or Amazon, and join us every other week for another edition of The Kennedy-Mighell Report, only on the Legal Talk Network.

[Music]

Continue Reading