Fellow and Senior Consultant
Tim Lister is a Fellow of the Cutter Business Technology Council and Business Technology Strategies practice and a Senior Consultant with Cutter's Agile Product & Project Management practice. He is also a frequent keynoter at Cutter Summits.
Mr. Lister, who has more than 37 years of professional software development experience, consults, trains, and lectures at enterprises worldwide. He assists IT organizations in tailoring methodologies and selecting tools for software development groups to increase project productivity and product reliability, and in developing metrics to make software project efforts more predictable. He instructs in the latest methods of software systems analysis and design. Mr. Lister also serves as a panelist for the American Arbitration Association, specializing in disputes involving software and software services. He is a frequent expert witness in IT disputes.
Mr. Lister and Cutter Fellow Tom DeMarco are coauthors of the classic Peopleware: Productive Projects and Teams, now in its third edition (Addison-Wesley, 2013). They are also authors of Waltzing With Bears: Managing Risk on Software Projects (Dorset House, 2003). It draws on their work assisting organizations with IT risk management and their expertise based on analysis of scores of large system projects that ended up in litigation. In addition, Mr. Lister and Mr. DeMarco coauthored the popular Achieving Best of Class seminar as well as the course and video sequence, Controlling Software Projects: Management, Measurement, and Estimation.
Mr. Lister is co-author with colleagues Cutter Fellow DeMarco, Cutter Senior Consultants James and Suzanne Robertson, Peter Hruschka, and Steve McMenamin of the 2009 Jolt Award winner, Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior.
Mr. Lister worked at YOURDON, Inc. for eight years where he served as an executive vice president and fellow, in charge of all instructor/consultants, the technical content of all courses, and the quality of all consultations. He has authored numerous reports, Opinions, and papers for Cutter and is a frequent keynoter at industry events around the world. Mr. Lister can be reached at firstname.lastname@example.org.
Don't Get Burned -- Risk Analysis for Projects That Had To Be Done Yesterday
What trends do you see when you visit clients to do risk analysis?
One of the trends I see when visiting clients is schedule compression: "we should have had this system yesterday." The time pressure on the development team is unbelievable. One of my clients is a company that just formed in January. The director of engineering brought me in; he was hired in April, and they have a schedule that shows that the first release of their first product will be 16 October. They're planning to hire 50 software developers by the end of the year (they have 24 now). They're somehow going to deliver a very sophisticated set of Internet tools -- immediately. However, as of last week, they were still discussing requirements.
There is always conflict about schedules on critical projects. You can't sit down and prove mathematically that you can't make it, so it becomes emotional. People have a hard time realizing whether or not they can make the timeframe. The front end of the project is a bit ephemeral: we're writing down requirements, discussing things, talking about options, and so on. It seems like you're making progress (and, indeed, you are), but no one says, "You know, we're having a conversation today that should have happened three months ago." For example, I was at my new client for a requirements review, and I said, "You know, this is a really interesting conversation for May of 1999 -- but it's May of 2000. What we're talking about has no prayer of being done for October. So why don't we table this until the next release. Or, let's talk about why this has to be in the first release, and maybe we should move the release."
I know I'm doing my job when the clients come by later and say, "Thank you for saying that." It's too bad that even in healthy organizations, you can't say things like that yourself. They all know it -- but no one can say, "Hey, we're being crazy here." There's too much at stake, it's too emotional. They're going to try like hell -- and if they don't make it, they don't make it. But everyone can say, "Well, we tried like hell."
Most of the time, people don't recognize early enough that there's a very small probability everything will go smoothly on a project. By the time they admit it, their options have closed. If they said today, "Okay, we can't deliver all of this functionality by the end of the year -- but we could deliver something." That discussion has to happen right away. It can't happen in October. It's irrelevant then: you've deployed your troops, everyone is out there trying to build it, and everyone is two-thirds finished, which means you've got nothing. Risk management is about forcing the issue early to managers and senior technical staff and saying, "What are our options here? We all want to make it, but what happens if we don't?"
Have you seen companies get better at risk management?
Most organizations, especially big ones, are not going to adopt this company-wide and be effective with it. But people do learn it and practice it. For example, a project manager that learns risk techniques brings a breath of fresh air to the projects he oversees. They ask all the good questions and don't punish people for coming in with bad news; they look at options and help their team leaders think through the process. "What are our options? How can you be so confident that we're going to make it? Show me why this is a sure thing."
Sadly, most companies don't see the importance of risk management until they've been burned. I've been in some companies where I've literally said, "You're not going to do this until you get burned. I can see what's going to happen: you're going to continue to cross your fingers and roll the dice." Then a big project that really has to get done becomes a painful embarrassment or major financial loss. Then someone says, "How did this happen, and how do we make sure it doesn't happen again?"
What other trends do you see?
In the last five years or so, unless the situation absolutely demands it, organizations are loath to start huge projects with hundreds of people. They're willing to try to tackle things that are really important with smaller groups.
This is a double-edged sword, however. When you are doing projects with smaller teams, you've got to have people who are fully tooled and fully skilled. The problem is that you don't have any junior-level people learning and experiencing things so that they can become more fully skilled.
Nevertheless, working in smaller groups definitely makes things more realistic, more direct. Managing a team of six or seven folks is infinitely more workable than managing sixty or seventy. I think Kent Beck captured this kind of highly evolutionary development beautifully. His book, Extreme Programming Explained (Addison Wesley, 2000), is one of the most interesting books I've read in a while. The ideas are radical and yet so sensible. I watch people build systems, and I've built systems, and the most exciting thing is building something together. I think Beck has identified a wonderful truth in our business. We thought that we were optimizing by having everyone take their own little piece and work on it. But I think that these small, collaborative teams -- especially for projects that had to be done yesterday -- are our best hope.
Are clients open to trying this type of development?
It's a matter of culture. Some people have a hard time with it, but many people are already doing this and not acknowledging it. If you're a really good developer, you have your friends that you "work with" on the side. You say, "Could you come take a look at this?" They're supposed to be working on their bit, but they come in, and the two of you start designing your piece.
When you talk about having two people write a piece of code, most managers say, "Wait a second, that will double the cost of the code." But Beck's notion of having two people sitting together composing has a lot of validity. First of all, the quality of the product is awesome. Second, two people know the code. We always complain about how idiosyncratic systems become -- well, it's a lot easier to build a product that's understandable if two people build it together. My guess is that the expense will go the other way: it probably doesn't cost any more because of what you save in terms of testing and defects. Slapping code up and then debugging forever costs us a fortune -- we certainly know that.
What do you recommend companies do to get better at risk management?
There are two levels at which you can do risk management. The first level is within the project team. You shut the door so everyone can speak freely, and the project manager, the team leader, and the technical staff go through risk identification and do some analysis on the risks (what probabilities are there, what will it cost us if these problems do occur, etc.)
The idea is to do this as early as possible to determine things that you can do to lower the probability or lessen the costs of the problem if it hits (or a combination of both) that would be a good investment. Try to lay out sensible responses that people understand, see how they fit into the schedule, and build some monitoring mechanisms into the plan. All of this can all be done within the team, without upper management or the client knowing about it.
However, although these types of discussions can help, the realkey is to get the manager above the project manager involved. This might be the client lead or a manager in the marketing department -- someone coming at the project from a different direction who can tell you the potential problems they see. The idea is to work together early on to determine what risks you want to try to manage up front.
Ideally, you should start risk management before you define the project because it will help you define the project. Let's say there are certain features that are technically extremely difficult, and they don't necessarily give you an enormous advantage. You might decide to put them in a later release or build the feature in a way that isn't quite as elegant (maybe it doesn't handle all cases perfectly). You've made a trade-off so that you could increase your probability of a shorter delivery time, easier testing, and so on.
Risk management really starts before the project, and carries right on in -- and it's not over until the project is delivered. I have never seen a project that has gone by all it's risks and there's still work to be done. Even when you're testing, there are still lots of unknowns. You're finding problems and saying, "Do I have to fix this problem before I can ship, or do we have a workaround?" Those are risks -- not acts of God.
Learn more about bringing Timothy Lister to your organization.Contact Us