Larry Putnam Jr., co-chief executive officer at QSM, sits down to talk about the importance of the proposal when executing a successful project, five key questions that should be answered before any project starts, and how software estimation ties into the proposal process.
Larry Putnam Jr., co-chief executive officer at Quantitative Software Management, sits down to talk about the importance of the proposal when executing a successful project, five key questions that should be answered before any project starts, and how software estimation ties into the proposal process.
Cameron Philipp-Edmonds: All right, today we are joined by Larry Putnam Jr. of QSM. Thank you so much for joining us today, Larry.
Larry Putnam Jr.: Glad to be here.
Cameron: To start things off, can you tell us a little bit about yourself?
Larry: Sure. I've been with Quantitative Software Management, QSM, for the last 26 years. I started in 1987. My background is in management information systems, so when I came to QSM, the expectation was I was going to work in the software development part of the company building products. When I got here they said "We don't need any developers right now, we need people to sell the product." Something I was ill-equipped to do, so it took me a few years to sort of learn the business development and sales aspects of things. At that point we were a really small company, so when I did sell a new customer, I had to do all the training for that customer, I had to do all the customer support for that customer. I had to do everything.
So, over the years, I've worked in every part of QSM.
I've even done research, so as the company's grown I've sort of grown along with it. And I think that's been a really positive thing, because today when I'm interacting with QSM employees and they're talking about their challenges in their particular area, I can relate to them, because I've done their job, I know what it's all about. I think that I probably wouldn't have gotten that if I had gone to work for a larger company, because usually you tend to specialize and go along in specific career paths. That's kind of my background at QSM, and that's me.
Cameron: What exactly is your current role at QSM?
Larry: I'm currently one of three CEOs here at QSM. I'm responsible for everything that is product related. I work with our business development group, they're the market penetrators and sales component, the revenue generators. I also have a great support and training group that takes over after the sale, so they do all the training and ramp up support, and hand-holding and mentoring as the customers start to use our products and services. Then we've got a research group that spends a lot of time mining ... we've got a large historical database we've compiled over the last thirty-some odd years, and they spend a lot of time mining that data to look for trends as new technologies and methodologies come along.
Like today, everybody's using lean and agile techniques, so they're looking at that to see how does that data look, how different and similar is it to more sequential waterfall types of things. Then can our products handle measuring and estimating those types of projects, or do we need to enhance them. They feed that back into our products group for enhancements to make our solutions even better. That's kind of what I do at QSM.
Cameron: Fantastic. Today you're going to be talking to us about the importance of the proposal. To kind of get into some of those questions, in the project management field, it can be said that projects go badly about 43% of the time, while projects fail 18% of the time. Now while there are numerous reasons why this is true, you believe that a good place to remedy the situation is indeed the proposal. Why is that?
Larry: Well, I think one of the main reasons for those statistics you just cited, the troubled project statistics, and those might even be conservative based on who you're talking to. The biggest problem, or the reason for that is that projects get signed up to absolutely unrealistic costs, schedules and budgets. The earlier we can identify a high-risk project, in fact if we can do it before it's a project while it's still a proposal and before it's been approved, that's when we have the most leverage to renegotiate an alternative that might be lower risk. We've really been focused on pushing risk identification, using estimation as far back in the life cycle as we can, and the absolute earliest is before it's a project. While it's still in the proposal stage. If we can identify those guys, nothing's really locked in at that point in time. We can renegotiate, present some alternatives, and that's the point in time where you've got the most leverage to do something like that.
Cameron: Yup. OK. You kind of mentioned earlier that the 43%, the other statistic, might be a little conservative, and I tend to agree. 43% seems a little low. Why is it that even in the proposal stage, so many of these proposals kind of doom the project from the get go?
Larry: Proposals usually get submitted. In a lot of organizations, they’ve got a lot of infrastructure in place, think of a project and portfolio management system in place. So they're submitting their proposals, usually the content of those proposals might be a couple paragraphs, pretty high level description of the capabilities and the functionality that the business needs. There's usually some analysis that goes on to make sure that those are going to provide value to the business, and that they're aligned with the corporate priorities and strategic goals.
Then there's usually a financial analysis that happens, that looks at what benefit will this set of capabilities provide back to the business, and what ROI are we likely to achieve? To determine that, we have to have some notion of the schedule. When will we deliver this product and get to that benefit starting to accrue? Then we have to have a notion of cost, because that's what goes into our ROI calculation. Those things get put into the proposal. Now, think about who's putting that information in. It's a business person, it's not a technical analyst, OK? Those costs and schedules are a desired cost and schedule.
It's when maybe a business stakeholder would like to have that capability available, and maybe how much he would like to spend. It doesn't always relate to how much it's really going to cost to turn those requirements into working software. If we can identify those situations and sanity check those desired numbers, we can identify these high-risk projects before they get approved into the portfolio project stream where we're handing ... it gets approved, gets hand off to a project manager, and he now has a project where he's got a 1% probability that he's going to be able to meet the target cost and schedule. That's the world we've been living in, and that's what I think this process has the ability to change that.
Cameron: Completely unrealistic expectations.
Larry: Exactly.
Cameron: Now QSM, they've done really well here and they've defined five major questions that every company should answer and must answer to determine if they should even submit a proposal. What really are those five questions?
Larry: The first one is all about value and alignment. Again, this is what value is this capability going to provide to the business, and is it aligned with our strategic goals that have been set at a very high level in the organization.
The second two things are cost and schedule. Those are critical to the success of the project. It turns out that using a top down estimation approach, along with a modest amount of facts, and in the estimation industry we call facts historical data. Using the top down estimation approach with a little bit of historical data provides us with a very good capability to produce credible estimates back at that proposal stage.
Then we have the ability to see, do the estimates line up with what the stakeholders want? If they don't, then that's how we identify high-risk projects. Then we've got the ability to look at practical alternatives. Can we negotiate a little bit more time or a little bit more budget? Or, if those are fixed, the cost and schedule are fixed, how do we repackage the functionality, the size and scope, to fit within that time frame? We've got a whole host of alternatives, but only if we can trap it early on when those things make sense and we're not locked into a patent with unrealistic cost and schedule.
The forth thing is going to be risks. These are things that potentially will impact us on the project after it's been approved and we're proceeding on the project. The way we deal with that is, that provides ... we look at the number and magnitude of these risks, and it provides us a way that we can do some intelligent risk-buffering, so that when we're quoting a schedule and a budget to somebody, we can package in an appropriate amount of additional schedule and additional budget so that the numbers we're quoting have a higher assurance that we can deliver on those things. The more risk, the more buffer.
Finally, the last thing is are we going to have the resources to do this project, because we can have the best estimates in the world, but if I don't have the people available, what good is that doing me? Those are really the five things that we think you need to look at during the proposal evaluation and approval process.
Cameron: OK. You kind of covered why those five questions are good to be considered, but it seems like the last one, knowing if you have the right resources available at the right time, seems to have a little more weight than the others. Why is this one so pivotal?
Larry: Well, this is about demand and capacity planning, That is something that will really get you the ear of the senior people in the organization, 'cause that's what they're dealing with all the time. They're always being asked to deliver more demand with a fixed capacity. It turns out that not only can we estimate the total effort early on for a project, but we can actually estimate it down to what types of labor do I need, and when do I need them? In other words on a project, when do I need my architects? For how long? How many of them do I need? Then when are my requirements guys rolling on and rolling off, and then I need developers and testers and QA people. We can actually estimate down to that level, and what that allows us to do then is, we've got the demand for resources, then we go over to the capacity side and we say, "Do I have those people when I need them?" Either on a project basis, but we can roll that up to a portfolio, and you start to look at it maybe by quarter.
We can see that well based on how we planned this current portfolio out, we're over-allocated. If I wanted to start that many projects in the first quarter, I don't have enough architects to do it. I got to do a couple things, I either need to re-sequence the projects, where I can get the demand down below the threshold that I've got available, or I’ve got to go increase the capacity—I go hire some people. That's the type of stuff that we can do, and we can do it very early on using a top down estimation approach. As I said, that information gets you into the C level suite, 'cause that's what they're dealing with all the time.
The other thing I'll just kind of throw in on that same note, is when we go into organizations and we gather up a little of their project data and we look at them and we compare them with our industry trends, what we see in many cases is they're way over-staffing their projects. It may be for a variety of reasons, it may be because that's optimal for their vendor for profitability reasons, or whatever, but we see situations where for this project you want to use thirty-five people on this particular project, our industry data says that other people would use something more like twenty people on a project like that. Right then and there, that's fifteen people that could be made available to take on additional work. More demand. That's another thing that we can bring to the table is how do we optimize the use of the capacity we have available to take on the maximum amount of demand for the organization?
Cameron: OK, so resources is kind of the linchpin for everything else to fall in place.
Larry: Yeah.
Cameron: OK. Now this is a lot of information to take in, so let's say someone's watching this interview, and it's very informative, and they come to realize that after listening to you talk about this that their proposal and their project doesn't really meet the standard of these questions. Is there really any hope for them, and is there really any way they can salvage the project if the proposal doesn't meet these requirements?
Larry: Well, I mean knowing you have a problem is the key. You got to have an estimation approach that will let you sanity check what those schedule and cost numbers that are being thrown out. As we said, the ideal time to do that is at proposal time, because we've got the maximum flexibility to renegotiate. If don't trap the project back there and we let it get through into the development stream. There's a point of no return on projects—when whatever's going to happen is going to happen. If you've got all the functionality defined, built, integrated, and you're into your testing activities and then you find out that you have an unrealistic schedule and cost, what do you do? Not much. You're either going to deliver it all and you're going to overrun the cost and the budget, or you're going to chop functionality at the eleventh hour.
That's not a good situation, customers are expecting everything, and when they don't get it with no notice, they're not happy. Or, we short change our testing activities and we deliver a buggy product, and that's maybe even worse. The earlier we can identify and renegotiate the better, because we don't want to be in the situation where we find out when it's too late and there's nothing we can do about it.
Cameron: It's really important really to realize that there is a problem first. OK. Now let's talk a little bit about you, the CEO, the man with the plan here. QSM is really well-known as a provider of software estimation tools and services. How does software estimation tie back into the proposal process?
Larry: We've been building measurement and estimation tools for a long, long time. I would say probably over the last three to five years we've been really focusing on how do we push this farther up in the life cycle like we've been talking about. We've got a new estimation methodology, and we've even implemented it in our new web services product. It's called a feasibility estimate. It's designed to be able to produce estimates very early on, using very little information, because there's not a lot available anyway at that point in time.
It does leverage some historic data to fill in the gaps, so if we have a little bit of history, hopefully from the company, but if not, QSM has a database that they can use as a surrogate, that will support their sizing and their productivity assumptions. We can then go ahead and generate an estimate, and then compare that with whatever the business stakeholders want, to see if there's good alignment. That's a product that we brought to market that specifically addresses these challenges early on. I think by using it, hopefully we can have an impact on those troubled project statistics that we started off talking about.
Cameron: OK. Technology in the world's moving so fast today, everything's changing rapidly. You look back ten years, people didn't really even have cell phones, so how has the field really changed since your father started the company way back when?
Larry: I think it's all about the maturity of this estimation industry. Back when Larry Sr, my Father, started the company in 1978, he was a guy with a new model, it was untested unproven, so we had to spend a lot of time showing people it would work, and that the industry data that it was based on, there's none of that today. Measurement estimation's a very mature industry, it's accepted that it's a discipline companies need to have in place to reduce the risk on their projects and improve project outcomes. The challenges today aren’t about should people, the companies be adopting it. It's more about are they ready, or do the benefits of adopting it outweigh the pain of the organizational change of actually implementing it? That's more of what it's about today, not should we do it but when are we ready to do it, or when is the pain bad enough that we're going to do it?
Cameron: OK. Lastly, for the last question here, over your career at QSM, to kind of loop this back to the very beginning, you talked about how you had many roles and many jobs within the company, and you've worked with many clients. With that being said, what are the characteristics of the most successful software development organizations?
Larry: From an estimation perspective, the most successful companies that do this have very high level executive support, OK? That's critical. They see measurement and estimation as a long-term solution that's critical to managing their software investments, just like they managed the rest of their business. They understand that to get good results in this area, you've got to make investments, both in money and in people. They measure, just like they measure software improvement, they measure what they're getting out of their estimation organizations, because every year they're going to have to justify the budget that they need. They need to be showing these are the benefits that we brought to the organization.
Typical example for one of my clients is at the end of every year, they sort of compile all the estimates that they’ve done, and then they go back with a report that says, "Hey, this year we've been able to identify fifty million dollars in cost avoidance because we didn't sign up to high risk proposals." They put a dollar amount on it, and then they submit their budget request for five million dollars. They can see right away that "Hey, we're getting a good return out of what these guys do." With some of my large global system integration projects customers, it's in the hundreds of millions of dollars. That's what they have to do is not only take it seriously, understand it's a long-term thing, and have the senior executive support, but also capture the metrics that show the impact that they're having on the business, and the benefits that they're bringing to the business.
Cameron: OK. I think it's a good analogy for a successful career too, have the support, think long- term, and really measure what you're doing.
Larry: Absolutely.
Cameron: Thank you, and that actually wraps up our interview today. Once again, this was the always informative and very intellectually stimulating Larry Putnam, Jr. Thank you for joining us.
Larry: Thank you.
Larry has 21 years of experience using the Putnam-SLIM Methodology. He has participated in more than 80 estimation and oversight service engagements, and is responsible for product management of the SLIM-Suite of measurement tools and customer care programs. Since becoming the Managing Partner of Products and Customer Care, Larry has developed a new customer care program that has increased customer satisfaction levels by 50 percent and increased client license renewals by 46 percent. Larry is a member of and active participant in numerous organizations, including the Quality Assurance Institute, Software Program Managers Network, International Function Point Users Group, and International Society of Parametric Analysts. Larry has delivered more than 27 speeches at conferences on software estimation and measurement, and has trained – over a five-year period – more than 1,000 software professionals in the use of the SLIM-Suite.
